2005 Message-Id: Date: Thu, 30 Jun 2005 15:04:16 -0400 From: "Joel M. Halpern" Subject: Result TLV Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Thu, 30 Jun 2005 10:51:47 -0400 From: "Joel M. Halpern" Subject: Redirect Message Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 29 Jun 2005 12:01:07 +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 Sm9lbCwNCg0KPiBJIGFtIGNvbmNlcm5lZCB0aGF0IHRoaXMgYXBwcm9hY2ggd2lsbCBtYW5kYX Rl IGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgDQo+IFJlZGlyZWN0IExGQnMgZm9yIHRob3NlIEZFcy B0 aGF0IHN1cHBvcnQgbG9naWNhbCBpbnRlcmZhY2VzICg4MDIuMSBWTEFOcywgDQo+IEZyYW1lIF Jl bGF5IG9yIEFUTSBWQ3MsIGV0Yy4pICBGb3Igb3RoZXIgdXNlcywgd2UgaGF2ZSBhbGxvd2VkIH Ro YXQgDQo+IG1ldGEtZGF0YSBtYXkgYmUgdXNlZCB0byBpbmRleCBpbnRvIExGQnMgd2hpY2ggaG F2 ZSB0YWJsZXMgb2YgDQo+IGJlaGF2aW9ycy4gIChXZSBoYXZlIG5vdCBtYW5kYXRlZCB0aGF0LC Bl aXRoZXIuKQ0KPiANCj4gSXQgd291bGQgc2VlbSBieSBhbmFsb2d5IHRoYXQgd2Ugc2hvdWxkIG Fs bG93IHNpbWlsYXIgdGFibGVzIGZvciBSZWRpcmVjdCANCj4gTEZCcy4gIFdoaWNoIG1lYW5zIH dl IG5lZWQgdG8gY2FycnkgdGhlICJtZXRhIiBpbmZvcm1hdGlvbiBzb21laG93IGJldHdlZW4gDQ o+ IHRoZSBDRSBhbmQgdGhlIEZFLg0KSXMgaXQgcG9zc2libGUgd2UgcmVwcmVzZW50IHRoZSBtZX Rh LWRhdGEgaW4gdGhlIHByb3RvY29sIG1lc3NhZ2VzIGluIGEgbW9yZSBpc29sYXRpbmcgd2F5IG Zy b20gdGhlIGRhdGEgaXRzZWxmLCBqdXN0IGxpa2UgYSBQYXRoLURhdGEgbW9kZT8gIA0KDQpUaG Fu a3MsDQpXZWltaW5nDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gQXQgMTE6MjEgUE0gNi 8y OC8yMDA1LCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+ID5KYW1hbCwNCj4gPg0KPiA+VGhhbmtzIG Zv ciB0aGUgcmVzcG9uc2UuDQo+ID4NCj4gPkkgdGhpbmsgdGhlIGtleSBkaWZmZXJlbmNlIGlzIG hv dyB0aGUgUmVkaXJlY3QgU291cmNlIGFuZCBTaW5rIExGQiwgd2hvc2UgDQo+ID5wb3J0cyBzaG 91 bGQgYmUgZGVmaW5lZC4gTGV0IG1lIHRyeSB0byBzdW1tYXJpemUgdGhlIGlkZWFzIGZpcnN0Og 0K PiA+MS4geW91cnMsIG9ubHkgb25lIFJlZGlyZWN0IExGQiB3aGljaCBoYXZlIG11bGl0cGxlIG lu cHV0cyBhcyB0aGUgc2luayANCj4gPnBvcnRzIHRvIHJlZGlyZWN0IGRhdGEgZnJvbSBGRS0+Q0 Us IGFuZCBtdWx0aXBsZSBvdXRwdXRzIGFzIHRoZSBzb3VyY2UgDQo+ID5wb3J0cyB0byByZWRpcm Vj dCBkYXRhIGZyb20gQ0UtPkZFLiBXaXRoIHRoaXMgc2NoZW1lLCB0aGVuIHBvcnQgbnVtYmVyIA 0K PiA+c2hvdWxkIGFwcGVhciBpbiB0aGUgUEwgcmVkaXJlY3QgbWVzc2FnZSBmb3JtYXQuDQo+ID 4N Cj4gPjIuIG1pbmUsIHNldmVyYWwgcmVkaXJlY3QgTEZCcywgd2l0aCBldmVyeSBMRkIgb25seS Bo YXMgb25lIGlucHV0KHNpbmsgDQo+ID5MRkIpIG9yIG9uZSBvdXRwdXQoc291cmNlIExGQikuIF dp dGggdGhpcyBzY2hlbWUsIHRoZXJlIGlzIG5vIG5lZWQgdG8gDQo+ID5hc3NpZ24gYSBwb3J0IG 51 bWJlciBhdCB0aGUgUEwgcmVkaXJlY3QgbWVzc2FnZSBsYXllci4gVGhlIExGQiBpbnN0YW5jZS BJ RCANCj4gPmFjdHVhbGx5IGFjdHMgYXMgdGhlIGZ1bmN0aW9uIG9mIHBvcnQgbnVtYmVyIGluIH Nj aGVtZSAxLg0KPiA+DQo+ID5Kb2VsIGFuZCBJIGFjdHVhbGx5IGhhdmUgaGFkIGEgc2hvcnQgZG lz Y3Vzc2lvbiBvbiB0aGlzLiBKb2VsJ3MgdGhvdWdodCANCj4gPndhcyB2ZXJ5IGlkZW50aWNhbC B0 byB5b3VycywgYnV0IEkganVzdCBhcmd1ZWQgdGhhdCB0aGUgcmVkaXJlY3QgTEZCIA0KPiA+aW 5z dGFuY2UgSUQgY2FuIGFjdCB3ZWxsIHRvIGltcGxlbWVudCB0aGUgdGFzayBhcyB3aGVyZSB0aG Ug cmVkaXJlY3QgZGF0YSANCj4gPnNob3VsZCBnZXQgYW5kIHB1dCBpbiB0aGUgTEZCIHRvcG9sb2 d5 LiBBbmQgSSdtIGFsc28gYSBsaXR0bGUgd29ycnkgdGhhdCANCj4gPidhIHBvcnQgbnVtYmVyJy Bp cyBwYXJhbWV0ZXIgdGhhdCB3aWxsIGhpZ2hseSBsaW5rcyB0byBob3cgRkUgbW9kZWwgDQo+ID 5k ZWZpbmVzLiBUbyBkaXJlY3RseSB1c2UgYSBGRSBtb2RlbCBwYXJhbWV0ZXIgd2l0aG91dCB1c2 lu ZyBhIFBBVEgtREFUQSANCj4gPnJ1bGUgaW4gdGhlIFBMIGxheWVyIG1heSByZXN1bHQgaW4gdG 9v IGhpZ2ggYmluZGluZyBvZiB0aGUgcHJvdG9jb2wgYW5kIA0KPiA+dGhlIEZFIG1vZGVsLCBpLm Uu LCBtb2RlbCBkZWZpbml0aW9uIG1heSBoYXZlIHRvIG1ha2UgdGhlIHByb3RvY29sIGNoYW5nZS 4N Cj4gPg0KPiA+UmVnYXJkaW5nIHRoZSByZWRpcmVjdCBkaXJlY3RseSBhdCBUTUwgbGF5ZXIsIG Nv dWxkIHlvdSBnaXZlIG1vcmUgZGV0YWlscywgDQo+ID5saWtlIG9uIHdoaWNoIGxheWVyIGl0IG lz IGluamVjdGVkLCB0aGUgVENQLCBJUCwgb3IgVlBOPyBFeGNlcHQgZG9pbmcgaXQgDQo+ID5kaX Jl Y3RseSBhdCBJUCwgSSBmaW5kIG90aGVycyBtYXkgYWxsIGhhdmUgdG8gaGF2ZSB0aGUgaGVscC Bm cm9tIHVzZXIgDQo+ID5zcGFjZSwgcmF0aGVyIHRoYW4gZnJvbSB0aGUgZm9yd2FyZGluZyBwbG Fu ZSBvbmx5LCB3aGljaCBtYWtlcyBpdCBxdWl0ZSANCj4gPnRoZSBzYW1lIGFzIHJlZGlyZWN0IG F0 IFBMIGxheWVyLg0KPiA+DQo+ID5UaGFua3MsDQo+ID5XZWltaW5nDQo+ID4NCj4gPi0tLS0tIE 9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaU B6 bnl4LmNvbT4NCj4gPlN1YmplY3Q6IFJlOiBbaXNzdWUzMl0gUGFja2V0IFJlZGlyZWN0DQo+ID 4N Cj4gPg0KPiA+ID4gT24gTW9uLCAyMDA1LTI3LTA2IGF0IDIzOjIwIC0wNDAwLCBKb2VsIE0uIE hh bHBlcm4gd3JvdGU6DQo+ID4gPiA+IEdpdmVuIHRoYXQgcGFja2V0cyByZXF1aXJpbmcgcmVkaX Jl Y3Rpb24gYXJlIGxpa2VseSB0byBiZSBzY2F0dGVyZWQsIGFuZA0KPiA+ID4gPiBnaXZlbiB0aG F0 IG11bHRpcGxlIHJlZGlyZWN0IFRMVnMgKGVhY2ggd2l0aCBhIHBhY2tldCkgY2FuIGJlIA0KPi A+ IGluY2x1ZGVkIGluIGENCj4gPiA+ID4gbWVzc2FnZSBpZiB0aGF0IGlzIHVzZWZ1bCwgSSBkb2 4n dCBzZWUgbXVjaCB2YWx1ZSBpdCB0aGUgZXh0cmEgDQo+ID4gd3JhcHBlciB0bw0KPiA+ID4gPi Bh bGxvdyBtdWx0aXBsZSBwYWNrZXRzIGluc2lkZSB0aGUgVExWLg0KPiA+ID4gPg0KPiA+ID4NCj 4g PiA+IExldCBtZSBzaGFyZSB3aGF0IHdlIGRvIC0gaSBoYXZlbnQgcmVhbGx5IHJlYWQgdGhlIH Ro cmVhZCBpbiBmdWxsIHRvDQo+ID4gPiBtYWtlIGZ1bGwgc2Vuc2Ugb2Ygd2hhdCBKb2VsL1dlaW 1p bmcgYXJlIHNheWluZ1sxXS4gU28gaSBkb250IGtub3cgd2hvIGkNCj4gPiA+IGFtIGFncmVlaW 5n IHdpdGggOy0+DQo+ID4gPg0KPiA+ID4gSGVyZXMgYW4gZXhhbXBsZSBvZiBhIHJlZGlyZWN0IH Ro YXQgd2UgaGF2ZSBpbXBsZW1lbnRlZCB0aHVzIGZhciBzaGlwcGVkDQo+ID4gPiBhcyBhIEZvcm Nl cyBtZXNzYWdlLg0KPiA+ID4NCj4gPiA+IGNvbW1vbiBoZWFkZXIgKHR5cGUgPSBSRURJUkVDVC kN Cj4gPiA+IHwNCj4gPiA+IHwNCj4gPiA+ICstLS0tIExGQiBzZWxlY3RvciAoUmVkaXJlY3QgTE ZC LCBpbnN0YW5jZSBYKQ0KPiA+ID4gICAgICAgfA0KPiA+ID4gICAgICAgfA0KPiA+ID4gICAgIC Ag Ky0tLS0tIFRMViwgVHlwZSA9IFJFRElSRUNUX2RldmljZSAoZm9yIGxhY2sgb2YgYmV0dGVyIG 5h bWUpDQo+ID4gPiAgICAgICAgICAgICAgIHwNCj4gPiA+ICAgICAgICAgICAgICAgfA0KPiA+ID 4g ICAgICAgICAgICAgICArLS0tIGlmaW5kZXggb2Ygc2luayBvciBzb3VyY2UgcG9ydA0KPiA+ID 4g ICAgICAgICAgICAgICB8DQo+ID4gPiAgICAgICAgICAgICAgIHwNCj4gPiA+ICAgICAgICAgIC Ag ICAgKy0tLSBQYWNrZXQgZGF0YSBpbiBuZXR3b3JrIG9yZGVyDQo+ID4gPg0KPiA+ID4gU2V2ZX Jh bCBvYnNlcnZhdGlvbnM6DQo+ID4gPg0KPiA+ID4gMSkgSW4gdGhlb3J5LCB3ZSBzaG91bGQgYm Ug YWJsZSB0byByZXBlYXQgdGhlIFRMViBtdWx0aXBsZSB0aW1lcyB0byBzZW5kDQo+ID4gPiBzZX Zl cmFsIHBhY2tldHMgaW4gb25lIFBMIG1lc3NhZ2UuIFdlIGRvbnQgZG8gdGhhdCBhdCB0aGUgbW 9t ZW50OyB3aGVuDQo+ID4gPiB3ZSBnZXQgdG8gb3B0aW1pemluZyB3ZSB3aWxsIHByb2JhYmx5IG Rv IHNvLg0KPiA+ID4NCj4gPiA+IDIpIFRoZXJlIGlzIG9ubHkgb25lIHRlcm1pbmF0aW9uIHBvaW 50 IGZvciBlaXRoZXIgc291cmNlL3NpbmsgLSB0aGV5IGFyZQ0KPiA+ID4gbm90IGJlaW5nIGRpZm Zl cmVudGlhdGVkIGFzIHR3byBkaWZmZXJlbnQgdGhpbmdzLiBTbyB3aGVuIHRoZSBtZXNzYWdlDQ o+ ID4gPiBnb2VzIGZyb20gRkUtPkNFLCB0aGUgaWZpbmRleCBpcyB0aGF0IG9mIHRoZSBGRXMgcG 9y dCBpbiB3aGljaCBpbiB0aGUNCj4gPiA+IHBhY2tldCB3YXMgcmVjZWl2ZWQvc291cmNlZC4gT2 4g dGhlIENFLT5GRSBkaXJlY3Rpb24sIHRoZSBpZmluZGV4IGlzDQo+ID4gPiB0aGF0IG9mIHRoZS BG RXMgcG9ydCBpbiB3aGljaCB0aGUgdGhlIHBhY2tldCBpcyB0byBiZSB0cmFuc21pdHRlZC4gV2 UN Cj4gPiA+IGZvdW5kIHRoYXQgd2UgYWJzb2x1dGVseSBuZWVkZWQgdG8gYXQgbGVhc3QgaGF2ZS B0 aGlzIGxpdHRsZSBpZmluZGV4DQo+ID4gPiBoZWFkZXIuDQo+ID4gPg0KPiA+ID4gMykgVGhlcm Ug aXMgb25seSBvbmUgUkVESVJFQ1QgTEZCIGFuZCBzZXZlcmFsIGluc3RhbmNlcyAob25lIGZvci BJ S0UsDQo+ID4gPiBvbmUgZm9yIE9TUEYgZXRjKS4NCj4gPiA+DQo+ID4gPiBTb21lIHBlcmZvcm 1h bmNlIG51bWJlcnM6DQo+ID4gPiBIZXJlIGFyZSBzb21lIG51bWJlcnMgd2hlbiB3ZSB1c2UgZG lm ZmVyZW50IHJlZGlyZWN0IHNjaGVtZXMgZnJvbSB0aGUNCj4gPiA+IEZFLT5DRToNCj4gPiA+DQ o+ ID4gPiBTY2hlbWUgMTogQXMgZGVzY3JpYmVkIGFib3ZlLCBNVVNUIGltcGxlbWVudCBmb3IgZm 9y Y2VzLiBSb3VuZHRyaXANCj4gPiA+IGxhdGVuY3kgYWRkcyAxLjEgbXMgKG5vdGUgd2UgY3Jvc3 Mg dG8vZnJvIHVzZXIgc3BhY2UgNCB0aW1lcykNCj4gPiA+DQo+ID4gPiBTY2hlbWUgMjogSSBkZX Nj cmliZWQgZWFybGllciwgdGFnZ2VkIGFzIHRoZSBUTUwgcmVkaXJlY3QgYnkgSm9lbDoNCj4gPi A+ IChyZWRpcmVjdCBoYXBwZW5zIGluIHRoZSBmb3J3YXJkaW5nIHBhdGg7IHRoaXMgY291bGQgYm Ug aW4gdGhlIGtlcm5lbCBvcg0KPiA+ID4gaW4gaGFyZHdhcmUpOiBhZGRzIGxlc3MgdGhhbiAxMH Vz IHRvIHJvdW5kIHRyaXAgbGF0ZW5jeS4NCj4gPiA+DQo+ID4gPiBjaGVlcnMsDQo+ID4gPiBqYW 1h bA0KPiA+ID4NCj4gPiA+IFsxXUkgYW0gdmVyeSB0aWVkIHVwIGVsc2V3aGVyZSBidXQgaG9wZS B0 byByZXN1cmZhY2UgYW5kIGNhdGNodXAgb24gdGhlDQo+ID4gPiBsaXN0IGhvcGVmdWxseSBieS Bl bmQgb2YgZGF5IG9yIHRvbW1vcm93IChJIHdpbGwgYXR0ZW5kIHRoZSBuZXh0IGNvbmNhbA0KPi A+ ID4gdGh1cnNkYXkgYnR3IC0gc29ycnkgaGF2ZW50IHJlc3BvbmRlZCkuDQo= 2005 Message-Id: Date: Wed, 29 Jun 2005 11:21:39 +0800 From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLg0KDQpJIHRoaW5rIHRoZSBrZXkgZG lm ZmVyZW5jZSBpcyBob3cgdGhlIFJlZGlyZWN0IFNvdXJjZSBhbmQgU2luayBMRkIsIHdob3NlIH Bv cnRzIHNob3VsZCBiZSBkZWZpbmVkLiBMZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSB0aGUgaWRlYX Mg Zmlyc3Q6DQoxLiB5b3Vycywgb25seSBvbmUgUmVkaXJlY3QgTEZCIHdoaWNoIGhhdmUgbXVsaX Rw bGUgaW5wdXRzIGFzIHRoZSBzaW5rIHBvcnRzIHRvIHJlZGlyZWN0IGRhdGEgZnJvbSBGRS0+Q0 Us IGFuZCBtdWx0aXBsZSBvdXRwdXRzIGFzIHRoZSBzb3VyY2UgcG9ydHMgdG8gcmVkaXJlY3QgZG F0 YSBmcm9tIENFLT5GRS4gV2l0aCB0aGlzIHNjaGVtZSwgdGhlbiBwb3J0IG51bWJlciBzaG91bG Qg YXBwZWFyIGluIHRoZSBQTCByZWRpcmVjdCBtZXNzYWdlIGZvcm1hdC4NCg0KMi4gbWluZSwgc2 V2 ZXJhbCByZWRpcmVjdCBMRkJzLCB3aXRoIGV2ZXJ5IExGQiBvbmx5IGhhcyBvbmUgaW5wdXQoc2 lu ayBMRkIpIG9yIG9uZSBvdXRwdXQoc291cmNlIExGQikuIFdpdGggdGhpcyBzY2hlbWUsIHRoZX Jl IGlzIG5vIG5lZWQgdG8gYXNzaWduIGEgcG9ydCBudW1iZXIgYXQgdGhlIFBMIHJlZGlyZWN0IG 1l c3NhZ2UgbGF5ZXIuIFRoZSBMRkIgaW5zdGFuY2UgSUQgYWN0dWFsbHkgYWN0cyBhcyB0aGUgZn Vu Y3Rpb24gb2YgcG9ydCBudW1iZXIgaW4gc2NoZW1lIDEuDQoNCkpvZWwgYW5kIEkgYWN0dWFsbH kg aGF2ZSBoYWQgYSBzaG9ydCBkaXNjdXNzaW9uIG9uIHRoaXMuIEpvZWwncyB0aG91Z2h0IHdhcy B2 ZXJ5IGlkZW50aWNhbCB0byB5b3VycywgYnV0IEkganVzdCBhcmd1ZWQgdGhhdCB0aGUgcmVkaX Jl Y3QgTEZCIGluc3RhbmNlIElEIGNhbiBhY3Qgd2VsbCB0byBpbXBsZW1lbnQgdGhlIHRhc2sgYX Mg d2hlcmUgdGhlIHJlZGlyZWN0IGRhdGEgc2hvdWxkIGdldCBhbmQgcHV0IGluIHRoZSBMRkIgdG 9w b2xvZ3kuIEFuZCBJJ20gYWxzbyBhIGxpdHRsZSB3b3JyeSB0aGF0ICdhIHBvcnQgbnVtYmVyJy Bp cyBwYXJhbWV0ZXIgdGhhdCB3aWxsIGhpZ2hseSBsaW5rcyB0byBob3cgRkUgbW9kZWwgZGVmaW 5l cy4gVG8gZGlyZWN0bHkgdXNlIGEgRkUgbW9kZWwgcGFyYW1ldGVyIHdpdGhvdXQgdXNpbmcgYS BQ QVRILURBVEEgcnVsZSBpbiB0aGUgUEwgbGF5ZXIgbWF5IHJlc3VsdCBpbiB0b28gaGlnaCBiaW 5k aW5nIG9mIHRoZSBwcm90b2NvbCBhbmQgdGhlIEZFIG1vZGVsLCBpLmUuLCBtb2RlbCBkZWZpbm l0 aW9uIG1heSBoYXZlIHRvIG1ha2UgdGhlIHByb3RvY29sIGNoYW5nZS4gIA0KDQpSZWdhcmRpbm cg dGhlIHJlZGlyZWN0IGRpcmVjdGx5IGF0IFRNTCBsYXllciwgY291bGQgeW91IGdpdmUgbW9yZS Bk ZXRhaWxzLCBsaWtlIG9uIHdoaWNoIGxheWVyIGl0IGlzIGluamVjdGVkLCB0aGUgVENQLCBJUC wg b3IgVlBOPyBFeGNlcHQgZG9pbmcgaXQgZGlyZWN0bHkgYXQgSVAsIEkgZmluZCBvdGhlcnMgbW F5 IGFsbCBoYXZlIHRvIGhhdmUgdGhlIGhlbHAgZnJvbSB1c2VyIHNwYWNlLCByYXRoZXIgdGhhbi Bm cm9tIHRoZSBmb3J3YXJkaW5nIHBsYW5lIG9ubHksIHdoaWNoIG1ha2VzIGl0IHF1aXRlIHRoZS Bz YW1lIGFzIHJlZGlyZWN0IGF0IFBMIGxheWVyLiANCg0KVGhhbmtzLA0KV2VpbWluZw0KDQotLS 0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYW Rp QHpueXguY29tPg0KU3ViamVjdDogUmU6IFtpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCg0KDQ o+ IE9uIE1vbiwgMjAwNS0yNy0wNiBhdCAyMzoyMCAtMDQwMCwgSm9lbCBNLiBIYWxwZXJuIHdyb3 Rl Og0KPiA+IEdpdmVuIHRoYXQgcGFja2V0cyByZXF1aXJpbmcgcmVkaXJlY3Rpb24gYXJlIGxpa2 Vs eSB0byBiZSBzY2F0dGVyZWQsIGFuZCANCj4gPiBnaXZlbiB0aGF0IG11bHRpcGxlIHJlZGlyZW N0 IFRMVnMgKGVhY2ggd2l0aCBhIHBhY2tldCkgY2FuIGJlIGluY2x1ZGVkIGluIGEgDQo+ID4gbW Vz c2FnZSBpZiB0aGF0IGlzIHVzZWZ1bCwgSSBkb24ndCBzZWUgbXVjaCB2YWx1ZSBpdCB0aGUgZX h0 cmEgd3JhcHBlciB0byANCj4gPiBhbGxvdyBtdWx0aXBsZSBwYWNrZXRzIGluc2lkZSB0aGUgVE xW Lg0KPiA+IA0KPiANCj4gTGV0IG1lIHNoYXJlIHdoYXQgd2UgZG8gLSBpIGhhdmVudCByZWFsbH kg cmVhZCB0aGUgdGhyZWFkIGluIGZ1bGwgdG8NCj4gbWFrZSBmdWxsIHNlbnNlIG9mIHdoYXQgSm 9l bC9XZWltaW5nIGFyZSBzYXlpbmdbMV0uIFNvIGkgZG9udCBrbm93IHdobyBpDQo+IGFtIGFncm Vl aW5nIHdpdGggOy0+IA0KPiANCj4gSGVyZXMgYW4gZXhhbXBsZSBvZiBhIHJlZGlyZWN0IHRoYX Qg d2UgaGF2ZSBpbXBsZW1lbnRlZCB0aHVzIGZhciBzaGlwcGVkDQo+IGFzIGEgRm9yY2VzIG1lc3 Nh Z2UuDQo+IA0KPiBjb21tb24gaGVhZGVyICh0eXBlID0gUkVESVJFQ1QpDQo+IHwNCj4gfA0KPi Ar LS0tLSBMRkIgc2VsZWN0b3IgKFJlZGlyZWN0IExGQiwgaW5zdGFuY2UgWCkNCj4gICAgICAgfA 0K PiAgICAgICB8DQo+ICAgICAgICstLS0tLSBUTFYsIFR5cGUgPSBSRURJUkVDVF9kZXZpY2UgKG Zv ciBsYWNrIG9mIGJldHRlciBuYW1lKSANCj4gICAgICAgICAgICAgICB8DQo+ICAgICAgICAgIC Ag ICAgfA0KPiAgICAgICAgICAgICAgICstLS0gaWZpbmRleCBvZiBzaW5rIG9yIHNvdXJjZSBwb3 J0 DQo+ICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgIC Ar LS0tIFBhY2tldCBkYXRhIGluIG5ldHdvcmsgb3JkZXINCj4gDQo+IFNldmVyYWwgb2JzZXJ2YX Rp b25zOg0KPiANCj4gMSkgSW4gdGhlb3J5LCB3ZSBzaG91bGQgYmUgYWJsZSB0byByZXBlYXQgdG hl IFRMViBtdWx0aXBsZSB0aW1lcyB0byBzZW5kDQo+IHNldmVyYWwgcGFja2V0cyBpbiBvbmUgUE wg bWVzc2FnZS4gV2UgZG9udCBkbyB0aGF0IGF0IHRoZSBtb21lbnQ7IHdoZW4NCj4gd2UgZ2V0IH Rv IG9wdGltaXppbmcgd2Ugd2lsbCBwcm9iYWJseSBkbyBzby4NCj4gDQo+IDIpIFRoZXJlIGlzIG 9u bHkgb25lIHRlcm1pbmF0aW9uIHBvaW50IGZvciBlaXRoZXIgc291cmNlL3NpbmsgLSB0aGV5IG Fy ZQ0KPiBub3QgYmVpbmcgZGlmZmVyZW50aWF0ZWQgYXMgdHdvIGRpZmZlcmVudCB0aGluZ3MuIF Nv IHdoZW4gdGhlIG1lc3NhZ2UNCj4gZ29lcyBmcm9tIEZFLT5DRSwgdGhlIGlmaW5kZXggaXMgdG hh dCBvZiB0aGUgRkVzIHBvcnQgaW4gd2hpY2ggaW4gdGhlDQo+IHBhY2tldCB3YXMgcmVjZWl2ZW Qv c291cmNlZC4gT24gdGhlIENFLT5GRSBkaXJlY3Rpb24sIHRoZSBpZmluZGV4IGlzDQo+IHRoYX Qg b2YgdGhlIEZFcyBwb3J0IGluIHdoaWNoIHRoZSB0aGUgcGFja2V0IGlzIHRvIGJlIHRyYW5zbW l0 dGVkLiBXZQ0KPiBmb3VuZCB0aGF0IHdlIGFic29sdXRlbHkgbmVlZGVkIHRvIGF0IGxlYXN0IG hh dmUgdGhpcyBsaXR0bGUgaWZpbmRleA0KPiBoZWFkZXIuDQo+IA0KPiAzKSBUaGVyZSBpcyBvbm x5 IG9uZSBSRURJUkVDVCBMRkIgYW5kIHNldmVyYWwgaW5zdGFuY2VzIChvbmUgZm9yIElLRSwNCj 4g b25lIGZvciBPU1BGIGV0YykuDQo+IA0KPiBTb21lIHBlcmZvcm1hbmNlIG51bWJlcnM6DQo+IE hl cmUgYXJlIHNvbWUgbnVtYmVycyB3aGVuIHdlIHVzZSBkaWZmZXJlbnQgcmVkaXJlY3Qgc2NoZW 1l cyBmcm9tIHRoZQ0KPiBGRS0+Q0U6DQo+IA0KPiBTY2hlbWUgMTogQXMgZGVzY3JpYmVkIGFib3 Zl LCBNVVNUIGltcGxlbWVudCBmb3IgZm9yY2VzLiBSb3VuZHRyaXANCj4gbGF0ZW5jeSBhZGRzID Eu MSBtcyAobm90ZSB3ZSBjcm9zcyB0by9mcm8gdXNlciBzcGFjZSA0IHRpbWVzKQ0KPiANCj4gU2 No ZW1lIDI6IEkgZGVzY3JpYmVkIGVhcmxpZXIsIHRhZ2dlZCBhcyB0aGUgVE1MIHJlZGlyZWN0IG J5 IEpvZWw6DQo+IChyZWRpcmVjdCBoYXBwZW5zIGluIHRoZSBmb3J3YXJkaW5nIHBhdGg7IHRoaX Mg Y291bGQgYmUgaW4gdGhlIGtlcm5lbCBvcg0KPiBpbiBoYXJkd2FyZSk6IGFkZHMgbGVzcyB0aG Fu IDEwdXMgdG8gcm91bmQgdHJpcCBsYXRlbmN5Lg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbCANCj 4g DQo+IFsxXUkgYW0gdmVyeSB0aWVkIHVwIGVsc2V3aGVyZSBidXQgaG9wZSB0byByZXN1cmZhY2 Ug YW5kIGNhdGNodXAgb24gdGhlDQo+IGxpc3QgaG9wZWZ1bGx5IGJ5IGVuZCBvZiBkYXkgb3IgdG 9t bW9yb3cgKEkgd2lsbCBhdHRlbmQgdGhlIG5leHQgY29uY2FsDQo+IHRodXJzZGF5IGJ0dyAtIH Nv cnJ5IGhhdmVudCByZXNwb25kZWQpLg0K 2005 Message-Id: Date: Wed, 29 Jun 2005 07:39:06 -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-29-06 at 00:23 -0400, Joel M. Halpern wrote: > Having a general, isolated, representation for the packet meta-data wiht > the redirected packet seems like a good idea. > Trying to come up with a good structure for that is one thing that has > stumped me. Good ideas would be welcome. > (I don't currently see how to use something like Path-Data, but that may > just be me being obtuse.) There are 2 attributes that i described earlier: - the ifindex and filterid. If we can say we have a table comprising of these attributes then we can certainly have a path to the pair of attributes. It is more than likely these two are aliases to attributes in two other LFBs (a port LFB and a classifier/filter LFB). cheers, jamal 2005 Message-Id: Date: Wed, 29 Jun 2005 07:32:30 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Wed, 2005-29-06 at 11:21 +0800, Wang,Weiming wrote: > Jamal, > > Thanks for the response. > > I think the key difference is how the Redirect Source and Sink LFB, whose ports should be defined. > Let me try to summarize the ideas first: > 1. yours, only one Redirect LFB which have mulitple inputs as the sink ports to redirect data from > FE->CE, and multiple outputs as the source ports to redirect data from CE->FE. With this scheme, then > port number should appear in the PL redirect message format. > > 2. mine, several redirect LFBs, with every LFB only has one input(sink LFB) or one output(source LFB). > With this scheme, there is no need to assign a port number at the PL redirect message layer. The LFB > instance ID actually acts as the function of port number in scheme 1. > > Joel and I actually have had a short discussion on this. Joel's thought was very identical to yours, > but I just argued that the redirect LFB instance ID can act well to implement the task as where the > redirect data should get and put in the LFB topology. And I'm also a little worry that 'a port number' > is parameter that will highly links to how FE model defines. To directly use a FE model parameter > without using a PATH-DATA rule in the PL layer may result in too high binding of the protocol and > the FE model, i.e., model definition may have to make the protocol change. > There are two things/numbers that are important: 1) the interface/port the packet goes in/out 2) the type of packet that is being filtered on receive. In our case #1 was in the ifindex i showed. #2 is in the instance of the class. Indeed both these parameters can be coded in the path; but if we do that it is better to keep a single LFB instance (Infact i would argue for a single LFB instance for simplicity). In such a case, the selection is of the form: FEx/LFB=redirect/instance=1/operation=config/path={port,filterid} . BTW, we havent really discussed how the CE subscribes to receive packets. > Regarding the redirect directly at TML layer, could you give more details, like on which layer it > is injected, the TCP, IP, or VPN? Except doing it directly at IP, I find others may all have to > have the help from user space, rather than from the forwarding plane only, which makes it quite > the same as redirect at PL layer. > Assume a stateless transport for this to work well; IP, ethernet etc. If you could map those two numbers {src/dst port, packet type} into something in a header, you could redirect to the PL layer. Lets say you could redirect at the FE in hardware (most of the ethernet switches my company sells are capable and i would suspect other vendors do): - add a filter rule in the FE hardware which says "if you see IKE packets on port 10 i want you to redirect to port 23 with VLAN tag Y" - CE is connected to port 23. On receipt of such a packet, the CE kernel or even user space is able to deduce (by looking at MAC + VLAN headers and peeking into the data) that the packet came through FE3, port 10 and is an IKE packet. - You can then reinject it with proper forces header to the forces process. We actually take more shortcuts, i am just simplifying. cheers, jamal 2005 Message-Id: Date: Wed, 29 Jun 2005 00:23:46 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Having a general, isolated, representation for the packet meta-data wiht the redirected packet seems like a good idea. Trying to come up with a good structure for that is one thing that has stumped me. Good ideas would be welcome. (I don't currently see how to use something like Path-Data, but that may just be me being obtuse.) Yours, Joel At 12:01 AM 6/29/2005, Wang,Weiming wrote: >Joel, > > > I am concerned that this approach will mandate a very large number of > > Redirect LFBs for those FEs that support logical interfaces (802.1 VLANs, > > Frame Relay or ATM VCs, etc.) For other uses, we have allowed that > > meta-data may be used to index into LFBs which have tables of > > behaviors. (We have not mandated that, either.) > > > > It would seem by analogy that we should allow similar tables for Redirect > > LFBs. Which means we need to carry the "meta" information somehow between > > the CE and the FE. >Is it possible we represent the meta-data in the protocol messages in a >more isolating way from the data itself, just like a Path-Data mode? > >Thanks, >Weiming 2005 Message-Id: Date: Tue, 28 Jun 2005 23:47:36 -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 I am concerned that this approach will mandate a very large number of Redirect LFBs for those FEs that support logical interfaces (802.1 VLANs, Frame Relay or ATM VCs, etc.) For other uses, we have allowed that meta-data may be used to index into LFBs which have tables of behaviors. (We have not mandated that, either.) It would seem by analogy that we should allow similar tables for Redirect LFBs. Which means we need to carry the "meta" information somehow between the CE and the FE. Yours, Joel At 11:21 PM 6/28/2005, Wang,Weiming wrote: >Jamal, > >Thanks for the response. > >I think the key difference is how the Redirect Source and Sink LFB, whose >ports should be defined. Let me try to summarize the ideas first: >1. yours, only one Redirect LFB which have mulitple inputs as the sink >ports to redirect data from FE->CE, and multiple outputs as the source >ports to redirect data from CE->FE. With this scheme, then port number >should appear in the PL redirect message format. > >2. mine, several redirect LFBs, with every LFB only has one input(sink >LFB) or one output(source LFB). With this scheme, there is no need to >assign a port number at the PL redirect message layer. The LFB instance ID >actually acts as the function of port number in scheme 1. > >Joel and I actually have had a short discussion on this. Joel's thought >was very identical to yours, but I just argued that the redirect LFB >instance ID can act well to implement the task as where the redirect data >should get and put in the LFB topology. And I'm also a little worry that >'a port number' is parameter that will highly links to how FE model >defines. To directly use a FE model parameter without using a PATH-DATA >rule in the PL layer may result in too high binding of the protocol and >the FE model, i.e., model definition may have to make the protocol change. > >Regarding the redirect directly at TML layer, could you give more details, >like on which layer it is injected, the TCP, IP, or VPN? Except doing it >directly at IP, I find others may all have to have the help from user >space, rather than from the forwarding plane only, which makes it quite >the same as redirect at PL layer. > >Thanks, >Weiming > >----- Original Message ----- >From: "Jamal Hadi Salim" >Subject: Re: [issue32] Packet Redirect > > > > On Mon, 2005-27-06 at 23:20 -0400, Joel M. Halpern wrote: > > > Given that packets requiring redirection are likely to be scattered, and > > > given that multiple redirect TLVs (each with a packet) can be > included in a > > > message if that is useful, I don't see much value it the extra > wrapper to > > > allow multiple packets inside the TLV. > > > > > > > Let me share what we do - i havent really read the thread in full to > > make full sense of what Joel/Weiming are saying[1]. So i dont know who i > > am agreeing with ;-> > > > > Heres an example of a redirect that we have implemented thus far shipped > > as a Forces message. > > > > common header (type = REDIRECT) > > | > > | > > +---- LFB selector (Redirect LFB, instance X) > > | > > | > > +----- TLV, Type = REDIRECT_device (for lack of better name) > > | > > | > > +--- ifindex of sink or source port > > | > > | > > +--- Packet data in network order > > > > Several observations: > > > > 1) In theory, we should be able to repeat the TLV multiple times to send > > several packets in one PL message. We dont do that at the moment; when > > we get to optimizing we will probably do so. > > > > 2) There is only one termination point for either source/sink - they are > > not being differentiated as two different things. So when the message > > goes from FE->CE, the ifindex is that of the FEs port in which in the > > packet was received/sourced. On the CE->FE direction, the ifindex is > > that of the FEs port in which the the packet is to be transmitted. We > > found that we absolutely needed to at least have this little ifindex > > header. > > > > 3) There is only one REDIRECT LFB and several instances (one for IKE, > > one for OSPF etc). > > > > Some performance numbers: > > Here are some numbers when we use different redirect schemes from the > > FE->CE: > > > > Scheme 1: As described above, MUST implement for forces. Roundtrip > > latency adds 1.1 ms (note we cross to/fro user space 4 times) > > > > Scheme 2: I described earlier, tagged as the TML redirect by Joel: > > (redirect happens in the forwarding path; this could be in the kernel or > > in hardware): adds less than 10us to round trip latency. > > > > cheers, > > jamal > > > > [1]I am very tied up elsewhere but hope to resurface and catchup on the > > list hopefully by end of day or tommorow (I will attend the next concal > > thursday btw - sorry havent responded). 2005 Message-Id: Date: Tue, 28 Jun 2005 11:04:35 +0800 From: Weiming Wang 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 DQo+IFRoZSBkaWZmZXJlbmNlcyBhcmUgbWlub3IuDQo+IEZpcnN0bHksIEkgd2FudGVkIHRvIG Ns YXJpZnkgdGhlIGdlbmVyYWwgcHJpbmNpcGxlIG9mIHRvcCBsZXZlbCBUTFZzLg0KPiBJIGFtIG 5v dCBzdXJlIHdlIG5lZWQgdGhlIExGQiBjbGFzcy4gIEl0IG1heSBiZSB1c2VmdWwgKGZvciBkaW Zm ZXJlbnRpb24gDQo+IHNvdXJjZSBmcm9tIHNpbmssIGFuZCBhbGxvd2luZyBzdWJjbGFzc2luZy Bv ZiB0aGUgcmVkaXJlY3QgTEZCcy4NCj4gQW5kIEkgd291bGQgbm90IGV4cGVjdCB0aGUgcmVtYW lu aW5nIGNvbnRlbnQgdG8gYmUgYW4gT3BlcmF0aW9uIA0KPiBUTFYuICBSYXRoZXIsIEkgd291bG Qg ZXhwZWN0IGl0IHRvIGJlIHRoZSBwYWNrZXQuDQpPbWl0dGluZyBvcGVyYXRpb24gVExWIHdpbG wg bGVhZCB0byB0aGUgZmFjdCB0aGF0IHdlIG9ubHkgYWxsb3cgb25lIHBhY2tldCBkYXRhIGluIG 9u ZSB0b3AgVExWLiBUaGF0J3MgdGhlIHF1ZXN0aW9uIHRoYXQgSSByYWlzZWQgZGF5cyBiZWZvcm Uu IEZyb20gdGhlIGVmZmljaWVuY3kgcG9pbnQgb2YgdmlldywgdG8gYWxsb3cgbW9yZSB0aGFuIG 9u ZSBwYWNrZXQgaW4gb25lIHRvcCBUTFYgbWF5IGJlIGJlbmlmaXRmdWwgYSBsaXR0bGUuDQoNCl Ro YW5rcywNCldlaW1pbmcNCj4gDQo+IEJ1dCBtb3N0bHksIHdlIGFyZSBpbiBhZ3JlZW1lbnQuDQ o+ IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gQXQgMDk6NTYgUE0gNi8yNy8yMDA1LCBXZWltaW 5n IFdhbmcgd3JvdGU6DQo+ID5Kb2VsLA0KPiA+DQo+ID4gPiAgICAgIFRoZSBQYWNrZXQgUmVkaX Jl Y3QgbWVzc2FnZSBjb250YWlucyBvbmUgb3IgbW9yZSAodHlwaWNhbGx5IG9uZSkNCj4gPiA+IH Bh Y2tldC1yZWRpcmVjdCBUTFZzLg0KPiA+DQo+ID5JZiBJIHVuZGVyc3RhbmQgeW91ciBhYm92ZS B0 aG91Z2h0IGNvcnJlY3RseSwgSSB0aGluayB5b3VyIHByb3Bvc2FsICBpcyB0byANCj4gPmRlZm lu ZSBhICBwYWNrZXQtcmVkaXJlY3QgVExWIHJhdGhhbiB0aGFuIGEgTEZCc2VsZWN0VExWIGF0IH Ro ZSB0b3AgbGV2ZWwgDQo+ID5mb3IgdGhlIG1lc3NhZ2UuIEluIHRoaXMgd2F5IGl0IHdpbGwgbG Vh dmUgTEZCIHNlbGVjdGlvbiBpbmZvcm1hdGlvbiBhcyANCj4gPmtpbmRzIG9mIG1ldGEtaW5mby Bh bmQgaW5zaWRlIHRoZSBUTFYsIHNvbWV0aGluZyBsaWtlOg0KPiA+DQo+ID4gPiA+ICAgICAgIC Ag Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAgICBUeXBlID0gDQo+ID4gUGFja2V0LV Jl ZGlyZWN0ICAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCj4gPiA+ID 4g ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIC Ag ICAgIExGQiBDbGFzcyBJRCAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gPiA+ICAgIC Ag ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTE ZC IEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ID4gPiAgICAgICAgIC st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rDQo+ID4gPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdG lv biBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiA+ID4gICAgICAgICAuICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag Lg0KPiA+ID4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4NCj4gPk5vdywgdGhlIHF1ZXN0aW9uIG lz IEkgZG8gZmluZCB0aGlzIGZvcm1hdCBpcyBub3QgdmVyeSBkaWZmZXJlbnQgd2l0aCB0aGF0IA 0K PiA+SSBwcm9wb3NlZC4gRG8gSSBtaXNzIHNvbWV0aGluZz8NCj4gPg0KPiA+VGhhbmtzLA0KPi A+ V2VpbWluZw0KPiA+DQo+ID4NCj4gPiA+IEkgd291bGQgYXBwcm9hY2ggdGhpcyBkaWZmZXJlbn Rs eS4gIFRoZSBjdXJyZW50IHRleHQgZGVzY3JpYmVzIHRoZQ0KPiA+ID4gTEZCc2VsZWN0IExGQi 4g IEl0IGNvcnJlY3RseSBkZWZpbmVzIHRoZSBMRkJzZWxlY3QgTEZCLiAgVGhhdCBkZWZpbml0aW 9u DQo+ID4gPiBzaG91bGQgbm90IGJlIHRocm93biBhd2F5Lg0KPiA+ID4NCj4gPiA+IFRoZSBtZX Nz YWdlIHN0cnVjdHVyZSBkb2N1bWVudGF0aW9uIGNhbiBzYXkNCj4gPiA+ICAgICBBIFBMIHByb3 Rv Y29sIG1lc3NhZ2VzIGNvbnNpc3RzIG9mIGEgcHJvdG9jb2wgaGVhZGVyIGZvbGxvd2VkIGJ5IA 0K PiA+IG9uZSBvcg0KPiA+ID4gbW9yZSBUTFZzLiAgQWxsIFRMVnMNCj4gPiA+ICAgICBjb25zaX N0 IG9mICB0d28gYnl0ZSB0eXBlIGFuZCBhIHR3byBieXRlIGxlbmd0aCwgZm9sbG93ZWQgYnkgY2 9u dGVudHMNCj4gPiA+IGRlcGVuZGVudCB1cG9uIHRoZSB0eXBlDQo+ID4gPiAgICAgb2YgdGhlIF RM Vi4gIFRoZSBUTFZzIHdoaWNoIGFyZSB2YWxpZCBpbiBhIG1lc3NhZ2UgZGVwZW5kIHVwb24gdG hl DQo+ID4gPiBtZXNzYWdlIHR5cGUuDQo+ID4gPiAgICAgTW9zdCBtZXNzYWdlIHR5cGVzIGFsbG 93 IG9uZSBvciBtb3JlIExGQnNlbGVjdCBUTFZzIGFuZCBubyBvdGhlciB0b3ANCj4gPiA+IGxldm Vs IFRMVnMuICBUaGUNCj4gPiA+ICAgICBmb2xsb3dpbmcgYXJlIHRoZSBtZXNzYWdlIHR5cGVzIH Ro aXMgYXBwbGllcyB0bzoNCj4gPiA+ICAgICAgICBBc3NvY2lhdGlvbiBzZXR1cCByZXF1ZXN0IG Fu ZCByZXNwb25zZS4NCj4gPiA+ICAgICAgICBDb25maWcgbWVzc2FnZSByZXF1ZXN0IGFuZCByZX Nw b25zZQ0KPiA+ID4gICAgICAgIFF1ZXJ5IG1lc3NhZ2UgcmVxdWVzdCBhbmQgcmVzcG9uc2UNCj 4g PiA+ICAgICAgICBFdmVudCBOb3RpZnkgbWVzc2FnZS4NCj4gPiA+ICAgICBUaGUgQXNzb2NpYX Rp b24gdGVhcmRvd24gbWVzc2FnZSBjb250YWlucyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUNCj 4g PiA+IHRlYXJkb3duLWNhdXNlIFRMVi4NCj4gPiA+ICAgICBUaGUgaGVhcnRiZWF0IG1lc3NhZ2 Ug Y29udGFpbnMgYSBzaW5nbGUgaW5zdGFuY2Ugb2YgdGhlIGhlYXRyYmVhdA0KPiA+ID4gVExWLi Ag KFVubGVzcyB3ZSBkZWNpZGUNCj4gPiA+ICAgICAgdG8ganVzdCB1c2UgYW4gZXZlbnQgZm9yIG hl YXJ0YmVhdHMuICBJIGRvbid0IHJlbWVtYmVyIHdoZXJlIHRoYXQNCj4gPiA+IGRpc2N1c3Npb2 4g c3RhbmRzLikNCj4gPiA+ICAgICAgVGhlIFBhY2tldCBSZWRpcmVjdCBtZXNzYWdlIGNvbnRhaW 5z IG9uZSBvciBtb3JlICh0eXBpY2FsbHkgb25lKQ0KPiA+ID4gcGFja2V0LXJlZGlyZWN0IFRMVn Mu DQo+ID4gPiBUaGlzIGlzIHRoZW4gZm9sbG93ZWQgYnkgYSBzZWN0aW9uIGZvciBlYWNoIG9mIH Ro ZXNlIHRvcCBsZXZlbCBUTFZzLg0KPiA+ID4NCj4gPiA+IFlvdXJzLA0KPiA+ID4gSm9lbCBNLi BI YWxwZXJuDQo+ID4gPg0KPiA+ID4gQXQgMTA6MDEgQU0gNi8yNy8yMDA1LCBXZWltaW5nIFdhbm cg d3JvdGU6DQo+ID4gPiA+Sm9lbCA6KQ0KPiA+ID4gPg0KPiA+ID4gPkhvdyBhYm91dCB3ZSBqdX N0 IG9ic29sZXRlIHRoZSBwYXRoIGZyb20gdGhlIGRhdGEgc3RydWN0dXJlIGFuZCBhZGQgc29tZQ 0K PiA+ID4gPm1ldGEtaW5mb3JtYXRpb24sIGFuZCBmb3JtIHRoZSBmb3JtYXQgYXMgYmVsb3cgKE kg Y3VycmVudGx5IGNhbiBvbmx5IHRoaW5rDQo+ID4gPiA+b2YgdGhlIG1ldGEtaW5mb3JtYXRpb2 4g YXMgdGhlIHBhY2tldCB0eXBlLiBXZSBtYXkgYWRkIHNvbWUgbW9yZSBsYXRlcikuDQo+ID4gPi A+ DQo+ID4gPiA+Q291bGQgeW91IGdpdmUgbW9yZSBjb21tZW50cyBvbiB0aGlzLCB0aGVuIHdlIG 1h eSBzb2x2ZSB0aGlzIGlzc3VlIHNvb24/DQo+ID4gPiA+DQo+ID4gPiA+VGhhbmsgeW91IHZlcn kg bXVjaC4NCj4gPiA+ID4NCj4gPiA+ID5XZWltaW5nDQo+ID4gPiA+DQo+ID4gPiA+LS0tLS0tLS 0t LS0tLS0tLS0tLS0tDQo+ID4gPiA+TWVzc2FnZSBCb2R5Og0KPiA+ID4gPiAgICAgICBDb25zaX N0 cyBvZiBvbmUgb3IgbW9yZSBUTFZzLCB3aXRoIGV2ZXJ5IFRMViBoYXZpbmcgdGhlIGZvbGxvd2 lu Zw0KPiA+ID4gPiAgICAgICBkYXRhIGZvcm1hdDoNCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgIC Aw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3ID gg OSAwIDENCj4gPiA+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgIC Ag IFR5cGUgPSBMRkJzZWxlY3QgICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgIC B8 DQo+ID4gPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAgICAgIC Ag ICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPi A+ ID4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgIC Ag ICAgICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiA+ID 4g ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIC Ag ICBPcGVyYXRpb24gVExWICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gPiA+ICAgIC Ag ICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgIC4NCj4gPiA+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIH 4g ICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICB+DQo+ID4gPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgIC Ag ICAgICAgICAgICAgICAgICAgT3BlcmF0aW9uIFRMViAgICAgICAgICAgICAgICAgICAgICAgIC Ag fA0KPiA+ID4gPiAgICAgICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAuDQo+ID4gPiA+ICAgICAgICAgKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj 4g PiA+ID4NCj4gPiA+ID4gICAgTEZCIGNsYXNzIElEOg0KPiA+ID4gPiAgICAgICBUaGVyZSBhcm Ug b25seSB0d28gcG9zc2libGUgTEZCIGNsYXNzZXMgaGVyZSwgdGhlICdSZWRpcmVjdFNpbmsnDQ o+ ID4gPiA+ICAgICAgIExGQiBvciB0aGUgJ1JlZGlyZWN0U291cmNlJyBMRkIuICBJZiB0aGUgbW Vz c2FnZSBpcyBmcm9tIEZFIHRvIENFLA0KPiA+ID4gPiAgICAgICB0aGUgTEZCIGNsYXNzIHNob3 Vs ZCBiZSAnUmVkaXJlY3RTaW5rJy4gIElmIHRoZSBtZXNzYWdlIGlzIGZyb20gQ0UNCj4gPiA+ID 4g ICAgICAgdG8gRkUsIHRoZSBMRkIgY2xhc3Mgc2hvdWxkIGJlICdSZWRpcmVjdFNvdXJjZScuDQ o+ ID4gPiA+ICAgIEluc3RhbmNlIElEOg0KPiA+ID4gPiAgICAgICBJbnN0YW5jZSBJRCBmb3IgdG hl ICdSZWRpcmVjdFNpbmsnIExGQiBvciAnUmVkaXJlY3RTb3VyY2UnIExGQi4NCj4gPiA+ID4gIC Ag T3BlcmF0aW9uIFRMVjoNCj4gPiA+ID4gICAgICAgVGhpcyBpcyBhIFRMViBkZXNjcmliaW5nIG 9u ZSBwYWNrZXQgb2YgZGF0YSB0byBiZSBkaXJlY3RlZCB2aWEgdGhlDQo+ID4gPiA+ICAgICAgIH Nw ZWNpZmllZCBMRkIgYWJvdmUuICBUaGUgb3JkZXIgb2YgdGhlIFRMViBhcHBlYXJlZCBpcyBhbH Nv IHRoZQ0KPiA+ID4gPiAgICAgICBvcmRlciB0aGUgZGF0YSBwYWNrZXQgYXJyaXZlcyB0aGUgcm Vk aXJlY3RvciBMRkIsIHRoYXQgaXMsIHRoZQ0KPiA+ID4gPiAgICAgICBSZWRpcmVjdGVkIERhdG Eg IGluIHRoZSBmaXJzdCBUTFYgc2hvdWxkIGFycml2ZSB0aGUgZWFybGllc3QuDQo+ID4gPiA+DQ o+ ID4gPiA+VGhlIFRMViBmb3JtYXQgaXMgYXMgZm9sbG93czoNCj4gPiA+ID4NCj4gPiA+ID4gIC Ag ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgVHlwZSA9IFBBWUxPQUQgICAgIC Ag ICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQo+ID4gPiA+ICAgICAgIC Ag Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB+ICAgICAgICAgUGFja2V0IFR5cGUgICAgICAgIC Ag IHwgICAgICAgICBQYWNrZXQgTGVuZ3RoICAgICAgICAgfg0KPiA+ID4gPiAgICAgICAgICstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rDQo+ID4gPiA+ICAgICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0ZW Qg UGFja2V0ICAgICAgICAgICAgICAgICAgICAgIH4NCj4gPiA+ID4gICAgICAgICArLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw 0K PiA+ID4gPg0KPiA+ID4gPiAgICAgVHlwZToNCj4gPiA+ID4gICAgICAgVGhlIHR5cGUgZm9yIH Ro ZSBUTFYgaXMgc2V0IHRvICdQQVlMT0FEJy4NCj4gPiA+ID4NCj4gPiA+ID4gICAgIExlbmd0aD oN Cj4gPiA+ID4gICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgVExWKGluIDRieXRlcykuDQo+ID4gPi A+ DQo+ID4gPiA+ICAgICBQYWNrZXQgVHlwZToNCj4gPiA+ID4gICAgICAgRGVmaW5lcyB3aGF0IH R5 cGUgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IGJlbG9uZ3MgdG8oc3VjaCBhcyAnSVB2NA0KPiA+ID 4g PiBQYWNrZXQnLA0KPiA+ID4gPiAgICAgICdJUHY2IFBhY2tldCcpLg0KPiA+ID4gPg0KPiA+ID 4g PiAgICAgUGFja2V0IExlbmd0aDoNCj4gPiA+ID4gICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgZm 9s bG93ZWQgcmVkaXJlY3RlZCBwYWNrZXQgKGluIGJ5dGUpDQo+ID4gPiA+DQo+ID4gPiA+ICAgIC BS ZWRpcmVjdGVkIFBhY2tldDoNCj4gPiA+ID4gICAgICAgb25lIHJlZGlyZWN0ZWQgcGFja2V0Lg 0K PiA+ID4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+DQo+ID4gPiA+DQ o+ ID4gPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPkZyb206ICJKb2VsIE 0u IEhhbHBlcm4iIA0KPiA+IDw8bWFpbHRvOmpvZWxAc3RldmVjcm9ja2VyLmNvbT5qb2VsQHN0ZX Zl Y3JvY2tlci5jb20+DQo+ID4gPiA+DQo+ID4gPiA+ID4gSSB3b3VsZCBleHBlY3QgdGhhdCBhIF Jl ZGlyZWN0IE1lc3NhZ2UgaGFzIGEgZGlmZmVyZW50IG91dGVybW9zdCANCj4gPiBUTFYuICBUaG UN Cj4gPiA+ID4gPiBncmFtbWFyIGlzIGludGVuZGVkIHRvIGhlbHAgdXMsIG5vdCBzZXJ2ZSBhcy Bh IA0KPiA+IHN0cmFpZ2h0amFja2V0LiAgRGlmZmVyZW50DQo+ID4gPiA+ID4gbWVzc2FnZSB0eX Bl cyBjYW4gaGF2ZSBkaWZmZXJlbnQgb3V0ZXIgVExWcy4gIEl0IGlzIGRlc2lyYWJsZSB0byANCj 4g PiB1c2UgdGhlDQo+ID4gPiA+ID4gc2FtZSBzdHJ1Y3R1cmUgd2hlbiBpdCBhcHBsaWVzLiAgQn V0 IHRoZSByZWRpcmVjdCBtZXNzYWdlIGlzIHNpbXBseSBhDQo+ID4gPiA+ID4gZGlmZmVyZW50IG Nh c2UuICBJdCdzIGNvbnRlbnRzIGFyZSBub3QgYSBEQVRBUkFXIG11Y2ggbGVzcyBhIERBVEENCj 4g PiA+ID4gVExWLiAgSXRzDQo+ID4gPiA+ID4gY29udGVudCBzdHJ1Y3R1cmUgaXMgbm90IGRlZm lu ZWQgYnkgYW4gTEZCIGVsZW1lbnQgZGVmaW5pdGlvbiBvciBNb2RlbA0KPiA+ID4gPiA+IERhdG FE ZWZzIHN0cnVjdHVyZSBkZWZpbml0aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSWYgd2Ugbm Vl ZCB0byBmaXggdGhlICJncmFtbWFyIiBzZWN0aW9uIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBub3 Qg DQo+ID4gYWxsIFBMDQo+ID4gPiA+ID4gbWVzc2FnZXMgbmVjZXNzYXJpbHkgdXNlIHRoZSBzYW 1l IG91dGVybW9zdCBUTFYsIHdlIHNob3VsZCBkbyANCj4gPiBzby4gICBNeSBvd24NCj4gPiA+ID 4g PiBhcHByb2FjaCB3b3VsZCBiZSB0byBzZXBhcmF0ZSB0aGUgZ3JhbW1hciBpbnRvIGEgZGVmaW 5p dGlvbiBvZiB0aGUNCj4gPiA+ID4gY29udGVudHMNCj4gPiA+ID4gPiBvZiB0aGF0IFRMViwgYW 5k IGEgc2VwYXJhdGUgZGVmaW5pdGlvbiBvZiB3aGljaCBUTFZzIC8gY29udGVudCBhcmUgDQo+ID 4g Y2FycmllZA0KPiA+ID4gPiA+IGluIHRoZSBvdXRlcm1vc3QgbGV2ZWwgb2Ygd2hpY2ggbWVzc2 Fn ZXMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBZb3VycywNCj4gPiA+ID4gPiBKb2VsDQo+ID4gPi A+ ID4NCj4gPiA+ID4gPiBQUzogV2VpbWluZywgSSBhbSBzb3JyeSB5b3UgZ290IGNhdWdodCB1cC Bp biB0aGlzIGNvbmZ1c2lvbi4gIEkgZG9uJ3QNCj4gPiA+ID4gdGhpbmsNCj4gPiA+ID4gPiB5b3 Ug Y3JlYXRlZCB0aGUgdGVuZGVuY3kgSSBhbSByYWlsaW5nIGFnYWluc3QgYWJvdmUuICBJIGFtIG p1 c3QgDQo+ID4gdXNpbmcgeW91cg0KPiA+ID4gPiA+IG1lc3NhZ2UgYXMgYSBzdGFydGluZyBwb2 lu dCB0byBoYW1tZXIgaG9tZSBhIHBvaW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQXQgMDQ6ND Ug QU0gNi8yNi8yMDA1LCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+ID4gPiA+ID4gPk1heWJlIGl0J3 Mg bWUgd2hvIG1pc3NlZCBzb21ldGhpbmcgOikNCj4gPiA+ID4gPiA+TXkgdGhvdWdodCB3YXMgd2 Ug bWlnaHQgbmVlZCB0byBvYmV5IG91ciBtZXNzYWdlIGdyYW1tYXIgd2VsbCB0aGF0IHdlDQo+ID 4g PiA+IGhhdmUNCj4gPiA+ID4gPiA+dG8gdXNlIGEgc3RyaWN0IFBhdGgtZGF0YSBmb3Igb3Blcm F0 aW9uIFRMVi4gIFRvIG9iZXkgdGhlIHJ1bGUsIA0KPiA+IHRyZWF0aW5nDQo+ID4gPiA+ID4gPm l0 IGFzIGFuIGV2ZW50IHdpbGwgZWFzZSB0aGUgbWVzc2FnZSBmb3JtYXQgZ3JlYXRseS4NCj4gPi A+ ID4gPiA+DQo+ID4gPiA+ID4gPkFjdHVhbGx5IEknbSB2ZXJ5IGhhcHB5IHRvIHNlZSB0aGF0IH lv dSBhZ3JlZSBhIHBhdGggY2FuIGJlIA0KPiA+IG9taXR0ZWQgZm9yDQo+ID4gPiA+ID4gPnNvbW Ug c3BlY2lmaWMgbWVzc2FnZXMgbGlrZSByZWRpcmVjdCBtZXNzZ2UuDQo+ID4gPiA+ID4gPg0KPi A+ ID4gPiA+ID5PSywgbGV0J3Mgc29sdmUgaXQgdGhlbiwgdG8gbGV0IHJlZGlyZWN0IG1lc3NhZ2 Ug b25seSBjb250YWluIERhdGENCj4gPiA+ID4gPiA+ZmllbGQ/ICBJIGNhbiB1cGRhdGUgdGhpcy By ZWRpcmVjdCBtZXNzYWdlIHBhcnQgdGV4dCB0aGVuLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPi A+ SmFtYWwsIGNvdWxkIHlvdSBnaXZlIGEgcmVzcG9uc2Ugb24gdGhpcz8NCj4gPiA+ID4gPiA+DQ o+ ID4gPiA+ID4gPk9uZSAgbGVzcyB2aXRhbCBxdWVzdGlvbiBpcywgc2hhbGwgd2UgYWxsb3cgZm 9y IG11bGl0cHVsIHJlZGlyZWN0IA0KPiA+IHBhY2tldHMNCj4gPiA+ID4gPiA+ZW5jYXBzdWxhdG Vk IGluIG9uZSBUTFYgb3IganVzdCBvbmUgVExWIG9ubHkgZm9yIG9uZSBwYWNrZXQ/IFRvIA0KPi A+ IHVzZSB0aGUNCj4gPiA+ID4gPiA+Zm9ybWVyLCB3ZSBoYXZlIHRvIGRlZmluZSBhIHNlcXVlbm Nl IGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIA0KPiA+IHRoZW4gaW4NCj4gPiA+ID4gPiA+dG hl IFRMVi4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPk9uICB0aGUgbWV0YS1pbmZvcm1hdGlvbi By ZWxhdGVkLCBJIHRoaW5rIExGQiBJRHMgaGFzIGFscmVhZHkgYmVlbg0KPiA+ID4gPiA+ID5pbm Ns dWRlZC4gSSBkb24ndCB0aGluayB3ZSBuZWVkIGFuIGV4dHJhIHBvcnQgSUQgdG8gaW5kaWNhdG Ug d2hlcmUgDQo+ID4gdG8gcHV0DQo+ID4gPiA+ID4gPnRoZSByZWRpcmVjdGVkIGRhdGEgdG8gb3 Ig dG8gZ2V0IHJlZGlyZWN0ZWQgZGF0YSBmcm9tLiBBIHJlZGlyZWN0IA0KPiA+IHNvdXJjZQ0KPi A+ ID4gPiA+ID5MRkIgIG9yIHNpbmsgTEZCIHdpbGwgIGhhdmUgYSBwb3J0IElELCB3aGljaCBiZW xv bmdzIHRvIEZFIExGQiANCj4gPiB0b3BvbG9neQ0KPiA+ID4gPiA+ID5jb25jZXB0LCBhbmQgRk Ug TEZCIHRvcG9sZ3kgY29uZmlndXJhdGlvbiBpcyBpbiBjaGFyZ2Ugb2YgDQo+ID4gdGhpcy4gIE 5v dCBzdXJlDQo+ID4gPiA+ID4gPmlmIGl0IGNvbXBsaWVzIHdpdGggeW91ciB0aG91Z2h0Pw0KPi A+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+VGhhbmtzLA0KPiA+ID4gPiA+ID5XZWltaW5nDQo+ID4gPi A+ ID4gPg0KPiA+ID4gPiA+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gPiA+ID 4g PkZyb206ICJKb2VsIE0uIEhhbHBlcm4iDQo+ID4gPiA+ID4gPlN1YmplY3Q6IFJlOiBbaXNzdW Uz Ml0gUGFja2V0IFJlZGlyZWN0DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPi A+ ID4gSSBhbSBtaXNzaWduIHNvbWV0aGluZyBpbiB5b3VyIHN1Z2dlc3Rpb24uDQo+ID4gPiA+ID 4g PiA+DQo+ID4gPiA+ID4gPiA+IFdoeSB3b3VsZCB3ZSB3YW50IHRvIHRyZWF0IHJlZGlyZWN0cy Bh cyBldmVudHM/DQo+ID4gPiA+ID4gPiA+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZGlyZW N0 cy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSSBhbSB2ZXJ5IGNvbmZ1c2VkIGFib3 V0 ICJIb3cgYSBwYXRoIHNob3VsZCBiZSBkZWZpbmVkIGluIGEgUGFja2V0DQo+ID4gPiA+ID4gPi BS ZWRpcmVjdA0KPiA+ID4gPiA+ID4gPiBNZXNzYWdlIiwgc2luY2UgYXMgZmFyIGFzIEkgY2FuIH Rl bGwsIGEgcmVkaXJlY3QgZG9lcyBub3QgbmVlZCBhDQo+ID4gPiA+IHBhdGguICBJdA0KPiA+ID 4g PiA+ID4gPiBuZWVkcyBhIGNvbGxlY3Rpb24gb2YgbWV0YS1pbmZvcm1hdGlvbiwgd2hpY2ggd2 Ug bmVlZCB0bw0KPiA+ID4gPiBkZWZpbmUuICBBdCB0aGUNCj4gPiA+ID4gPiA+ID4gbW9tZW50LC B0 aGF0IGhhcyB0byBpbmNsdWRlIGF0IGxlYXN0IHRoZSBMRkIgSUQgdGhhdCB0aGUgDQo+ID4gcm Vk aXJlY3QgaXMNCj4gPiA+ID4gPiA+IGZyb20gLw0KPiA+ID4gPiA+ID4gPiB0by4gIEkgc3VwcG 9z ZSBieSBkZWNsYXJpbmcgYSBtdWx0aXBsaWNpdHkgb2Ygc3VjaCBMRkJzLCB0aGF0IA0KPiA+IG Nh biBiZQ0KPiA+ID4gPiA+ID4gYWxsIG9mDQo+ID4gPiA+ID4gPiA+IHRoZSBpbmZvcm1hdGlvbi 4g IChJIHVzdWFsbHkgdGhpbmsgaW4gdGVybXMgb2YgYXQgbGVhc3QgYSBsb2dpY2FsDQo+ID4gPi A+ IHBvcnQgSUQNCj4gPiA+ID4gPiA+ID4gdGhlIHBhY2tldCBjYW1lIGZyb20gLyBpcyBpbnRlbm Rl ZCBmb3IuKQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBZb3VycywNCj4gPiA+ID4gPi A+ ID4gSm9lbA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBBdCAxMDo1MCBQTSA2LzI1Lz Iw MDUsIFdlaW1pbmcgV2FuZyB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPkphbWFsLCBKb2VsLCBhbm Qg SG9ybXpkLA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID5JIHN1cHBvc2Ugd2UgY2 91 bGQgY2xvc2UgdGhpcyBpc3N1ZSBieSByZWFjaGluZyB0aGUgZm9sbG93aW5nIA0KPiA+IHBvaW 50 czoNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+MS4gVGhlIHJlZGlyZWN0IExGQn Mg Y2FsbGVkIFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luaw0KPiA+ID4gPiBMRk Ig YXJlDQo+ID4gPiA+ID4gPiA+ID5tb3ZlZCB0byB0aGUgbW9kZWwsIGJ1dCB0aGUgcHJvdG9jb2 wg cmV0YWlucyB0aGUgUmVkaXJlY3QgDQo+ID4gTWVzc2FnZS4gVGhlDQo+ID4gPiA+ID4gPiA+ID 5y ZWFzb24gdG8ga2VlcCB0aGUgc3BlY2lmaWMgbWVzc2FnZSBpcyB3ZSBuZWVkIHRvIHNwZWNpZm lj YWxseQ0KPiA+ID4gPiByZWNvZ25pemUNCj4gPiA+ID4gPiA+ID4gPnJlZGlyZWN0ZWQgZGF0YS Bi ZXR3ZWVuIENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIGF2b2lkIERvUyBhdHRhY2tzLg0KPiA+ID 4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4yLiBUaGUgcmVkaXJlY3RlZCBkYXRhIGluIHRoZS BM RkJzIGNhbiBiZSB0cmVhdGVkIGFzIGEga2luZCBvZiANCj4gPiBTUEVDSUFMDQo+ID4gPiA+ID 4g PiA+ID5ldmVudHMgaW4gdGhhdDoNCj4gPiA+ID4gPiA+ID4gPiAgICAgIGEuIFRoZSBldmVudC Bp cyB0cmlnZ2VyZWQgZXZlcnkgdGltZSBhIG5ldyByZWRpcmVjdGVkIHBhY2tldA0KPiA+ID4gPi A+ ID4gYXJyaXZlcw0KPiA+ID4gPiA+ID4gPiA+IGF0IHRoZSBMRkJzLg0KPiA+ID4gPiA+ID4gPi A+ ICAgICAgYi4gVGhlIGV2ZW50IGlzIHRyYW5zcG9ydGVkIGJ5IHRoZSBSZWRpcmVjdCAgTWVzc2 Fn ZSBvbmx5LA0KPiA+ID4gPiB3aGlsZQ0KPiA+ID4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiA+ID 4g UmVkaXJlY3QgTWVzc2FnZSB3aWxsIHRoZSBzYW1lIG1lc3NhZ2UgZm9ybWF0IGFzIGEgZ2VuZX Jh bCBldmVudA0KPiA+ID4gPiA+ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQgdG hl IG1lc3NhZ2UgdHlwZSBpbiB0aGUgaGVhZGVyKS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPi A+ ID4gPiA+QnkgZG9pbmcgaW4gdGhpcyB3YXksIHdlIGNhbiBhbHNvIHNvbHZlIHRoZSBpc3N1ZT Uz IChIb3cgYSBwYXRoDQo+ID4gPiA+IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID4gPiA+ZGVmaW5lZC Ag aW4gUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UpIHRoZW4uDQo+ID4gPiA+ID4gPiA+ID4NCj4gPi A+ ID4gPiA+ID4gPlVuZm9ydHVuYXRlbHksICBJIHRoaW5rIG9mIGFub3RoZXIgcXVlc3Rpb24gdG hh dCBpcyByZWxhdGVkIHRvIA0KPiA+IHRoZQ0KPiA+ID4gPiBQYWNrZXQNCj4gPiA+ID4gPiA+ID 4g PlJlZGlyZWN0IE1lc3NhZ2UgYXMgd2VsbCBhcyB0byBFdmVudCBOb3RpZmljYXRpb24gTWVzc2 Fn ZS4gVGhlDQo+ID4gPiA+IHF1ZXN0aW9uDQo+ID4gPiA+ID4gPiA+ID5pcywgdGhlIEV2ZW50IE 5v dGlmaWNhdGlvbiBNZXNzYWdlIGFsbG93cyBldmVudCBnZW5lcmF0ZWQgYnkgQ0UNCj4gPiA+ID 4g YW5kIHNlbnQNCj4gPiA+ID4gPiA+ID4gPnRvIEZFLiBJbiB0aGUgY2FzZSwgaW4gdGhlIG1lc3 Nh Z2UgZm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0bw0KPiA+ID4gPiB0aGUgTEZCcw0KPiA+ID 4g PiA+ID4gPiA+dGhhdCB3aWxsIHJlY2VpdmUgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiwgYnV0IH Ro ZSBxdWVzdGlvbiBpcywNCj4gPiA+ID4gd2hhdCB0aGUNCj4gPiA+ID4gPiA+ID4gPlBhdGggaW 4g dGhlIG1lc3NhZ2UgcmVmZXJzIHRvIHRoZW4gPz8gIFRoZSBzYW1lIGFsc28gaGFwcGVucyANCj 4g PiB0byBQYWNrZXQNCj4gPiA+ID4gPiA+ID4gPlJlZGlyZWN0IE1lc3NhZ2UgZnJvbSBDRSB0by BG RS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+VGhhbmtzLA0KPiA+ID4gPiA+ID 4g PiA+V2VpbWluZw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4tLS0tLSBPcmlnaW 5h bCBNZXNzYWdlIC0tLS0tDQo+ID4gPiA+ID4gPiA+ID5Gcm9tOiAiQXZyaSBEb3JpYSINCj4gPi A+ ID4gPDxtYWlsdG86dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+dHJhY2tlci1mb3JjZXNAbWlwNC 5v cmc+DQo+ID4gPiA+ID4gPiA+ID5UbzogDQo+ID4gPDxtYWlsdG86Rk9SQ0VTQFBFQUNILkVBU0 Uu TFNPRlQuQ09NPkZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NCj4gPiA+ID4gPiA+ID4gPl Nl bnQ6IE1vbmRheSwgTWF5IDIzLCAyMDA1IDI6MzUgQU0NCj4gPiA+ID4gPiA+ID4gPlN1YmplY3 Q6 IFtpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID 4g PiA+DQo+ID4gPiA+ID4gPiA+ID5OZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgDQo+ID 4g PDxtYWlsdG86YXZyaUBhY20ub3JnPmF2cmlAYWNtLm9yZz46DQo+ID4gPiA+ID4gPiA+ID4NCj 4g PiA+ID4gPiA+ID4gPjYuOA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gIEVkaX Rv cmlhbCBOb3RlOiAgVGhlcmUgYXJlIGFsc28gZGlzY3Vzc2lvbnMgb24gaG93IExGQnMgaW4gDQ o+ ID4gRkUgbW9kZWwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHRoYXQgYX Jl IHJlbGF0ZWQgdG8gcGFja2V0IHJlZGlyZWN0IA0KPiA+IG9wZXJhdGlvbnMNCj4gPiA+ID4gPi A+ ID4gPiAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBiZSBkZWZpbmVkLiAgQWx0aG91Z2ggaX Qg aXMgb3V0IG9mIA0KPiA+IHRoZQ0KPiA+ID4gPiBzY29wZQ0KPiA+ID4gPiA+ID4gPiA+ICAgIC Ag ICAgICAgICAgICAgICAgb2YgZm9yY2VzIHByb3RvY29sLCBob3cgdG8gZGVmaW5lIHRoZSANCj 4g PiBMRkJzIGFmZmVjdA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgdGhlIF Bh Y2tldCBSZWRpcmVjdCBNZXNzYWdlIGRlc2NyaWJlZA0KPiA+ID4gPiBoZXJlLiAgQmVjYXVzZQ 0K PiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgY3VycmVudGx5IGl0IGlzIHN0aW xs IGluIHByb2dyZXNzIGluIEZFIA0KPiA+IG1vZGVsDQo+ID4gPiA+IG9uIGhvdw0KPiA+ID4gPi A+ ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgdG8gZGVmaW5lIHN1Y2ggTEZCcywgd2UgdHJ5IH Rv IHBvc3Qgc29tZQ0KPiA+ID4gPiB0aG91Z2h0cyBvbg0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIC Ag ICAgICAgICAgICAgdGhpcyBoZXJlIGZvciBkaXNjdXNzaW9uLiAgVGhleSB3aWxsIGJlIA0KPi A+ IHJlbW92ZWQNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGxhdGVyIGFsb2 5n IHdpdGggdGhlIHByb2dyZXNzIG9mIHRoZSBGRSANCj4gPiBtb2RlbA0KPiA+ID4gPiB3b3JrLg 0K PiA+ID4gPiA+ID4gPiA+ICAgICAgICAgVGhvdWdodCAxOiAgVG8gZGVmaW5lIExGQnMgY2FsbG Vk ICdSZWRpcmVjdFNpbmsnIGFuZA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIC Ag J1JlZGlyZWN0VGFwJyBmb3IgcGFja2V0IHJlZGlyZWN0Lg0KPiA+ID4gPiA+ID4gPiA+ICAgIC Ag ICAgICAgICAgICAgICAgQW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBpcw0KPi A+ ID4gPiByZXNwb25zaWJsZSB0bw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIC Ag Y29sbGVjdCBkYXRhIHBhY2tldHMgdGhhdCBuZWVkIHRvIGJlDQo+ID4gPiA+IHJlZGlyZWN0ZW Qg dG8NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIENFLiAgRnJvbSB0aGUgcG Vy c3BlY3RpdmUgb2YgdGhlIEZFIExGQiANCj4gPiB0b3BvbG9neSwNCj4gPiA+ID4gPiA+ID4gPi Ag ICAgICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgaXMgYW4gTEZCIHdpdG gg b25seQ0KPiA+ID4gPiBvbmUgaW5wdXQNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgIC Ag ICAgIHBvcnQgYW5kIHdpdGhvdXQgYW55IG91dHB1dCBwb3J0LCBhbmQgdGhlDQo+ID4gPiA+IG lu cHV0IHBvcnQNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGNhbiB0aGVuIG Jl IGNvbm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFDQo+ID4gPiA+IG1vZGVsDQo+ID4gPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIH Ro ZSBmb3J3YXJkaW5nIA0KPiA+IHBsYW5lLg0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgIC Ag ICAgICAgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIEZvckNFUyBwcm90b2NvbA0KPiA+ID 4g PiBsYXllciwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHRoZSAnUmVkaX Jl Y3RTaW5rJyBMRkIgd2lsbCBnZW5lcmF0ZSB0aGUgDQo+ID4gUGFja2V0DQo+ID4gPiA+ID4gPi A+ ID4gICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdCBNZXNzYWdlcyB3aGVuIGl0IHJlY2Vpdm Vz IGRhdGENCj4gPiA+ID4gcGFja2V0cyBmcm9tDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgIC Ag ICAgICAgICBmb3J3YXJkaW5nIHBsYW5lLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPi A+ ID4gICAgICAgICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFRhcC cg aXMNCj4gPiA+ID4gcmVzcG9uc2libGUgdG8NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgIHJlY2VpdmUgZGF0YSBwYWNrZXRzIHRoYXQgYXJlIHJlZGlyZWN0ZWQgDQo+ID4gZn Jv bSBDRS4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIEZyb20gdGhlIHBlcn Nw ZWN0aXZlIG9mIHRoZSBGRSBMRkIgDQo+ID4gdG9wb2xvZ3ksIHRoZQ0KPiA+ID4gPiA+ID4gPi A+ ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb2 5s eSBvbmUgDQo+ID4gb3V0cHV0DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgIC Bw b3J0IGFuZCB3aXRob3V0IGFueSBpbnB1dCBwb3J0LCBhbmQgdGhlDQo+ID4gPiA+IG91dHB1dC Bw b3J0DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBjYW4gdGhlbiBiZSBjb2 5u ZWN0ZWQgdG8gYW55IG90aGVyIExGQiBpbiBGRQ0KPiA+ID4gPiBtb2RlbA0KPiA+ID4gPiA+ID 4g PiA+ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm 9y d2FyZGluZyANCj4gPiBwbGFuZS4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgIC Ag IEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIEZvckNFUyBwcm90b2NvbA0KPiA+ID4gPiBsYXllci wg dGhlDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJlY3RUYXAnIE xG QiBjYW4gcmVjZWl2ZSB0aGUgUGFja2V0IA0KPiA+IFJlZGlyZWN0DQo+ID4gPiA+ID4gPiA+ID 4g ICAgICAgICAgICAgICAgICAgICBNZXNzYWdlcyBmcm9tIENFLCBhbmQgdW4tZW5jYXBzdWxhdG Ug dGhlIGRhdGENCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHBhY2tldHMgZn Jv bSB0aGUgbWVzc2FnZSBhbmQgcHV0IHRoZW0gdG8NCj4gPiA+ID4gZGF0YXBhdGhzDQo+ID4gPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gIE Fj dHVhbGx5IHRoZQ0KPiA+ID4gPiAnUmVjaXJlY3RUYXAnDQo+ID4gPiA+ID4gPiA+ID4gICAgIC Ag ICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxpa2UgYSB0cmFuc2NvZGVyIHRoYXQNCj4gPi A+ ID4gdHJhbnNmZXJzIHRoZQ0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRm 9y Q0VTIHByb3RvY29sIG1lc3NhZ2VzIHRvIG5vcm1hbCBkYXRhDQo+ID4gPiA+IHBhY2tldHMgaW 4N Cj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIElQIGZvcndhcmRpbmcgcGxhbm Uu ICBBcyBhIHJlc3VsdCwgaWYgd2UgDQo+ID4gbmVlZCB0bw0KPiA+ID4gPiA+ID4gPiA+ICAgIC Ag ICAgICAgICAgICAgICAgaGF2ZSByZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbW Ug DQo+ID4gTEZCDQo+ID4gPiA+IChzYXkgYQ0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgIC Ag ICAgICAgU2NoZWR1bGVyKSBpbiBGRSBtb2RlbCwgd2Ugb25seSBuZWVkIHRvDQo+ID4gPiA+IG Nv bm5lY3QgdGhlDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJlY3 RU YXAgTEZCIHRvIHRoZSBTY2hlZHVsZXIgTEZCDQo+ID4gPiA+IGRpcmVjdGx5IHZpYSBhDQo+ID 4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KPi A+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgDQo+ID4gKy0tLS0tLS0tLS 0t Kw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWRpcm Vj dFRhcCBMRkIgDQo+ID4gfC0tLS0tLT58ICAgICAgICAgICB8DQo+ID4gPiA+ID4gPiA+ID4gIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgIHwgDQ o+ ID4gICAgICAgfA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiA+IFNjaGVkdWxlciB8DQo+ID4gPiA+ID 4g PiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJvbSBvdGhlciANCj4gPi BM RkIgICAtLS0tPnwgICAgTEZCICAgIHwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gPiAgICAgICB8DQ o+ ID4gPiA+ID4gPiA+ID4gDQo+ID4gKy0tLS0tLS0tLS0tKw0KPiA+ID4gPiA+ID4gPiA+DQo+ID 4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyNw0KPi A+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBCeSB1c2 Ug b2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW5rJyBMRkJzIGFuZCANCj4gPiBzZXZlcmFsDQo+ID4gPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJlY3RUYXAnIExGQnMgdGhhdCBjb2 5u ZWN0IHRvIHNldmVyYWwNCj4gPiA+ID4gZGlmZmVyZW50DQo+ID4gPiA+ID4gPiA+ID4gICAgIC Ag ICAgICAgICAgICAgICBkYXRhcGF0aHMgaW4gRkUgZm9yd2FyZGluZyBwbGFuZSwgDQo+ID4gbX Vs dGlwbGUgcGFja2V0DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICByZWRpcm Vj dCBwYXRocyBiZXR3ZWVuIENFIGFuZCBGRSBjYW4gYmUNCj4gPiA+ID4gY29uc3RydWN0ZWQuDQ o+ ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgIFRob3VnaHQgMjogIFRoZX Jl IG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQo+ID4gPiA+ID4gPiA+ID 4g ICAgICAgICAgICAgICAgICAgICByZWRpcmVjdGVkOiBkaXJlY3RseSBieSBhIGZvcndhcmRpbm cg cGF0aCwNCj4gPiA+ID4gZS5nLiwgYnkNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgIC Ag ICAgIEZQR0EvQVNJQy9OUCBtaWNyb2NvZGUuICBJbiBzdWNoIGEgY2FzZSANCj4gPiB3ZSBkby Bu b3QNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gcHV0IGluIG Eg bG90IG9mIHNtYXJ0bmVzcy4gIFByb2JhYmx5DQo+ID4gPiA+IGEgbGluaw0KPiA+ID4gPiA+ID 4g PiA+ICAgICAgICAgICAgICAgICAgICAgbGF5ZXIgb3IgZXZlbiBuZXR3b3JrIGxldmVsIGhlYW Rl ciBpcw0KPiA+ID4gPiBlbm91Z2guICBUaGUNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgIHJlY2VpdmVyIGRlbXV4ZXMgaXQgb25seSBiYXNlZCBvbiBzb21lDQo+ID4gPiA+IH By b3RvY29sIHR5cGUNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGluIHRoZS Bs aW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNwb3J0DQo+ID4gPiA+IGxheWVyLiAgVGhlDQo+ID 4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBwcm9zIGZvciB0aGlzIGFwcHJhb2NoIG lz IGl0IG1heSBwcm92aWRlIGENCj4gPiA+ID4gZmFzdCBhbmQNCj4gPiA+ID4gPiA+ID4gPiAgIC Ag ICAgICAgICAgICAgICAgIGNvc3QtZWZmZWN0aXZlIHBhdGggZm9yIHBhY2tldCANCj4gPiByZW Rp cmVjdC4gIFRoZQ0KPiA+ID4gPiBjb25zDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgIC Ag ICAgICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIA0KPiA+IHRoZS BG cA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcmVmZXJlbmNlIHBvaW50IG Rl ZmluaXRpb24gaW4gRm9yQ0VTIA0KPiA+IGZyYW1ld29yay4NCj4gPiA+ID4gPiA+ID4gPg0KPi A+ ID4gPiA+ID4gPiA+LS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gPiA+Y2F0ZWdvcnk6IEVkaXRvcm lh bA0KPiA+ID4gPiA+ID4gPiA+ZHJhZnQ6IGRyYWZ0LWlldGYtZm9yY2VzLXByb3RvY29sDQo+ID 4g PiA+ID4gPiA+ID5tZXNzYWdlczogNDkNCj4gPiA+ID4gPiA+ID4gPm5vc3k6IGF2cmkNCj4gPi A+ ID4gPiA+ID4gPnByaW9yaXR5OiBNdXN0IGZpeA0KPiA+ID4gPiA+ID4gPiA+c3RhdHVzOiBOby Bk aXNjdXNzaW9uDQo+ID4gPiA+ID4gPiA+ID50aXRsZTogUGFja2V0IFJlZGlyZWN0DQo+ID4gPi A+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gPiA+Rm9yY2VzIGlzc3VlIHRyYWNrZX IN Cj4gPiA+ID4gPDxtYWlsdG86dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+dHJhY2tlci1mb3JjZX NA bWlwNC5vcmc+DQo+ID4gPiA+ID4gPiA+ID48aHR0cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdH Jh Y2tlci9mb3JjZXMvaXNzdWUzMj4NCj4gPiA+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gPg== 2005 Message-Id: Date: Tue, 28 Jun 2005 09:56:56 +0800 From: Weiming Wang 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 Sm9lbCwNCg0KPiAgICAgIFRoZSBQYWNrZXQgUmVkaXJlY3QgbWVzc2FnZSBjb250YWlucyBvbm Ug b3IgbW9yZSAodHlwaWNhbGx5IG9uZSkgDQo+IHBhY2tldC1yZWRpcmVjdCBUTFZzLg0KDQpJZi BJ IHVuZGVyc3RhbmQgeW91ciBhYm92ZSB0aG91Z2h0IGNvcnJlY3RseSwgSSB0aGluayB5b3VyIH By b3Bvc2FsICBpcyB0byBkZWZpbmUgYSAgcGFja2V0LXJlZGlyZWN0IFRMViByYXRoYW4gdGhhbi Bh IExGQnNlbGVjdFRMViBhdCB0aGUgdG9wIGxldmVsIGZvciB0aGUgbWVzc2FnZS4gSW4gdGhpcy B3 YXkgaXQgd2lsbCBsZWF2ZSBMRkIgc2VsZWN0aW9uIGluZm9ybWF0aW9uIGFzIGtpbmRzIG9mIG 1l dGEtaW5mbyBhbmQgaW5zaWRlIHRoZSBUTFYsIHNvbWV0aGluZyBsaWtlOg0KDQo+ID4gICAgIC Ag ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAgICAgICAgVHlwZSA9IFBhY2tldC1SZWRpcmVjdC Ag ICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQo+ID4gICAgICAgICArLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKw0KPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIE lE ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gIC Ag ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgIC Ag ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgIHwgICAgIC Ag ICAgICAgICAgICAgICAgICBPcGVyYXRpb24gVExWICAgICAgICAgICAgICAgICAgICAgICAgIC B8 DQo+ID4gICAgICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgLg0KPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTm93LCB0aG Ug cXVlc3Rpb24gaXMgSSBkbyBmaW5kIHRoaXMgZm9ybWF0IGlzIG5vdCB2ZXJ5IGRpZmZlcmVudC B3 aXRoIHRoYXQgSSBwcm9wb3NlZC4gRG8gSSBtaXNzIHNvbWV0aGluZz8NCg0KVGhhbmtzLA0KV2 Vp bWluZw0KDQoNCj4gSSB3b3VsZCBhcHByb2FjaCB0aGlzIGRpZmZlcmVudGx5LiAgVGhlIGN1cn Jl bnQgdGV4dCBkZXNjcmliZXMgdGhlIA0KPiBMRkJzZWxlY3QgTEZCLiAgSXQgY29ycmVjdGx5IG Rl ZmluZXMgdGhlIExGQnNlbGVjdCBMRkIuICBUaGF0IGRlZmluaXRpb24gDQo+IHNob3VsZCBub3 Qg YmUgdGhyb3duIGF3YXkuDQo+IA0KPiBUaGUgbWVzc2FnZSBzdHJ1Y3R1cmUgZG9jdW1lbnRhdG lv biBjYW4gc2F5DQo+ICAgICBBIFBMIHByb3RvY29sIG1lc3NhZ2VzIGNvbnNpc3RzIG9mIGEgcH Jv dG9jb2wgaGVhZGVyIGZvbGxvd2VkIGJ5IG9uZSBvciANCj4gbW9yZSBUTFZzLiAgQWxsIFRMVn MN Cj4gICAgIGNvbnNpc3Qgb2YgIHR3byBieXRlIHR5cGUgYW5kIGEgdHdvIGJ5dGUgbGVuZ3RoLC Bm b2xsb3dlZCBieSBjb250ZW50cyANCj4gZGVwZW5kZW50IHVwb24gdGhlIHR5cGUNCj4gICAgIG 9m IHRoZSBUTFYuICBUaGUgVExWcyB3aGljaCBhcmUgdmFsaWQgaW4gYSBtZXNzYWdlIGRlcGVuZC B1 cG9uIHRoZSANCj4gbWVzc2FnZSB0eXBlLg0KPiAgICAgTW9zdCBtZXNzYWdlIHR5cGVzIGFsbG 93 IG9uZSBvciBtb3JlIExGQnNlbGVjdCBUTFZzIGFuZCBubyBvdGhlciB0b3AgDQo+IGxldmVsIF RM VnMuICBUaGUNCj4gICAgIGZvbGxvd2luZyBhcmUgdGhlIG1lc3NhZ2UgdHlwZXMgdGhpcyBhcH Bs aWVzIHRvOg0KPiAgICAgICAgQXNzb2NpYXRpb24gc2V0dXAgcmVxdWVzdCBhbmQgcmVzcG9uc2 Uu DQo+ICAgICAgICBDb25maWcgbWVzc2FnZSByZXF1ZXN0IGFuZCByZXNwb25zZQ0KPiAgICAgIC Ag UXVlcnkgbWVzc2FnZSByZXF1ZXN0IGFuZCByZXNwb25zZQ0KPiAgICAgICAgRXZlbnQgTm90aW Z5 IG1lc3NhZ2UuDQo+ICAgICBUaGUgQXNzb2NpYXRpb24gdGVhcmRvd24gbWVzc2FnZSBjb250YW lu cyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgDQo+IHRlYXJkb3duLWNhdXNlIFRMVi4NCj4gIC Ag IFRoZSBoZWFydGJlYXQgbWVzc2FnZSBjb250YWlucyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aG Ug aGVhdHJiZWF0IA0KPiBUTFYuICAoVW5sZXNzIHdlIGRlY2lkZQ0KPiAgICAgIHRvIGp1c3QgdX Nl IGFuIGV2ZW50IGZvciBoZWFydGJlYXRzLiAgSSBkb24ndCByZW1lbWJlciB3aGVyZSB0aGF0IA 0K PiBkaXNjdXNzaW9uIHN0YW5kcy4pDQo+ICAgICAgVGhlIFBhY2tldCBSZWRpcmVjdCBtZXNzYW dl IGNvbnRhaW5zIG9uZSBvciBtb3JlICh0eXBpY2FsbHkgb25lKSANCj4gcGFja2V0LXJlZGlyZW N0 IFRMVnMuDQo+IFRoaXMgaXMgdGhlbiBmb2xsb3dlZCBieSBhIHNlY3Rpb24gZm9yIGVhY2ggb2 Yg dGhlc2UgdG9wIGxldmVsIFRMVnMuDQo+IA0KPiBZb3VycywNCj4gSm9lbCBNLiBIYWxwZXJuDQ o+ IA0KPiBBdCAxMDowMSBBTSA2LzI3LzIwMDUsIFdlaW1pbmcgV2FuZyB3cm90ZToNCj4gPkpvZW wg OikNCj4gPg0KPiA+SG93IGFib3V0IHdlIGp1c3Qgb2Jzb2xldGUgdGhlIHBhdGggZnJvbSB0aG Ug ZGF0YSBzdHJ1Y3R1cmUgYW5kIGFkZCBzb21lDQo+ID5tZXRhLWluZm9ybWF0aW9uLCBhbmQgZm 9y bSB0aGUgZm9ybWF0IGFzIGJlbG93IChJIGN1cnJlbnRseSBjYW4gb25seSB0aGluaw0KPiA+b2 Yg dGhlIG1ldGEtaW5mb3JtYXRpb24gYXMgdGhlIHBhY2tldCB0eXBlLiBXZSBtYXkgYWRkIHNvbW Ug bW9yZSBsYXRlcikuDQo+ID4NCj4gPkNvdWxkIHlvdSBnaXZlIG1vcmUgY29tbWVudHMgb24gdG hp cywgdGhlbiB3ZSBtYXkgc29sdmUgdGhpcyBpc3N1ZSBzb29uPw0KPiA+DQo+ID5UaGFuayB5b3 Ug dmVyeSBtdWNoLg0KPiA+DQo+ID5XZWltaW5nDQo+ID4NCj4gPi0tLS0tLS0tLS0tLS0tLS0tLS 0t LQ0KPiA+TWVzc2FnZSBCb2R5Og0KPiA+ICAgICAgIENvbnNpc3RzIG9mIG9uZSBvciBtb3JlIF RM VnMsIHdpdGggZXZlcnkgVExWIGhhdmluZyB0aGUgZm9sbG93aW5nDQo+ID4gICAgICAgZGF0YS Bm b3JtYXQ6DQo+ID4NCj4gPiAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0ID Ug NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+ICAgICAgICAgKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj 4g PiAgICAgICAgIHwgICAgICAgIFR5cGUgPSBMRkJzZWxlY3QgICAgICAgfCAgICAgICAgICAgIC Ag IExlbmd0aCAgICAgICAgICB8DQo+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgICAgfC Ag ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgIC Ag ICAgIHwNCj4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgICAgICB8ICAgICAgICAgICAgIC Ag ICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+IC Ag ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcG Vy YXRpb24gVExWICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAuICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag Lg0KPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgIH4gICAgICAgICAgICAgICAgIC Ag ICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+DQo+ID4gICAgIC Ag ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdG lv biBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgIC4gICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQ o+ ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKw0KPiA+DQo+ID4gICAgTEZCIGNsYXNzIElEOg0KPiA+ICAgIC Ag IFRoZXJlIGFyZSBvbmx5IHR3byBwb3NzaWJsZSBMRkIgY2xhc3NlcyBoZXJlLCB0aGUgJ1JlZG ly ZWN0U2luaycNCj4gPiAgICAgICBMRkIgb3IgdGhlICdSZWRpcmVjdFNvdXJjZScgTEZCLiAgSW Yg dGhlIG1lc3NhZ2UgaXMgZnJvbSBGRSB0byBDRSwNCj4gPiAgICAgICB0aGUgTEZCIGNsYXNzIH No b3VsZCBiZSAnUmVkaXJlY3RTaW5rJy4gIElmIHRoZSBtZXNzYWdlIGlzIGZyb20gQ0UNCj4gPi Ag ICAgICB0byBGRSwgdGhlIExGQiBjbGFzcyBzaG91bGQgYmUgJ1JlZGlyZWN0U291cmNlJy4NCj 4g PiAgICBJbnN0YW5jZSBJRDoNCj4gPiAgICAgICBJbnN0YW5jZSBJRCBmb3IgdGhlICdSZWRpcm Vj dFNpbmsnIExGQiBvciAnUmVkaXJlY3RTb3VyY2UnIExGQi4NCj4gPiAgICBPcGVyYXRpb24gVE xW Og0KPiA+ICAgICAgIFRoaXMgaXMgYSBUTFYgZGVzY3JpYmluZyBvbmUgcGFja2V0IG9mIGRhdG Eg dG8gYmUgZGlyZWN0ZWQgdmlhIHRoZQ0KPiA+ICAgICAgIHNwZWNpZmllZCBMRkIgYWJvdmUuIC BU aGUgb3JkZXIgb2YgdGhlIFRMViBhcHBlYXJlZCBpcyBhbHNvIHRoZQ0KPiA+ICAgICAgIG9yZG Vy IHRoZSBkYXRhIHBhY2tldCBhcnJpdmVzIHRoZSByZWRpcmVjdG9yIExGQiwgdGhhdCBpcywgdG hl DQo+ID4gICAgICAgUmVkaXJlY3RlZCBEYXRhICBpbiB0aGUgZmlyc3QgVExWIHNob3VsZCBhcn Jp dmUgdGhlIGVhcmxpZXN0Lg0KPiA+DQo+ID5UaGUgVExWIGZvcm1hdCBpcyBhcyBmb2xsb3dzOg 0K PiA+DQo+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAgICBUeXBlID0gUEFZTE 9B RCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCj4gPiAgIC Ag ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rDQo+ID4gICAgICAgICB+ICAgICAgICAgUGFja2V0IFR5cGUgICAgICAgIC Ag IHwgICAgICAgICBQYWNrZXQgTGVuZ3RoICAgICAgICAgfg0KPiA+ICAgICAgICAgKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS sN Cj4gPiAgICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdGVkIFBhY2tldC Ag ICAgICAgICAgICAgICAgICAgICB+DQo+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+DQo+ID4gIC Ag IFR5cGU6DQo+ID4gICAgICAgVGhlIHR5cGUgZm9yIHRoZSBUTFYgaXMgc2V0IHRvICdQQVlMT0 FE Jy4NCj4gPg0KPiA+ICAgICBMZW5ndGg6DQo+ID4gICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgVE xW KGluIDRieXRlcykuDQo+ID4NCj4gPiAgICAgUGFja2V0IFR5cGU6DQo+ID4gICAgICAgRGVmaW 5l cyB3aGF0IHR5cGUgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IGJlbG9uZ3MgdG8oc3VjaCBhcyAnSV B2 NCANCj4gPiBQYWNrZXQnLA0KPiA+ICAgICAgJ0lQdjYgUGFja2V0JykuDQo+ID4NCj4gPiAgIC Ag UGFja2V0IExlbmd0aDoNCj4gPiAgICAgICB0aGUgbGVuZ3RoIG9mIHRoZSBmb2xsb3dlZCByZW Rp cmVjdGVkIHBhY2tldCAoaW4gYnl0ZSkNCj4gPg0KPiA+ICAgICBSZWRpcmVjdGVkIFBhY2tldD oN Cj4gPiAgICAgICBvbmUgcmVkaXJlY3RlZCBwYWNrZXQuDQo+ID4tLS0tLS0tLS0tLS0tLS0tLS 0t LS0tLS0tLS0tLQ0KPiA+DQo+ID4NCj4gPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj 4g PkZyb206ICJKb2VsIE0uIEhhbHBlcm4iIDw8bWFpbHRvOmpvZWxAc3RldmVjcm9ja2VyLmNvbT 5q b2VsQHN0ZXZlY3JvY2tlci5jb20+DQo+ID4NCj4gPiA+IEkgd291bGQgZXhwZWN0IHRoYXQgYS BS ZWRpcmVjdCBNZXNzYWdlIGhhcyBhIGRpZmZlcmVudCBvdXRlcm1vc3QgVExWLiAgVGhlDQo+ID 4g PiBncmFtbWFyIGlzIGludGVuZGVkIHRvIGhlbHAgdXMsIG5vdCBzZXJ2ZSBhcyBhIHN0cmFpZ2 h0 amFja2V0LiAgRGlmZmVyZW50DQo+ID4gPiBtZXNzYWdlIHR5cGVzIGNhbiBoYXZlIGRpZmZlcm Vu dCBvdXRlciBUTFZzLiAgSXQgaXMgZGVzaXJhYmxlIHRvIHVzZSB0aGUNCj4gPiA+IHNhbWUgc3 Ry dWN0dXJlIHdoZW4gaXQgYXBwbGllcy4gIEJ1dCB0aGUgcmVkaXJlY3QgbWVzc2FnZSBpcyBzaW 1w bHkgYQ0KPiA+ID4gZGlmZmVyZW50IGNhc2UuICBJdCdzIGNvbnRlbnRzIGFyZSBub3QgYSBEQV RB UkFXIG11Y2ggbGVzcyBhIERBVEEgDQo+ID4gVExWLiAgSXRzDQo+ID4gPiBjb250ZW50IHN0cn Vj dHVyZSBpcyBub3QgZGVmaW5lZCBieSBhbiBMRkIgZWxlbWVudCBkZWZpbml0aW9uIG9yIE1vZG Vs DQo+ID4gPiBEYXRhRGVmcyBzdHJ1Y3R1cmUgZGVmaW5pdGlvbi4NCj4gPiA+DQo+ID4gPiBJZi B3 ZSBuZWVkIHRvIGZpeCB0aGUgImdyYW1tYXIiIHNlY3Rpb24gdG8gbWFrZSBpdCBjbGVhciB0aG F0 IG5vdCBhbGwgUEwNCj4gPiA+IG1lc3NhZ2VzIG5lY2Vzc2FyaWx5IHVzZSB0aGUgc2FtZSBvdX Rl cm1vc3QgVExWLCB3ZSBzaG91bGQgZG8gc28uICAgTXkgb3duDQo+ID4gPiBhcHByb2FjaCB3b3 Vs ZCBiZSB0byBzZXBhcmF0ZSB0aGUgZ3JhbW1hciBpbnRvIGEgZGVmaW5pdGlvbiBvZiB0aGUgDQ o+ ID4gY29udGVudHMNCj4gPiA+IG9mIHRoYXQgVExWLCBhbmQgYSBzZXBhcmF0ZSBkZWZpbml0aW 9u IG9mIHdoaWNoIFRMVnMgLyBjb250ZW50IGFyZSBjYXJyaWVkDQo+ID4gPiBpbiB0aGUgb3V0ZX Jt b3N0IGxldmVsIG9mIHdoaWNoIG1lc3NhZ2VzLg0KPiA+ID4NCj4gPiA+IFlvdXJzLA0KPiA+ID 4g Sm9lbA0KPiA+ID4NCj4gPiA+IFBTOiBXZWltaW5nLCBJIGFtIHNvcnJ5IHlvdSBnb3QgY2F1Z2 h0 IHVwIGluIHRoaXMgY29uZnVzaW9uLiAgSSBkb24ndCANCj4gPiB0aGluaw0KPiA+ID4geW91IG Ny ZWF0ZWQgdGhlIHRlbmRlbmN5IEkgYW0gcmFpbGluZyBhZ2FpbnN0IGFib3ZlLiAgSSBhbSBqdX N0 IHVzaW5nIHlvdXINCj4gPiA+IG1lc3NhZ2UgYXMgYSBzdGFydGluZyBwb2ludCB0byBoYW1tZX Ig aG9tZSBhIHBvaW50Lg0KPiA+ID4NCj4gPiA+IEF0IDA0OjQ1IEFNIDYvMjYvMjAwNSwgV2FuZy xX ZWltaW5nIHdyb3RlOg0KPiA+ID4gPk1heWJlIGl0J3MgbWUgd2hvIG1pc3NlZCBzb21ldGhpbm cg OikNCj4gPiA+ID5NeSB0aG91Z2h0IHdhcyB3ZSBtaWdodCBuZWVkIHRvIG9iZXkgb3VyIG1lc3 Nh Z2UgZ3JhbW1hciB3ZWxsIHRoYXQgd2UgDQo+ID4gaGF2ZQ0KPiA+ID4gPnRvIHVzZSBhIHN0cm lj dCBQYXRoLWRhdGEgZm9yIG9wZXJhdGlvbiBUTFYuICBUbyBvYmV5IHRoZSBydWxlLCB0cmVhdG lu Zw0KPiA+ID4gPml0IGFzIGFuIGV2ZW50IHdpbGwgZWFzZSB0aGUgbWVzc2FnZSBmb3JtYXQgZ3 Jl YXRseS4NCj4gPiA+ID4NCj4gPiA+ID5BY3R1YWxseSBJJ20gdmVyeSBoYXBweSB0byBzZWUgdG hh dCB5b3UgYWdyZWUgYSBwYXRoIGNhbiBiZSBvbWl0dGVkIGZvcg0KPiA+ID4gPnNvbWUgc3BlY2 lm aWMgbWVzc2FnZXMgbGlrZSByZWRpcmVjdCBtZXNzZ2UuDQo+ID4gPiA+DQo+ID4gPiA+T0ssIG xl dCdzIHNvbHZlIGl0IHRoZW4sIHRvIGxldCByZWRpcmVjdCBtZXNzYWdlIG9ubHkgY29udGFpbi BE YXRhDQo+ID4gPiA+ZmllbGQ/ICBJIGNhbiB1cGRhdGUgdGhpcyByZWRpcmVjdCBtZXNzYWdlIH Bh cnQgdGV4dCB0aGVuLg0KPiA+ID4gPg0KPiA+ID4gPkphbWFsLCBjb3VsZCB5b3UgZ2l2ZSBhIH Jl c3BvbnNlIG9uIHRoaXM/DQo+ID4gPiA+DQo+ID4gPiA+T25lICBsZXNzIHZpdGFsIHF1ZXN0aW 9u IGlzLCBzaGFsbCB3ZSBhbGxvdyBmb3IgbXVsaXRwdWwgcmVkaXJlY3QgcGFja2V0cw0KPiA+ID 4g PmVuY2Fwc3VsYXRlZCBpbiBvbmUgVExWIG9yIGp1c3Qgb25lIFRMViBvbmx5IGZvciBvbmUgcG Fj a2V0PyBUbyB1c2UgdGhlDQo+ID4gPiA+Zm9ybWVyLCB3ZSBoYXZlIHRvIGRlZmluZSBhIHNlcX Vl bmNlIGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIHRoZW4gaW4NCj4gPiA+ID50aGUgVExWLg 0K PiA+ID4gPg0KPiA+ID4gPk9uICB0aGUgbWV0YS1pbmZvcm1hdGlvbiByZWxhdGVkLCBJIHRoaW 5r IExGQiBJRHMgaGFzIGFscmVhZHkgYmVlbg0KPiA+ID4gPmluY2x1ZGVkLiBJIGRvbid0IHRoaW 5r IHdlIG5lZWQgYW4gZXh0cmEgcG9ydCBJRCB0byBpbmRpY2F0ZSB3aGVyZSB0byBwdXQNCj4gPi A+ ID50aGUgcmVkaXJlY3RlZCBkYXRhIHRvIG9yIHRvIGdldCByZWRpcmVjdGVkIGRhdGEgZnJvbS 4g QSByZWRpcmVjdCBzb3VyY2UNCj4gPiA+ID5MRkIgIG9yIHNpbmsgTEZCIHdpbGwgIGhhdmUgYS Bw b3J0IElELCB3aGljaCBiZWxvbmdzIHRvIEZFIExGQiB0b3BvbG9neQ0KPiA+ID4gPmNvbmNlcH Qs IGFuZCBGRSBMRkIgdG9wb2xneSBjb25maWd1cmF0aW9uIGlzIGluIGNoYXJnZSBvZiB0aGlzLi Ag Tm90IHN1cmUNCj4gPiA+ID5pZiBpdCBjb21wbGllcyB3aXRoIHlvdXIgdGhvdWdodD8NCj4gPi A+ ID4NCj4gPiA+ID5UaGFua3MsDQo+ID4gPiA+V2VpbWluZw0KPiA+ID4gPg0KPiA+ID4gPi0tLS 0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ID5Gcm9tOiAiSm9lbCBNLiBIYWxwZXJuIg 0K PiA+ID4gPlN1YmplY3Q6IFJlOiBbaXNzdWUzMl0gUGFja2V0IFJlZGlyZWN0DQo+ID4gPiA+DQ o+ ID4gPiA+DQo+ID4gPiA+ID4gSSBhbSBtaXNzaWduIHNvbWV0aGluZyBpbiB5b3VyIHN1Z2dlc3 Rp b24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaHkgd291bGQgd2Ugd2FudCB0byB0cmVhdCByZW Rp cmVjdHMgYXMgZXZlbnRzPw0KPiA+ID4gPiA+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZG ly ZWN0cy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgYW0gdmVyeSBjb25mdXNlZCBhYm91dCAiSG 93 IGEgcGF0aCBzaG91bGQgYmUgZGVmaW5lZCBpbiBhIFBhY2tldA0KPiA+ID4gPiBSZWRpcmVjdA 0K PiA+ID4gPiA+IE1lc3NhZ2UiLCBzaW5jZSBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgYSByZWRpcm Vj dCBkb2VzIG5vdCBuZWVkIGEgDQo+ID4gcGF0aC4gIEl0DQo+ID4gPiA+ID4gbmVlZHMgYSBjb2 xs ZWN0aW9uIG9mIG1ldGEtaW5mb3JtYXRpb24sIHdoaWNoIHdlIG5lZWQgdG8gDQo+ID4gZGVmaW 5l LiAgQXQgdGhlDQo+ID4gPiA+ID4gbW9tZW50LCB0aGF0IGhhcyB0byBpbmNsdWRlIGF0IGxlYX N0 IHRoZSBMRkIgSUQgdGhhdCB0aGUgcmVkaXJlY3QgaXMNCj4gPiA+ID4gZnJvbSAvDQo+ID4gPi A+ ID4gdG8uICBJIHN1cHBvc2UgYnkgZGVjbGFyaW5nIGEgbXVsdGlwbGljaXR5IG9mIHN1Y2ggTE ZC cywgdGhhdCBjYW4gYmUNCj4gPiA+ID4gYWxsIG9mDQo+ID4gPiA+ID4gdGhlIGluZm9ybWF0aW 9u LiAgKEkgdXN1YWxseSB0aGluayBpbiB0ZXJtcyBvZiBhdCBsZWFzdCBhIGxvZ2ljYWwgDQo+ID 4g cG9ydCBJRA0KPiA+ID4gPiA+IHRoZSBwYWNrZXQgY2FtZSBmcm9tIC8gaXMgaW50ZW5kZWQgZm 9y LikNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFlvdXJzLA0KPiA+ID4gPiA+IEpvZWwNCj4gPiA+ID 4g Pg0KPiA+ID4gPiA+IEF0IDEwOjUwIFBNIDYvMjUvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOg 0K PiA+ID4gPiA+ID5KYW1hbCwgSm9lbCwgYW5kIEhvcm16ZCwNCj4gPiA+ID4gPiA+DQo+ID4gPi A+ ID4gPkkgc3VwcG9zZSB3ZSBjb3VsZCBjbG9zZSB0aGlzIGlzc3VlIGJ5IHJlYWNoaW5nIHRoZS Bm b2xsb3dpbmcgcG9pbnRzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+MS4gVGhlIHJlZGlyZW N0 IExGQnMgY2FsbGVkIFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luayANCj4gPi BM RkIgYXJlDQo+ID4gPiA+ID4gPm1vdmVkIHRvIHRoZSBtb2RlbCwgYnV0IHRoZSBwcm90b2NvbC By ZXRhaW5zIHRoZSBSZWRpcmVjdCBNZXNzYWdlLiBUaGUNCj4gPiA+ID4gPiA+cmVhc29uIHRvIG tl ZXAgdGhlIHNwZWNpZmljIG1lc3NhZ2UgaXMgd2UgbmVlZCB0byBzcGVjaWZpY2FsbHkgDQo+ID 4g cmVjb2duaXplDQo+ID4gPiA+ID4gPnJlZGlyZWN0ZWQgZGF0YSBiZXR3ZWVuIENFLUZFIHRyYW 5z cG9ydGF0aW9uIHRvIGF2b2lkIERvUyBhdHRhY2tzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPi A+ Mi4gVGhlIHJlZGlyZWN0ZWQgZGF0YSBpbiB0aGUgTEZCcyBjYW4gYmUgdHJlYXRlZCBhcyBhIG tp bmQgb2YgU1BFQ0lBTA0KPiA+ID4gPiA+ID5ldmVudHMgaW4gdGhhdDoNCj4gPiA+ID4gPiA+IC Ag ICAgYS4gVGhlIGV2ZW50IGlzIHRyaWdnZXJlZCBldmVyeSB0aW1lIGEgbmV3IHJlZGlyZWN0ZW Qg cGFja2V0DQo+ID4gPiA+IGFycml2ZXMNCj4gPiA+ID4gPiA+IGF0IHRoZSBMRkJzLg0KPiA+ID 4g PiA+ID4gICAgICBiLiBUaGUgZXZlbnQgaXMgdHJhbnNwb3J0ZWQgYnkgdGhlIFJlZGlyZWN0IC BN ZXNzYWdlIG9ubHksIA0KPiA+IHdoaWxlDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gUmVkaX Jl Y3QgTWVzc2FnZSB3aWxsIHRoZSBzYW1lIG1lc3NhZ2UgZm9ybWF0IGFzIGEgZ2VuZXJhbCBldm Vu dA0KPiA+ID4gPiA+ID4gbm90aWZpY2F0aW9uIG1lc3NhZ2UgKGV4Y2VwdCB0aGUgbWVzc2FnZS B0 eXBlIGluIHRoZSBoZWFkZXIpLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+QnkgZG9pbmcgaW 4g dGhpcyB3YXksIHdlIGNhbiBhbHNvIHNvbHZlIHRoZSBpc3N1ZTUzIChIb3cgYSBwYXRoIA0KPi A+ IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID5kZWZpbmVkICBpbiBQYWNrZXQgUmVkaXJlY3QgTWVzc2 Fn ZSkgdGhlbi4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPlVuZm9ydHVuYXRlbHksICBJIHRoaW 5r IG9mIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRvIHRoZSANCj4gPiBQYWNrZX QN Cj4gPiA+ID4gPiA+UmVkaXJlY3QgTWVzc2FnZSBhcyB3ZWxsIGFzIHRvIEV2ZW50IE5vdGlmaW Nh dGlvbiBNZXNzYWdlLiBUaGUgDQo+ID4gcXVlc3Rpb24NCj4gPiA+ID4gPiA+aXMsIHRoZSBFdm Vu dCBOb3RpZmljYXRpb24gTWVzc2FnZSBhbGxvd3MgZXZlbnQgZ2VuZXJhdGVkIGJ5IENFIA0KPi A+ IGFuZCBzZW50DQo+ID4gPiA+ID4gPnRvIEZFLiBJbiB0aGUgY2FzZSwgaW4gdGhlIG1lc3NhZ2 Ug Zm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0byANCj4gPiB0aGUgTEZCcw0KPiA+ID4gPiA+ID 50 aGF0IHdpbGwgcmVjZWl2ZSB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLCBidXQgdGhlIHF1ZXN0aW 9u IGlzLCANCj4gPiB3aGF0IHRoZQ0KPiA+ID4gPiA+ID5QYXRoIGluIHRoZSBtZXNzYWdlIHJlZm Vy cyB0byB0aGVuID8/ICBUaGUgc2FtZSBhbHNvIGhhcHBlbnMgdG8gUGFja2V0DQo+ID4gPiA+ID 4g PlJlZGlyZWN0IE1lc3NhZ2UgZnJvbSBDRSB0byBGRS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID 4g PlRoYW5rcywNCj4gPiA+ID4gPiA+V2VpbWluZw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+LS 0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiA+ID5Gcm9tOiAiQXZyaSBEb3JpYS Ig DQo+ID4gPDxtYWlsdG86dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+dHJhY2tlci1mb3JjZXNAbW lw NC5vcmc+DQo+ID4gPiA+ID4gPlRvOiA8PG1haWx0bzpGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC 5D T00+Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KPiA+ID4gPiA+ID5TZW50OiBNb25kYX ks IE1heSAyMywgMjAwNSAyOjM1IEFNDQo+ID4gPiA+ID4gPlN1YmplY3Q6IFtpc3N1ZTMyXSBQYW Nr ZXQgUmVkaXJlY3QNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID5OZXcgc3 Vi bWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPDxtYWlsdG86YXZyaUBhY20ub3JnPmF2cmlAYWNtLm 9y Zz46DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID42LjgNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID 4g PiAgRWRpdG9yaWFsIE5vdGU6ICBUaGVyZSBhcmUgYWxzbyBkaXNjdXNzaW9ucyBvbiBob3cgTE ZC cyBpbiBGRSBtb2RlbA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0aGF0IGFyZS By ZWxhdGVkIHRvIHBhY2tldCByZWRpcmVjdCBvcGVyYXRpb25zDQo+ID4gPiA+ID4gPiAgICAgIC Ag ICAgICAgICAgICAgIHNob3VsZCBiZSBkZWZpbmVkLiAgQWx0aG91Z2ggaXQgaXMgb3V0IG9mIH Ro ZSANCj4gPiBzY29wZQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBvZiBmb3JjZX Mg cHJvdG9jb2wsIGhvdyB0byBkZWZpbmUgdGhlIExGQnMgYWZmZWN0DQo+ID4gPiA+ID4gPiAgIC Ag ICAgICAgICAgICAgICAgIHRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkZXNjcmliZWQgDQ o+ ID4gaGVyZS4gIEJlY2F1c2UNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgY3Vycm Vu dGx5IGl0IGlzIHN0aWxsIGluIHByb2dyZXNzIGluIEZFIG1vZGVsIA0KPiA+IG9uIGhvdw0KPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0byBkZWZpbmUgc3VjaCBMRkJzLCB3ZSB0cn kg dG8gcG9zdCBzb21lIA0KPiA+IHRob3VnaHRzIG9uDQo+ID4gPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgIHRoaXMgaGVyZSBmb3IgZGlzY3Vzc2lvbi4gIFRoZXkgd2lsbCBiZSByZW1vdmVkDQ o+ ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGxhdGVyIGFsb25nIHdpdGggdGhlIHByb2 dy ZXNzIG9mIHRoZSBGRSBtb2RlbCANCj4gPiB3b3JrLg0KPiA+ID4gPiA+ID4gICAgICAgICBUaG 91 Z2h0IDE6ICBUbyBkZWZpbmUgTEZCcyBjYWxsZWQgJ1JlZGlyZWN0U2luaycgYW5kDQo+ID4gPi A+ ID4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgZm9yIHBhY2tldCByZWRpcm Vj dC4NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgQW4gTEZCIGluIEZFIGNhbGxlZC An UmVkaXJlY3RTaW5rJyBpcyANCj4gPiByZXNwb25zaWJsZSB0bw0KPiA+ID4gPiA+ID4gICAgIC Ag ICAgICAgICAgICAgICBjb2xsZWN0IGRhdGEgcGFja2V0cyB0aGF0IG5lZWQgdG8gYmUgDQo+ID 4g cmVkaXJlY3RlZCB0bw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBDRS4gIEZyb2 0g dGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGRSBMRkIgdG9wb2xvZ3ksDQo+ID4gPiA+ID4gPiAgIC Ag ICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgaXMgYW4gTEZCIHdpdGggb2 5s eSANCj4gPiBvbmUgaW5wdXQNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcG9ydC Bh bmQgd2l0aG91dCBhbnkgb3V0cHV0IHBvcnQsIGFuZCB0aGUgDQo+ID4gaW5wdXQgcG9ydA0KPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBjYW4gdGhlbiBiZSBjb25uZWN0ZWQgdG8gYW 55 IG90aGVyIExGQiBpbiBGRSANCj4gPiBtb2RlbA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgIC Ag ICAgICBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLg0KPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aG Ug Rm9yQ0VTIHByb3RvY29sIA0KPiA+IGxheWVyLA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgIC Ag ICAgICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIHdpbGwgZ2VuZXJhdGUgdGhlIFBhY2tldA0KPi A+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdCBNZXNzYWdlcyB3aGVuIGl0IH Jl Y2VpdmVzIGRhdGEgDQo+ID4gcGFja2V0cyBmcm9tDQo+ID4gPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgIGZvcndhcmRpbmcgcGxhbmUuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgIC Ag ICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFRhcCcgaXMgDQo+ID 4g cmVzcG9uc2libGUgdG8NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcmVjZWl2ZS Bk YXRhIHBhY2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLg0KPiA+ID4gPiA+ID4gIC Ag ICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG 9s b2d5LCB0aGUNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJy BM RkIgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgb3V0cHV0DQo+ID4gPiA+ID4gPiAgICAgICAgIC Ag ICAgICAgICAgIHBvcnQgYW5kIHdpdGhvdXQgYW55IGlucHV0IHBvcnQsIGFuZCB0aGUgDQo+ID 4g b3V0cHV0IHBvcnQNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgY2FuIHRoZW4gYm Ug Y29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgDQo+ID4gbW9kZWwNCj4gPiA+ID4gPi A+ ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2 Fy ZGluZyBwbGFuZS4NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRnJvbSB0aGUgcG Vy c3BlY3RpdmUgb2YgRm9yQ0VTIHByb3RvY29sIA0KPiA+IGxheWVyLCB0aGUNCj4gPiA+ID4gPi A+ ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgY2FuIHJlY2VpdmUgdGhlIF Bh Y2tldCBSZWRpcmVjdA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBNZXNzYWdlcy Bm cm9tIENFLCBhbmQgdW4tZW5jYXBzdWxhdGUgdGhlIGRhdGENCj4gPiA+ID4gPiA+ICAgICAgIC Ag ICAgICAgICAgICAgcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgdGhlbSB0byANCj 4g PiBkYXRhcGF0aHMNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgaW4gdGhlIGZvcn dh cmRpbmcgcGxhbmUuICBBY3R1YWxseSB0aGUgDQo+ID4gJ1JlY2lyZWN0VGFwJw0KPiA+ID4gPi A+ ID4gICAgICAgICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxpa2UgYSB0cmFuc2NvZGVyIH Ro YXQgDQo+ID4gdHJhbnNmZXJzIHRoZQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgIC BG b3JDRVMgcHJvdG9jb2wgbWVzc2FnZXMgdG8gbm9ybWFsIGRhdGEgDQo+ID4gcGFja2V0cyBpbg 0K PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBJUCBmb3J3YXJkaW5nIHBsYW5lLiAgQX Mg YSByZXN1bHQsIGlmIHdlIG5lZWQgdG8NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIC Ag aGF2ZSByZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbWUgTEZCIA0KPiA+IChzYX kg YQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBTY2hlZHVsZXIpIGluIEZFIG1vZG Vs LCB3ZSBvbmx5IG5lZWQgdG8gDQo+ID4gY29ubmVjdCB0aGUNCj4gPiA+ID4gPiA+ICAgICAgIC Ag ICAgICAgICAgICAgJ1JlZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIExGQiANCj4gPi Bk aXJlY3RseSB2aWEgYQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkYXRhcGF0aC Bh cyBmb2xsb3dzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS 0t LS0tKw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJlZGlyZW N0 VGFwIExGQiB8LS0tLS0tPnwgICAgICAgICAgIHwNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8DQ o+ ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgfCBTY2hlZHVsZXIgfA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgRnJvbSBvdGhlciBMRkIgICAtLS0tPnwgICAgTEZCICAgIHwNCj4gPiA+ID 4g PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICB8ICAgICAgICAgICB8DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KPiA+ID4gPiA+ID4NCj 4g PiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjcNCj4gPi A+ ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIEJ5IHVzZSBvZiBzZXZlcm Fs ICdSZWRpcmVjdFNpbmsnIExGQnMgYW5kIHNldmVyYWwNCj4gPiA+ID4gPiA+ICAgICAgICAgIC Ag ICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkJzIHRoYXQgY29ubmVjdCB0byBzZXZlcmFsIA0KPi A+ IGRpZmZlcmVudA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkYXRhcGF0aHMgaW 4g RkUgZm9yd2FyZGluZyBwbGFuZSwgbXVsdGlwbGUgcGFja2V0DQo+ID4gPiA+ID4gPiAgICAgIC Ag ICAgICAgICAgICAgIHJlZGlyZWN0IHBhdGhzIGJldHdlZW4gQ0UgYW5kIEZFIGNhbiBiZSANCj 4g PiBjb25zdHJ1Y3RlZC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICAgIFRob3VnaH Qg MjogIFRoZXJlIG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQo+ID4gPi A+ ID4gPiAgICAgICAgICAgICAgICAgICAgIHJlZGlyZWN0ZWQ6IGRpcmVjdGx5IGJ5IGEgZm9yd2 Fy ZGluZyBwYXRoLCANCj4gPiBlLmcuLCBieQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgIC Ag ICBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiAgSW4gc3VjaCBhIGNhc2Ugd2UgZG8gbm90DQo+ID 4g PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIHNtYX J0 bmVzcy4gIFByb2JhYmx5IA0KPiA+IGEgbGluaw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgIC Ag ICAgICBsYXllciBvciBldmVuIG5ldHdvcmsgbGV2ZWwgaGVhZGVyIGlzIA0KPiA+IGVub3VnaC 4g IFRoZQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaXZlciBkZW11eGVzIG l0 IG9ubHkgYmFzZWQgb24gc29tZSANCj4gPiBwcm90b2NvbCB0eXBlDQo+ID4gPiA+ID4gPiAgIC Ag ICAgICAgICAgICAgICAgIGluIHRoZSBsaW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNwb3J0IA 0K PiA+IGxheWVyLiAgVGhlDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHByb3MgZm 9y IHRoaXMgYXBwcmFvY2ggaXMgaXQgbWF5IHByb3ZpZGUgYSANCj4gPiBmYXN0IGFuZA0KPiA+ID 4g PiA+ID4gICAgICAgICAgICAgICAgICAgICBjb3N0LWVmZmVjdGl2ZSBwYXRoIGZvciBwYWNrZX Qg cmVkaXJlY3QuICBUaGUgDQo+ID4gY29ucw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgIC Ag ICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIHRoZSBGcA0KPiA+ID 4g PiA+ID4gICAgICAgICAgICAgICAgICAgICByZWZlcmVuY2UgcG9pbnQgZGVmaW5pdGlvbiBpbi BG b3JDRVMgZnJhbWV3b3JrLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+LS0tLS0tLS0tLQ0KPi A+ ID4gPiA+ID5jYXRlZ29yeTogRWRpdG9yaWFsDQo+ID4gPiA+ID4gPmRyYWZ0OiBkcmFmdC1pZX Rm LWZvcmNlcy1wcm90b2NvbA0KPiA+ID4gPiA+ID5tZXNzYWdlczogNDkNCj4gPiA+ID4gPiA+bm 9z eTogYXZyaQ0KPiA+ID4gPiA+ID5wcmlvcml0eTogTXVzdCBmaXgNCj4gPiA+ID4gPiA+c3RhdH Vz OiBObyBkaXNjdXNzaW9uDQo+ID4gPiA+ID4gPnRpdGxlOiBQYWNrZXQgUmVkaXJlY3QNCj4gPi A+ ID4gPiA+DQo+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fXw0KPiA+ID4gPiA+ID5Gb3JjZXMgaXNzdWUgdHJhY2tlciANCj4gPiA8PG 1h aWx0bzp0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz50cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NCj 4g PiA+ID4gPiA+PGh0dHA6Ly93d3cubWlwNC5vcmcvaXNzdWVzL3RyYWNrZXIvZm9yY2VzL2lzc3 Vl MzI+DQo+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fXw0KPiA+ID4gPiA+ 2005 Message-Id: Date: Tue, 28 Jun 2005 08:57:11 -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 Mon, 2005-27-06 at 23:20 -0400, Joel M. Halpern wrote: > Given that packets requiring redirection are likely to be scattered, and > given that multiple redirect TLVs (each with a packet) can be included in a > message if that is useful, I don't see much value it the extra wrapper to > allow multiple packets inside the TLV. > Let me share what we do - i havent really read the thread in full to make full sense of what Joel/Weiming are saying[1]. So i dont know who i am agreeing with ;-> Heres an example of a redirect that we have implemented thus far shipped as a Forces message. common header (type = REDIRECT) | | +---- LFB selector (Redirect LFB, instance X) | | +----- TLV, Type = REDIRECT_device (for lack of better name) | | +--- ifindex of sink or source port | | +--- Packet data in network order Several observations: 1) In theory, we should be able to repeat the TLV multiple times to send several packets in one PL message. We dont do that at the moment; when we get to optimizing we will probably do so. 2) There is only one termination point for either source/sink - they are not being differentiated as two different things. So when the message goes from FE->CE, the ifindex is that of the FEs port in which in the packet was received/sourced. On the CE->FE direction, the ifindex is that of the FEs port in which the the packet is to be transmitted. We found that we absolutely needed to at least have this little ifindex header. 3) There is only one REDIRECT LFB and several instances (one for IKE, one for OSPF etc). Some performance numbers: Here are some numbers when we use different redirect schemes from the FE->CE: Scheme 1: As described above, MUST implement for forces. Roundtrip latency adds 1.1 ms (note we cross to/fro user space 4 times) Scheme 2: I described earlier, tagged as the TML redirect by Joel: (redirect happens in the forwarding path; this could be in the kernel or in hardware): adds less than 10us to round trip latency. cheers, jamal [1]I am very tied up elsewhere but hope to resurface and catchup on the list hopefully by end of day or tommorow (I will attend the next concal thursday btw - sorry havent responded). 2005 Message-Id: Date: Mon, 27 Jun 2005 23:20:28 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Given that packets requiring redirection are likely to be scattered, and given that multiple redirect TLVs (each with a packet) can be included in a message if that is useful, I don't see much value it the extra wrapper to allow multiple packets inside the TLV. Yours, Joel At 11:04 PM 6/27/2005, Weiming Wang wrote: > > The differences are minor. > > Firstly, I wanted to clarify the general principle of top level TLVs. > > I am not sure we need the LFB class. It may be useful (for differention > > source from sink, and allowing subclassing of the redirect LFBs. > > And I would not expect the remaining content to be an Operation > > TLV. Rather, I would expect it to be the packet. >Omitting operation TLV will lead to the fact that we only allow one packet >data in one top TLV. That's the question that I raised days before. From >the efficiency point of view, to allow more than one packet in one top TLV >may be benifitful a little. > >Thanks, >Weiming > > > > But mostly, we are in agreement. > > > > Yours, > > Joel > > > > At 09:56 PM 6/27/2005, Weiming Wang wrote: > > >Joel, > > > > > > > The Packet Redirect message contains one or more (typically one) > > > > packet-redirect TLVs. > > > > > >If I understand your above thought correctly, I think your > proposal is to > > >define a packet-redirect TLV rathan than a LFBselectTLV at the top level > > >for the message. In this way it will leave LFB selection information as > > >kinds of meta-info and inside the TLV, something like: > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Type = > > > Packet-Redirect | Length | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Class > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Instance > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Operation > TLV | > > > > > . > . > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Now, the question is I do find this format is not very different with > that > > >I proposed. Do I miss something? > > > > > >Thanks, > > >Weiming > > > > > > > > > > I would approach this differently. The current text describes the > > > > LFBselect LFB. It correctly defines the LFBselect LFB. That > definition > > > > should not be thrown away. > > > > > > > > The message structure documentation can say > > > > A PL protocol messages consists of a protocol header followed by > > > one or > > > > more TLVs. All TLVs > > > > consist of two byte type and a two byte length, followed by > contents > > > > dependent upon the type > > > > of the TLV. The TLVs which are valid in a message depend upon the > > > > message type. > > > > Most message types allow one or more LFBselect TLVs and no > other top > > > > level TLVs. The > > > > following are the message types this applies to: > > > > Association setup request and response. > > > > Config message request and response > > > > Query message request and response > > > > Event Notify message. > > > > The Association teardown message contains a single instance of the > > > > teardown-cause TLV. > > > > The heartbeat message contains a single instance of the heatrbeat > > > > TLV. (Unless we decide > > > > to just use an event for heartbeats. I don't remember where that > > > > discussion stands.) > > > > The Packet Redirect message contains one or more (typically one) > > > > packet-redirect TLVs. > > > > This is then followed by a section for each of these top level TLVs. > > > > > > > > Yours, > > > > Joel M. Halpern > > > > > > > > At 10:01 AM 6/27/2005, Weiming Wang wrote: > > > > >Joel :) > > > > > > > > > >How about we just obsolete the path from the data structure and > add some > > > > >meta-information, and form the format as below (I currently can > only think > > > > >of the meta-information as the packet type. We may add some more > later). > > > > > > > > > >Could you give more comments on this, then we may solve this issue > soon? > > > > > > > > > >Thank you very much. > > > > > > > > > >Weiming > > > > > > > > > >--------------------- > > > > >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 = > LFBselect | Length | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Class > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Instance > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Operation > TLV | > > > > > . > . > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > ~ ... > ~ > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Operation > TLV | > > > > > . > . > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > LFB class ID: > > > > > There are only two possible LFB classes here, the > 'RedirectSink' > > > > > LFB or the 'RedirectSource' LFB. If the message is from FE > to CE, > > > > > the LFB class should be 'RedirectSink'. If the message is > from CE > > > > > to FE, the LFB class should be 'RedirectSource'. > > > > > Instance ID: > > > > > Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. > > > > > Operation TLV: > > > > > This is a TLV describing one packet of data to be directed > via the > > > > > specified LFB above. The order of the TLV appeared is also the > > > > > order the data packet arrives the redirector LFB, that is, the > > > > > Redirected Data in the first TLV should arrive the earliest. > > > > > > > > > >The TLV format is as follows: > > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Type = > PAYLOAD | Length | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > ~ Packet Type | Packet > Length ~ > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > ~ Redirected > Packet ~ > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Type: > > > > > The type for the TLV is set to 'PAYLOAD'. > > > > > > > > > > Length: > > > > > the length of the TLV(in 4bytes). > > > > > > > > > > Packet Type: > > > > > Defines what type the redirected packet belongs to(such as > 'IPv4 > > > > > Packet', > > > > > 'IPv6 Packet'). > > > > > > > > > > Packet Length: > > > > > the length of the followed redirected packet (in byte) > > > > > > > > > > Redirected Packet: > > > > > one redirected packet. > > > > >----------------------------- > > > > > > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > <joel@stevecrocker.com> > > > > > > > > > > > I would expect that a Redirect Message has a different outermost > > > TLV. The > > > > > > grammar is intended to help us, not serve as a > > > straightjacket. Different > > > > > > message types can have different outer TLVs. It is desirable to > > > use the > > > > > > same structure when it applies. But the redirect message is > simply a > > > > > > different case. It's contents are not a DATARAW much less a DATA > > > > > TLV. Its > > > > > > content structure is not defined by an LFB element definition > or Model > > > > > > DataDefs structure definition. > > > > > > > > > > > > If we need to fix the "grammar" section to make it clear that not > > > all PL > > > > > > messages necessarily use the same outermost TLV, we should do > > > so. My own > > > > > > approach would be to separate the grammar into a definition of the > > > > > contents > > > > > > of that TLV, and a separate definition of which TLVs / content are > > > carried > > > > > > in the outermost level of which messages. > > > > > > > > > > > > Yours, > > > > > > Joel > > > > > > > > > > > > PS: Weiming, I am sorry you got caught up in this confusion. I > don't > > > > > think > > > > > > you created the tendency I am railing against above. I am just > > > using your > > > > > > message as a starting point to hammer home a point. > > > > > > > > > > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote: > > > > > > >Maybe it's me who missed something :) > > > > > > >My thought was we might need to obey our message grammar well > that we > > > > > have > > > > > > >to use a strict Path-data for operation TLV. To obey the rule, > > > treating > > > > > > >it as an event will ease the message format greatly. > > > > > > > > > > > > > >Actually I'm very happy to see that you agree a path can be > > > omitted for > > > > > > >some specific messages like redirect messge. > > > > > > > > > > > > > >OK, let's solve it then, to let redirect message only contain Data > > > > > > >field? I can update this redirect message part text then. > > > > > > > > > > > > > >Jamal, could you give a response on this? > > > > > > > > > > > > > >One less vital question is, shall we allow for mulitpul redirect > > > packets > > > > > > >encapsulated in one TLV or just one TLV only for one packet? To > > > use the > > > > > > >former, we have to define a sequence for the redirected packets > > > then in > > > > > > >the TLV. > > > > > > > > > > > > > >On the meta-information related, I think LFB IDs has already been > > > > > > >included. I don't think we need an extra port ID to indicate > where > > > to put > > > > > > >the redirected data to or to get redirected data from. A redirect > > > source > > > > > > >LFB or sink LFB will have a port ID, which belongs to FE LFB > > > topology > > > > > > >concept, and FE LFB topolgy configuration is in charge of > > > this. Not sure > > > > > > >if it complies with your thought? > > > > > > > > > > > > > >Thanks, > > > > > > >Weiming > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Joel M. Halpern" > > > > > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > > > > > > > > > > > > > I am missign something in your suggestion. > > > > > > > > > > > > > > > > Why would we want to treat redirects as events? > > > > > > > > We should treat them as redirects. > > > > > > > > > > > > > > > > I am very confused about "How a path should be defined in a > Packet > > > > > > > Redirect > > > > > > > > Message", since as far as I can tell, a redirect does not > need a > > > > > path. It > > > > > > > > needs a collection of meta-information, which we need to > > > > > define. At the > > > > > > > > moment, that has to include at least the LFB ID that the > > > redirect is > > > > > > > from / > > > > > > > > to. I suppose by declaring a multiplicity of such LFBs, that > > > can be > > > > > > > all of > > > > > > > > the information. (I usually think in terms of at least a > logical > > > > > port ID > > > > > > > > the packet came from / is intended for.) > > > > > > > > > > > > > > > > Yours, > > > > > > > > Joel > > > > > > > > > > > > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > > > > > > > >Jamal, Joel, and Hormzd, > > > > > > > > > > > > > > > > > >I suppose we could close this issue by reaching the following > > > points: > > > > > > > > > > > > > > > > > >1. The redirect LFBs called RedirectSource LFB and > RedirectSink > > > > > LFB are > > > > > > > > >moved to the model, but the protocol retains the Redirect > > > Message. The > > > > > > > > >reason to keep the specific message is we need to specifically > > > > > recognize > > > > > > > > >redirected data between CE-FE transportation to avoid DoS > attacks. > > > > > > > > > > > > > > > > > >2. The redirected data in the LFBs can be treated as a > kind of > > > SPECIAL > > > > > > > > >events in that: > > > > > > > > > a. The event is triggered every time a new > redirected packet > > > > > > > arrives > > > > > > > > > at the LFBs. > > > > > > > > > b. The event is transported by the Redirect Message > only, > > > > > while > > > > > > > the > > > > > > > > > Redirect Message will the same message format as a > general event > > > > > > > > > notification message (except the message type in the header). > > > > > > > > > > > > > > > > > >By doing in this way, we can also solve the issue53 (How a > path > > > > > should be > > > > > > > > >defined in Packet Redirect Message) then. > > > > > > > > > > > > > > > > > >Unfortunately, I think of another question that is > related to > > > the > > > > > Packet > > > > > > > > >Redirect Message as well as to Event Notification Message. The > > > > > question > > > > > > > > >is, the Event Notification Message allows event generated > by CE > > > > > and sent > > > > > > > > >to FE. In the case, in the message format, the LFB IDs > refer to > > > > > the LFBs > > > > > > > > >that will receive the event notification, but the question is, > > > > > what the > > > > > > > > >Path in the message refers to then ?? The same also happens > > > to Packet > > > > > > > > >Redirect Message from CE to FE. > > > > > > > > > > > > > > > > > >Thanks, > > > > > > > > >Weiming > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > >From: "Avri Doria" > > > > > <tracker-forces@mip4.org> > > > > > > > > >To: > > > <FORCES@PEACH.EASE.LSOFT.COM> > > > > > > > > >Sent: Monday, May 23, 2005 2:35 AM > > > > > > > > >Subject: [issue32] Packet Redirect > > > > > > > > > > > > > > > > > > > > > > > > > > >New submission from Avri Doria > > > <avri@acm.org>: > > > > > > > > > > > > > > > > > >6.8 > > > > > > > > > > > > > > > > > > Editorial Note: There are also discussions on how LFBs in > > > FE model > > > > > > > > > that are related to packet redirect > > > operations > > > > > > > > > should be defined. Although it is > out of > > > the > > > > > scope > > > > > > > > > of forces protocol, how to define the > > > LFBs affect > > > > > > > > > the Packet Redirect Message described > > > > > here. Because > > > > > > > > > currently it is still in progress in FE > > > model > > > > > on how > > > > > > > > > to define such LFBs, we try to post some > > > > > thoughts on > > > > > > > > > this here for discussion. They will be > > > removed > > > > > > > > > later along with the progress of the FE > > > model > > > > > work. > > > > > > > > > Thought 1: To define LFBs called 'RedirectSink' and > > > > > > > > > 'RedirectTap' for packet redirect. > > > > > > > > > An LFB in FE called 'RedirectSink' is > > > > > responsible to > > > > > > > > > collect data packets that need to be > > > > > redirected to > > > > > > > > > CE. From the perspective of the FE LFB > > > topology, > > > > > > > > > the 'RedirectSink' LFB is an LFB with > only > > > > > one input > > > > > > > > > port and without any output port, and the > > > > > input port > > > > > > > > > can then be connected to any other > LFB in FE > > > > > model > > > > > > > > > by means of a datapath in the forwarding > > > plane. > > > > > > > > > From the perspective of the ForCES > protocol > > > > > layer, > > > > > > > > > the 'RedirectSink' LFB will generate the > > > Packet > > > > > > > > > Redirect Messages when it receives data > > > > > packets from > > > > > > > > > forwarding plane. > > > > > > > > > > > > > > > > > > An LFB in FE called 'RedirectTap' is > > > > > responsible to > > > > > > > > > receive data packets that are redirected > > > from CE. > > > > > > > > > From the perspective of the FE LFB > > > topology, the > > > > > > > > > 'RedirectTap' LFB is an LFB with only > one > > > output > > > > > > > > > port and without any input port, and the > > > > > output port > > > > > > > > > can then be connected to any other > LFB in FE > > > > > model > > > > > > > > > by means of a datapath in the forwarding > > > plane. > > > > > > > > > From the perspective of ForCES protocol > > > > > layer, the > > > > > > > > > 'RedirectTap' LFB can receive the Packet > > > Redirect > > > > > > > > > Messages from CE, and un-encapsulate > the data > > > > > > > > > packets from the message and put them to > > > > > datapaths > > > > > > > > > in the forwarding plane. Actually the > > > > > 'RecirectTap' > > > > > > > > > LFB acts more like a transcoder that > > > > > transfers the > > > > > > > > > ForCES protocol messages to normal data > > > > > packets in > > > > > > > > > IP forwarding plane. As a result, if we > > > need to > > > > > > > > > have redirected packets connected to > some > > > LFB > > > > > (say a > > > > > > > > > Scheduler) in FE model, we only need to > > > > > connect the > > > > > > > > > 'RedirectTap LFB to the Scheduler LFB > > > > > directly via a > > > > > > > > > datapath as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > +-----------------+ > > > +-----------+ > > > > > > > > > | RedirectTap LFB > > > |------>| | > > > > > > > > > +-----------------+ | > > > | > > > > > > > > > | > > > Scheduler | > > > > > > > > > From other > > > LFB ---->| LFB | > > > > > > > > > | > > > | > > > > > > > > > > > > +-----------+ > > > > > > > > > > > > > > > > > > Figure 27 > > > > > > > > > > > > > > > > > > By use of several 'RedirectSink' LFBs > and > > > several > > > > > > > > > 'RedirectTap' LFBs that connect to > several > > > > > different > > > > > > > > > datapaths in FE forwarding plane, > > > multiple packet > > > > > > > > > redirect paths between CE and FE can be > > > > > constructed. > > > > > > > > > > > > > > > > > > Thought 2: There might be another way a packet > could be > > > > > > > > > redirected: directly by a forwarding > path, > > > > > e.g., by > > > > > > > > > FPGA/ASIC/NP microcode. In such a case > > > we do not > > > > > > > > > need to put in a lot of > smartness. Probably > > > > > a link > > > > > > > > > layer or even network level header is > > > > > enough. The > > > > > > > > > receiver demuxes it only based on some > > > > > protocol type > > > > > > > > > in the link layer or network transport > > > > > layer. The > > > > > > > > > pros for this appraoch is it may > provide a > > > > > fast and > > > > > > > > > cost-effective path for packet > > > redirect. The > > > > > cons > > > > > > > > > for this is it may more or less confuses > > > the Fp > > > > > > > > > reference point definition in ForCES > > > framework. > > > > > > > > > > > > > > > > > >---------- > > > > > > > > >category: Editorial > > > > > > > > >draft: draft-ietf-forces-protocol > > > > > > > > >messages: 49 > > > > > > > > >nosy: avri > > > > > > > > >priority: Must fix > > > > > > > > >status: No discussion > > > > > > > > >title: Packet Redirect > > > > > > > > > > > > > > > > > >___________________________________________________ > > > > > > > > >Forces issue tracker > > > > > <tracker-forces@mip4.org> > > > > > > > > > > > > > > > > > >___________________________________________________ > > > > > > > > 2005 Message-Id: Date: Mon, 27 Jun 2005 22:55:08 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The differences are minor. Firstly, I wanted to clarify the general principle of top level TLVs. I am not sure we need the LFB class. It may be useful (for differention source from sink, and allowing subclassing of the redirect LFBs. And I would not expect the remaining content to be an Operation TLV. Rather, I would expect it to be the packet. But mostly, we are in agreement. Yours, Joel At 09:56 PM 6/27/2005, Weiming Wang wrote: >Joel, > > > The Packet Redirect message contains one or more (typically one) > > packet-redirect TLVs. > >If I understand your above thought correctly, I think your proposal is to >define a packet-redirect TLV rathan than a LFBselectTLV at the top level >for the message. In this way it will leave LFB selection information as >kinds of meta-info and inside the TLV, something like: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = > Packet-Redirect | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Class ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Instance ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Operation TLV | > > > . . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Now, the question is I do find this format is not very different with that >I proposed. Do I miss something? > >Thanks, >Weiming > > > > I would approach this differently. The current text describes the > > LFBselect LFB. It correctly defines the LFBselect LFB. That definition > > should not be thrown away. > > > > The message structure documentation can say > > A PL protocol messages consists of a protocol header followed by > one or > > more TLVs. All TLVs > > consist of two byte type and a two byte length, followed by contents > > dependent upon the type > > of the TLV. The TLVs which are valid in a message depend upon the > > message type. > > Most message types allow one or more LFBselect TLVs and no other top > > level TLVs. The > > following are the message types this applies to: > > Association setup request and response. > > Config message request and response > > Query message request and response > > Event Notify message. > > The Association teardown message contains a single instance of the > > teardown-cause TLV. > > The heartbeat message contains a single instance of the heatrbeat > > TLV. (Unless we decide > > to just use an event for heartbeats. I don't remember where that > > discussion stands.) > > The Packet Redirect message contains one or more (typically one) > > packet-redirect TLVs. > > This is then followed by a section for each of these top level TLVs. > > > > Yours, > > Joel M. Halpern > > > > At 10:01 AM 6/27/2005, Weiming Wang wrote: > > >Joel :) > > > > > >How about we just obsolete the path from the data structure and add some > > >meta-information, and form the format as below (I currently can only think > > >of the meta-information as the packet type. We may add some more later). > > > > > >Could you give more comments on this, then we may solve this issue soon? > > > > > >Thank you very much. > > > > > >Weiming > > > > > >--------------------- > > >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 = LFBselect | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Class ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Instance ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Operation TLV | > > > . . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ ... ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Operation TLV | > > > . . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > LFB class ID: > > > There are only two possible LFB classes here, the 'RedirectSink' > > > LFB or the 'RedirectSource' LFB. If the message is from FE to CE, > > > the LFB class should be 'RedirectSink'. If the message is from CE > > > to FE, the LFB class should be 'RedirectSource'. > > > Instance ID: > > > Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. > > > Operation TLV: > > > This is a TLV describing one packet of data to be directed via the > > > specified LFB above. The order of the TLV appeared is also the > > > order the data packet arrives the redirector LFB, that is, the > > > Redirected Data in the first TLV should arrive the earliest. > > > > > >The TLV format is as follows: > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = PAYLOAD | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ Packet Type | Packet Length ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ Redirected Packet ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Type: > > > The type for the TLV is set to 'PAYLOAD'. > > > > > > Length: > > > the length of the TLV(in 4bytes). > > > > > > Packet Type: > > > Defines what type the redirected packet belongs to(such as 'IPv4 > > > Packet', > > > 'IPv6 Packet'). > > > > > > Packet Length: > > > the length of the followed redirected packet (in byte) > > > > > > Redirected Packet: > > > one redirected packet. > > >----------------------------- > > > > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > <joel@stevecrocker.com> > > > > > > > I would expect that a Redirect Message has a different outermost > TLV. The > > > > grammar is intended to help us, not serve as a > straightjacket. Different > > > > message types can have different outer TLVs. It is desirable to > use the > > > > same structure when it applies. But the redirect message is simply a > > > > different case. It's contents are not a DATARAW much less a DATA > > > TLV. Its > > > > content structure is not defined by an LFB element definition or Model > > > > DataDefs structure definition. > > > > > > > > If we need to fix the "grammar" section to make it clear that not > all PL > > > > messages necessarily use the same outermost TLV, we should do > so. My own > > > > approach would be to separate the grammar into a definition of the > > > contents > > > > of that TLV, and a separate definition of which TLVs / content are > carried > > > > in the outermost level of which messages. > > > > > > > > Yours, > > > > Joel > > > > > > > > PS: Weiming, I am sorry you got caught up in this confusion. I don't > > > think > > > > you created the tendency I am railing against above. I am just > using your > > > > message as a starting point to hammer home a point. > > > > > > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote: > > > > >Maybe it's me who missed something :) > > > > >My thought was we might need to obey our message grammar well that we > > > have > > > > >to use a strict Path-data for operation TLV. To obey the rule, > treating > > > > >it as an event will ease the message format greatly. > > > > > > > > > >Actually I'm very happy to see that you agree a path can be > omitted for > > > > >some specific messages like redirect messge. > > > > > > > > > >OK, let's solve it then, to let redirect message only contain Data > > > > >field? I can update this redirect message part text then. > > > > > > > > > >Jamal, could you give a response on this? > > > > > > > > > >One less vital question is, shall we allow for mulitpul redirect > packets > > > > >encapsulated in one TLV or just one TLV only for one packet? To > use the > > > > >former, we have to define a sequence for the redirected packets > then in > > > > >the TLV. > > > > > > > > > >On the meta-information related, I think LFB IDs has already been > > > > >included. I don't think we need an extra port ID to indicate where > to put > > > > >the redirected data to or to get redirected data from. A redirect > source > > > > >LFB or sink LFB will have a port ID, which belongs to FE LFB > topology > > > > >concept, and FE LFB topolgy configuration is in charge of > this. Not sure > > > > >if it complies with your thought? > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > > > > > > > I am missign something in your suggestion. > > > > > > > > > > > > Why would we want to treat redirects as events? > > > > > > We should treat them as redirects. > > > > > > > > > > > > I am very confused about "How a path should be defined in a Packet > > > > > Redirect > > > > > > Message", since as far as I can tell, a redirect does not need a > > > path. It > > > > > > needs a collection of meta-information, which we need to > > > define. At the > > > > > > moment, that has to include at least the LFB ID that the > redirect is > > > > > from / > > > > > > to. I suppose by declaring a multiplicity of such LFBs, that > can be > > > > > all of > > > > > > the information. (I usually think in terms of at least a logical > > > port ID > > > > > > the packet came from / is intended for.) > > > > > > > > > > > > Yours, > > > > > > Joel > > > > > > > > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > > > > > >Jamal, Joel, and Hormzd, > > > > > > > > > > > > > >I suppose we could close this issue by reaching the following > points: > > > > > > > > > > > > > >1. The redirect LFBs called RedirectSource LFB and RedirectSink > > > LFB are > > > > > > >moved to the model, but the protocol retains the Redirect > Message. The > > > > > > >reason to keep the specific message is we need to specifically > > > recognize > > > > > > >redirected data between CE-FE transportation to avoid DoS attacks. > > > > > > > > > > > > > >2. The redirected data in the LFBs can be treated as a kind of > SPECIAL > > > > > > >events in that: > > > > > > > a. The event is triggered every time a new redirected packet > > > > > arrives > > > > > > > at the LFBs. > > > > > > > b. The event is transported by the Redirect Message only, > > > while > > > > > the > > > > > > > Redirect Message will the same message format as a general event > > > > > > > notification message (except the message type in the header). > > > > > > > > > > > > > >By doing in this way, we can also solve the issue53 (How a path > > > should be > > > > > > >defined in Packet Redirect Message) then. > > > > > > > > > > > > > >Unfortunately, I think of another question that is related to > the > > > Packet > > > > > > >Redirect Message as well as to Event Notification Message. The > > > question > > > > > > >is, the Event Notification Message allows event generated by CE > > > and sent > > > > > > >to FE. In the case, in the message format, the LFB IDs refer to > > > the LFBs > > > > > > >that will receive the event notification, but the question is, > > > what the > > > > > > >Path in the message refers to then ?? The same also happens > to Packet > > > > > > >Redirect Message from CE to FE. > > > > > > > > > > > > > >Thanks, > > > > > > >Weiming > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Avri Doria" > > > <tracker-forces@mip4.org> > > > > > > >To: > <FORCES@PEACH.EASE.LSOFT.COM> > > > > > > >Sent: Monday, May 23, 2005 2:35 AM > > > > > > >Subject: [issue32] Packet Redirect > > > > > > > > > > > > > > > > > > > > >New submission from Avri Doria > <avri@acm.org>: > > > > > > > > > > > > > >6.8 > > > > > > > > > > > > > > Editorial Note: There are also discussions on how LFBs in > FE model > > > > > > > that are related to packet redirect > operations > > > > > > > should be defined. Although it is out of > the > > > scope > > > > > > > of forces protocol, how to define the > LFBs affect > > > > > > > the Packet Redirect Message described > > > here. Because > > > > > > > currently it is still in progress in FE > model > > > on how > > > > > > > to define such LFBs, we try to post some > > > thoughts on > > > > > > > this here for discussion. They will be > removed > > > > > > > later along with the progress of the FE > model > > > work. > > > > > > > Thought 1: To define LFBs called 'RedirectSink' and > > > > > > > 'RedirectTap' for packet redirect. > > > > > > > An LFB in FE called 'RedirectSink' is > > > responsible to > > > > > > > collect data packets that need to be > > > redirected to > > > > > > > CE. From the perspective of the FE LFB > topology, > > > > > > > the 'RedirectSink' LFB is an LFB with only > > > one input > > > > > > > port and without any output port, and the > > > input port > > > > > > > can then be connected to any other LFB in FE > > > model > > > > > > > by means of a datapath in the forwarding > plane. > > > > > > > From the perspective of the ForCES protocol > > > layer, > > > > > > > the 'RedirectSink' LFB will generate the > Packet > > > > > > > Redirect Messages when it receives data > > > packets from > > > > > > > forwarding plane. > > > > > > > > > > > > > > An LFB in FE called 'RedirectTap' is > > > responsible to > > > > > > > receive data packets that are redirected > from CE. > > > > > > > From the perspective of the FE LFB > topology, the > > > > > > > 'RedirectTap' LFB is an LFB with only one > output > > > > > > > port and without any input port, and the > > > output port > > > > > > > can then be connected to any other LFB in FE > > > model > > > > > > > by means of a datapath in the forwarding > plane. > > > > > > > From the perspective of ForCES protocol > > > layer, the > > > > > > > 'RedirectTap' LFB can receive the Packet > Redirect > > > > > > > Messages from CE, and un-encapsulate the data > > > > > > > packets from the message and put them to > > > datapaths > > > > > > > in the forwarding plane. Actually the > > > 'RecirectTap' > > > > > > > LFB acts more like a transcoder that > > > transfers the > > > > > > > ForCES protocol messages to normal data > > > packets in > > > > > > > IP forwarding plane. As a result, if we > need to > > > > > > > have redirected packets connected to some > LFB > > > (say a > > > > > > > Scheduler) in FE model, we only need to > > > connect the > > > > > > > 'RedirectTap LFB to the Scheduler LFB > > > directly via a > > > > > > > datapath as follows: > > > > > > > > > > > > > > > > > > > > > +-----------------+ > +-----------+ > > > > > > > | RedirectTap LFB > |------>| | > > > > > > > +-----------------+ | > | > > > > > > > | > Scheduler | > > > > > > > From other > LFB ---->| LFB | > > > > > > > | > | > > > > > > > > +-----------+ > > > > > > > > > > > > > > Figure 27 > > > > > > > > > > > > > > By use of several 'RedirectSink' LFBs and > several > > > > > > > 'RedirectTap' LFBs that connect to several > > > different > > > > > > > datapaths in FE forwarding plane, > multiple packet > > > > > > > redirect paths between CE and FE can be > > > constructed. > > > > > > > > > > > > > > Thought 2: There might be another way a packet could be > > > > > > > redirected: directly by a forwarding path, > > > e.g., by > > > > > > > FPGA/ASIC/NP microcode. In such a case > we do not > > > > > > > need to put in a lot of smartness. Probably > > > a link > > > > > > > layer or even network level header is > > > enough. The > > > > > > > receiver demuxes it only based on some > > > protocol type > > > > > > > in the link layer or network transport > > > layer. The > > > > > > > pros for this appraoch is it may provide a > > > fast and > > > > > > > cost-effective path for packet > redirect. The > > > cons > > > > > > > for this is it may more or less confuses > the Fp > > > > > > > reference point definition in ForCES > framework. > > > > > > > > > > > > > >---------- > > > > > > >category: Editorial > > > > > > >draft: draft-ietf-forces-protocol > > > > > > >messages: 49 > > > > > > >nosy: avri > > > > > > >priority: Must fix > > > > > > >status: No discussion > > > > > > >title: Packet Redirect > > > > > > > > > > > > > >___________________________________________________ > > > > > > >Forces issue tracker > > > <tracker-forces@mip4.org> > > > > > > > > > > > > > >___________________________________________________ > > > > > > 2005 Message-Id: Date: Mon, 27 Jun 2005 22:01:10 +0800 From: Weiming Wang Subject: Re: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C57B63.BA753770" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C57B63.BA753770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCA6KQ0KDQpIb3cgYWJvdXQgd2UganVzdCBvYnNvbGV0ZSB0aGUgcGF0aCBmcm9tIHRoZS Bk YXRhIHN0cnVjdHVyZSBhbmQgYWRkIHNvbWUgDQptZXRhLWluZm9ybWF0aW9uLCBhbmQgZm9ybS B0 aGUgZm9ybWF0IGFzIGJlbG93IChJIGN1cnJlbnRseSBjYW4gb25seSB0aGluayANCm9mIHRoZS Bt ZXRhLWluZm9ybWF0aW9uIGFzIHRoZSBwYWNrZXQgdHlwZS4gV2UgbWF5IGFkZCBzb21lIG1vcm Ug bGF0ZXIpLg0KDQpDb3VsZCB5b3UgZ2l2ZSBtb3JlIGNvbW1lbnRzIG9uIHRoaXMsIHRoZW4gd2 Ug bWF5IHNvbHZlIHRoaXMgaXNzdWUgc29vbj8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaC4NCg0KV2 Vp bWluZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk1lc3NhZ2UgQm9keToNCiAgICAgIENvbn Np c3RzIG9mIG9uZSBvciBtb3JlIFRMVnMsIHdpdGggZXZlcnkgVExWIGhhdmluZyB0aGUgZm9sbG 93 aW5nDQogICAgICBkYXRhIGZvcm1hdDoNCg0KICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5ID Ag MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICAgKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSsNCiAgICAgICAgfCAgICAgICAgVHlwZSA9IExGQnNlbGVjdCAgICAgICB8ICAgICAgICAgIC Ag ICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICAgIC Ag ICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAgICAgIH wN CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExGQi BJ bnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCi Ag ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvbiBUTFYgICAgICAgICAgIC Ag ICAgICAgICAgICAgIHwNCiAgICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgICAgKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIC Ag ICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgIH4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICAgICAgICAgICAgIC Ag ICAgICAgIE9wZXJhdGlvbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgIC Ag LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgIC4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCiAgIExGQiBjbGFzcyBJRDoNCiAgICAgIF Ro ZXJlIGFyZSBvbmx5IHR3byBwb3NzaWJsZSBMRkIgY2xhc3NlcyBoZXJlLCB0aGUgJ1JlZGlyZW N0 U2luaycNCiAgICAgIExGQiBvciB0aGUgJ1JlZGlyZWN0U291cmNlJyBMRkIuICBJZiB0aGUgbW Vz c2FnZSBpcyBmcm9tIEZFIHRvIENFLA0KICAgICAgdGhlIExGQiBjbGFzcyBzaG91bGQgYmUgJ1 Jl ZGlyZWN0U2luaycuICBJZiB0aGUgbWVzc2FnZSBpcyBmcm9tIENFDQogICAgICB0byBGRSwgdG hl IExGQiBjbGFzcyBzaG91bGQgYmUgJ1JlZGlyZWN0U291cmNlJy4NCiAgIEluc3RhbmNlIElEOg 0K ICAgICAgSW5zdGFuY2UgSUQgZm9yIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgb3IgJ1JlZGlyZW N0 U291cmNlJyBMRkIuDQogICBPcGVyYXRpb24gVExWOg0KICAgICAgVGhpcyBpcyBhIFRMViBkZX Nj cmliaW5nIG9uZSBwYWNrZXQgb2YgZGF0YSB0byBiZSBkaXJlY3RlZCB2aWEgdGhlDQogICAgIC Bz cGVjaWZpZWQgTEZCIGFib3ZlLiAgVGhlIG9yZGVyIG9mIHRoZSBUTFYgYXBwZWFyZWQgaXMgYW xz byB0aGUNCiAgICAgIG9yZGVyIHRoZSBkYXRhIHBhY2tldCBhcnJpdmVzIHRoZSByZWRpcmVjdG 9y IExGQiwgdGhhdCBpcywgdGhlDQogICAgICBSZWRpcmVjdGVkIERhdGEgIGluIHRoZSBmaXJzdC BU TFYgc2hvdWxkIGFycml2ZSB0aGUgZWFybGllc3QuICANCg0KVGhlIFRMViBmb3JtYXQgaXMgYX Mg Zm9sbG93czoNCiANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICBUeXBlID0gUEFZTE 9B RCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgIC Ag Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSsNCiAgICAgICAgfiAgICAgICAgIFBhY2tldCBUeXBlICAgICAgICAgICB8ICAgIC Ag ICAgUGFja2V0IExlbmd0aCAgICAgICAgIH4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfi Ag ICAgICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0ZWQgUGFja2V0ICAgICAgICAgICAgICAgIC Ag ICAgIH4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCiAgICBUeXBlOg0KICAgICAgVGhlIHR5cGUgZm 9y IHRoZSBUTFYgaXMgc2V0IHRvICdQQVlMT0FEJy4gDQoNCiAgICBMZW5ndGg6DQogICAgICB0aG Ug bGVuZ3RoIG9mIHRoZSBUTFYoaW4gNGJ5dGVzKS4NCg0KICAgIFBhY2tldCBUeXBlOg0KICAgIC Ag RGVmaW5lcyB3aGF0IHR5cGUgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IGJlbG9uZ3MgdG8oc3VjaC Bh cyAnSVB2NCBQYWNrZXQnLA0KICAgICAnSVB2NiBQYWNrZXQnKS4gICAgDQoNCiAgICBQYWNrZX Qg TGVuZ3RoOg0KICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgZm9sbG93ZWQgcmVkaXJlY3RlZCBwYW Nr ZXQgKGluIGJ5dGUpDQoNCiAgICBSZWRpcmVjdGVkIFBhY2tldDoNCiAgICAgIG9uZSByZWRpcm Vj dGVkIHBhY2tldC4gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCg0KDQotLS0tLS BP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3 Rl dmVjcm9ja2VyLmNvbT4NCg0KDQo+IEkgd291bGQgZXhwZWN0IHRoYXQgYSBSZWRpcmVjdCBNZX Nz YWdlIGhhcyBhIGRpZmZlcmVudCBvdXRlcm1vc3QgVExWLiAgVGhlIA0KPiBncmFtbWFyIGlzIG lu dGVuZGVkIHRvIGhlbHAgdXMsIG5vdCBzZXJ2ZSBhcyBhIHN0cmFpZ2h0amFja2V0LiAgRGlmZm Vy ZW50IA0KPiBtZXNzYWdlIHR5cGVzIGNhbiBoYXZlIGRpZmZlcmVudCBvdXRlciBUTFZzLiAgSX Qg aXMgZGVzaXJhYmxlIHRvIHVzZSB0aGUgDQo+IHNhbWUgc3RydWN0dXJlIHdoZW4gaXQgYXBwbG ll cy4gIEJ1dCB0aGUgcmVkaXJlY3QgbWVzc2FnZSBpcyBzaW1wbHkgYSANCj4gZGlmZmVyZW50IG Nh c2UuICBJdCdzIGNvbnRlbnRzIGFyZSBub3QgYSBEQVRBUkFXIG11Y2ggbGVzcyBhIERBVEEgVE xW LiAgSXRzIA0KPiBjb250ZW50IHN0cnVjdHVyZSBpcyBub3QgZGVmaW5lZCBieSBhbiBMRkIgZW xl bWVudCBkZWZpbml0aW9uIG9yIE1vZGVsIA0KPiBEYXRhRGVmcyBzdHJ1Y3R1cmUgZGVmaW5pdG lv bi4NCj4gDQo+IElmIHdlIG5lZWQgdG8gZml4IHRoZSAiZ3JhbW1hciIgc2VjdGlvbiB0byBtYW tl IGl0IGNsZWFyIHRoYXQgbm90IGFsbCBQTCANCj4gbWVzc2FnZXMgbmVjZXNzYXJpbHkgdXNlIH Ro ZSBzYW1lIG91dGVybW9zdCBUTFYsIHdlIHNob3VsZCBkbyBzby4gICBNeSBvd24gDQo+IGFwcH Jv YWNoIHdvdWxkIGJlIHRvIHNlcGFyYXRlIHRoZSBncmFtbWFyIGludG8gYSBkZWZpbml0aW9uIG 9m IHRoZSBjb250ZW50cyANCj4gb2YgdGhhdCBUTFYsIGFuZCBhIHNlcGFyYXRlIGRlZmluaXRpb2 4g b2Ygd2hpY2ggVExWcyAvIGNvbnRlbnQgYXJlIGNhcnJpZWQgDQo+IGluIHRoZSBvdXRlcm1vc3 Qg bGV2ZWwgb2Ygd2hpY2ggbWVzc2FnZXMuDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gUF M6 IFdlaW1pbmcsIEkgYW0gc29ycnkgeW91IGdvdCBjYXVnaHQgdXAgaW4gdGhpcyBjb25mdXNpb2 4u ICBJIGRvbid0IHRoaW5rIA0KPiB5b3UgY3JlYXRlZCB0aGUgdGVuZGVuY3kgSSBhbSByYWlsaW 5n IGFnYWluc3QgYWJvdmUuICBJIGFtIGp1c3QgdXNpbmcgeW91ciANCj4gbWVzc2FnZSBhcyBhIH N0 YXJ0aW5nIHBvaW50IHRvIGhhbW1lciBob21lIGEgcG9pbnQuDQo+IA0KPiBBdCAwNDo0NSBBTS A2 LzI2LzIwMDUsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gPk1heWJlIGl0J3MgbWUgd2hvIG1pc3 Nl ZCBzb21ldGhpbmcgOikNCj4gPk15IHRob3VnaHQgd2FzIHdlIG1pZ2h0IG5lZWQgdG8gb2JleS Bv dXIgbWVzc2FnZSBncmFtbWFyIHdlbGwgdGhhdCB3ZSBoYXZlIA0KPiA+dG8gdXNlIGEgc3RyaW N0 IFBhdGgtZGF0YSBmb3Igb3BlcmF0aW9uIFRMVi4gIFRvIG9iZXkgdGhlIHJ1bGUsIHRyZWF0aW 5n IA0KPiA+aXQgYXMgYW4gZXZlbnQgd2lsbCBlYXNlIHRoZSBtZXNzYWdlIGZvcm1hdCBncmVhdG x5 Lg0KPiA+DQo+ID5BY3R1YWxseSBJJ20gdmVyeSBoYXBweSB0byBzZWUgdGhhdCB5b3UgYWdyZW Ug YSBwYXRoIGNhbiBiZSBvbWl0dGVkIGZvciANCj4gPnNvbWUgc3BlY2lmaWMgbWVzc2FnZXMgbG lr ZSByZWRpcmVjdCBtZXNzZ2UuDQo+ID4NCj4gPk9LLCBsZXQncyBzb2x2ZSBpdCB0aGVuLCB0by Bs ZXQgcmVkaXJlY3QgbWVzc2FnZSBvbmx5IGNvbnRhaW4gRGF0YSANCj4gPmZpZWxkPyAgSSBjYW 4g dXBkYXRlIHRoaXMgcmVkaXJlY3QgbWVzc2FnZSBwYXJ0IHRleHQgdGhlbi4NCj4gPg0KPiA+Sm Ft YWwsIGNvdWxkIHlvdSBnaXZlIGEgcmVzcG9uc2Ugb24gdGhpcz8NCj4gPg0KPiA+T25lICBsZX Nz IHZpdGFsIHF1ZXN0aW9uIGlzLCBzaGFsbCB3ZSBhbGxvdyBmb3IgbXVsaXRwdWwgcmVkaXJlY3 Qg cGFja2V0cyANCj4gPmVuY2Fwc3VsYXRlZCBpbiBvbmUgVExWIG9yIGp1c3Qgb25lIFRMViBvbm x5 IGZvciBvbmUgcGFja2V0PyBUbyB1c2UgdGhlIA0KPiA+Zm9ybWVyLCB3ZSBoYXZlIHRvIGRlZm lu ZSBhIHNlcXVlbmNlIGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIHRoZW4gaW4gDQo+ID50aG Ug VExWLg0KPiA+DQo+ID5PbiAgdGhlIG1ldGEtaW5mb3JtYXRpb24gcmVsYXRlZCwgSSB0aGluay BM RkIgSURzIGhhcyBhbHJlYWR5IGJlZW4gDQo+ID5pbmNsdWRlZC4gSSBkb24ndCB0aGluayB3ZS Bu ZWVkIGFuIGV4dHJhIHBvcnQgSUQgdG8gaW5kaWNhdGUgd2hlcmUgdG8gcHV0IA0KPiA+dGhlIH Jl ZGlyZWN0ZWQgZGF0YSB0byBvciB0byBnZXQgcmVkaXJlY3RlZCBkYXRhIGZyb20uIEEgcmVkaX Jl Y3Qgc291cmNlIA0KPiA+TEZCICBvciBzaW5rIExGQiB3aWxsICBoYXZlIGEgcG9ydCBJRCwgd2 hp Y2ggYmVsb25ncyB0byBGRSBMRkIgdG9wb2xvZ3kgDQo+ID5jb25jZXB0LCBhbmQgRkUgTEZCIH Rv cG9sZ3kgY29uZmlndXJhdGlvbiBpcyBpbiBjaGFyZ2Ugb2YgdGhpcy4gIE5vdCBzdXJlIA0KPi A+ aWYgaXQgY29tcGxpZXMgd2l0aCB5b3VyIHRob3VnaHQ/DQo+ID4NCj4gPlRoYW5rcywNCj4gPl dl aW1pbmcNCj4gPg0KPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+RnJvbTogIk pv ZWwgTS4gSGFscGVybiINCj4gPlN1YmplY3Q6IFJlOiBbaXNzdWUzMl0gUGFja2V0IFJlZGlyZW N0 DQo+ID4NCj4gPg0KPiA+ID4gSSBhbSBtaXNzaWduIHNvbWV0aGluZyBpbiB5b3VyIHN1Z2dlc3 Rp b24uDQo+ID4gPg0KPiA+ID4gV2h5IHdvdWxkIHdlIHdhbnQgdG8gdHJlYXQgcmVkaXJlY3RzIG Fz IGV2ZW50cz8NCj4gPiA+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZGlyZWN0cy4NCj4gPi A+ DQo+ID4gPiBJIGFtIHZlcnkgY29uZnVzZWQgYWJvdXQgIkhvdyBhIHBhdGggc2hvdWxkIGJlIG Rl ZmluZWQgaW4gYSBQYWNrZXQgDQo+ID4gUmVkaXJlY3QNCj4gPiA+IE1lc3NhZ2UiLCBzaW5jZS Bh cyBmYXIgYXMgSSBjYW4gdGVsbCwgYSByZWRpcmVjdCBkb2VzIG5vdCBuZWVkIGEgcGF0aC4gIE l0 DQo+ID4gPiBuZWVkcyBhIGNvbGxlY3Rpb24gb2YgbWV0YS1pbmZvcm1hdGlvbiwgd2hpY2ggd2 Ug bmVlZCB0byBkZWZpbmUuICBBdCB0aGUNCj4gPiA+IG1vbWVudCwgdGhhdCBoYXMgdG8gaW5jbH Vk ZSBhdCBsZWFzdCB0aGUgTEZCIElEIHRoYXQgdGhlIHJlZGlyZWN0IGlzIA0KPiA+IGZyb20gLw 0K PiA+ID4gdG8uICBJIHN1cHBvc2UgYnkgZGVjbGFyaW5nIGEgbXVsdGlwbGljaXR5IG9mIHN1Y2 gg TEZCcywgdGhhdCBjYW4gYmUgDQo+ID4gYWxsIG9mDQo+ID4gPiB0aGUgaW5mb3JtYXRpb24uIC Ao SSB1c3VhbGx5IHRoaW5rIGluIHRlcm1zIG9mIGF0IGxlYXN0IGEgbG9naWNhbCBwb3J0IElEDQ o+ ID4gPiB0aGUgcGFja2V0IGNhbWUgZnJvbSAvIGlzIGludGVuZGVkIGZvci4pDQo+ID4gPg0KPi A+ ID4gWW91cnMsDQo+ID4gPiBKb2VsDQo+ID4gPg0KPiA+ID4gQXQgMTA6NTAgUE0gNi8yNS8yMD A1 LCBXZWltaW5nIFdhbmcgd3JvdGU6DQo+ID4gPiA+SmFtYWwsIEpvZWwsIGFuZCBIb3JtemQsDQ o+ ID4gPiA+DQo+ID4gPiA+SSBzdXBwb3NlIHdlIGNvdWxkIGNsb3NlIHRoaXMgaXNzdWUgYnkgcm Vh Y2hpbmcgdGhlIGZvbGxvd2luZyBwb2ludHM6DQo+ID4gPiA+DQo+ID4gPiA+MS4gVGhlIHJlZG ly ZWN0IExGQnMgY2FsbGVkIFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luayBMRk Ig YXJlDQo+ID4gPiA+bW92ZWQgdG8gdGhlIG1vZGVsLCBidXQgdGhlIHByb3RvY29sIHJldGFpbn Mg dGhlIFJlZGlyZWN0IE1lc3NhZ2UuIFRoZQ0KPiA+ID4gPnJlYXNvbiB0byBrZWVwIHRoZSBzcG Vj aWZpYyBtZXNzYWdlIGlzIHdlIG5lZWQgdG8gc3BlY2lmaWNhbGx5IHJlY29nbml6ZQ0KPiA+ID 4g PnJlZGlyZWN0ZWQgZGF0YSBiZXR3ZWVuIENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIGF2b2lkIE Rv UyBhdHRhY2tzLg0KPiA+ID4gPg0KPiA+ID4gPjIuIFRoZSByZWRpcmVjdGVkIGRhdGEgaW4gdG hl IExGQnMgY2FuIGJlIHRyZWF0ZWQgYXMgYSBraW5kIG9mIFNQRUNJQUwNCj4gPiA+ID5ldmVudH Mg aW4gdGhhdDoNCj4gPiA+ID4gICAgICBhLiBUaGUgZXZlbnQgaXMgdHJpZ2dlcmVkIGV2ZXJ5IH Rp bWUgYSBuZXcgcmVkaXJlY3RlZCBwYWNrZXQgDQo+ID4gYXJyaXZlcw0KPiA+ID4gPiBhdCB0aG Ug TEZCcy4NCj4gPiA+ID4gICAgICBiLiBUaGUgZXZlbnQgaXMgdHJhbnNwb3J0ZWQgYnkgdGhlIF Jl ZGlyZWN0ICBNZXNzYWdlIG9ubHksIHdoaWxlIA0KPiA+IHRoZQ0KPiA+ID4gPiBSZWRpcmVjdC BN ZXNzYWdlIHdpbGwgdGhlIHNhbWUgbWVzc2FnZSBmb3JtYXQgYXMgYSBnZW5lcmFsIGV2ZW50DQ o+ ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQgdGhlIG1lc3NhZ2UgdHlwZSBpbi B0 aGUgaGVhZGVyKS4NCj4gPiA+ID4NCj4gPiA+ID5CeSBkb2luZyBpbiB0aGlzIHdheSwgd2UgY2 Fu IGFsc28gc29sdmUgdGhlIGlzc3VlNTMgKEhvdyBhIHBhdGggc2hvdWxkIGJlDQo+ID4gPiA+ZG Vm aW5lZCAgaW4gUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UpIHRoZW4uDQo+ID4gPiA+DQo+ID4gPi A+ VW5mb3J0dW5hdGVseSwgIEkgdGhpbmsgb2YgYW5vdGhlciBxdWVzdGlvbiB0aGF0IGlzIHJlbG F0 ZWQgdG8gdGhlIFBhY2tldA0KPiA+ID4gPlJlZGlyZWN0IE1lc3NhZ2UgYXMgd2VsbCBhcyB0by BF dmVudCBOb3RpZmljYXRpb24gTWVzc2FnZS4gVGhlIHF1ZXN0aW9uDQo+ID4gPiA+aXMsIHRoZS BF dmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSBhbGxvd3MgZXZlbnQgZ2VuZXJhdGVkIGJ5IENFIG Fu ZCBzZW50DQo+ID4gPiA+dG8gRkUuIEluIHRoZSBjYXNlLCBpbiB0aGUgbWVzc2FnZSBmb3JtYX Qs IHRoZSBMRkIgSURzIHJlZmVyIHRvIHRoZSBMRkJzDQo+ID4gPiA+dGhhdCB3aWxsIHJlY2Vpdm Ug dGhlIGV2ZW50IG5vdGlmaWNhdGlvbiwgYnV0IHRoZSBxdWVzdGlvbiBpcywgd2hhdCB0aGUNCj 4g PiA+ID5QYXRoIGluIHRoZSBtZXNzYWdlIHJlZmVycyB0byB0aGVuID8/ICBUaGUgc2FtZSBhbH Nv IGhhcHBlbnMgdG8gUGFja2V0DQo+ID4gPiA+UmVkaXJlY3QgTWVzc2FnZSBmcm9tIENFIHRvIE ZF Lg0KPiA+ID4gPg0KPiA+ID4gPlRoYW5rcywNCj4gPiA+ID5XZWltaW5nDQo+ID4gPiA+DQo+ID 4g PiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPkZyb206ICJBdnJpIERvcm lh IiA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo+ID4gPiA+VG86IDxGT1JDRVNAUEVBQ0guRU FT RS5MU09GVC5DT00+DQo+ID4gPiA+U2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMDUgMjozNSBBTQ 0K PiA+ID4gPlN1YmplY3Q6IFtpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCj4gPiA+ID4NCj4gPi A+ ID4NCj4gPiA+ID5OZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPGF2cmlAYWNtLm9yZz 46 DQo+ID4gPiA+DQo+ID4gPiA+Ni44DQo+ID4gPiA+DQo+ID4gPiA+ICBFZGl0b3JpYWwgTm90ZT og IFRoZXJlIGFyZSBhbHNvIGRpc2N1c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1vZGVsDQo+ID 4g PiA+ICAgICAgICAgICAgICAgICAgICAgdGhhdCBhcmUgcmVsYXRlZCB0byBwYWNrZXQgcmVkaX Jl Y3Qgb3BlcmF0aW9ucw0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBiZSBkZW Zp bmVkLiAgQWx0aG91Z2ggaXQgaXMgb3V0IG9mIHRoZSBzY29wZQ0KPiA+ID4gPiAgICAgICAgIC Ag ICAgICAgICAgIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IHRvIGRlZmluZSB0aGUgTEZCcyBhZm Zl Y3QNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0aGUgUGFja2V0IFJlZGlyZWN0IE1lc3 Nh Z2UgZGVzY3JpYmVkIGhlcmUuICBCZWNhdXNlDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgIC Ag Y3VycmVudGx5IGl0IGlzIHN0aWxsIGluIHByb2dyZXNzIGluIEZFIG1vZGVsIG9uIGhvdw0KPi A+ ID4gPiAgICAgICAgICAgICAgICAgICAgIHRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0by Bw b3N0IHNvbWUgdGhvdWdodHMgb24NCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0aGlzIG hl cmUgZm9yIGRpc2N1c3Npb24uICBUaGV5IHdpbGwgYmUgcmVtb3ZlZA0KPiA+ID4gPiAgICAgIC Ag ICAgICAgICAgICAgIGxhdGVyIGFsb25nIHdpdGggdGhlIHByb2dyZXNzIG9mIHRoZSBGRSBtb2 Rl bCB3b3JrLg0KPiA+ID4gPiAgICAgICAgIFRob3VnaHQgMTogIFRvIGRlZmluZSBMRkJzIGNhbG xl ZCAnUmVkaXJlY3RTaW5rJyBhbmQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaX Jl Y3RUYXAnIGZvciBwYWNrZXQgcmVkaXJlY3QuDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgIC Ag QW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBpcyByZXNwb25zaWJsZSB0bw0KPi A+ ID4gPiAgICAgICAgICAgICAgICAgICAgIGNvbGxlY3QgZGF0YSBwYWNrZXRzIHRoYXQgbmVlZC B0 byBiZSByZWRpcmVjdGVkIHRvDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgQ0UuICBGcm 9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LA0KPiA+ID4gPiAgICAgIC Ag ICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgaXMgYW4gTEZCIHdpdGggb25seS Bv bmUgaW5wdXQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBwb3J0IGFuZCB3aXRob3V0IG Fu eSBvdXRwdXQgcG9ydCwgYW5kIHRoZSBpbnB1dCBwb3J0DQo+ID4gPiA+ICAgICAgICAgICAgIC Ag ICAgICAgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW9kZW wN Cj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIH Ro ZSBmb3J3YXJkaW5nIHBsYW5lLg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIEZyb20gdG hl IHBlcnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsDQo+ID4gPiA+ICAgIC Ag ICAgICAgICAgICAgICAgdGhlICdSZWRpcmVjdFNpbmsnIExGQiB3aWxsIGdlbmVyYXRlIHRoZS BQ YWNrZXQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdCBNZXNzYWdlcyB3aG Vu IGl0IHJlY2VpdmVzIGRhdGEgcGFja2V0cyBmcm9tDQo+ID4gPiA+ICAgICAgICAgICAgICAgIC Ag ICAgZm9yd2FyZGluZyBwbGFuZS4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgICAgIC Ag ICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFRhcCcgaXMgcmVzcG9uc2libGUgdG8NCj 4g PiA+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaXZlIGRhdGEgcGFja2V0cyB0aGF0IGFyZS By ZWRpcmVjdGVkIGZyb20gQ0UuDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRnJvbSB0aG Ug cGVyc3BlY3RpdmUgb2YgdGhlIEZFIExGQiB0b3BvbG9neSwgdGhlDQo+ID4gPiA+ICAgICAgIC Ag ICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgb3 V0 cHV0DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcG9ydCBhbmQgd2l0aG91dCBhbnkgaW 5w dXQgcG9ydCwgYW5kIHRoZSBvdXRwdXQgcG9ydA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgIC Ag IGNhbiB0aGVuIGJlIGNvbm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIG1vZGVsDQo+ID 4g PiA+ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm 9y d2FyZGluZyBwbGFuZS4NCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZX Jz cGVjdGl2ZSBvZiBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsIHRoZQ0KPiA+ID4gPiAgICAgICAgIC Ag ICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZCIGNhbiByZWNlaXZlIHRoZSBQYWNrZXQgUmVkaX Jl Y3QNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBNZXNzYWdlcyBmcm9tIENFLCBhbmQgdW 4t ZW5jYXBzdWxhdGUgdGhlIGRhdGENCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBwYWNrZX Rz IGZyb20gdGhlIG1lc3NhZ2UgYW5kIHB1dCB0aGVtIHRvIGRhdGFwYXRocw0KPiA+ID4gPiAgIC Ag ICAgICAgICAgICAgICAgIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiAgQWN0dWFsbHkgdGhlIC dS ZWNpcmVjdFRhcCcNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIG xp a2UgYSB0cmFuc2NvZGVyIHRoYXQgdHJhbnNmZXJzIHRoZQ0KPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgIEZvckNFUyBwcm90b2NvbCBtZXNzYWdlcyB0byBub3JtYWwgZGF0YSBwYWNrZXRzIG lu DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgSVAgZm9yd2FyZGluZyBwbGFuZS4gIEFzIG Eg cmVzdWx0LCBpZiB3ZSBuZWVkIHRvDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgaGF2ZS By ZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbWUgTEZCIChzYXkgYQ0KPiA+ID4gPi Ag ICAgICAgICAgICAgICAgICAgIFNjaGVkdWxlcikgaW4gRkUgbW9kZWwsIHdlIG9ubHkgbmVlZC B0 byBjb25uZWN0IHRoZQ0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcC BM RkIgdG8gdGhlIFNjaGVkdWxlciBMRkIgZGlyZWN0bHkgdmlhIGENCj4gPiA+ID4gICAgICAgIC Ag ICAgICAgICAgICBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID 4g PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgIC Ag Ky0tLS0tLS0tLS0tKw0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgUm Vk aXJlY3RUYXAgTEZCIHwtLS0tLS0+fCAgICAgICAgICAgfA0KPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgfCAgICAgICAgICAgfA 0K PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgfCBTY2hlZHVsZXIgfA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICBGcm9tIG90aGVyIExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KPiA+ID4gPiAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIC Ag ICAgfA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgRmlndXJlIDI3DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgIC Ag ICAgICAgICAgQnkgdXNlIG9mIHNldmVyYWwgJ1JlZGlyZWN0U2luaycgTEZCcyBhbmQgc2V2ZX Jh bA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZCcyB0aGF0IG Nv bm5lY3QgdG8gc2V2ZXJhbCBkaWZmZXJlbnQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgIC Bk YXRhcGF0aHMgaW4gRkUgZm9yd2FyZGluZyBwbGFuZSwgbXVsdGlwbGUgcGFja2V0DQo+ID4gPi A+ ICAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3QgcGF0aHMgYmV0d2VlbiBDRSBhbmQgRkUgY2 Fu IGJlIGNvbnN0cnVjdGVkLg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgIFRob3VnaHQgMjogIF Ro ZXJlIG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQo+ID4gPiA+ICAgIC Ag ICAgICAgICAgICAgICAgcmVkaXJlY3RlZDogZGlyZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdG gs IGUuZy4sIGJ5DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRlBHQS9BU0lDL05QIG1pY3 Jv Y29kZS4gIEluIHN1Y2ggYSBjYXNlIHdlIGRvIG5vdA0KPiA+ID4gPiAgICAgICAgICAgICAgIC Ag ICAgIG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIHNtYXJ0bmVzcy4gIFByb2JhYmx5IGEgbGluaw 0K PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbC Bo ZWFkZXIgaXMgZW5vdWdoLiAgVGhlDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcmVjZW l2 ZXIgZGVtdXhlcyBpdCBvbmx5IGJhc2VkIG9uIHNvbWUgcHJvdG9jb2wgdHlwZQ0KPiA+ID4gPi Ag ICAgICAgICAgICAgICAgICAgIGluIHRoZSBsaW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNwb3 J0 IGxheWVyLiAgVGhlDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcHJvcyBmb3IgdGhpcy Bh cHByYW9jaCBpcyBpdCBtYXkgcHJvdmlkZSBhIGZhc3QgYW5kDQo+ID4gPiA+ICAgICAgICAgIC Ag ICAgICAgICAgY29zdC1lZmZlY3RpdmUgcGF0aCBmb3IgcGFja2V0IHJlZGlyZWN0LiAgVGhlIG Nv bnMNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZS Bv ciBsZXNzIGNvbmZ1c2VzIHRoZSBGcA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHJlZm Vy ZW5jZSBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuDQo+ID4gPiA+DQo+ID 4g PiA+LS0tLS0tLS0tLQ0KPiA+ID4gPmNhdGVnb3J5OiBFZGl0b3JpYWwNCj4gPiA+ID5kcmFmdD og ZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wNCj4gPiA+ID5tZXNzYWdlczogNDkNCj4gPiA+ID 5u b3N5OiBhdnJpDQo+ID4gPiA+cHJpb3JpdHk6IE11c3QgZml4DQo+ID4gPiA+c3RhdHVzOiBOby Bk aXNjdXNzaW9uDQo+ID4gPiA+dGl0bGU6IFBhY2tldCBSZWRpcmVjdA0KPiA+ID4gPg0KPiA+ID 4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPi A+ ID4gPkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NCj4gPi A+ ID48aHR0cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzMj4NCj 4g PiA+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 8N Cj4gPiA+ ------=_NextPart_000_0009_01C57B63.BA753770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYW wv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udG Vu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE 1M IDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRU FE Pg0KPEJPRFk+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Sm9lbC A6 KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj 48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaX pl PTI+SG93IGFib3V0IHdlIGp1c3Qgb2Jzb2xldGUgdGhlIHBhdGggZnJvbSB0aGUgZGF0YSANCn N0 cnVjdHVyZSBhbmQgYWRkIHNvbWUgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMj M0 MzU7JiMyMDMwNzsgc2l6ZT0yPm1ldGEtaW5mb3JtYXRpb24sIGFuZCZuYnNwO2Zvcm0gdGhlIG Zv cm1hdCBhcyBiZWxvdyAoSSANCmN1cnJlbnRseSBjYW4gb25seSB0aGluayA8L0ZPTlQ+PC9ESV Y+ DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+b2YgdGhlIG1ldGEtaW 5m b3JtYXRpb24gYXMgdGhlIHBhY2tldCB0eXBlLiBXZSBtYXkgYWRkIA0Kc29tZSBtb3JlIGxhdG Vy KS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPT I+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2 l6 ZT0yPkNvdWxkIHlvdSBnaXZlIG1vcmUgY29tbWVudHMgb24gdGhpcywgdGhlbiB3ZSBtYXkgDQ pz b2x2ZSB0aGlzIGlzc3VlIHNvb24/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMj M0 MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT 0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5UaGFuayZuYnNwO3lvdSB2ZXJ5IG11Y2guPC9GT05UPj wv RElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbm Jz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5XZWltaW 5n PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPj wv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpem U9 Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ji My MzQzNTsmIzIwMzA3OyBzaXplPTI+TWVzc2FnZSBCb2R5OjxCUj4mbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsgDQpDb25zaXN0cyBvZiBvbmUgb3IgbW9yZSBUTFZzLCB3aXRoIGV2ZXJ5IF RM ViBoYXZpbmcgdGhlIA0KZm9sbG93aW5nPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyBkYXRhIGZvcm1hdDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIz Iw MzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0Mz U7 JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyAwIDEgMiAzIDQgNSANCjYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNS A2 IDcgOCA5IDAgDQoxPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHlwZSA9IA 0K TEZCc2VsZWN0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyANCkxlbmd0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyANCkxGQiBDbGFzcyANCklEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj 4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj 4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7IA0KTEZCIEluc3RhbmNlIA0KSUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sg DQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpPcGVyYXRpb24gDQpUTFYmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyANCi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQouPEJSPiZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPEJSPiZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCn4mbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQouLi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQ p+ PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsgDQpPcGVyYXRpb24gDQpUTFYmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyANCi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQouPEJSPiZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9GT05UPjwvRE lW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOzwvRk9OVD 48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbm Jz cDsgTEZCIGNsYXNzIA0KSUQ6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaG Vy ZSBhcmUgb25seSB0d28gcG9zc2libGUgTEZCIGNsYXNzZXMgDQpoZXJlLCB0aGUgJ1JlZGlyZW N0 U2luayc8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExGQiBvciB0aGUgDQonUm Vk aXJlY3RTb3VyY2UnIExGQi4mbmJzcDsgSWYgdGhlIG1lc3NhZ2UgaXMgZnJvbSBGRSB0byANCk NF LDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIExGQiBjbGFzcyBzaG91bG Qg YmUgDQonUmVkaXJlY3RTaW5rJy4mbmJzcDsgSWYgdGhlIG1lc3NhZ2UgaXMgZnJvbSANCkNFPE JS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBGRSwgdGhlIExGQiBjbGFzcyBzaG 91 bGQgYmUgDQonUmVkaXJlY3RTb3VyY2UnLjxCUj4mbmJzcDsmbmJzcDsgSW5zdGFuY2UgSUQ6PE JS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkluc3RhbmNlIElEIGZvciB0aGUgJ1 Jl ZGlyZWN0U2luaycgTEZCIG9yICdSZWRpcmVjdFNvdXJjZScgTEZCLjxCUj4mbmJzcDsmbmJzcD sg DQpPcGVyYXRpb24gVExWOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcy Bp cyBhIFRMViBkZXNjcmliaW5nIG9uZSANCnBhY2tldCBvZiBkYXRhIHRvIGJlIGRpcmVjdGVkIH Zp YSB0aGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0Kc3BlY2lmaWVkIExGQi Bh Ym92ZS4mbmJzcDsgVGhlIG9yZGVyIG9mIHRoZSBUTFYgYXBwZWFyZWQgaXMgYWxzbyANCnRoZT xC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3JkZXIgdGhlIGRhdGEgcGFja2V0IG Fy cml2ZXMgdGhlIA0KcmVkaXJlY3RvciBMRkIsIHRoYXQgaXMsIHRoZTxCUj4mbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsgUmVkaXJlY3RlZCANCkRhdGEmbmJzcDsgaW4gdGhlIGZpcnN0IF RM ViZuYnNwO3Nob3VsZCBhcnJpdmUgdGhlIGVhcmxpZXN0LiZuYnNwOyA8L0ZPTlQ+PC9ESVY+DQ o8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRE lW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlRoZSBUTFYgZm9ybW F0 IGlzIGFzIGZvbGxvd3M6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7Ji My MDMwNzsgc2l6ZT0yPiZuYnNwOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLS st Ky0rLSstKy0rLSstKy0rLSstKzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFR5cGUgPSANClBBWUxPQUQmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KTGVuZ3RoJm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLSstKy0rLSstKy0rLSstKy 0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj4mbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt+Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KUGFja2V0IFR5cGUmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGFja2 V0 IA0KTGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 IA0KfjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2 l6 ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO34mbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpSZWRpcmVjdGVkJm5ic3A7UGFja2V0Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 IA0KfjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLS st Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy 0r LSstKzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpem U9 Mj4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oy Bz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KVHlwZTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7VGhlIHR5cGUgZm9yIHRoZSBUTFYgaXMgc2V0IHRvIA0KJ1BBWUxPQU Qn LiA8L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTl Q+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPS Yj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNz sg c2l6ZT0yPjwvRk9OVD4NCjxESVY+PEJSPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaX pl PTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlbmd0aDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIG Zh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7dGhlIGxlbmd0aCBvZiB0aGUgDQpUTFYoaW4gNGJ5dGVzKS48L0ZPTlQ+PC9ESVY+DQ o8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRE lW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOy Zu YnNwOyBQYWNrZXQgVHlwZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNT sm IzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RGVmaW 5l cyB3aGF0IHR5cGUgDQp0aGUgcmVkaXJlY3RlZCBwYWNrZXQgYmVsb25ncyB0byhzdWNoIGFzIC dJ UHY0IFBhY2tldCcsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMD Mw Nzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsnSVB2NiBQYWNrZXQnKS4gJm5ic3 A7 Jm5ic3A7IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNz sg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMj Az MDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgUGFja2V0IExlbmd0aDoNCjxESVY+PEZPTl Qg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDt0aGUgbGVuZ3RoIG9mIHRoZSANCmZvbGxvd2VkIHJlZGlyZWN0ZWQgcGFja2V0IC hp biBieXRlKTwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMz Qz NTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPS Yj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBSZWRpcmVjdGVkIA0KUG Fj a2V0OjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvbmUmbmJzcDtyZW Rp cmVjdGVkJm5ic3A7cGFja2V0LiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT 0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZuYn Nw OzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj 48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaX pl PTI+Jm5ic3A7PC9ESVY+PC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNz sg c2l6ZT0yPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9GT05UPg0KPERJVj48Rk9OVC Bm YWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkZyb206ICJKb2VsIE0uIEhhbHBlcm4iICZsdD s8 L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86am9lbEBzdGV2ZWNyb2NrZXIuY29tIj48Rk9OVCBmYW Nl PSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+am9lbEBzdGV2ZWNyb2NrZXIuY29tPC9GT05UPj wv QT48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+Jmd0OzwvRk9OVD48L0RJVj 48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxCUj48Rk9OVCBzaXplPT I+ PC9GT05UPjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPT I+ Jmd0OyBJIHdvdWxkIGV4cGVjdCB0aGF0IGEgUmVkaXJlY3QgTWVzc2FnZSBoYXMgYSBkaWZmZX Jl bnQgb3V0ZXJtb3N0IA0KVExWLiZuYnNwOyBUaGUgPEJSPiZndDsgZ3JhbW1hciBpcyBpbnRlbm Rl ZCB0byBoZWxwIHVzLCBub3Qgc2VydmUgYXMgYSANCnN0cmFpZ2h0amFja2V0LiZuYnNwOyBEaW Zm ZXJlbnQgPEJSPiZndDsgbWVzc2FnZSB0eXBlcyBjYW4gaGF2ZSBkaWZmZXJlbnQgb3V0ZXIgDQ pU TFZzLiZuYnNwOyBJdCBpcyBkZXNpcmFibGUgdG8gdXNlIHRoZSA8QlI+Jmd0OyBzYW1lIHN0cn Vj dHVyZSB3aGVuIGl0IA0KYXBwbGllcy4mbmJzcDsgQnV0IHRoZSByZWRpcmVjdCBtZXNzYWdlIG lz IHNpbXBseSBhIDxCUj4mZ3Q7IGRpZmZlcmVudCANCmNhc2UuJm5ic3A7IEl0J3MgY29udGVudH Mg YXJlIG5vdCBhIERBVEFSQVcgbXVjaCBsZXNzIGEgREFUQSBUTFYuJm5ic3A7IEl0cyANCjxCUj 4m Z3Q7IGNvbnRlbnQgc3RydWN0dXJlIGlzIG5vdCBkZWZpbmVkIGJ5IGFuIExGQiBlbGVtZW50IG Rl ZmluaXRpb24gb3IgTW9kZWwgDQo8QlI+Jmd0OyBEYXRhRGVmcyBzdHJ1Y3R1cmUgZGVmaW5pdG lv bi48QlI+Jmd0OyA8QlI+Jmd0OyBJZiB3ZSBuZWVkIHRvIGZpeCB0aGUgDQoiZ3JhbW1hciIgc2 Vj dGlvbiB0byBtYWtlIGl0IGNsZWFyIHRoYXQgbm90IGFsbCBQTCA8QlI+Jmd0OyBtZXNzYWdlcy Bu ZWNlc3NhcmlseSANCnVzZSB0aGUgc2FtZSBvdXRlcm1vc3QgVExWLCB3ZSBzaG91bGQgZG8gc2 8u Jm5ic3A7Jm5ic3A7IE15IG93biA8QlI+Jmd0OyANCmFwcHJvYWNoIHdvdWxkIGJlIHRvIHNlcG Fy YXRlIHRoZSBncmFtbWFyIGludG8gYSBkZWZpbml0aW9uIG9mIHRoZSBjb250ZW50cyANCjxCUj 4m Z3Q7IG9mIHRoYXQgVExWLCBhbmQgYSBzZXBhcmF0ZSBkZWZpbml0aW9uIG9mIHdoaWNoIFRMVn Mg LyBjb250ZW50IGFyZSANCmNhcnJpZWQgPEJSPiZndDsgaW4gdGhlIG91dGVybW9zdCBsZXZlbC Bv ZiB3aGljaCBtZXNzYWdlcy48QlI+Jmd0OyA8QlI+Jmd0OyANCllvdXJzLDxCUj4mZ3Q7IEpvZW w8 QlI+Jmd0OyA8QlI+Jmd0OyBQUzogV2VpbWluZywgSSBhbSBzb3JyeSB5b3UgZ290IGNhdWdodC B1 cCANCmluIHRoaXMgY29uZnVzaW9uLiZuYnNwOyBJIGRvbid0IHRoaW5rIDxCUj4mZ3Q7IHlvdS Bj cmVhdGVkIHRoZSB0ZW5kZW5jeSBJIGFtIA0KcmFpbGluZyBhZ2FpbnN0IGFib3ZlLiZuYnNwOy BJ IGFtIGp1c3QgdXNpbmcgeW91ciA8QlI+Jmd0OyBtZXNzYWdlIGFzIGEgc3RhcnRpbmcgDQpwb2 lu dCB0byBoYW1tZXIgaG9tZSBhIHBvaW50LjxCUj4mZ3Q7IDxCUj4mZ3Q7IEF0IDA0OjQ1IEFNID Yv MjYvMjAwNSwgDQpXYW5nLFdlaW1pbmcgd3JvdGU6PEJSPiZndDsgJmd0O01heWJlIGl0J3MgbW Ug d2hvIG1pc3NlZCBzb21ldGhpbmcgOik8QlI+Jmd0OyANCiZndDtNeSB0aG91Z2h0IHdhcyB3ZS Bt aWdodCBuZWVkIHRvIG9iZXkgb3VyIG1lc3NhZ2UgZ3JhbW1hciB3ZWxsIHRoYXQgd2UgaGF2ZS AN CjxCUj4mZ3Q7ICZndDt0byB1c2UgYSBzdHJpY3QgUGF0aC1kYXRhIGZvciBvcGVyYXRpb24gVE xW LiZuYnNwOyBUbyBvYmV5IHRoZSANCnJ1bGUsIHRyZWF0aW5nIDxCUj4mZ3Q7ICZndDtpdCBhcy Bh biBldmVudCB3aWxsIGVhc2UgdGhlIG1lc3NhZ2UgZm9ybWF0IA0KZ3JlYXRseS48QlI+Jmd0Oy Am Z3Q7PEJSPiZndDsgJmd0O0FjdHVhbGx5IEknbSB2ZXJ5IGhhcHB5IHRvIHNlZSB0aGF0IHlvdS Bh Z3JlZSANCmEgcGF0aCBjYW4gYmUgb21pdHRlZCBmb3IgPEJSPiZndDsgJmd0O3NvbWUgc3BlY2 lm aWMgbWVzc2FnZXMgbGlrZSByZWRpcmVjdCANCm1lc3NnZS48QlI+Jmd0OyAmZ3Q7PEJSPiZndD sg Jmd0O09LLCBsZXQncyBzb2x2ZSBpdCB0aGVuLCB0byBsZXQgcmVkaXJlY3QgDQptZXNzYWdlIG 9u bHkgY29udGFpbiBEYXRhIDxCUj4mZ3Q7ICZndDtmaWVsZD8mbmJzcDsgSSBjYW4gdXBkYXRlIH Ro aXMgcmVkaXJlY3QgDQptZXNzYWdlIHBhcnQgdGV4dCB0aGVuLjxCUj4mZ3Q7ICZndDs8QlI+Jm d0 OyAmZ3Q7SmFtYWwsIGNvdWxkIHlvdSBnaXZlIGEgDQpyZXNwb25zZSBvbiB0aGlzPzxCUj4mZ3 Q7 ICZndDs8QlI+Jmd0OyAmZ3Q7T25lJm5ic3A7IGxlc3Mgdml0YWwgcXVlc3Rpb24gaXMsIA0Kc2 hh bGwgd2UgYWxsb3cgZm9yIG11bGl0cHVsIHJlZGlyZWN0IHBhY2tldHMgPEJSPiZndDsgJmd0O2 Vu Y2Fwc3VsYXRlZCBpbiBvbmUgDQpUTFYgb3IganVzdCBvbmUgVExWIG9ubHkgZm9yIG9uZSBwYW Nr ZXQ/IFRvIHVzZSB0aGUgPEJSPiZndDsgJmd0O2Zvcm1lciwgd2UgaGF2ZSANCnRvIGRlZmluZS Bh IHNlcXVlbmNlIGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIHRoZW4gaW4gPEJSPiZndDsgJm d0 O3RoZSANClRMVi48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0O09uJm5ic3A7IHRoZSBtZXRhLW lu Zm9ybWF0aW9uIHJlbGF0ZWQsIEkgdGhpbmsgTEZCIA0KSURzIGhhcyBhbHJlYWR5IGJlZW4gPE JS PiZndDsgJmd0O2luY2x1ZGVkLiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgYW4gZXh0cmEgcG9ydC AN CklEIHRvIGluZGljYXRlIHdoZXJlIHRvIHB1dCA8QlI+Jmd0OyAmZ3Q7dGhlIHJlZGlyZWN0ZW Qg ZGF0YSB0byBvciB0byBnZXQgDQpyZWRpcmVjdGVkIGRhdGEgZnJvbS4gQSByZWRpcmVjdCBzb3 Vy Y2UgPEJSPiZndDsgJmd0O0xGQiZuYnNwOyBvciBzaW5rIExGQiANCndpbGwmbmJzcDsgaGF2ZS Bh IHBvcnQgSUQsIHdoaWNoIGJlbG9uZ3MgdG8gRkUgTEZCIHRvcG9sb2d5IDxCUj4mZ3Q7IA0KJm d0 O2NvbmNlcHQsIGFuZCBGRSBMRkIgdG9wb2xneSBjb25maWd1cmF0aW9uIGlzIGluIGNoYXJnZS Bv ZiB0aGlzLiZuYnNwOyBOb3QgDQpzdXJlIDxCUj4mZ3Q7ICZndDtpZiBpdCBjb21wbGllcyB3aX Ro IHlvdXIgdGhvdWdodD88QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgDQomZ3Q7VGhhbmtzLDxCUj4mZ3 Q7 ICZndDtXZWltaW5nPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDstLS0tLSBPcmlnaW5hbCBNZX Nz YWdlIA0KLS0tLS08QlI+Jmd0OyAmZ3Q7RnJvbTogIkpvZWwgTS4gSGFscGVybiI8QlI+Jmd0Oy Am Z3Q7U3ViamVjdDogUmU6IFtpc3N1ZTMyXSANClBhY2tldCBSZWRpcmVjdDxCUj4mZ3Q7ICZndD s8 QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEkgYW0gbWlzc2lnbiANCnNvbWV0aGluZy Bp biB5b3VyIHN1Z2dlc3Rpb24uPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IF do eSB3b3VsZCB3ZSANCndhbnQgdG8gdHJlYXQgcmVkaXJlY3RzIGFzIGV2ZW50cz88QlI+Jmd0Oy Am Z3Q7ICZndDsgV2Ugc2hvdWxkIHRyZWF0IHRoZW0gYXMgDQpyZWRpcmVjdHMuPEJSPiZndDsgJm d0 OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEkgYW0gdmVyeSBjb25mdXNlZCBhYm91dCAiSG93IG Eg DQpwYXRoIHNob3VsZCBiZSBkZWZpbmVkIGluIGEgUGFja2V0IDxCUj4mZ3Q7ICZndDsgUmVkaX Jl Y3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgDQpNZXNzYWdlIiwgc2luY2UgYXMgZmFyIGFzIEkgY2FuIH Rl bGwsIGEgcmVkaXJlY3QgZG9lcyBub3QgbmVlZCBhIHBhdGguJm5ic3A7IA0KSXQ8QlI+Jmd0Oy Am Z3Q7ICZndDsgbmVlZHMgYSBjb2xsZWN0aW9uIG9mIG1ldGEtaW5mb3JtYXRpb24sIHdoaWNoIH dl IG5lZWQgdG8gDQpkZWZpbmUuJm5ic3A7IEF0IHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyBtb21lbn Qs IHRoYXQgaGFzIHRvIGluY2x1ZGUgYXQgbGVhc3QgdGhlIA0KTEZCIElEIHRoYXQgdGhlIHJlZG ly ZWN0IGlzIDxCUj4mZ3Q7ICZndDsgZnJvbSAvPEJSPiZndDsgJmd0OyAmZ3Q7IHRvLiZuYnNwOy BJ IA0Kc3VwcG9zZSBieSBkZWNsYXJpbmcgYSBtdWx0aXBsaWNpdHkgb2Ygc3VjaCBMRkJzLCB0aG F0 IGNhbiBiZSA8QlI+Jmd0OyAmZ3Q7IGFsbCANCm9mPEJSPiZndDsgJmd0OyAmZ3Q7IHRoZSBpbm Zv cm1hdGlvbi4mbmJzcDsgKEkgdXN1YWxseSB0aGluayBpbiB0ZXJtcyBvZiBhdCANCmxlYXN0IG Eg bG9naWNhbCBwb3J0IElEPEJSPiZndDsgJmd0OyAmZ3Q7IHRoZSBwYWNrZXQgY2FtZSBmcm9tIC 8g aXMgaW50ZW5kZWQgDQpmb3IuKTxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0Oy BZ b3Vycyw8QlI+Jmd0OyAmZ3Q7ICZndDsgSm9lbDxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7PEJSPiZndD sg Jmd0OyAmZ3Q7IEF0IDEwOjUwIFBNIDYvMjUvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOjxCUj 4m Z3Q7IA0KJmd0OyAmZ3Q7ICZndDtKYW1hbCwgSm9lbCwgYW5kIEhvcm16ZCw8QlI+Jmd0OyAmZ3 Q7 ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtJIHN1cHBvc2Ugd2UgY291bGQgY2 xv c2UgdGhpcyBpc3N1ZSBieSByZWFjaGluZyB0aGUgZm9sbG93aW5nIA0KcG9pbnRzOjxCUj4mZ3 Q7 ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsxLiBUaGUgcmVkaXJlY3QgTE ZC cyBjYWxsZWQgDQpSZWRpcmVjdFNvdXJjZSZuYnNwOyBMRkIgYW5kIFJlZGlyZWN0U2luayBMRk Ig YXJlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDttb3ZlZCB0byANCnRoZSBtb2RlbCwgYnV0IHRoZS Bw cm90b2NvbCByZXRhaW5zIHRoZSBSZWRpcmVjdCBNZXNzYWdlLiBUaGU8QlI+Jmd0OyAmZ3Q7IC Zn dDsgDQomZ3Q7cmVhc29uIHRvIGtlZXAgdGhlIHNwZWNpZmljIG1lc3NhZ2UgaXMgd2UgbmVlZC B0 byBzcGVjaWZpY2FsbHkgDQpyZWNvZ25pemU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0O3JlZGlyZW N0 ZWQgZGF0YSBiZXR3ZWVuIENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIA0KYXZvaWQgRG9TIGF0dG Fj a3MuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzIuIFRoZS AN CnJlZGlyZWN0ZWQgZGF0YSBpbiB0aGUgTEZCcyBjYW4gYmUgdHJlYXRlZCBhcyBhIGtpbmQgb2 Yg U1BFQ0lBTDxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDtldmVudHMgaW4gdGhhdDo8QlI+Jmd0Oy Am Z3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhLiANClRoZSBldm Vu dCBpcyB0cmlnZ2VyZWQgZXZlcnkgdGltZSBhIG5ldyByZWRpcmVjdGVkIHBhY2tldCA8QlI+Jm d0 OyAmZ3Q7IA0KYXJyaXZlczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0IHRoZSBMRkJzLjxCUj 4m Z3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYi4gVG hl IGV2ZW50IGlzIHRyYW5zcG9ydGVkIGJ5IHRoZSANClJlZGlyZWN0Jm5ic3A7IE1lc3NhZ2Ugb2 5s eSwgd2hpbGUgPEJSPiZndDsgJmd0OyB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANClJlZG ly ZWN0IE1lc3NhZ2Ugd2lsbCB0aGUgc2FtZSBtZXNzYWdlIGZvcm1hdCBhcyBhIGdlbmVyYWwgZX Zl bnQ8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyAmZ3Q7IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcH Qg dGhlIG1lc3NhZ2UgdHlwZSBpbiB0aGUgaGVhZGVyKS48QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3 Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDtCeSBkb2luZyBpbiB0aGlzIHdheSwgd2UgY2FuIGFsc2 8g c29sdmUgdGhlIA0KaXNzdWU1MyAoSG93IGEgcGF0aCBzaG91bGQgYmU8QlI+Jmd0OyAmZ3Q7IC Zn dDsgJmd0O2RlZmluZWQmbmJzcDsgaW4gUGFja2V0IA0KUmVkaXJlY3QgTWVzc2FnZSkgdGhlbi 48 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtVbmZvcnR1bm F0 ZWx5LCZuYnNwOyBJIHRoaW5rIG9mIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIH Rv IHRoZSANClBhY2tldDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7UmVkaXJlY3QgTWVzc2FnZSBhcy B3 ZWxsIGFzIHRvIEV2ZW50IE5vdGlmaWNhdGlvbiANCk1lc3NhZ2UuIFRoZSBxdWVzdGlvbjxCUj 4m Z3Q7ICZndDsgJmd0OyAmZ3Q7aXMsIHRoZSBFdmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSANCm Fs bG93cyBldmVudCBnZW5lcmF0ZWQgYnkgQ0UgYW5kIHNlbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJm d0 O3RvIEZFLiBJbiB0aGUgY2FzZSwgDQppbiB0aGUgbWVzc2FnZSBmb3JtYXQsIHRoZSBMRkIgSU Rz IHJlZmVyIHRvIHRoZSBMRkJzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDt0aGF0IA0Kd2lsbCByZW Nl aXZlIHRoZSBldmVudCBub3RpZmljYXRpb24sIGJ1dCB0aGUgcXVlc3Rpb24gaXMsIHdoYXQgdG hl PEJSPiZndDsgJmd0OyANCiZndDsgJmd0O1BhdGggaW4gdGhlIG1lc3NhZ2UgcmVmZXJzIHRvIH Ro ZW4gPz8mbmJzcDsgVGhlIHNhbWUgYWxzbyBoYXBwZW5zIHRvIA0KUGFja2V0PEJSPiZndDsgJm d0 OyAmZ3Q7ICZndDtSZWRpcmVjdCBNZXNzYWdlIGZyb20gQ0UgdG8gRkUuPEJSPiZndDsgJmd0Oy Am Z3Q7IA0KJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7VGhhbmtzLDxCUj4mZ3Q7ICZndDsgJm d0 OyAmZ3Q7V2VpbWluZzxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndD sg Jmd0Oy0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3 Q7 RnJvbTogIkF2cmkgRG9yaWEiICZsdDs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnRyYWNrZXItZm 9y Y2VzQG1pcDQub3JnIj48Rk9OVCANCmZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+dHJhY2 tl ci1mb3JjZXNAbWlwNC5vcmc8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oy AN CnNpemU9Mj4mZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDtUbzogJmx0OzwvRk9OVD48QSANCm hy ZWY9Im1haWx0bzpGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00iPjxGT05UIGZhY2U9JiMyMz Qz NTsmIzIwMzA3OyANCnNpemU9Mj5GT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT008L0ZPTlQ+PC 9B PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jmd0OzxCUj4mZ3Q7IA0KJmd0Oy Am Z3Q7ICZndDtTZW50OiBNb25kYXksIE1heSAyMywgMjAwNSAyOjM1IEFNPEJSPiZndDsgJmd0Oy Am Z3Q7ICZndDtTdWJqZWN0OiANCltpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3Q8QlI+Jmd0OyAmZ3 Q7 ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgDQomZ3Q7ICZndDsgJm d0 O05ldyBzdWJtaXNzaW9uIGZyb20gQXZyaSBEb3JpYSAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibW Fp bHRvOmF2cmlAYWNtLm9yZyI+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5hdn Jp QGFjbS5vcmc8L0ZPTlQ+PC9BPjxGT05UIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj 4m Z3Q7OjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs2Ljg8Ql I+ Jmd0OyANCiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgRWRpdG 9y aWFsIE5vdGU6Jm5ic3A7IFRoZXJlIGFyZSBhbHNvIA0KZGlzY3Vzc2lvbnMgb24gaG93IExGQn Mg aW4gRkUgbW9kZWw8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdGhhdCBhcmUgcm Vs YXRlZCB0byBwYWNrZXQgcmVkaXJlY3Qgb3BlcmF0aW9uczxCUj4mZ3Q7ICZndDsgJmd0OyANCi Zn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsgDQpzaG91bGQgYmUgZGVmaW5lZC4mbmJzcDsgQWx0aG91Z2ggaXQgaXMgb3V0IG 9m IHRoZSBzY29wZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpvZiBmb3JjZXMgcH Jv dG9jb2wsIGhvdyB0byBkZWZpbmUgdGhlIExGQnMgYWZmZWN0PEJSPiZndDsgJmd0OyAmZ3Q7IA 0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyANCnRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkZXNjcmliZWQgaGVyZS 4m bmJzcDsgQmVjYXVzZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpjdXJyZW50bH kg aXQgaXMgc3RpbGwgaW4gcHJvZ3Jlc3MgaW4gRkUgbW9kZWwgb24gaG93PEJSPiZndDsgJmd0Oy Am Z3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyANCnRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBwb3N0IH Nv bWUgdGhvdWdodHMgb248QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdGhpcyBoZX Jl IGZvciBkaXNjdXNzaW9uLiZuYnNwOyBUaGV5IHdpbGwgYmUgcmVtb3ZlZDxCUj4mZ3Q7ICZndD sg Jmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsgDQpsYXRlciBhbG9uZyB3aXRoIHRoZSBwcm9ncmVzcyBvZiB0aG Ug RkUgbW9kZWwgd29yay48QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRob3VnaHQgMTombmJzcDsgVG8gZGVmaW 5l IA0KTEZCcyBjYWxsZWQgJ1JlZGlyZWN0U2luaycgYW5kPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJm d0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyANCidSZWRpcmVjdFRhcCcgZm9yIHBhY2tldCByZWRpcmVjdC48QlI+Jmd0OyAmZ3 Q7 ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KQW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RTaW5rJy Bp cyByZXNwb25zaWJsZSB0bzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpjb2xsZW N0 IGRhdGEgcGFja2V0cyB0aGF0IG5lZWQgdG8gYmUgcmVkaXJlY3RlZCB0bzxCUj4mZ3Q7ICZndD sg Jmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsgDQpDRS4mbmJzcDsgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdG hl IEZFIExGQiB0b3BvbG9neSw8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdGhlIC dS ZWRpcmVjdFNpbmsnIExGQiBpcyBhbiBMRkIgd2l0aCBvbmx5IG9uZSBpbnB1dDxCUj4mZ3Q7IC Zn dDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwb3J0IGFuZCB3aXRob3V0IGFueSBvdXRwdXQgcG9ydC wg YW5kIHRoZSBpbnB1dCBwb3J0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmNhbi B0 aGVuIGJlIGNvbm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIG1vZGVsPEJSPiZndDsgJm d0 OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyANCmJ5IG1lYW5zIG9mIGEgZGF0YXBhdGggaW4gdGhlIGZvcn dh cmRpbmcgcGxhbmUuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkZyb20gdGhlIH Bl cnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsPEJSPiZndDsgJmd0OyAmZ3 Q7 IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyANCnRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgd2lsbCBnZW5lcmF0ZSB0aG Ug UGFja2V0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClJlZGlyZWN0IE1lc3NhZ2 Vz IHdoZW4gaXQgcmVjZWl2ZXMgZGF0YSBwYWNrZXRzIGZyb208QlI+Jmd0OyAmZ3Q7ICZndDsgDQ om Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7IA0KZm9yd2FyZGluZyBwbGFuZS48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj 4m Z3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcm Vj dFRhcCcgaXMgcmVzcG9uc2libGUgdG88QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA 0K cmVjZWl2ZSBkYXRhIHBhY2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLjxCUj4mZ3 Q7 ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRk Ug TEZCIHRvcG9sb2d5LCB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJ1JlZG ly ZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgb3V0cHV0PEJSPiZndDsgJmd0Oy Am Z3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyANCnBvcnQgYW5kIHdpdGhvdXQgYW55IGlucHV0IHBvcnQsIGFuZC B0 aGUgb3V0cHV0IHBvcnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KY2FuIHRoZW 4g YmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW9kZWw8QlI+Jmd0OyAmZ3Q7IC Zn dDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7IA0KYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2FyZG lu ZyBwbGFuZS48QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KRnJvbSB0aGUgcGVyc3 Bl Y3RpdmUgb2YgRm9yQ0VTIHByb3RvY29sIGxheWVyLCB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQ om Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7IA0KJ1JlZGlyZWN0VGFwJyBMRkIgY2FuIHJlY2VpdmUgdGhlIFBhY2tldCBSZW Rp cmVjdDxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpNZXNzYWdlcyBmcm9tIENFLC Bh bmQgdW4tZW5jYXBzdWxhdGUgdGhlIGRhdGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 IA0KcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgdGhlbSB0byBkYXRhcGF0aHM8Ql I+ Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuJm 5i c3A7IEFjdHVhbGx5IHRoZSAnUmVjaXJlY3RUYXAnPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0Oy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyANCkxGQiBhY3RzIG1vcmUgbGlrZSBhIHRyYW5zY29kZXIgdGhhdCB0cmFuc2ZlcnMgdG hl PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkZvckNFUyBwcm90b2NvbCBtZXNzYW dl cyB0byBub3JtYWwgZGF0YSBwYWNrZXRzIGluPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyANCklQIGZvcndhcmRpbmcgcGxhbmUuJm5ic3A7IEFzIGEgcmVzdWx0LCBpZiB3ZSBuZWVkIH Rv PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmhhdmUgcmVkaXJlY3RlZCBwYWNrZX Rz IGNvbm5lY3RlZCB0byBzb21lIExGQiAoc2F5IGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7IA0KU2NoZWR1bGVyKSBpbiBGRSBtb2RlbCwgd2Ugb25seSBuZWVkIHRvIGNvbm5lY3QgdG hl PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCidSZWRpcmVjdFRhcCBMRkIgdG8gdG hl IFNjaGVkdWxlciBMRkIgZGlyZWN0bHkgdmlhIGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7IA0KZGF0YXBhdGggYXMgZm9sbG93czo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3 Q7 ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyANCiZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS 0t LS0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS0tLS0tLS 0t LS0rPEJSPiZndDsgDQomZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCBSZWRpcmVjdFRhcCBMRkIgDQ p8 LS0tLS0tJmd0O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS 0t LS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH w8 QlI+Jmd0OyAmZ3Q7IA0KJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsgDQp8IFNjaGVkdWxlciB8PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0Oy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkZyb20gb3RoZXIgTEZCJm5ic3A7Jm5ic3A7IC 0t LS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyBMRkImbmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPi Zn dDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsgfDxCUj4mZ3Q7ICZndDsgDQomZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS0tLS0tLSs8QlI+Jmd0Oy Am Z3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQ pG aWd1cmUgMjc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsgDQpCeSB1c2Ugb2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW5rJyBMRkJzIGFuZCBzZXZlcm Fs PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCidSZWRpcmVjdFRhcCcgTEZCcyB0aG F0 IGNvbm5lY3QgdG8gc2V2ZXJhbCBkaWZmZXJlbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7IA0KZGF0YXBhdGhzIGluIEZFIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxlIHBhY2tldD xC Uj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpyZWRpcmVjdCBwYXRocyBiZXR3ZWVuIE NF IGFuZCBGRSBjYW4gYmUgY29uc3RydWN0ZWQuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OzxCUj 4m Z3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7IA0KVGhvdWdodCAyOiZuYnNwOyBUaGVyZSBtaWdodCBiZSBhbm90aGVyIHdheS Bh IHBhY2tldCBjb3VsZCBiZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpyZWRpcm Vj dGVkOiBkaXJlY3RseSBieSBhIGZvcndhcmRpbmcgcGF0aCwgZS5nLiwgYnk8QlI+Jmd0OyAmZ3 Q7 ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KRlBHQS9BU0lDL05QIG1pY3JvY29kZS4mbmJzcDsgSW4gc3 Vj aCBhIGNhc2Ugd2UgZG8gbm90PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCm5lZW Qg dG8gcHV0IGluIGEgbG90IG9mIHNtYXJ0bmVzcy4mbmJzcDsgUHJvYmFibHkgYSBsaW5rPEJSPi Zn dDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbC Bo ZWFkZXIgaXMgZW5vdWdoLiZuYnNwOyBUaGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3 A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm 5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3 A7 IA0KcmVjZWl2ZXIgZGVtdXhlcyBpdCBvbmx5IGJhc2VkIG9uIHNvbWUgcHJvdG9jb2wgdHlwZT xC Uj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQppbiB0aGUgbGluayBsYXllciBvciBuZX R3 b3JrIHRyYW5zcG9ydCBsYXllci4mbmJzcDsgVGhlPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0Oy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyANCnByb3MgZm9yIHRoaXMgYXBwcmFvY2ggaXMgaXQgbWF5IHByb3ZpZGUgYSBmYXN0IG Fu ZDxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbm Jz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpjb3N0LWVmZmVjdGl2ZSBwYXRoIG Zv ciBwYWNrZXQgcmVkaXJlY3QuJm5ic3A7IFRoZSBjb25zPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJm d0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyANCmZvciB0aGlzIGlzIGl0IG1heSBtb3JlIG9yIGxlc3MgY29uZnVzZXMgdGhlIE Zw PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy Zu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYn Nw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnJlZmVyZW5jZSBwb2ludCBkZWZpbm l0 aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0Oy AN CiZndDsgJmd0OyAmZ3Q7LS0tLS0tLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Y2F0ZWdvcn k6 IEVkaXRvcmlhbDxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDtkcmFmdDogZHJhZnQtaWV0Zi1mb3 Jj ZXMtcHJvdG9jb2w8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0O21lc3NhZ2VzOiANCjQ5PEJSPiZndD sg Jmd0OyAmZ3Q7ICZndDtub3N5OiBhdnJpPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDtwcmlvcml0eT og TXVzdCANCmZpeDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7c3RhdHVzOiBObyBkaXNjdXNzaW9uPE JS PiZndDsgJmd0OyAmZ3Q7ICZndDt0aXRsZTogDQpQYWNrZXQgUmVkaXJlY3Q8QlI+Jmd0OyAmZ3 Q7 ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtfX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Rm 9y Y2VzIGlzc3VlIHRyYWNrZXIgJmx0OzwvRk9OVD48QSANCmhyZWY9Im1haWx0bzp0cmFja2VyLW Zv cmNlc0BtaXA0Lm9yZyI+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6ZT0yPnRyYW Nr ZXItZm9yY2VzQG1pcDQub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNz sg c2l6ZT0yPiZndDs8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyAmZ3Q7Jmx0OzwvRk9OVD48QSANCmhyZW Y9 Imh0dHA6Ly93d3cubWlwNC5vcmcvaXNzdWVzL3RyYWNrZXIvZm9yY2VzL2lzc3VlMzIiPjxGT0 5U IGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj5odHRwOi8vd3d3Lm1pcDQub3JnL2lzc3 Vl cy90cmFja2VyL2ZvcmNlcy9pc3N1ZTMyPC9GT05UPjwvQT48Rk9OVCBmYWNlPSYjMjM0MzU7Ji My MDMwNzsgDQpzaXplPTI+Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtfX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7IA0KJm d0 OzwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0009_01C57B63.BA753770-- 2005 Message-Id: Date: Mon, 27 Jun 2005 11:30:33 -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 I would approach this differently. The current text describes the LFBselect LFB. It correctly defines the LFBselect LFB. That definition should not be thrown away. The message structure documentation can say A PL protocol messages consists of a protocol header followed by one or more TLVs. All TLVs consist of two byte type and a two byte length, followed by contents dependent upon the type of the TLV. The TLVs which are valid in a message depend upon the message type. Most message types allow one or more LFBselect TLVs and no other top level TLVs. The following are the message types this applies to: Association setup request and response. Config message request and response Query message request and response Event Notify message. The Association teardown message contains a single instance of the teardown-cause TLV. The heartbeat message contains a single instance of the heatrbeat TLV. (Unless we decide to just use an event for heartbeats. I don't remember where that discussion stands.) The Packet Redirect message contains one or more (typically one) packet-redirect TLVs. This is then followed by a section for each of these top level TLVs. Yours, Joel M. Halpern At 10:01 AM 6/27/2005, Weiming Wang wrote: >Joel :) > >How about we just obsolete the path from the data structure and add some >meta-information, and form the format as below (I currently can only think >of the meta-information as the packet type. We may add some more later). > >Could you give more comments on this, then we may solve this issue soon? > >Thank you very much. > >Weiming > >--------------------- >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 = LFBselect | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > LFB class ID: > There are only two possible LFB classes here, the 'RedirectSink' > LFB or the 'RedirectSource' LFB. If the message is from FE to CE, > the LFB class should be 'RedirectSink'. If the message is from CE > to FE, the LFB class should be 'RedirectSource'. > Instance ID: > Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. > Operation TLV: > This is a TLV describing one packet of data to be directed via the > specified LFB above. The order of the TLV appeared is also the > order the data packet arrives the redirector LFB, that is, the > Redirected Data in the first TLV should arrive the earliest. > >The TLV format is as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = PAYLOAD | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Packet Type | Packet Length ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Redirected Packet ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: > The type for the TLV is set to 'PAYLOAD'. > > Length: > the length of the TLV(in 4bytes). > > Packet Type: > Defines what type the redirected packet belongs to(such as 'IPv4 > Packet', > 'IPv6 Packet'). > > Packet Length: > the length of the followed redirected packet (in byte) > > Redirected Packet: > one redirected packet. >----------------------------- > > >----- Original Message ----- >From: "Joel M. Halpern" <joel@stevecrocker.com> > > > I would expect that a Redirect Message has a different outermost TLV. The > > grammar is intended to help us, not serve as a straightjacket. Different > > message types can have different outer TLVs. It is desirable to use the > > same structure when it applies. But the redirect message is simply a > > different case. It's contents are not a DATARAW much less a DATA > TLV. Its > > content structure is not defined by an LFB element definition or Model > > DataDefs structure definition. > > > > If we need to fix the "grammar" section to make it clear that not all PL > > messages necessarily use the same outermost TLV, we should do so. My own > > approach would be to separate the grammar into a definition of the > contents > > of that TLV, and a separate definition of which TLVs / content are carried > > in the outermost level of which messages. > > > > Yours, > > Joel > > > > PS: Weiming, I am sorry you got caught up in this confusion. I don't > think > > you created the tendency I am railing against above. I am just using your > > message as a starting point to hammer home a point. > > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote: > > >Maybe it's me who missed something :) > > >My thought was we might need to obey our message grammar well that we > have > > >to use a strict Path-data for operation TLV. To obey the rule, treating > > >it as an event will ease the message format greatly. > > > > > >Actually I'm very happy to see that you agree a path can be omitted for > > >some specific messages like redirect messge. > > > > > >OK, let's solve it then, to let redirect message only contain Data > > >field? I can update this redirect message part text then. > > > > > >Jamal, could you give a response on this? > > > > > >One less vital question is, shall we allow for mulitpul redirect packets > > >encapsulated in one TLV or just one TLV only for one packet? To use the > > >former, we have to define a sequence for the redirected packets then in > > >the TLV. > > > > > >On the meta-information related, I think LFB IDs has already been > > >included. I don't think we need an extra port ID to indicate where to put > > >the redirected data to or to get redirected data from. A redirect source > > >LFB or sink LFB will have a port ID, which belongs to FE LFB topology > > >concept, and FE LFB topolgy configuration is in charge of this. Not sure > > >if it complies with your thought? > > > > > >Thanks, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > I am missign something in your suggestion. > > > > > > > > Why would we want to treat redirects as events? > > > > We should treat them as redirects. > > > > > > > > I am very confused about "How a path should be defined in a Packet > > > Redirect > > > > Message", since as far as I can tell, a redirect does not need a > path. It > > > > needs a collection of meta-information, which we need to > define. At the > > > > moment, that has to include at least the LFB ID that the redirect is > > > from / > > > > to. I suppose by declaring a multiplicity of such LFBs, that can be > > > all of > > > > the information. (I usually think in terms of at least a logical > port ID > > > > the packet came from / is intended for.) > > > > > > > > Yours, > > > > Joel > > > > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > > > >Jamal, Joel, and Hormzd, > > > > > > > > > >I suppose we could close this issue by reaching the following points: > > > > > > > > > >1. The redirect LFBs called RedirectSource LFB and RedirectSink > LFB are > > > > >moved to the model, but the protocol retains the Redirect Message. The > > > > >reason to keep the specific message is we need to specifically > recognize > > > > >redirected data between CE-FE transportation to avoid DoS attacks. > > > > > > > > > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL > > > > >events in that: > > > > > a. The event is triggered every time a new redirected packet > > > arrives > > > > > at the LFBs. > > > > > b. The event is transported by the Redirect Message only, > while > > > the > > > > > Redirect Message will the same message format as a general event > > > > > notification message (except the message type in the header). > > > > > > > > > >By doing in this way, we can also solve the issue53 (How a path > should be > > > > >defined in Packet Redirect Message) then. > > > > > > > > > >Unfortunately, I think of another question that is related to the > Packet > > > > >Redirect Message as well as to Event Notification Message. The > question > > > > >is, the Event Notification Message allows event generated by CE > and sent > > > > >to FE. In the case, in the message format, the LFB IDs refer to > the LFBs > > > > >that will receive the event notification, but the question is, > what the > > > > >Path in the message refers to then ?? The same also happens to Packet > > > > >Redirect Message from CE to FE. > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Avri Doria" > <tracker-forces@mip4.org> > > > > >To: <FORCES@PEACH.EASE.LSOFT.COM> > > > > >Sent: Monday, May 23, 2005 2:35 AM > > > > >Subject: [issue32] Packet Redirect > > > > > > > > > > > > > > >New submission from Avri Doria <avri@acm.org>: > > > > > > > > > >6.8 > > > > > > > > > > Editorial Note: There are also discussions on how LFBs in FE model > > > > > that are related to packet redirect operations > > > > > should be defined. Although it is out of the > scope > > > > > of forces protocol, how to define the LFBs affect > > > > > the Packet Redirect Message described > here. Because > > > > > currently it is still in progress in FE model > on how > > > > > to define such LFBs, we try to post some > thoughts on > > > > > this here for discussion. They will be removed > > > > > later along with the progress of the FE model > work. > > > > > Thought 1: To define LFBs called 'RedirectSink' and > > > > > 'RedirectTap' for packet redirect. > > > > > An LFB in FE called 'RedirectSink' is > responsible to > > > > > collect data packets that need to be > redirected to > > > > > CE. From the perspective of the FE LFB topology, > > > > > the 'RedirectSink' LFB is an LFB with only > one input > > > > > port and without any output port, and the > input port > > > > > can then be connected to any other LFB in FE > model > > > > > by means of a datapath in the forwarding plane. > > > > > From the perspective of the ForCES protocol > layer, > > > > > the 'RedirectSink' LFB will generate the Packet > > > > > Redirect Messages when it receives data > packets from > > > > > forwarding plane. > > > > > > > > > > An LFB in FE called 'RedirectTap' is > responsible to > > > > > receive data packets that are redirected from CE. > > > > > From the perspective of the FE LFB topology, the > > > > > 'RedirectTap' LFB is an LFB with only one output > > > > > port and without any input port, and the > output port > > > > > can then be connected to any other LFB in FE > model > > > > > by means of a datapath in the forwarding plane. > > > > > From the perspective of ForCES protocol > layer, the > > > > > 'RedirectTap' LFB can receive the Packet Redirect > > > > > Messages from CE, and un-encapsulate the data > > > > > packets from the message and put them to > datapaths > > > > > in the forwarding plane. Actually the > 'RecirectTap' > > > > > LFB acts more like a transcoder that > transfers the > > > > > ForCES protocol messages to normal data > packets in > > > > > IP forwarding plane. As a result, if we need to > > > > > have redirected packets connected to some LFB > (say a > > > > > Scheduler) in FE model, we only need to > connect the > > > > > 'RedirectTap LFB to the Scheduler LFB > directly via a > > > > > datapath as follows: > > > > > > > > > > > > > > > +-----------------+ +-----------+ > > > > > | RedirectTap LFB |------>| | > > > > > +-----------------+ | | > > > > > | Scheduler | > > > > > From other LFB ---->| LFB | > > > > > | | > > > > > +-----------+ > > > > > > > > > > Figure 27 > > > > > > > > > > By use of several 'RedirectSink' LFBs and several > > > > > 'RedirectTap' LFBs that connect to several > different > > > > > datapaths in FE forwarding plane, multiple packet > > > > > redirect paths between CE and FE can be > constructed. > > > > > > > > > > Thought 2: There might be another way a packet could be > > > > > redirected: directly by a forwarding path, > e.g., by > > > > > FPGA/ASIC/NP microcode. In such a case we do not > > > > > need to put in a lot of smartness. Probably > a link > > > > > layer or even network level header is > enough. The > > > > > receiver demuxes it only based on some > protocol type > > > > > in the link layer or network transport > layer. The > > > > > pros for this appraoch is it may provide a > fast and > > > > > cost-effective path for packet redirect. The > cons > > > > > for this is it may more or less confuses the Fp > > > > > reference point definition in ForCES framework. > > > > > > > > > >---------- > > > > >category: Editorial > > > > >draft: draft-ietf-forces-protocol > > > > >messages: 49 > > > > >nosy: avri > > > > >priority: Must fix > > > > >status: No discussion > > > > >title: Packet Redirect > > > > > > > > > >___________________________________________________ > > > > >Forces issue tracker > <tracker-forces@mip4.org> > > > > > > > > > >___________________________________________________ > > > > 2005 Message-Id: Date: Mon, 27 Jun 2005 10:37:58 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Question about the FE Model Comments: To: louati MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57B3E.F5D58C09" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57B3E.F5D58C09 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, this scenario is very much possible and would be a way to implement = an extensible software router. =20 regards Hormuzd p.s. copying the ForCES list in case anyone from the FE Model team would = like to add to my comment. ________________________________ From: louati [mailto:wajdi.louati@int-evry.fr]=20 Sent: Monday, June 27, 2005 6:03 AM To: Khosravi, Hormuzd M Subject: Question about the FE Model Dear Khosravi, =20 I have a question about the FE model (Software/Hardware) implementation = . CE functions are typically performed in software running on a = general-purpose CPU, while FEs can be based on a variety of different = hardware platforms such as ASICs, FPGAs and network processors. Is it possible that these FEs are also performed in software running on = a general-purpose CPU ? I mean the FE Model is executed by a software = forwarding path (like Click, scott ....). In fact, ForCES provides mechanisms to realize a distributed router. = Assuming that two PC based linux are connected via a gigabit network = link. The first one integrates the control plane and the second PC = implements only the Forwarding Plane (Software Forwarding PATH such as = Linux forwarding path, Click, Scott ... rather than the use of the = Network Processor). Of course, the ForCES protocol exchanges messages = between the two PCs. Is this scenario possible? Can we consider this architecture as a = software based router ?=20 Thank you in advance for your answers. Best Regards, Wajdi _________________________________ Wajdi LOUATI Wireless Networks and Services Group=20 Wireless Networks and Multimedia Services Department Institut National des T=E9l=E9communications 9 rue Charles Fourier 91011 EVRY Cedex, France Phone : 331 60 76 45 84 Fax : 331 60 76 45 78 e-mail : wajdi.louati@int-evry.fr ________________________________ ------_=_NextPart_001_01C57B3E.F5D58C09 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Yes, this scenario is very much possible and = would be a way=20 to implement an extensible software router.
 
regards
Hormuzd
p.s. copying the ForCES list in ca= se anyone from the FE Model team would like&nbs= p;to add to my comment.
From: louati = [mailto:wajdi.louati@int-evry.fr]=20
Sent: Monday, June 27, 2005 6:03 AM
To: Khosravi, = Hormuzd=20 M
Subject: Question about the FE Model

Dear Khosravi,
 
I have a question about the FE model=20 (Software/Hardware) implementation .

CE functions are typically performed in = software=20 running on a general-purpose CPU, while FEs can be based on a variety of = different hardware platforms such as ASICs, FPGAs and network=20 processors.

Is it possible that these FEs are also = performed in software = running on a=20 general-purpose CPU ? I mean the FE Model is executed by a software = forwarding=20 path (like Click, scott =85.).

In fact, ForCES provides mechanisms to = realize a=20 distributed router. Assuming that two PC based linux are connected via a = gigabit=20 network link. The first one integrates the control plane and the second = PC=20 implements only the Forwarding Plane (Software Forwarding PATH such as = Linux=20 forwarding path, Click, Scott =85 rather than the use of the Network = Processor).=20 Of course, the ForCES protocol exchanges  messages between the = two=20 PCs.

Is this scenario possible? Can we = consider this=20 architecture as a software based router ?

Thank you in advance for your = answers.

Best Regards,

Wajdi

_________________________________
Wajdi=20 LOUATI
Wireless Networks and Services Group
Wireless Networks and = Multimedia Services Department
Institut National des = T=E9l=E9communications
9=20 rue Charles Fourier
91011 EVRY Cedex, France
Phone : 331 60 76 45=20 84
Fax : 331 60 76 45 78
e-mail : wajdi.louati@int-evry.fr
= ________________________________
------_=_NextPart_001_01C57B3E.F5D58C09-- 2005 Message-Id: Date: Sun, 26 Jun 2005 16:45:59 +0800 From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 TWF5YmUgaXQncyBtZSB3aG8gbWlzc2VkIHNvbWV0aGluZyA6KQ0KTXkgdGhvdWdodCB3YXMgd2 Ug bWlnaHQgbmVlZCB0byBvYmV5IG91ciBtZXNzYWdlIGdyYW1tYXIgd2VsbCB0aGF0IHdlIGhhdm Ug dG8gdXNlIGEgc3RyaWN0IFBhdGgtZGF0YSBmb3Igb3BlcmF0aW9uIFRMVi4gIFRvIG9iZXkgdG hl IHJ1bGUsIHRyZWF0aW5nIGl0IGFzIGFuIGV2ZW50IHdpbGwgZWFzZSB0aGUgbWVzc2FnZSBmb3 Jt YXQgZ3JlYXRseS4gDQoNCkFjdHVhbGx5IEknbSB2ZXJ5IGhhcHB5IHRvIHNlZSB0aGF0IHlvdS Bh Z3JlZSBhIHBhdGggY2FuIGJlIG9taXR0ZWQgZm9yIHNvbWUgc3BlY2lmaWMgbWVzc2FnZXMgbG lr ZSByZWRpcmVjdCBtZXNzZ2UuICANCg0KT0ssIGxldCdzIHNvbHZlIGl0IHRoZW4sIHRvIGxldC By ZWRpcmVjdCBtZXNzYWdlIG9ubHkgY29udGFpbiBEYXRhIGZpZWxkPyAgSSBjYW4gdXBkYXRlIH Ro aXMgcmVkaXJlY3QgbWVzc2FnZSBwYXJ0IHRleHQgdGhlbi4gDQoNCkphbWFsLCBjb3VsZCB5b3 Ug Z2l2ZSBhIHJlc3BvbnNlIG9uIHRoaXM/DQoNCk9uZSAgbGVzcyB2aXRhbCBxdWVzdGlvbiBpcy wg c2hhbGwgd2UgYWxsb3cgZm9yIG11bGl0cHVsIHJlZGlyZWN0IHBhY2tldHMgZW5jYXBzdWxhdG Vk IGluIG9uZSBUTFYgb3IganVzdCBvbmUgVExWIG9ubHkgZm9yIG9uZSBwYWNrZXQ/IFRvIHVzZS B0 aGUgZm9ybWVyLCB3ZSBoYXZlIHRvIGRlZmluZSBhIHNlcXVlbmNlIGZvciB0aGUgcmVkaXJlY3 Rl ZCBwYWNrZXRzIHRoZW4gaW4gdGhlIFRMVi4NCg0KT24gIHRoZSBtZXRhLWluZm9ybWF0aW9uIH Jl bGF0ZWQsIEkgdGhpbmsgTEZCIElEcyBoYXMgYWxyZWFkeSBiZWVuIGluY2x1ZGVkLiBJIGRvbi d0 IHRoaW5rIHdlIG5lZWQgYW4gZXh0cmEgcG9ydCBJRCB0byBpbmRpY2F0ZSB3aGVyZSB0byBwdX Qg dGhlIHJlZGlyZWN0ZWQgZGF0YSB0byBvciB0byBnZXQgcmVkaXJlY3RlZCBkYXRhIGZyb20uIE Eg cmVkaXJlY3Qgc291cmNlIExGQiAgb3Igc2luayBMRkIgd2lsbCAgaGF2ZSBhIHBvcnQgSUQsIH do aWNoIGJlbG9uZ3MgdG8gRkUgTEZCIHRvcG9sb2d5IGNvbmNlcHQsIGFuZCBGRSBMRkIgdG9wb2 xn eSBjb25maWd1cmF0aW9uIGlzIGluIGNoYXJnZSBvZiB0aGlzLiAgTm90IHN1cmUgaWYgaXQgY2 9t cGxpZXMgd2l0aCB5b3VyIHRob3VnaHQ/DQoNClRoYW5rcywNCldlaW1pbmcNCg0KLS0tLS0gT3 Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhhbHBlcm4iICANClN1YmplY3 Q6 IFJlOiBbaXNzdWUzMl0gUGFja2V0IFJlZGlyZWN0DQoNCg0KPiBJIGFtIG1pc3NpZ24gc29tZX Ro aW5nIGluIHlvdXIgc3VnZ2VzdGlvbi4NCj4gDQo+IFdoeSB3b3VsZCB3ZSB3YW50IHRvIHRyZW F0 IHJlZGlyZWN0cyBhcyBldmVudHM/DQo+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZGlyZW N0 cy4NCj4gDQo+IEkgYW0gdmVyeSBjb25mdXNlZCBhYm91dCAiSG93IGEgcGF0aCBzaG91bGQgYm Ug ZGVmaW5lZCBpbiBhIFBhY2tldCBSZWRpcmVjdCANCj4gTWVzc2FnZSIsIHNpbmNlIGFzIGZhci Bh cyBJIGNhbiB0ZWxsLCBhIHJlZGlyZWN0IGRvZXMgbm90IG5lZWQgYSBwYXRoLiAgSXQgDQo+IG 5l ZWRzIGEgY29sbGVjdGlvbiBvZiBtZXRhLWluZm9ybWF0aW9uLCB3aGljaCB3ZSBuZWVkIHRvIG Rl ZmluZS4gIEF0IHRoZSANCj4gbW9tZW50LCB0aGF0IGhhcyB0byBpbmNsdWRlIGF0IGxlYXN0IH Ro ZSBMRkIgSUQgdGhhdCB0aGUgcmVkaXJlY3QgaXMgZnJvbSAvIA0KPiB0by4gIEkgc3VwcG9zZS Bi eSBkZWNsYXJpbmcgYSBtdWx0aXBsaWNpdHkgb2Ygc3VjaCBMRkJzLCB0aGF0IGNhbiBiZSBhbG wg b2YgDQo+IHRoZSBpbmZvcm1hdGlvbi4gIChJIHVzdWFsbHkgdGhpbmsgaW4gdGVybXMgb2YgYX Qg bGVhc3QgYSBsb2dpY2FsIHBvcnQgSUQgDQo+IHRoZSBwYWNrZXQgY2FtZSBmcm9tIC8gaXMgaW 50 ZW5kZWQgZm9yLikNCj4gDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBBdCAxMDo1MCBQTSA2Lz I1 LzIwMDUsIFdlaW1pbmcgV2FuZyB3cm90ZToNCj4gPkphbWFsLCBKb2VsLCBhbmQgSG9ybXpkLA 0K PiA+DQo+ID5JIHN1cHBvc2Ugd2UgY291bGQgY2xvc2UgdGhpcyBpc3N1ZSBieSByZWFjaGluZy B0 aGUgZm9sbG93aW5nIHBvaW50czoNCj4gPg0KPiA+MS4gVGhlIHJlZGlyZWN0IExGQnMgY2FsbG Vk IFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luayBMRkIgYXJlIA0KPiA+bW92ZW Qg dG8gdGhlIG1vZGVsLCBidXQgdGhlIHByb3RvY29sIHJldGFpbnMgdGhlIFJlZGlyZWN0IE1lc3 Nh Z2UuIFRoZSANCj4gPnJlYXNvbiB0byBrZWVwIHRoZSBzcGVjaWZpYyBtZXNzYWdlIGlzIHdlIG 5l ZWQgdG8gc3BlY2lmaWNhbGx5IHJlY29nbml6ZSANCj4gPnJlZGlyZWN0ZWQgZGF0YSBiZXR3ZW Vu IENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIGF2b2lkIERvUyBhdHRhY2tzLg0KPiA+DQo+ID4yLi BU aGUgcmVkaXJlY3RlZCBkYXRhIGluIHRoZSBMRkJzIGNhbiBiZSB0cmVhdGVkIGFzIGEga2luZC Bv ZiBTUEVDSUFMIA0KPiA+ZXZlbnRzIGluIHRoYXQ6DQo+ID4gICAgICBhLiBUaGUgZXZlbnQgaX Mg dHJpZ2dlcmVkIGV2ZXJ5IHRpbWUgYSBuZXcgcmVkaXJlY3RlZCBwYWNrZXQgYXJyaXZlcyANCj 4g PiBhdCB0aGUgTEZCcy4NCj4gPiAgICAgIGIuIFRoZSBldmVudCBpcyB0cmFuc3BvcnRlZCBieS B0 aGUgUmVkaXJlY3QgIE1lc3NhZ2Ugb25seSwgd2hpbGUgdGhlIA0KPiA+IFJlZGlyZWN0IE1lc3 Nh Z2Ugd2lsbCB0aGUgc2FtZSBtZXNzYWdlIGZvcm1hdCBhcyBhIGdlbmVyYWwgZXZlbnQgDQo+ID 4g bm90aWZpY2F0aW9uIG1lc3NhZ2UgKGV4Y2VwdCB0aGUgbWVzc2FnZSB0eXBlIGluIHRoZSBoZW Fk ZXIpLg0KPiA+DQo+ID5CeSBkb2luZyBpbiB0aGlzIHdheSwgd2UgY2FuIGFsc28gc29sdmUgdG hl IGlzc3VlNTMgKEhvdyBhIHBhdGggc2hvdWxkIGJlIA0KPiA+ZGVmaW5lZCAgaW4gUGFja2V0IF Jl ZGlyZWN0IE1lc3NhZ2UpIHRoZW4uDQo+ID4NCj4gPlVuZm9ydHVuYXRlbHksICBJIHRoaW5rIG 9m IGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRvIHRoZSBQYWNrZXQgDQo+ID5SZW Rp cmVjdCBNZXNzYWdlIGFzIHdlbGwgYXMgdG8gRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UuIF Ro ZSBxdWVzdGlvbiANCj4gPmlzLCB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgYWxsb3 dz IGV2ZW50IGdlbmVyYXRlZCBieSBDRSBhbmQgc2VudCANCj4gPnRvIEZFLiBJbiB0aGUgY2FzZS wg aW4gdGhlIG1lc3NhZ2UgZm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0byB0aGUgTEZCcyANCj 4g PnRoYXQgd2lsbCByZWNlaXZlIHRoZSBldmVudCBub3RpZmljYXRpb24sIGJ1dCB0aGUgcXVlc3 Rp b24gaXMsIHdoYXQgdGhlIA0KPiA+UGF0aCBpbiB0aGUgbWVzc2FnZSByZWZlcnMgdG8gdGhlbi A/ PyAgVGhlIHNhbWUgYWxzbyBoYXBwZW5zIHRvIFBhY2tldCANCj4gPlJlZGlyZWN0IE1lc3NhZ2 Ug ZnJvbSBDRSB0byBGRS4NCj4gPg0KPiA+VGhhbmtzLA0KPiA+V2VpbWluZw0KPiA+DQo+ID4tLS 0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID5Gcm9tOiAiQXZyaSBEb3JpYSIgPHRyYWNrZX It Zm9yY2VzQG1pcDQub3JnPg0KPiA+VG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQ o+ ID5TZW50OiBNb25kYXksIE1heSAyMywgMjAwNSAyOjM1IEFNDQo+ID5TdWJqZWN0OiBbaXNzdW Uz Ml0gUGFja2V0IFJlZGlyZWN0DQo+ID4NCj4gPg0KPiA+TmV3IHN1Ym1pc3Npb24gZnJvbSBBdn Jp IERvcmlhIDxhdnJpQGFjbS5vcmc+Og0KPiA+DQo+ID42LjgNCj4gPg0KPiA+ICBFZGl0b3JpYW wg Tm90ZTogIFRoZXJlIGFyZSBhbHNvIGRpc2N1c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1vZG Vs DQo+ID4gICAgICAgICAgICAgICAgICAgICB0aGF0IGFyZSByZWxhdGVkIHRvIHBhY2tldCByZW Rp cmVjdCBvcGVyYXRpb25zDQo+ID4gICAgICAgICAgICAgICAgICAgICBzaG91bGQgYmUgZGVmaW 5l ZC4gIEFsdGhvdWdoIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUNCj4gPiAgICAgICAgICAgICAgIC Ag ICAgIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IHRvIGRlZmluZSB0aGUgTEZCcyBhZmZlY3QNCj 4g PiAgICAgICAgICAgICAgICAgICAgIHRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkZXNjcm li ZWQgaGVyZS4gIEJlY2F1c2UNCj4gPiAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRseSBpdC Bp cyBzdGlsbCBpbiBwcm9ncmVzcyBpbiBGRSBtb2RlbCBvbiBob3cNCj4gPiAgICAgICAgICAgIC Ag ICAgICAgIHRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBwb3N0IHNvbWUgdGhvdWdodH Mg b24NCj4gPiAgICAgICAgICAgICAgICAgICAgIHRoaXMgaGVyZSBmb3IgZGlzY3Vzc2lvbi4gIF Ro ZXkgd2lsbCBiZSByZW1vdmVkDQo+ID4gICAgICAgICAgICAgICAgICAgICBsYXRlciBhbG9uZy B3 aXRoIHRoZSBwcm9ncmVzcyBvZiB0aGUgRkUgbW9kZWwgd29yay4NCj4gPiAgICAgICAgIFRob3 Vn aHQgMTogIFRvIGRlZmluZSBMRkJzIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBhbmQNCj4gPiAgIC Ag ICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgZm9yIHBhY2tldCByZWRpcmVjdC4NCj4gPi Ag ICAgICAgICAgICAgICAgICAgIEFuIExGQiBpbiBGRSBjYWxsZWQgJ1JlZGlyZWN0U2luaycgaX Mg cmVzcG9uc2libGUgdG8NCj4gPiAgICAgICAgICAgICAgICAgICAgIGNvbGxlY3QgZGF0YSBwYW Nr ZXRzIHRoYXQgbmVlZCB0byBiZSByZWRpcmVjdGVkIHRvDQo+ID4gICAgICAgICAgICAgICAgIC Ag ICBDRS4gIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGRSBMRkIgdG9wb2xvZ3ksDQo+ID 4g ICAgICAgICAgICAgICAgICAgICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIGlzIGFuIExGQiB3aX Ro IG9ubHkgb25lIGlucHV0DQo+ID4gICAgICAgICAgICAgICAgICAgICBwb3J0IGFuZCB3aXRob3 V0 IGFueSBvdXRwdXQgcG9ydCwgYW5kIHRoZSBpbnB1dCBwb3J0DQo+ID4gICAgICAgICAgICAgIC Ag ICAgICBjYW4gdGhlbiBiZSBjb25uZWN0ZWQgdG8gYW55IG90aGVyIExGQiBpbiBGRSBtb2RlbA 0K PiA+ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm 9y d2FyZGluZyBwbGFuZS4NCj4gPiAgICAgICAgICAgICAgICAgICAgIEZyb20gdGhlIHBlcnNwZW N0 aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsDQo+ID4gICAgICAgICAgICAgICAgIC Ag ICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIHdpbGwgZ2VuZXJhdGUgdGhlIFBhY2tldA0KPiA+IC Ag ICAgICAgICAgICAgICAgICAgUmVkaXJlY3QgTWVzc2FnZXMgd2hlbiBpdCByZWNlaXZlcyBkYX Rh IHBhY2tldHMgZnJvbQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgZm9yd2FyZGluZyBwbGFuZS 4N Cj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgQW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaX Jl Y3RUYXAnIGlzIHJlc3BvbnNpYmxlIHRvDQo+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaX Zl IGRhdGEgcGFja2V0cyB0aGF0IGFyZSByZWRpcmVjdGVkIGZyb20gQ0UuDQo+ID4gICAgICAgIC Ag ICAgICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LC B0 aGUNCj4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZCIGlzIGFuIExGQi B3 aXRoIG9ubHkgb25lIG91dHB1dA0KPiA+ICAgICAgICAgICAgICAgICAgICAgcG9ydCBhbmQgd2 l0 aG91dCBhbnkgaW5wdXQgcG9ydCwgYW5kIHRoZSBvdXRwdXQgcG9ydA0KPiA+ICAgICAgICAgIC Ag ICAgICAgICAgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW 9k ZWwNCj4gPiAgICAgICAgICAgICAgICAgICAgIGJ5IG1lYW5zIG9mIGEgZGF0YXBhdGggaW4gdG hl IGZvcndhcmRpbmcgcGxhbmUuDQo+ID4gICAgICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZX Jz cGVjdGl2ZSBvZiBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsIHRoZQ0KPiA+ICAgICAgICAgICAgIC Ag ICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgY2FuIHJlY2VpdmUgdGhlIFBhY2tldCBSZWRpcmVjdA 0K PiA+ICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZXMgZnJvbSBDRSwgYW5kIHVuLWVuY2Fwc3 Vs YXRlIHRoZSBkYXRhDQo+ID4gICAgICAgICAgICAgICAgICAgICBwYWNrZXRzIGZyb20gdGhlIG 1l c3NhZ2UgYW5kIHB1dCB0aGVtIHRvIGRhdGFwYXRocw0KPiA+ICAgICAgICAgICAgICAgICAgIC Ag aW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuICBBY3R1YWxseSB0aGUgJ1JlY2lyZWN0VGFwJw0KPi A+ ICAgICAgICAgICAgICAgICAgICAgTEZCIGFjdHMgbW9yZSBsaWtlIGEgdHJhbnNjb2RlciB0aG F0 IHRyYW5zZmVycyB0aGUNCj4gPiAgICAgICAgICAgICAgICAgICAgIEZvckNFUyBwcm90b2NvbC Bt ZXNzYWdlcyB0byBub3JtYWwgZGF0YSBwYWNrZXRzIGluDQo+ID4gICAgICAgICAgICAgICAgIC Ag ICBJUCBmb3J3YXJkaW5nIHBsYW5lLiAgQXMgYSByZXN1bHQsIGlmIHdlIG5lZWQgdG8NCj4gPi Ag ICAgICAgICAgICAgICAgICAgIGhhdmUgcmVkaXJlY3RlZCBwYWNrZXRzIGNvbm5lY3RlZCB0by Bz b21lIExGQiAoc2F5IGENCj4gPiAgICAgICAgICAgICAgICAgICAgIFNjaGVkdWxlcikgaW4gRk Ug bW9kZWwsIHdlIG9ubHkgbmVlZCB0byBjb25uZWN0IHRoZQ0KPiA+ICAgICAgICAgICAgICAgIC Ag ICAgJ1JlZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIExGQiBkaXJlY3RseSB2aWEgYQ 0K PiA+ICAgICAgICAgICAgICAgICAgICAgZGF0YXBhdGggYXMgZm9sbG93czoNCj4gPg0KPiA+DQ o+ ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgIC Ag ICstLS0tLS0tLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVkaX Jl Y3RUYXAgTEZCIHwtLS0tLS0+fCAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8DQo+ID4gIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgU2 No ZWR1bGVyIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGcm9tIG90aG Vy IExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8DQo+ID4gICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS 0t LSsNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjcNCj 4g Pg0KPiA+ICAgICAgICAgICAgICAgICAgICAgQnkgdXNlIG9mIHNldmVyYWwgJ1JlZGlyZWN0U2 lu aycgTEZCcyBhbmQgc2V2ZXJhbA0KPiA+ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VG Fw JyBMRkJzIHRoYXQgY29ubmVjdCB0byBzZXZlcmFsIGRpZmZlcmVudA0KPiA+ICAgICAgICAgIC Ag ICAgICAgICAgZGF0YXBhdGhzIGluIEZFIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxlIHBhY2 tl dA0KPiA+ICAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3QgcGF0aHMgYmV0d2VlbiBDRSBhbm Qg RkUgY2FuIGJlIGNvbnN0cnVjdGVkLg0KPiA+DQo+ID4gICAgICAgICBUaG91Z2h0IDI6ICBUaG Vy ZSBtaWdodCBiZSBhbm90aGVyIHdheSBhIHBhY2tldCBjb3VsZCBiZQ0KPiA+ICAgICAgICAgIC Ag ICAgICAgICAgcmVkaXJlY3RlZDogZGlyZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdGgsIGUuZy 4s IGJ5DQo+ID4gICAgICAgICAgICAgICAgICAgICBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiAgSW 4g c3VjaCBhIGNhc2Ugd2UgZG8gbm90DQo+ID4gICAgICAgICAgICAgICAgICAgICBuZWVkIHRvIH B1 dCBpbiBhIGxvdCBvZiBzbWFydG5lc3MuICBQcm9iYWJseSBhIGxpbmsNCj4gPiAgICAgICAgIC Ag ICAgICAgICAgIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbCBoZWFkZXIgaXMgZW5vdWdoLi Ag VGhlDQo+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaXZlciBkZW11eGVzIGl0IG9ubHkgYm Fz ZWQgb24gc29tZSBwcm90b2NvbCB0eXBlDQo+ID4gICAgICAgICAgICAgICAgICAgICBpbiB0aG Ug bGluayBsYXllciBvciBuZXR3b3JrIHRyYW5zcG9ydCBsYXllci4gIFRoZQ0KPiA+ICAgICAgIC Ag ICAgICAgICAgICAgcHJvcyBmb3IgdGhpcyBhcHByYW9jaCBpcyBpdCBtYXkgcHJvdmlkZSBhIG Zh c3QgYW5kDQo+ID4gICAgICAgICAgICAgICAgICAgICBjb3N0LWVmZmVjdGl2ZSBwYXRoIGZvci Bw YWNrZXQgcmVkaXJlY3QuICBUaGUgY29ucw0KPiA+ICAgICAgICAgICAgICAgICAgICAgZm9yIH Ro aXMgaXMgaXQgbWF5IG1vcmUgb3IgbGVzcyBjb25mdXNlcyB0aGUgRnANCj4gPiAgICAgICAgIC Ag ICAgICAgICAgIHJlZmVyZW5jZSBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdvcm su DQo+ID4NCj4gPi0tLS0tLS0tLS0NCj4gPmNhdGVnb3J5OiBFZGl0b3JpYWwNCj4gPmRyYWZ0Oi Bk cmFmdC1pZXRmLWZvcmNlcy1wcm90b2NvbA0KPiA+bWVzc2FnZXM6IDQ5DQo+ID5ub3N5OiBhdn Jp DQo+ID5wcmlvcml0eTogTXVzdCBmaXgNCj4gPnN0YXR1czogTm8gZGlzY3Vzc2lvbg0KPiA+dG l0 bGU6IFBhY2tldCBSZWRpcmVjdA0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFja2 Vy LWZvcmNlc0BtaXA0Lm9yZz4NCj4gPjxodHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vlcy90cmFja2 Vy L2ZvcmNlcy9pc3N1ZTMyPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fDQo+IA0K 2005 Message-Id: Date: Sun, 26 Jun 2005 10:50:27 +0800 From: Weiming Wang Subject: Re: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFtYWwsIEpvZWwsIGFuZCBIb3JtemQsDQoNCkkgc3VwcG9zZSB3ZSBjb3VsZCBjbG9zZSB0aG lz IGlzc3VlIGJ5IHJlYWNoaW5nIHRoZSBmb2xsb3dpbmcgcG9pbnRzOg0KDQoxLiBUaGUgcmVkaX Jl Y3QgTEZCcyBjYWxsZWQgUmVkaXJlY3RTb3VyY2UgIExGQiBhbmQgUmVkaXJlY3RTaW5rIExGQi Bh cmUgbW92ZWQgdG8gdGhlIG1vZGVsLCBidXQgdGhlIHByb3RvY29sIHJldGFpbnMgdGhlIFJlZG ly ZWN0IE1lc3NhZ2UuIFRoZSByZWFzb24gdG8ga2VlcCB0aGUgc3BlY2lmaWMgbWVzc2FnZSBpcy B3 ZSBuZWVkIHRvIHNwZWNpZmljYWxseSByZWNvZ25pemUgcmVkaXJlY3RlZCBkYXRhIGJldHdlZW 4g Q0UtRkUgdHJhbnNwb3J0YXRpb24gdG8gYXZvaWQgRG9TIGF0dGFja3MuDQoNCjIuIFRoZSByZW Rp cmVjdGVkIGRhdGEgaW4gdGhlIExGQnMgY2FuIGJlIHRyZWF0ZWQgYXMgYSBraW5kIG9mIFNQRU NJ QUwgZXZlbnRzIGluIHRoYXQ6DQogICAgIGEuIFRoZSBldmVudCBpcyB0cmlnZ2VyZWQgZXZlcn kg dGltZSBhIG5ldyByZWRpcmVjdGVkIHBhY2tldCBhcnJpdmVzIGF0IHRoZSBMRkJzLg0KICAgIC Bi LiBUaGUgZXZlbnQgaXMgdHJhbnNwb3J0ZWQgYnkgdGhlIFJlZGlyZWN0ICBNZXNzYWdlIG9ubH ks IHdoaWxlIHRoZSBSZWRpcmVjdCBNZXNzYWdlIHdpbGwgdGhlIHNhbWUgbWVzc2FnZSBmb3JtYX Qg YXMgYSBnZW5lcmFsIGV2ZW50IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQgdGhlIG1lc3 Nh Z2UgdHlwZSBpbiB0aGUgaGVhZGVyKS4NCg0KQnkgZG9pbmcgaW4gdGhpcyB3YXksIHdlIGNhbi Bh bHNvIHNvbHZlIHRoZSBpc3N1ZTUzIChIb3cgYSBwYXRoIHNob3VsZCBiZSBkZWZpbmVkICBpbi BQ YWNrZXQgUmVkaXJlY3QgTWVzc2FnZSkgdGhlbi4gDQoNClVuZm9ydHVuYXRlbHksICBJIHRoaW 5r IG9mIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRvIHRoZSBQYWNrZXQgUmVkaX Jl Y3QgTWVzc2FnZSBhcyB3ZWxsIGFzIHRvIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlLiBUaG Ug cXVlc3Rpb24gaXMsIHRoZSBFdmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSBhbGxvd3MgZXZlbn Qg Z2VuZXJhdGVkIGJ5IENFIGFuZCBzZW50IHRvIEZFLiBJbiB0aGUgY2FzZSwgaW4gdGhlIG1lc3 Nh Z2UgZm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0byB0aGUgTEZCcyB0aGF0IHdpbGwgcmVjZW l2 ZSB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLCBidXQgdGhlIHF1ZXN0aW9uIGlzLCB3aGF0IHRoZS BQ YXRoIGluIHRoZSBtZXNzYWdlIHJlZmVycyB0byB0aGVuID8/ICBUaGUgc2FtZSBhbHNvIGhhcH Bl bnMgdG8gUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UgZnJvbSBDRSB0byBGRS4NCg0KVGhhbmtzLA 0K V2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkF2cmkgRG 9y aWEiIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NClRvOiA8Rk9SQ0VTQFBFQUNILkVBU0UuTF NP RlQuQ09NPg0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMDUgMjozNSBBTQ0KU3ViamVjdDogW2 lz c3VlMzJdIFBhY2tldCBSZWRpcmVjdA0KDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gQXZyaSBEb3 Jp YSA8YXZyaUBhY20ub3JnPjoNCg0KNi44DQoNCiBFZGl0b3JpYWwgTm90ZTogIFRoZXJlIGFyZS Bh bHNvIGRpc2N1c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1vZGVsDQogICAgICAgICAgICAgIC Ag ICAgIHRoYXQgYXJlIHJlbGF0ZWQgdG8gcGFja2V0IHJlZGlyZWN0IG9wZXJhdGlvbnMNCiAgIC Ag ICAgICAgICAgICAgICAgc2hvdWxkIGJlIGRlZmluZWQuICBBbHRob3VnaCBpdCBpcyBvdXQgb2 Yg dGhlIHNjb3BlDQogICAgICAgICAgICAgICAgICAgIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IH Rv IGRlZmluZSB0aGUgTEZCcyBhZmZlY3QNCiAgICAgICAgICAgICAgICAgICAgdGhlIFBhY2tldC BS ZWRpcmVjdCBNZXNzYWdlIGRlc2NyaWJlZCBoZXJlLiAgQmVjYXVzZQ0KICAgICAgICAgICAgIC Ag ICAgICBjdXJyZW50bHkgaXQgaXMgc3RpbGwgaW4gcHJvZ3Jlc3MgaW4gRkUgbW9kZWwgb24gaG 93 DQogICAgICAgICAgICAgICAgICAgIHRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBwb3 N0 IHNvbWUgdGhvdWdodHMgb24NCiAgICAgICAgICAgICAgICAgICAgdGhpcyBoZXJlIGZvciBkaX Nj dXNzaW9uLiAgVGhleSB3aWxsIGJlIHJlbW92ZWQNCiAgICAgICAgICAgICAgICAgICAgbGF0ZX Ig YWxvbmcgd2l0aCB0aGUgcHJvZ3Jlc3Mgb2YgdGhlIEZFIG1vZGVsIHdvcmsuDQogICAgICAgIF Ro b3VnaHQgMTogIFRvIGRlZmluZSBMRkJzIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBhbmQNCiAgIC Ag ICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBmb3IgcGFja2V0IHJlZGlyZWN0Lg0KICAgIC Ag ICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFNpbmsnIGlzIHJlc3 Bv bnNpYmxlIHRvDQogICAgICAgICAgICAgICAgICAgIGNvbGxlY3QgZGF0YSBwYWNrZXRzIHRoYX Qg bmVlZCB0byBiZSByZWRpcmVjdGVkIHRvDQogICAgICAgICAgICAgICAgICAgIENFLiAgRnJvbS B0 aGUgcGVyc3BlY3RpdmUgb2YgdGhlIEZFIExGQiB0b3BvbG9neSwNCiAgICAgICAgICAgICAgIC Ag ICAgdGhlICdSZWRpcmVjdFNpbmsnIExGQiBpcyBhbiBMRkIgd2l0aCBvbmx5IG9uZSBpbnB1dA 0K ICAgICAgICAgICAgICAgICAgICBwb3J0IGFuZCB3aXRob3V0IGFueSBvdXRwdXQgcG9ydCwgYW 5k IHRoZSBpbnB1dCBwb3J0DQogICAgICAgICAgICAgICAgICAgIGNhbiB0aGVuIGJlIGNvbm5lY3 Rl ZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIG1vZGVsDQogICAgICAgICAgICAgICAgICAgIGJ5IG 1l YW5zIG9mIGEgZGF0YXBhdGggaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuDQogICAgICAgICAgIC Ag ICAgICAgIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZX Is DQogICAgICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgd2lsbCBnZW5lcm F0 ZSB0aGUgUGFja2V0DQogICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0IE1lc3NhZ2VzIHdoZW 4g aXQgcmVjZWl2ZXMgZGF0YSBwYWNrZXRzIGZyb20NCiAgICAgICAgICAgICAgICAgICAgZm9yd2 Fy ZGluZyBwbGFuZS4NCg0KICAgICAgICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkIC dS ZWRpcmVjdFRhcCcgaXMgcmVzcG9uc2libGUgdG8NCiAgICAgICAgICAgICAgICAgICAgcmVjZW l2 ZSBkYXRhIHBhY2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLg0KICAgICAgICAgIC Ag ICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LCB0aG UN CiAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb2 5s eSBvbmUgb3V0cHV0DQogICAgICAgICAgICAgICAgICAgIHBvcnQgYW5kIHdpdGhvdXQgYW55IG lu cHV0IHBvcnQsIGFuZCB0aGUgb3V0cHV0IHBvcnQNCiAgICAgICAgICAgICAgICAgICAgY2FuIH Ro ZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW9kZWwNCiAgICAgICAgIC Ag ICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS 4N CiAgICAgICAgICAgICAgICAgICAgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgRm9yQ0VTIHByb3 Rv Y29sIGxheWVyLCB0aGUNCiAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgY2 Fu IHJlY2VpdmUgdGhlIFBhY2tldCBSZWRpcmVjdA0KICAgICAgICAgICAgICAgICAgICBNZXNzYW dl cyBmcm9tIENFLCBhbmQgdW4tZW5jYXBzdWxhdGUgdGhlIGRhdGENCiAgICAgICAgICAgICAgIC Ag ICAgcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgdGhlbSB0byBkYXRhcGF0aHMNCi Ag ICAgICAgICAgICAgICAgICAgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuICBBY3R1YWxseSB0aG Ug J1JlY2lyZWN0VGFwJw0KICAgICAgICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxpa2UgYS B0 cmFuc2NvZGVyIHRoYXQgdHJhbnNmZXJzIHRoZQ0KICAgICAgICAgICAgICAgICAgICBGb3JDRV Mg cHJvdG9jb2wgbWVzc2FnZXMgdG8gbm9ybWFsIGRhdGEgcGFja2V0cyBpbg0KICAgICAgICAgIC Ag ICAgICAgICBJUCBmb3J3YXJkaW5nIHBsYW5lLiAgQXMgYSByZXN1bHQsIGlmIHdlIG5lZWQgdG 8N CiAgICAgICAgICAgICAgICAgICAgaGF2ZSByZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIH Rv IHNvbWUgTEZCIChzYXkgYQ0KICAgICAgICAgICAgICAgICAgICBTY2hlZHVsZXIpIGluIEZFIG 1v ZGVsLCB3ZSBvbmx5IG5lZWQgdG8gY29ubmVjdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgJ1 Jl ZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIExGQiBkaXJlY3RseSB2aWEgYQ0KICAgIC Ag ICAgICAgICAgICAgICBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KDQoNCiAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0rDQogIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVkaXJlY3RUYXAgTEZCIHwtLS0tLS0+fCAgIC Ag ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS 0r ICAgICAgIHwgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICB8IFNjaGVkdWxlciB8DQogICAgICAgICAgICAgICAgICAgIC Ag ICAgICAgICAgICBGcm9tIG90aGVyIExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KICAgICAgIC Ag ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIC Ag IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC Ag ICArLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cm Ug MjcNCg0KICAgICAgICAgICAgICAgICAgICBCeSB1c2Ugb2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW 5r JyBMRkJzIGFuZCBzZXZlcmFsDQogICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgTE ZC cyB0aGF0IGNvbm5lY3QgdG8gc2V2ZXJhbCBkaWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgIC Ag ZGF0YXBhdGhzIGluIEZFIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxlIHBhY2tldA0KICAgIC Ag ICAgICAgICAgICAgICByZWRpcmVjdCBwYXRocyBiZXR3ZWVuIENFIGFuZCBGRSBjYW4gYmUgY2 9u c3RydWN0ZWQuDQoNCiAgICAgICAgVGhvdWdodCAyOiAgVGhlcmUgbWlnaHQgYmUgYW5vdGhlci B3 YXkgYSBwYWNrZXQgY291bGQgYmUNCiAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3RlZDogZG ly ZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdGgsIGUuZy4sIGJ5DQogICAgICAgICAgICAgICAgIC Ag IEZQR0EvQVNJQy9OUCBtaWNyb2NvZGUuICBJbiBzdWNoIGEgY2FzZSB3ZSBkbyBub3QNCiAgIC Ag ICAgICAgICAgICAgICAgbmVlZCB0byBwdXQgaW4gYSBsb3Qgb2Ygc21hcnRuZXNzLiAgUHJvYm Fi bHkgYSBsaW5rDQogICAgICAgICAgICAgICAgICAgIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZX Zl bCBoZWFkZXIgaXMgZW5vdWdoLiAgVGhlDQogICAgICAgICAgICAgICAgICAgIHJlY2VpdmVyIG Rl bXV4ZXMgaXQgb25seSBiYXNlZCBvbiBzb21lIHByb3RvY29sIHR5cGUNCiAgICAgICAgICAgIC Ag ICAgICAgaW4gdGhlIGxpbmsgbGF5ZXIgb3IgbmV0d29yayB0cmFuc3BvcnQgbGF5ZXIuICBUaG UN CiAgICAgICAgICAgICAgICAgICAgcHJvcyBmb3IgdGhpcyBhcHByYW9jaCBpcyBpdCBtYXkgcH Jv dmlkZSBhIGZhc3QgYW5kDQogICAgICAgICAgICAgICAgICAgIGNvc3QtZWZmZWN0aXZlIHBhdG gg Zm9yIHBhY2tldCByZWRpcmVjdC4gIFRoZSBjb25zDQogICAgICAgICAgICAgICAgICAgIGZvci B0 aGlzIGlzIGl0IG1heSBtb3JlIG9yIGxlc3MgY29uZnVzZXMgdGhlIEZwDQogICAgICAgICAgIC Ag ICAgICAgIHJlZmVyZW5jZSBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuDQ oN Ci0tLS0tLS0tLS0NCmNhdGVnb3J5OiBFZGl0b3JpYWwNCmRyYWZ0OiBkcmFmdC1pZXRmLWZvcm Nl cy1wcm90b2NvbA0KbWVzc2FnZXM6IDQ5DQpub3N5OiBhdnJpDQpwcmlvcml0eTogTXVzdCBmaX gN CnN0YXR1czogTm8gZGlzY3Vzc2lvbg0KdGl0bGU6IFBhY2tldCBSZWRpcmVjdA0KDQpfX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZvcmNlcyBpc3 N1 ZSB0cmFja2VyIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NCjxodHRwOi8vd3d3Lm1pcDQub3 Jn L2lzc3Vlcy90cmFja2VyL2ZvcmNlcy9pc3N1ZTMyPg0KX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= 2005 Message-Id: Date: Sun, 26 Jun 2005 09:49:21 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I would expect that a Redirect Message has a different outermost TLV. The grammar is intended to help us, not serve as a straightjacket. Different message types can have different outer TLVs. It is desirable to use the same structure when it applies. But the redirect message is simply a different case. It's contents are not a DATARAW much less a DATA TLV. Its content structure is not defined by an LFB element definition or Model DataDefs structure definition. If we need to fix the "grammar" section to make it clear that not all PL messages necessarily use the same outermost TLV, we should do so. My own approach would be to separate the grammar into a definition of the contents of that TLV, and a separate definition of which TLVs / content are carried in the outermost level of which messages. Yours, Joel PS: Weiming, I am sorry you got caught up in this confusion. I don't think you created the tendency I am railing against above. I am just using your message as a starting point to hammer home a point. At 04:45 AM 6/26/2005, Wang,Weiming wrote: >Maybe it's me who missed something :) >My thought was we might need to obey our message grammar well that we have >to use a strict Path-data for operation TLV. To obey the rule, treating >it as an event will ease the message format greatly. > >Actually I'm very happy to see that you agree a path can be omitted for >some specific messages like redirect messge. > >OK, let's solve it then, to let redirect message only contain Data >field? I can update this redirect message part text then. > >Jamal, could you give a response on this? > >One less vital question is, shall we allow for mulitpul redirect packets >encapsulated in one TLV or just one TLV only for one packet? To use the >former, we have to define a sequence for the redirected packets then in >the TLV. > >On the meta-information related, I think LFB IDs has already been >included. I don't think we need an extra port ID to indicate where to put >the redirected data to or to get redirected data from. A redirect source >LFB or sink LFB will have a port ID, which belongs to FE LFB topology >concept, and FE LFB topolgy configuration is in charge of this. Not sure >if it complies with your thought? > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: [issue32] Packet Redirect > > > > I am missign something in your suggestion. > > > > Why would we want to treat redirects as events? > > We should treat them as redirects. > > > > I am very confused about "How a path should be defined in a Packet > Redirect > > Message", since as far as I can tell, a redirect does not need a path. It > > needs a collection of meta-information, which we need to define. At the > > moment, that has to include at least the LFB ID that the redirect is > from / > > to. I suppose by declaring a multiplicity of such LFBs, that can be > all of > > the information. (I usually think in terms of at least a logical port ID > > the packet came from / is intended for.) > > > > Yours, > > Joel > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > >Jamal, Joel, and Hormzd, > > > > > >I suppose we could close this issue by reaching the following points: > > > > > >1. The redirect LFBs called RedirectSource LFB and RedirectSink LFB are > > >moved to the model, but the protocol retains the Redirect Message. The > > >reason to keep the specific message is we need to specifically recognize > > >redirected data between CE-FE transportation to avoid DoS attacks. > > > > > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL > > >events in that: > > > a. The event is triggered every time a new redirected packet > arrives > > > at the LFBs. > > > b. The event is transported by the Redirect Message only, while > the > > > Redirect Message will the same message format as a general event > > > notification message (except the message type in the header). > > > > > >By doing in this way, we can also solve the issue53 (How a path should be > > >defined in Packet Redirect Message) then. > > > > > >Unfortunately, I think of another question that is related to the Packet > > >Redirect Message as well as to Event Notification Message. The question > > >is, the Event Notification Message allows event generated by CE and sent > > >to FE. In the case, in the message format, the LFB IDs refer to the LFBs > > >that will receive the event notification, but the question is, what the > > >Path in the message refers to then ?? The same also happens to Packet > > >Redirect Message from CE to FE. > > > > > >Thanks, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Avri Doria" > > >Sent: Monday, May 23, 2005 2:35 AM > > >Subject: [issue32] Packet Redirect > > > > > > > > >New submission from Avri Doria : > > > > > >6.8 > > > > > > Editorial Note: There are also discussions on how LFBs in FE model > > > that are related to packet redirect operations > > > should be defined. Although it is out of the scope > > > of forces protocol, how to define the LFBs affect > > > the Packet Redirect Message described here. Because > > > currently it is still in progress in FE model on how > > > to define such LFBs, we try to post some thoughts on > > > this here for discussion. They will be removed > > > later along with the progress of the FE model work. > > > Thought 1: To define LFBs called 'RedirectSink' and > > > 'RedirectTap' for packet redirect. > > > An LFB in FE called 'RedirectSink' is responsible to > > > collect data packets that need to be redirected to > > > CE. From the perspective of the FE LFB topology, > > > the 'RedirectSink' LFB is an LFB with only one input > > > port and without any output port, and the input port > > > can then be connected to any other LFB in FE model > > > by means of a datapath in the forwarding plane. > > > From the perspective of the ForCES protocol layer, > > > the 'RedirectSink' LFB will generate the Packet > > > Redirect Messages when it receives data packets from > > > forwarding plane. > > > > > > An LFB in FE called 'RedirectTap' is responsible to > > > receive data packets that are redirected from CE. > > > From the perspective of the FE LFB topology, the > > > 'RedirectTap' LFB is an LFB with only one output > > > port and without any input port, and the output port > > > can then be connected to any other LFB in FE model > > > by means of a datapath in the forwarding plane. > > > From the perspective of ForCES protocol layer, the > > > 'RedirectTap' LFB can receive the Packet Redirect > > > Messages from CE, and un-encapsulate the data > > > packets from the message and put them to datapaths > > > in the forwarding plane. Actually the 'RecirectTap' > > > LFB acts more like a transcoder that transfers the > > > ForCES protocol messages to normal data packets in > > > IP forwarding plane. As a result, if we need to > > > have redirected packets connected to some LFB (say a > > > Scheduler) in FE model, we only need to connect the > > > 'RedirectTap LFB to the Scheduler LFB directly via a > > > datapath as follows: > > > > > > > > > +-----------------+ +-----------+ > > > | RedirectTap LFB |------>| | > > > +-----------------+ | | > > > | Scheduler | > > > From other LFB ---->| LFB | > > > | | > > > +-----------+ > > > > > > Figure 27 > > > > > > By use of several 'RedirectSink' LFBs and several > > > 'RedirectTap' LFBs that connect to several different > > > datapaths in FE forwarding plane, multiple packet > > > redirect paths between CE and FE can be constructed. > > > > > > Thought 2: There might be another way a packet could be > > > redirected: directly by a forwarding path, e.g., by > > > FPGA/ASIC/NP microcode. In such a case we do not > > > need to put in a lot of smartness. Probably a link > > > layer or even network level header is enough. The > > > receiver demuxes it only based on some protocol type > > > in the link layer or network transport layer. The > > > pros for this appraoch is it may provide a fast and > > > cost-effective path for packet redirect. The cons > > > for this is it may more or less confuses the Fp > > > reference point definition in ForCES framework. > > > > > >---------- > > >category: Editorial > > >draft: draft-ietf-forces-protocol > > >messages: 49 > > >nosy: avri > > >priority: Must fix > > >status: No discussion > > >title: Packet Redirect > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ > > 2005 Message-Id: Date: Sat, 25 Jun 2005 23:42:18 -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 I am missign something in your suggestion. Why would we want to treat redirects as events? We should treat them as redirects. I am very confused about "How a path should be defined in a Packet Redirect Message", since as far as I can tell, a redirect does not need a path. It needs a collection of meta-information, which we need to define. At the moment, that has to include at least the LFB ID that the redirect is from / to. I suppose by declaring a multiplicity of such LFBs, that can be all of the information. (I usually think in terms of at least a logical port ID the packet came from / is intended for.) Yours, Joel At 10:50 PM 6/25/2005, Weiming Wang wrote: >Jamal, Joel, and Hormzd, > >I suppose we could close this issue by reaching the following points: > >1. The redirect LFBs called RedirectSource LFB and RedirectSink LFB are >moved to the model, but the protocol retains the Redirect Message. The >reason to keep the specific message is we need to specifically recognize >redirected data between CE-FE transportation to avoid DoS attacks. > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL >events in that: > a. The event is triggered every time a new redirected packet arrives > at the LFBs. > b. The event is transported by the Redirect Message only, while the > Redirect Message will the same message format as a general event > notification message (except the message type in the header). > >By doing in this way, we can also solve the issue53 (How a path should be >defined in Packet Redirect Message) then. > >Unfortunately, I think of another question that is related to the Packet >Redirect Message as well as to Event Notification Message. The question >is, the Event Notification Message allows event generated by CE and sent >to FE. In the case, in the message format, the LFB IDs refer to the LFBs >that will receive the event notification, but the question is, what the >Path in the message refers to then ?? The same also happens to Packet >Redirect Message from CE to FE. > >Thanks, >Weiming > >----- Original Message ----- >From: "Avri Doria" >Sent: Monday, May 23, 2005 2:35 AM >Subject: [issue32] Packet Redirect > > >New submission from Avri Doria : > >6.8 > > Editorial Note: There are also discussions on how LFBs in FE model > that are related to packet redirect operations > should be defined. Although it is out of the scope > of forces protocol, how to define the LFBs affect > the Packet Redirect Message described here. Because > currently it is still in progress in FE model on how > to define such LFBs, we try to post some thoughts on > this here for discussion. They will be removed > later along with the progress of the FE model work. > Thought 1: To define LFBs called 'RedirectSink' and > 'RedirectTap' for packet redirect. > An LFB in FE called 'RedirectSink' is responsible to > collect data packets that need to be redirected to > CE. From the perspective of the FE LFB topology, > the 'RedirectSink' LFB is an LFB with only one input > port and without any output port, and the input port > can then be connected to any other LFB in FE model > by means of a datapath in the forwarding plane. > From the perspective of the ForCES protocol layer, > the 'RedirectSink' LFB will generate the Packet > Redirect Messages when it receives data packets from > forwarding plane. > > An LFB in FE called 'RedirectTap' is responsible to > receive data packets that are redirected from CE. > From the perspective of the FE LFB topology, the > 'RedirectTap' LFB is an LFB with only one output > port and without any input port, and the output port > can then be connected to any other LFB in FE model > by means of a datapath in the forwarding plane. > From the perspective of ForCES protocol layer, the > 'RedirectTap' LFB can receive the Packet Redirect > Messages from CE, and un-encapsulate the data > packets from the message and put them to datapaths > in the forwarding plane. Actually the 'RecirectTap' > LFB acts more like a transcoder that transfers the > ForCES protocol messages to normal data packets in > IP forwarding plane. As a result, if we need to > have redirected packets connected to some LFB (say a > Scheduler) in FE model, we only need to connect the > 'RedirectTap LFB to the Scheduler LFB directly via a > datapath as follows: > > > +-----------------+ +-----------+ > | RedirectTap LFB |------>| | > +-----------------+ | | > | Scheduler | > From other LFB ---->| LFB | > | | > +-----------+ > > Figure 27 > > By use of several 'RedirectSink' LFBs and several > 'RedirectTap' LFBs that connect to several different > datapaths in FE forwarding plane, multiple packet > redirect paths between CE and FE can be constructed. > > Thought 2: There might be another way a packet could be > redirected: directly by a forwarding path, e.g., by > FPGA/ASIC/NP microcode. In such a case we do not > need to put in a lot of smartness. Probably a link > layer or even network level header is enough. The > receiver demuxes it only based on some protocol type > in the link layer or network transport layer. The > pros for this appraoch is it may provide a fast and > cost-effective path for packet redirect. The cons > for this is it may more or less confuses the Fp > reference point definition in ForCES framework. > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 49 >nosy: avri >priority: Must fix >status: No discussion >title: Packet Redirect > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Sat, 25 Jun 2005 22:40:10 -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, -----Original Message----- From: Forwarding and Control Element Separation=20 I am missign something in your suggestion. Why would we want to treat redirects as events? We should treat them as redirects. [HK] This seems like a terminology issue...but I think Weiming means the same thing. I am very confused about "How a path should be defined in a Packet Redirect=20 Message", since as far as I can tell, a redirect does not need a path. It=20 needs a collection of meta-information, which we need to define. At the moment, that has to include at least the LFB ID that the redirect is from /=20 to. I suppose by declaring a multiplicity of such LFBs, that can be all of=20 the information. (I usually think in terms of at least a logical port ID=20 the packet came from / is intended for.) [HK] I agree, we don't need a path for Packet Redirect message, Regards Hormuzd At 10:50 PM 6/25/2005, Weiming Wang wrote: >Jamal, Joel, and Hormzd, > >I suppose we could close this issue by reaching the following points: > >1. The redirect LFBs called RedirectSource LFB and RedirectSink LFB are=20 >moved to the model, but the protocol retains the Redirect Message. The=20 >reason to keep the specific message is we need to specifically recognize=20 >redirected data between CE-FE transportation to avoid DoS attacks. > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL=20 >events in that: > a. The event is triggered every time a new redirected packet arrives=20 > at the LFBs. > b. The event is transported by the Redirect Message only, while the=20 > Redirect Message will the same message format as a general event=20 > notification message (except the message type in the header). > >By doing in this way, we can also solve the issue53 (How a path should be=20 >defined in Packet Redirect Message) then. > >Unfortunately, I think of another question that is related to the Packet=20 >Redirect Message as well as to Event Notification Message. The question >is, the Event Notification Message allows event generated by CE and sent=20 >to FE. In the case, in the message format, the LFB IDs refer to the LFBs=20 >that will receive the event notification, but the question is, what the >Path in the message refers to then ?? The same also happens to Packet=20 >Redirect Message from CE to FE. > >Thanks, >Weiming > 2005 Message-Id: Date: Sat, 25 Jun 2005 14:48:30 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue22] Overview - Response Formatting Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jamal, It seems like I misunderstand what you mean by Full Response...from your email and that of Alex, looks like you mean is sending back the Request Message in every response, right? If that is the case then this is not what we have done nor what we need for the protocol....we are in complete agreement. What I mean by full Response, is getting back a message for each Request... e.g. Config Response for Config Request, that tells me whether it was successful or it failed. We already have provisions for this in the protocol...the ACK flags allow us to do this. - ACK indicator(2 bit) The description for using the two bits is: 'NoACK' (00) 'SuccessACK'(01) 'UnsuccessACK'(10) 'ACKAll' (11) The RESULT TLV is probably also about the details of what should be returned in response to the request. It seems to me like this issue should be closed since we already have agreement on the ACK flags. Let me know your thoughts? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, June 24, 2005 6:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue22] Overview - Response Formatting On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > Jamal, >=20 > I briefly looked at this... >=20 > I don't agree with what is said about 3.xx.1 Full response in the text. > We have sent responses for all messages, its worked out very well and > its important for building a reliable product. >=20 Parse error. What do you mean by so far you have sent response for all messages? (cliches like "reliable product" to justify anything technical will end up diverting the focus of the discussion - and I am pretty sure we dont have marketing people participating that need to be confused with such terms. Why not be explicit?). I think the Full response will have to go; it's more there for completion sake. I cant remember why it was rejected; i know it will consume more bandwidth. It's value is in as mentioned to validate what was sent. This is derived from looking at behaviors of certain hardware. There is hardware out there (typically using CAMs) which returns you both the question asked and answer to the question.=20 > Also, stated... > 3.xx.2.2 More than Basic > Proposed by both Weiming and Joel: Introduce RESULT TLV > to describe the results of a SET operation. The RESULT TLV will > have more data in it than what 3.2.1 is proposing. >=20 > I don't understand the difference between this and Full response above. > Also, what does RESULT TLV look like? >=20 The RESULT TLV is still to be defined. Joel and Weiming were both proposing it. Thanks for taking the time to read the text. It is amazing for a draft that we are trying to rush out to last call not that many people are responding. cheers, jamal 2005 Message-Id: Date: Sat, 25 Jun 2005 14:37:32 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert, I don't understand the need for a transaction id. I believe SN and = Correlator are more than sufficient for the protocol. It almost seems = like a terminology issue, if calling a correlator a transaction id makes = you happy, I am fine with that. But other than terminology I don't see a = need for yet another ID. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Sent: Friday, June 24, 2005 6:35 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header I haven't heard much reactions to my last post on the topic, so let me reformulate it in a shorter way: - what is currently called SN is in fact used as a Transaction ID. One can (ab)use it for sequencing a subset of messages (see details in my previous post) - for full sequencing capability, a distinct field from Transaction ID should be introduced. - in addition, yet another field for higher-level correlation should be introduced. So now that we agreed we need (at least) two fields, how shall we call=20 them and what meaning/semantic do we give to them ? field #1: Transaction ID ? 16 bits ? field #2: Correlator ? 32 bits ? possibly field #3: true Sequence Number 16-32 bits ? Regards, -Robert Jamal Hadi Salim wrote: >On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote: > =20 > >>Thanks for the input, Sue. >>I believe we have decided to leave the SN as is and add a Correlator = as >>well to the header. So that should address any such requirements. >> >> =20 >> > >I dont know if we have heard from Weiming on this so we can close it? > >cheers, >jamal > > > =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/~rha 2005 Message-Id: Date: Sat, 25 Jun 2005 01:58:34 +0800 From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 U3VzYW4sDQoNClZlcnkgZ2xhZCB0byBzZWUgeW91LiAgDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3 Nh Z2UgLS0tLS0gDQpGcm9tOiAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmV4dGhvcC5jb20+DQpTdW Jq ZWN0OiBSRTogW0ZPUkNFU10gW2lzc3VlNTRdIGNvcnJlbGF0b3IgaW4gdGhlIFBMIG1lc3NhZ2 Ug aGVhZGVyDQoNCg0KV2VpbWluZzoNCg0KR3JlYXQgbmV3cyB0aGF0IHdlIGNhbiBoYXZlIDIgZm ll bGRzLiAgQXJlIHlvdSBmaXJtIG9uIHRoZSBTTi9jb3JyZWxhdG9yDQp2YWx1ZXMgb3Igd291bG Qg eW91IGVudGVydGFpbiBhIGRpc2N1c3Npb24gb2YgcGFyYWxsZWxpemF0aW9uIG9mDQp1cGRhdG lu ZyBzdHJlYW1zIHVzaW5nIHRoZSBTTi9jb3JyZWxhdG9yPw0KW1dlaW1pbmddIFNvcnJ5LCBidX Qg SSBqdXN0IGNhbm4ndCBjYXRjaCB3ZWxsIG9uIHRoZSBwYXJhbGxlbGl6YXRpb24gb2YgdXBkYX Rp bmcgc3RyZWFtcyBoZXJlLiAgQ291bGQgeW91IHNob3cgbW9yZSBvZiB5b3VyIHRob3VnaHRzIG 9u IHRoaXM/DQoNClRoYW5rcywNCldlaW1pbmcNCg0KDQpTdWUgSGFyZXMNCg0KDQotLS0tLU9yaW dp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IF Nl cGFyYXRpb24NClttYWlsdG86Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NXSBPbiBCZWhhbG Yg T2YgV2VpbWluZyBXYW5nDQpTZW50OiBGcmlkYXksIEp1bmUgMjQsIDIwMDUgMTI6MTQgUE0NCl Rv OiBGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00NClN1YmplY3Q6IFJlOiBbRk9SQ0VTXSBbaX Nz dWU1NF0gY29ycmVsYXRvciBpbiB0aGUgUEwgbWVzc2FnZSBoZWFkZXINCg0KSmFtYWwsDQoNCl Ro YW5rcyBmb3IgdGhlIG1lbnRpb24sIHdoZXJlYXMgSSB0aGluayBJJ3YgZXhwcmVzc2VkIG15IG 9w aW5pb24gaW4gbXkNCnByZXZpb3VzIHBvc3RzLiBJIGNhbiBsaXZlIHdpdGggdHdvIGZpZWxkcy Ao U04gYW5kIGNvcnJlbGF0b3IpIHNvbHV0aW9uLA0KdGhvdWdodCBJIGRvIHRoaW5rIG9uZSBmaW Vs ZCBpcyBlbm91Z2ggZm9yIG91ciBjdXJyZW50IHVzZSBmb3IgdGhlDQptZXNzYWdlIHNlcXVlbm Np bmcgcHVycG9zZSwgdGhhdCBpcywgc2VxdWVuY2luZyBvZiBtZXNzYWdlcyB3aXRob3V0DQpyZX Nw b25zZSBtZXNzYWdlcywgd2hpY2ggYWxyZWFkeSBlbm91Z2ggZm9yIHRoZSBwdXJwb3NlIGxpa2 Ug cmVkaXJlY3QNCm1lc3NhZ2Ugb3JkZXJpbmcgYmFjay4gT25lIG1vcmUgdGhpbmcgaXMsIGZvci B0 d28gZmllbGRzIHNvbHV0aW9ucywgSQ0Kc3VnZ2VzdCB0byBsZXQgdGhlIGNvcnJlbGF0b3IgZm ll bGQgdXN1YWxseSBoYXZlIHRoZSBzYW1lIHZhbHVlIGFzIHRoZQ0KU04gZmllbGQsIGV4Y2VwdC Bm b3IgcmVzcG9uc2UgbWVzc2FnZXMsIHdoaWNoIHNob3VsZCBoYXZlIHRoZSBjb3JyZWxhdG9yDQ p2 YWx1ZXMgYXMgdGhlIG1lc3NhZ2VzIHRoZXkgcmVwbHksIHNvIGFzIHRvIHNpbXBsaWZ5IHRoZS Bj b3JyZWxhdG9yDQp2YWx1ZSBnZW5lcmF0aW5nLg0KDQpUaGFua3MsDQpXZWltaW5nDQotLS0tLS BP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQH pu eXguY29tPg0KU3ViamVjdDogUmU6IFtpc3N1ZTU0XSBjb3JyZWxhdG9yIGluIHRoZSBQTCBtZX Nz YWdlIGhlYWRlcg0KDQoNCj4gT24gVGh1LCAyMDA1LTIzLTA2IGF0IDAwOjE3IC0wNzAwLCBLaG 9z cmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KPiA+IFRoYW5rcyBmb3IgdGhlIGlucHV0LCBTdWUuDQ o+ ID4gSSBiZWxpZXZlIHdlIGhhdmUgZGVjaWRlZCB0byBsZWF2ZSB0aGUgU04gYXMgaXMgYW5kIG Fk ZCBhIENvcnJlbGF0b3INCmFzDQo+ID4gd2VsbCB0byB0aGUgaGVhZGVyLiBTbyB0aGF0IHNob3 Vs ZCBhZGRyZXNzIGFueSBzdWNoIHJlcXVpcmVtZW50cy4NCj4gPiANCj4gDQo+IEkgZG9udCBrbm 93 IGlmIHdlIGhhdmUgaGVhcmQgZnJvbSBXZWltaW5nIG9uIHRoaXMgc28gd2UgY2FuIGNsb3NlIG l0 Pw0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0K 2005 Message-Id: Date: Sat, 25 Jun 2005 00:13:48 +0800 From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYW5rcyBmb3IgdGhlIG1lbnRpb24sIHdoZXJlYXMgSSB0aGluayBJJ3YgZX hw cmVzc2VkIG15IG9waW5pb24gaW4gbXkgcHJldmlvdXMgcG9zdHMuIEkgY2FuIGxpdmUgd2l0aC B0 d28gZmllbGRzIChTTiBhbmQgY29ycmVsYXRvcikgc29sdXRpb24sIHRob3VnaHQgSSBkbyB0aG lu ayBvbmUgZmllbGQgaXMgZW5vdWdoIGZvciBvdXIgY3VycmVudCB1c2UgZm9yIHRoZSBtZXNzYW dl IHNlcXVlbmNpbmcgcHVycG9zZSwgdGhhdCBpcywgc2VxdWVuY2luZyBvZiBtZXNzYWdlcyB3aX Ro b3V0IHJlc3BvbnNlIG1lc3NhZ2VzLCB3aGljaCBhbHJlYWR5IGVub3VnaCBmb3IgdGhlIHB1cn Bv c2UgbGlrZSByZWRpcmVjdCBtZXNzYWdlIG9yZGVyaW5nIGJhY2suIE9uZSBtb3JlIHRoaW5nIG lz LCBmb3IgdHdvIGZpZWxkcyBzb2x1dGlvbnMsIEkgc3VnZ2VzdCB0byBsZXQgdGhlIGNvcnJlbG F0 b3IgZmllbGQgdXN1YWxseSBoYXZlIHRoZSBzYW1lIHZhbHVlIGFzIHRoZSBTTiBmaWVsZCwgZX hj ZXB0IGZvciByZXNwb25zZSBtZXNzYWdlcywgd2hpY2ggc2hvdWxkIGhhdmUgdGhlIGNvcnJlbG F0 b3IgdmFsdWVzIGFzIHRoZSBtZXNzYWdlcyB0aGV5IHJlcGx5LCBzbyBhcyB0byBzaW1wbGlmeS B0 aGUgY29ycmVsYXRvciB2YWx1ZSBnZW5lcmF0aW5nLg0KDQpUaGFua3MsDQpXZWltaW5nDQotLS 0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYW Rp QHpueXguY29tPg0KU3ViamVjdDogUmU6IFtpc3N1ZTU0XSBjb3JyZWxhdG9yIGluIHRoZSBQTC Bt ZXNzYWdlIGhlYWRlcg0KDQoNCj4gT24gVGh1LCAyMDA1LTIzLTA2IGF0IDAwOjE3IC0wNzAwLC BL aG9zcmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KPiA+IFRoYW5rcyBmb3IgdGhlIGlucHV0LCBTdW Uu DQo+ID4gSSBiZWxpZXZlIHdlIGhhdmUgZGVjaWRlZCB0byBsZWF2ZSB0aGUgU04gYXMgaXMgYW 5k IGFkZCBhIENvcnJlbGF0b3IgYXMNCj4gPiB3ZWxsIHRvIHRoZSBoZWFkZXIuIFNvIHRoYXQgc2 hv dWxkIGFkZHJlc3MgYW55IHN1Y2ggcmVxdWlyZW1lbnRzLg0KPiA+IA0KPiANCj4gSSBkb250IG tu b3cgaWYgd2UgaGF2ZSBoZWFyZCBmcm9tIFdlaW1pbmcgb24gdGhpcyBzbyB3ZSBjYW4gY2xvc2 Ug aXQ/DQo+IA0KPiBjaGVlcnMsDQo+IGphbWFs 2005 Message-Id: Date: Fri, 24 Jun 2005 15:35:05 +0200 From: Robert Haas Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I haven't heard much reactions to my last post on the topic, so let me reformulate it in a shorter way: - what is currently called SN is in fact used as a Transaction ID. One can (ab)use it for sequencing a subset of messages (see details in my previous post) - for full sequencing capability, a distinct field from Transaction ID should be introduced. - in addition, yet another field for higher-level correlation should be introduced. So now that we agreed we need (at least) two fields, how shall we call=20 them and what meaning/semantic do we give to them ? field #1: Transaction ID ? 16 bits ? field #2: Correlator ? 32 bits ? possibly field #3: true Sequence Number 16-32 bits ? Regards, -Robert Jamal Hadi Salim wrote: >On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote: > =20 > >>Thanks for the input, Sue. >>I believe we have decided to leave the SN as is and add a Correlator as >>well to the header. So that should address any such requirements. >> >> =20 >> > >I dont know if we have heard from Weiming on this so we can close it? > >cheers, >jamal > > > =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: Fri, 24 Jun 2005 10:16:48 -0400 From: Alex Audu Subject: Re: [issue54] correlator in the PL message header Comments: To: rha@zurich.ibm.com Content-Type: multipart/alternative; boundary="--------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol. com" MIME-Version: 1.0 ----------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Robert, =20 Given that a transaction is a sequence of message or information exchanges t= reated as a unit for the purpose of satisfying a request, I am finding a little difficulty in= understanding why=20 we need a transaction ID in this layer. And then a correlator? What is the= need for this? =20 Regards, Alex. =20 =20 -----Original Message----- From: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Sent: Fri, 24 Jun 2005 15:35:05 +0200 Subject: Re: [issue54] correlator in the PL message header I haven't heard much reactions to my last post on the topic, so let me=20 reformulate it in a shorter way:=20 - what is currently called SN is in fact used as a Transaction ID. One=20 can (ab)use it for sequencing a subset of messages (see details in my=20 previous post)=20 - for full sequencing capability, a distinct field from Transaction ID=20 should be introduced.=20 - in addition, yet another field for higher-level correlation should be=20 introduced.=20 =20 So now that we agreed we need (at least) two fields, how shall we call them=20= and what meaning/semantic do we give to them ?=20 =20 field #1: Transaction ID ? 16 bits ?=20 field #2: Correlator ? 32 bits ?=20 possibly field #3: true Sequence Number 16-32 bits ?=20 =20 Regards,=20 -Robert=20 =20 Jamal Hadi Salim wrote:=20 =20 >On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote:=20 > >=20 >>Thanks for the input, Sue.=20 >>I believe we have decided to leave the SN as is and add a Correlator as=20 >>well to the header. So that should address any such requirements.=20 >>=20 >> >>=20 >=20 >I dont know if we have heard from Weiming on this so we can close it?=20 >=20 >cheers,=20 >jamal=20 >=20 >=20 > >=20 =20 -- Dr. Robert R. Haas=20 IBM Zurich Research Laboratory=20 S=E4umerstrasse 4=20 CH-8803 R=FCschlikon/Switzerland=20 phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha=20 ----------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hel= lo Robert,
 
Given that a transaction is a sequence of message or information exchan= ges treated as a unit
for the purpose of satisfying a request, I am finding a little difficul= ty in understanding why
we need a transaction ID in this layer.  And then a correlator?&nb= sp; What is the need for this?
 
Regards,
Alex.
 
 

-----Original Message-----
From: Robert Haas <rha@zurich.ibm.= com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Fri, 24 Jun 2005 15:35:0= 5 +0200
Subject: Re: [issue54] correlator in the PL message header
I haven't heard much reactions to my last post on the topic, so let= me 
reformulate it in a shorter way: 
- what is currently c= alled SN is in fact used as a Transaction ID. One 
can (ab)use it fo= r sequencing a subset of messages (see details in my 
previous post)=  
- for full sequencing capability, a distinct field from Transactio= n ID 
should be introduced. 
- in addition, yet another fiel= d for higher-level correlation should be 
introduced. 
 = ;
So now that we agreed we need (at least) two fields, how shall we call=20= them and what meaning/semantic do we give to them ? 
 
field= #1: Transaction ID ? 16 bits ? 
field #2: Correlator ? 32 bits ?&nb= sp;
possibly field #3: true Sequence Number 16-32 bits ? 
 <= BR>Regards, 
-Robert 
 
Jamal Hadi Salim wrote: = ;
 
>On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wr= ote: 
> > 
>>Thanks for the input, Sue. >>I believe we have decided to leave the SN as is and add a Correlato= r as 
>>well to the header. So that should address any such re= quirements. 
>> 
>> >> 
> =
>I dont know if we have heard from Weiming on this so we can close it= ? 
> 
>cheers, 
>jamal 
>  ;<= BR>> 
> > 
 
-- Dr. Robert R. Haas IBM Zurich Research Laboratory 
S=E4umerstrasse 4 
CH-8803=20= R=FCschlikon/Switzerland 
phone +41-44-724-8698 fax +41-44-724-8578=20= http://www.zurich= .ibm.com/~rha 
----------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com-- 2005 Message-Id: Date: Fri, 24 Jun 2005 09:38:22 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-24-06 at 09:27 -0400, Joel M. Halpern wrote: > I can see how what you suggest would work if events were homogenous. I > don't think they are. > Given that they are not, I will try to add suitable explanatory text about > what aggregations can and can not be registered for, and why. That would be fine with me. Thanks. cheers, jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 09:37:52 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue22] Overview - Response Formatting Comments: To: aaudu2000@aol.com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Mr Audu alive and kicking! Welcome back. I forgot to mention the debug feature, thanks for bringing it up. cheers, jamal On Fri, 2005-24-06 at 09:27 -0400, Alex Audu wrote: > Hi All, > > Can we make this feature configurable? There is no doubt this feature > is useful (e.g. when debuging > data connectivity problems from the application side). It is also > true you don't want to echo the > the request all the time. That could kill your bandwidth efficiency. > So,..make it configurable; so I can > turn it on when I need it. > > Cheers, > Alex. > > > -----Original Message----- > From: Jamal Hadi Salim > To: FORCES@PEACH.EASE.LSOFT.COM > Sent: Fri, 24 Jun 2005 09:11:45 -0400 > Subject: Re: [issue22] Overview - Response Formatting > > On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > > Jamal, > > > > I briefly looked at this... > > > > I don't agree with what is said about 3.xx.1 Full response in the text. > > We have sent responses for all messages, its worked out very well and > > its important for building a reliable product. > > > > Parse error. What do you mean by so far you have sent response for all > messages? > (cliches like "reliable product" to justify anything technical will end > up diverting the focus of the discussion - and I am pretty sure we dont > have marketing people participating that need to be confused with such > terms. Why not be explicit?). > > I think the Full response will have to go; it's more there for > completion sake. I cant remember why it was rejected; i know it will > consume more bandwidth. It's value is in as mentioned to validate what > was sent. This is derived from looking at behaviors of certain hardware. > There is hardware out there (typically using CAMs) which returns you > both the question asked and answer to the question. > > > Also, stated... > > 3.xx.2.2 More than Basic > > Proposed by both Weiming and Joel: Introduce RESULT TLV > > to describe the results of a SET operation. The RESULT TLV will > > have more data in it than what 3.2.1 is proposing. > > > > I don't understand the difference between this and Full response above. > > Also, what does RESULT TLV look like? > > > > The RESULT TLV is still to be defined. Joel and Weiming were both > proposing it. > > Thanks for taking the time to read the text. > It is amazing for a draft that we are trying to rush out to last call > not that many people are responding. > > > cheers, > jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 09:27:45 -0400 From: "Joel M. Halpern" Subject: Re: Event subscription -- properties (model and protocol) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I can see how what you suggest would work if events were homogenous. I don't think they are. Given that they are not, I will try to add suitable explanatory text about what aggregations can and can not be registered for, and why. Yours, Joel At 07:59 AM 6/24/2005, Jamal Hadi Salim wrote: >On Fri, 2005-24-06 at 07:34 -0400, Joel M. Halpern wrote: > > If I understand your suggestion, you are proposing that it be possible to > > add event declarations for targets without conditions. These event ids / > > declarations are used only for registration (they would never appear in > > notifications. > >No they would appear in the notification. Its up to the CE (if i >understood you correctly) to map them to something meaningful. > > > A registration for such an event constitutes a registration for every > > actual event that can be generated against the given target? > > > >Ok, i realize i was thinking narrowly basing on the scope of what we >have implemented to date. The only thing we are currently excited about >as far as event is of nature (whether its ipsec, port LFB etc). >Thats the only events we have. >So my thoughts were along the mindset that the event type will be >homogenous across the table i.e all of A, B, and C throw events >and i can therefore register for 7.4 ("the table events"). If the events >are not going to be homegenous then it is not worth it. If however, we >can leave that up to the CE it may be worth it. > > > We can do that, but is it really worth it? Aggregating subscripts is both > > natural and necessary, since there may be many of them, and they may be > > created at any time. On the other hand, the events are known a priori to > > the CE, and there are not many. The effort for the CE to register for the > > events is not much harder than the effort of registering for this > > aggregation event. > >I think we are partially agreeing: >If i heard you correctly you are saying i can register for agregated >events 7.1, 7.2, 7.3 and receive fine grained notifications for 7.1.1, >7.1.n etc. This i like. >What i also thought i heard you say is you cant register for aggregate >event 7.4 "the table events". This is where we differ (given our >current implemented LFBs have homogenous event types). > > > And I am somewhat uncomfortable with event declarations that are not > events. > >If 7.4 will introduce complexity to the model then i can live with the >CE translating it to mean {7.1, 7.2, 7.3}. It will help to explicitly >mention this in your text somewhere. It does seem to me like it would >ease things for the FE if i told it about 7.4 instead, no? > >cheers, >jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 09:27:06 -0400 From: Alex Audu Subject: Re: [issue22] Overview - Response Formatting Comments: To: hadi@znyx.com Content-Type: multipart/alternative; boundary="--------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol. com" MIME-Version: 1.0 ----------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Hi All, Can we make this feature configurable? There is no doubt this feature is useful (e.g. when debuging data connectivity problems from the application side). It is also true you don't want to echo the the request all the time. That could kill your bandwidth efficiency. So,..make it configurable; so I can turn it on when I need it. Cheers, Alex. -----Original Message----- From: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM Sent: Fri, 24 Jun 2005 09:11:45 -0400 Subject: Re: [issue22] Overview - Response Formatting On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > I briefly looked at this... > > I don't agree with what is said about 3.xx.1 Full response in the text. > We have sent responses for all messages, its worked out very well and > its important for building a reliable product. > Parse error. What do you mean by so far you have sent response for all messages? (cliches like "reliable product" to justify anything technical will end up diverting the focus of the discussion - and I am pretty sure we dont have marketing people participating that need to be confused with such terms. Why not be explicit?). I think the Full response will have to go; it's more there for completion sake. I cant remember why it was rejected; i know it will consume more bandwidth. It's value is in as mentioned to validate what was sent. This is derived from looking at behaviors of certain hardware. There is hardware out there (typically using CAMs) which returns you both the question asked and answer to the question. > Also, stated... > 3.xx.2.2 More than Basic > Proposed by both Weiming and Joel: Introduce RESULT TLV > to describe the results of a SET operation. The RESULT TLV will > have more data in it than what 3.2.1 is proposing. > > I don't understand the difference between this and Full response above. > Also, what does RESULT TLV look like? > The RESULT TLV is still to be defined. Joel and Weiming were both proposing it. Thanks for taking the time to read the text. It is amazing for a draft that we are trying to rush out to last call not that many people are responding. cheers, jamal ----------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com Content-Type: text/html; charset="us-ascii"
Hi All,
 
Can we make this feature configurable?  There is no doubt this feature is useful (e.g. when debuging
data connectivity problems from the application side).  It is also true you don't want to echo the
the request all the time. That could kill your bandwidth efficiency.  So,..make it configurable; so I can
turn it on when I need it.
 
Cheers,
Alex.
  
 
-----Original Message-----
From: Jamal Hadi Salim <hadi@znyx.com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Fri, 24 Jun 2005 09:11:45 -0400
Subject: Re: [issue22] Overview - Response Formatting

On Thu,
2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote:
> Jamal,
>
> I briefly looked at this...
>
> I don't agree with what is said about 3.xx.1 Full response in the
text.
> We have sent responses for all messages, its worked out very well and
> its important for building a reliable product.
>

Parse error. What do you mean by so far you have sent response for all
messages?
(cliches like "reliable product" to justify anything technical will end
up diverting the focus of the discussion -  and I am pretty sure we dont
have marketing people participating that need to be confused with such
terms. Why not be explicit?).

I think the Full response will have to go; it's more there for
completion sake. I cant remember why it was rejected; i know it will
consume more bandwidth. It's value is in as mentioned to validate what
was sent. This is derived from looking at behaviors of certain hardware.
There is hardware out there (typically using CAMs) which returns you
both the question asked and answer to the question.

> Also, stated...
> 3.xx.2.2 More than Basic
> Proposed by both Weiming and Joel: Introduce RESULT TLV
> to describe the results of a SET operation. The RESULT TLV will
> have more data in it than what 3.2.1 is proposing.
>
> I don't understand the difference between this and Full response
above.
> Also, what does RESULT TLV look like?
>

The RESULT TLV is still to be defined. Joel and Weiming were both
proposing it.

Thanks for taking the time to read the text.
It is amazing for a draft that we are trying to rush out to last call
not that many people are responding.


cheers,
jamal
----------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com-- 2005 Message-Id: Date: Fri, 24 Jun 2005 09:11:45 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue22] Overview - Response Formatting Comments: To: "Khosravi, Hormuzd M" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > I briefly looked at this... > > I don't agree with what is said about 3.xx.1 Full response in the text. > We have sent responses for all messages, its worked out very well and > its important for building a reliable product. > Parse error. What do you mean by so far you have sent response for all messages? (cliches like "reliable product" to justify anything technical will end up diverting the focus of the discussion - and I am pretty sure we dont have marketing people participating that need to be confused with such terms. Why not be explicit?). I think the Full response will have to go; it's more there for completion sake. I cant remember why it was rejected; i know it will consume more bandwidth. It's value is in as mentioned to validate what was sent. This is derived from looking at behaviors of certain hardware. There is hardware out there (typically using CAMs) which returns you both the question asked and answer to the question. > Also, stated... > 3.xx.2.2 More than Basic > Proposed by both Weiming and Joel: Introduce RESULT TLV > to describe the results of a SET operation. The RESULT TLV will > have more data in it than what 3.2.1 is proposing. > > I don't understand the difference between this and Full response above. > Also, what does RESULT TLV look like? > The RESULT TLV is still to be defined. Joel and Weiming were both proposing it. Thanks for taking the time to read the text. It is amazing for a draft that we are trying to rush out to last call not that many people are responding. cheers, jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 08:40:44 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Khosravi, Hormuzd M" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote: > Thanks for the input, Sue. > I believe we have decided to leave the SN as is and add a Correlator as > well to the header. So that should address any such requirements. > I dont know if we have heard from Weiming on this so we can close it? cheers, jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 07:59:09 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-24-06 at 07:34 -0400, Joel M. Halpern wrote: > If I understand your suggestion, you are proposing that it be possible to > add event declarations for targets without conditions. These event ids / > declarations are used only for registration (they would never appear in > notifications. No they would appear in the notification. Its up to the CE (if i understood you correctly) to map them to something meaningful. > A registration for such an event constitutes a registration for every > actual event that can be generated against the given target? > Ok, i realize i was thinking narrowly basing on the scope of what we have implemented to date. The only thing we are currently excited about as far as event is of nature (whether its ipsec, port LFB etc). Thats the only events we have. So my thoughts were along the mindset that the event type will be homogenous across the table i.e all of A, B, and C throw events and i can therefore register for 7.4 ("the table events"). If the events are not going to be homegenous then it is not worth it. If however, we can leave that up to the CE it may be worth it. > We can do that, but is it really worth it? Aggregating subscripts is both > natural and necessary, since there may be many of them, and they may be > created at any time. On the other hand, the events are known a priori to > the CE, and there are not many. The effort for the CE to register for the > events is not much harder than the effort of registering for this > aggregation event. I think we are partially agreeing: If i heard you correctly you are saying i can register for agregated events 7.1, 7.2, 7.3 and receive fine grained notifications for 7.1.1, 7.1.n etc. This i like. What i also thought i heard you say is you cant register for aggregate event 7.4 "the table events". This is where we differ (given our current implemented LFBs have homogenous event types). > And I am somewhat uncomfortable with event declarations that are not events. If 7.4 will introduce complexity to the model then i can live with the CE translating it to mean {7.1, 7.2, 7.3}. It will help to explicitly mention this in your text somewhere. It does seem to me like it would ease things for the FE if i told it about 7.4 instead, no? cheers, jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 07:34:16 -0400 From: "Joel M. Halpern" Subject: Re: Event subscription -- properties (model and protocol) Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed If I understand your suggestion, you are proposing that it be possible to add event declarations for targets without conditions. These event ids / declarations are used only for registration (they would never appear in notifications. A registration for such an event constitutes a registration for every actual event that can be generated against the given target? We can do that, but is it really worth it? Aggregating subscripts is both natural and necessary, since there may be many of them, and they may be created at any time. On the other hand, the events are known a priori to the CE, and there are not many. The effort for the CE to register for the events is not much harder than the effort of registering for this aggregation event. And I am somewhat uncomfortable with event declarations that are not events. Yours, Joel At 07:03 AM 6/24/2005, Jamal Hadi Salim wrote: >On Tue, 2005-21-06 at 12:03 -0400, Joel M. Halpern wrote: > > Sorry I was unclear. let me try an example. > > Suppose that we have an LFB. > > Suppose that it has a table X. The contents of X are a structure with > > several fields, A, B, and C. > > > > The event definitions define the path prefix 7 as meaning events. > > Event ID 1 is defined as any change on field A of an entry in table X > > (hence the specific path is 7.1.subscript) > > event ID 2 is defined as any change on field B of an entry in table X > > (hence the specific path is 7.2.subscript). > > To subscribe to changes in the A field of the third table entry, one sets > > the subscribe field of the properties of path 7.1.3. > > To subscribe to changes in the A field of any entry in table X, one sets > > the subscribe field of the properties of path 7.1 > > To subscribe to any events from the LFB, one sets the subscribe field of > > the path 7. > > > > However, there is no path to subscribe to all the events on cell 3 of > table > > X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on > table > > X (7.1 and 7.2) > > > > This is actually driven by simplicity, but makes sense to me because 7.1 > > and 7.2 are easily known by the CE, while subscribing to every entry in > the > > table individually, particularly when new entries are created, is harder. > > > >I read the originating text and since this you have an example here, >this is probably the better example to jump to. >I cant recall what our conclusion on this discussion was and i apologize >in advance if i am rehashing. >note: I agree with moving things into the properties of the events. >I also see sense in the simplicity you introduce in the agregation. > >One thing i am unsettled about still is the registration, in particular >with elements which present hierachies. > >You know at table definition time what the columns are (A, B, C in your >example) - but you dont know the subscripts. >This leads to a challenge for subscription purposes in my view and i >think hierachical/coarse registration, bits of which you have in your >other text, is a good thing; for simplicty - a very fine grained >notification detail on the other is a good thing. Let me illustrate, >using your example and draw the relationship that makes sense to me for >both registration and notification. This is not an intuitive way to show >a table, but it makes sense for the way events should be and actually it >is the way you define event paths. >I introduce event ID 4 on top of your example. > > tableX (event ID 4) > | > +-- A (event ID 1) > | | > | +-- row 1 > | | > | +-- row 2 > | | > . . > . . > | +-- row n > | > +-- B (event ID 2) > | | > | +-- row 1 > | | > | +-- row 2 > | | > . . > . . > | +-- row n > | > +-- C (event ID 3) > | > +-- row 1 > | > +-- row 2 > | > . > . > +-- row n > >Coarse Registration: >- I should be able to register to 7.1, 7.2, 7.3 or 7.4. >Note 7.4 covers the whole table (of course for event generating >elements). > >Fine grained registration: >Registering to 7.3.1 is harder in the case where the event to add such >an entry happens dynamically at the FE. It is easy to do if the CE adds >the entry for tableX, row 1. > >Notification: >Notification will always have the details of what generated the event to >the finest grained level; example 7.3.1 even though i register for 7.3 >or 7.4. > >Thoughts? > >cheers, >jamal 2005 Message-Id: Date: Fri, 24 Jun 2005 07:03:50 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Tue, 2005-21-06 at 12:03 -0400, Joel M. Halpern wrote: > Sorry I was unclear. let me try an example. > Suppose that we have an LFB. > Suppose that it has a table X. The contents of X are a structure with > several fields, A, B, and C. > > The event definitions define the path prefix 7 as meaning events. > Event ID 1 is defined as any change on field A of an entry in table X > (hence the specific path is 7.1.subscript) > event ID 2 is defined as any change on field B of an entry in table X > (hence the specific path is 7.2.subscript). > To subscribe to changes in the A field of the third table entry, one sets > the subscribe field of the properties of path 7.1.3. > To subscribe to changes in the A field of any entry in table X, one sets > the subscribe field of the properties of path 7.1 > To subscribe to any events from the LFB, one sets the subscribe field of > the path 7. > > However, there is no path to subscribe to all the events on cell 3 of table > X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on table > X (7.1 and 7.2) > > This is actually driven by simplicity, but makes sense to me because 7.1 > and 7.2 are easily known by the CE, while subscribing to every entry in the > table individually, particularly when new entries are created, is harder. > I read the originating text and since this you have an example here, this is probably the better example to jump to. I cant recall what our conclusion on this discussion was and i apologize in advance if i am rehashing. note: I agree with moving things into the properties of the events. I also see sense in the simplicity you introduce in the agregation. One thing i am unsettled about still is the registration, in particular with elements which present hierachies. You know at table definition time what the columns are (A, B, C in your example) - but you dont know the subscripts. This leads to a challenge for subscription purposes in my view and i think hierachical/coarse registration, bits of which you have in your other text, is a good thing; for simplicty - a very fine grained notification detail on the other is a good thing. Let me illustrate, using your example and draw the relationship that makes sense to me for both registration and notification. This is not an intuitive way to show a table, but it makes sense for the way events should be and actually it is the way you define event paths. I introduce event ID 4 on top of your example. tableX (event ID 4) | +-- A (event ID 1) | | | +-- row 1 | | | +-- row 2 | | . . . . | +-- row n | +-- B (event ID 2) | | | +-- row 1 | | | +-- row 2 | | . . . . | +-- row n | +-- C (event ID 3) | +-- row 1 | +-- row 2 | . . +-- row n Coarse Registration: - I should be able to register to 7.1, 7.2, 7.3 or 7.4. Note 7.4 covers the whole table (of course for event generating elements). Fine grained registration: Registering to 7.3.1 is harder in the case where the event to add such an entry happens dynamically at the FE. It is easy to do if the CE adds the entry for tableX, row 1. Notification: Notification will always have the details of what generated the event to the finest grained level; example 7.3.1 even though i register for 7.3 or 7.4. Thoughts? cheers, jamal 2005 Message-Id: Date: Thu, 23 Jun 2005 00:50:28 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue22] Overview - Response Formatting Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jamal, I briefly looked at this... I don't agree with what is said about 3.xx.1 Full response in the text. We have sent responses for all messages, its worked out very well and its important for building a reliable product. Also, stated... 3.xx.2.2 More than Basic Proposed by both Weiming and Joel: Introduce RESULT TLV to describe the results of a SET operation. The RESULT TLV will have more data in it than what 3.2.1 is proposing. I don't understand the difference between this and Full response above. Also, what does RESULT TLV look like? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Thursday, June 16, 2005 8:53 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] [issue22] Overview - Response Formatting Can we work on closing issue #22? Knocking it off will allow us to resolve a few outstanding issues. Url is: http://www.mip4.org/issues/tracker/forces/issue22 cheers, jamal 2005 Message-Id: Date: Thu, 23 Jun 2005 00:26:04 -0700 From: "Khosravi, Hormuzd M" Subject: Re: packet redirect as a core LFB Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would agree that the LFB contents for redirector LFB should be moved out of the protocol draft. The redirect message should still be there in the PL. It seems like we are all on the same page here, we should be able to close this one soon. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, June 17, 2005 6:40 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] packet redirect as a core LFB Folks, Should we be thinking of moving the redirect part out of the protocol draft as well and making it a core LFB? It could definetely be refered as a core LFB and therefore creating speacial message types for it seems a little overzelous. It may also help speedup the closure of the protocol draft. cheers, jamal 2005 Message-Id: Date: Thu, 23 Jun 2005 00:17:42 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: Susan Hares MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the input, Sue. I believe we have decided to leave the SN as is and add a Correlator as well to the header. So that should address any such requirements. Hormuzd -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com]=20 Sent: Tuesday, June 21, 2005 9:55 AM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] [issue54] correlator in the PL message header Hormuzd & All: Just in case this doesn't get covered, sequence number can have other benefits besides reliable transport. =20 The ordering of information at the application layer can enable some parallelization of functions for the control plane=20 Sue -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Khosravi, Hormuzd M Sent: Sunday, June 12, 2005 3:23 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Jamal, Do you see a good reason to keep a SN? I don't see one since the TML provides reliability. If there is another reason, let us know...otherwise we should get rid of the SN. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, June 12, 2005 8:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. >=20 Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header.=20 cheers, jamal 2005 Message-Id: Date: Tue, 21 Jun 2005 16:22:29 -0400 From: "Joel M. Halpern" Subject: Event Target Identificiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In the declaration of events, the XML has to include identification of what field is being tested for the event, and what information is to be reported. There are a number of minor issues. 1) We are not currently allowing for "and" conditions (report this event when the link has more than 3 errors per second and the usage is more than 1 megabit per second.) 2) The current proposal for naming the target and reporting fields is that each one will be a test string of the form fieldname1.fieldname2.fieldname3... where each fieldname is a valid field name in the containing context (initially, the LFB), and where if the containing context is an array then the fieldname is either a number (rare) or $digit to indicate that the event applies to all array elements. The $digit can then be used in similar strings in the reporting information. This will result in: element,arrayfield.$1.structelement (we could use local-name instead of $1, since the context implies a subscript.) We could instead get much more verbose, using more XML elements: element arrayfield local-name structelement and similar constructs for each report component. The later is more correct XML. I had originally proposed the former. Someone express a preference. Please. Joel 2005 Message-Id: Date: Tue, 21 Jun 2005 12:03:40 -0400 From: "Joel M. Halpern" Subject: Re: Event subscription -- properties (model and protocol) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sorry I was unclear. let me try an example. Suppose that we have an LFB. Suppose that it has a table X. The contents of X are a structure with several fields, A, B, and C. The event definitions define the path prefix 7 as meaning events. Event ID 1 is defined as any change on field A of an entry in table X (hence the specific path is 7.1.subscript) event ID 2 is defined as any change on field B of an entry in table X (hence the specific path is 7.2.subscript). To subscribe to changes in the A field of the third table entry, one sets the subscribe field of the properties of path 7.1.3. To subscribe to changes in the A field of any entry in table X, one sets the subscribe field of the properties of path 7.1 To subscribe to any events from the LFB, one sets the subscribe field of the path 7. However, there is no path to subscribe to all the events on cell 3 of table X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on table X (7.1 and 7.2) This is actually driven by simplicity, but makes sense to me because 7.1 and 7.2 are easily known by the CE, while subscribing to every entry in the table individually, particularly when new entries are created, is harder. Yours, Joel At 11:45 AM 6/21/2005, Putzolu, David wrote: >Hi Joel. > >I don't understand the following two sentences excerpted from >your email - they seem to contradict each other to me. Can you >elaborate a bit? > >"If the subscribe or unsubscribe is the event-base and the event-id, but > >the event is defined in terms of a table, one has subscriber or >unsubscribed to the entire table." > >vs. > >"This does not allow for subscriber or unsubscribing in one reference to > >either all events on a given table cell, or to all events on a given >table. " > >The first sentence seems to say for a table, subscribing "higher" in the >path subscribes to the whole thing. The second seems to say one cannot >subscribe to the whole thing? > >-David 2005 Message-Id: Date: Tue, 21 Jun 2005 11:26:59 -0400 From: "Joel M. Halpern" Subject: Event subscription -- properties (model and protocol) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In the last event description I sent to the list, I proposed that event information would have two IDs, one for identifying the event, and one for indicating subscription to the event. The properties information seems to create an opportunity to simplify this. And to address some of the issue of aggregate registration. Instead of declaring another ID, the subscription state of an event will be part of its properties. Thus, the properties returned for a GET-PROPERTIES operation on an event path will include the event accessibility (unsupported, supported) and the subscription state. Given that we may want to extend the subscription semantics, we will use an integer variable, with 0 meaning not subscribed, and 1 meaning subscribed. This then gives an easy way to subscribe or unsubscribe to all events from the LFB, and to all instances of a given event on a table. Remember that the event path will be event-base.event-id.subscripts (possibly with more than one subscript). The subscripts indicate which table entry the event refers to. Thus a subscriber or unsubscribe is a SET-PROPERTIES with a path. If the path is just the event-base, one has changed the subscription to all events for the LFB. If the subscribe or unsubscribe is the event-base and the event-id, but the event is defined in terms of a table, one has subscriber or unsubscribed to the entire table. This does not allow for subscriber or unsubscribing in one reference to either all events on a given table cell, or to all events on a given table. Given that presumably there are a modest number of events, it seems a good trade to aggregate the table, while requiring explicit reference to each event. Yours, Joel M. Halpern 2005 Message-Id: Date: Tue, 21 Jun 2005 11:18:58 -0400 From: "Joel M. Halpern" Subject: Properties component selection (model and protocol) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have had several discussions (mostly with Jamal) about the details of the properties approach that was discussed on the list earlier. I am going to add this to the model. Please shout on the list if any of what follows seems a bad idea. One pair of issues affects the protocol more than the model. You may recall an earlier email that discussed the issue of using a flag in the path to indiciate taht one wanted property information instead of content information. This introduced some odd ambiguities and confusion. So instead it appears to make more sense to introduce two new protocol operations, GET-PROPERTIES, and SET-PROPERTIES These will take paths and data as content just as GET and SET do. And remove the ambiguity about the path reference flag. Unfortunately, I then found a further complication. Some properties are only a single value (in a structure, for inheritance). However, some have more fields than that. Array properties have several fields. Alias properties have several fields, some writeable. So this raises the issue of access to elements of the property structure. We could declare for a read that one just gets the whole structure. But we want to be able to write certain property information. Aside: We could decide to give up on using properties for aliases, and that would remove all current writeable properties. But it is reasonable to expect them to return. In fact, I want to use them again for events. So we need writeable properties. For writing, it is clearly necessary to be able to indicate which field or fields within the property information one is trying to write. So we need another path flag. This flag is valid only within a GET-PROPERTY or SET-PROPERTY. And is not valid on path information nested within a path that has used this flag. The flag indicates that this path, and all nested paths within it are to be applied to the property information, not to the base path for selecting property information. (I currently can not imagine needing such nesting, but prohibiting it seems wrong) While this flag does have some special cases, they are at least clear. And this allows for selecting components of proprty information. 2005 Message-Id: Date: Tue, 21 Jun 2005 08:45:50 -0700 From: "Putzolu, David" Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel. I don't understand the following two sentences excerpted from=20 your email - they seem to contradict each other to me. Can you=20 elaborate a bit?=20 "If the subscribe or unsubscribe is the event-base and the event-id, but the event is defined in terms of a table, one has subscriber or=20 unsubscribed to the entire table." vs.=20 "This does not allow for subscriber or unsubscribing in one reference to either all events on a given table cell, or to all events on a given=20 table. " The first sentence seems to say for a table, subscribing "higher" in the path subscribes to the whole thing. The second seems to say one cannot subscribe to the whole thing? -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, June 21, 2005 8:27 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Event subscription -- properties (model and protocol) In the last event description I sent to the list, I proposed that event=20 information would have two IDs, one for identifying the event, and one for=20 indicating subscription to the event. The properties information seems to create an opportunity to simplify=20 this. And to address some of the issue of aggregate registration. Instead of declaring another ID, the subscription state of an event will be=20 part of its properties. Thus, the properties returned for a GET-PROPERTIES=20 operation on an event path will include the event accessibility=20 (unsupported, supported) and the subscription state. Given that we may=20 want to extend the subscription semantics, we will use an integer variable,=20 with 0 meaning not subscribed, and 1 meaning subscribed. This then gives an easy way to subscribe or unsubscribe to all events from=20 the LFB, and to all instances of a given event on a table. Remember that the event path will be event-base.event-id.subscripts=20 (possibly with more than one subscript). The subscripts indicate which=20 table entry the event refers to. Thus a subscriber or unsubscribe is a=20 SET-PROPERTIES with a path. If the path is just the event-base, one has changed the subscription to all events for the LFB. If the subscribe or unsubscribe is the event-base and the event-id, but the event is defined in=20 terms of a table, one has subscriber or unsubscribed to the entire table. This does not allow for subscriber or unsubscribing in one reference to=20 either all events on a given table cell, or to all events on a given=20 table. Given that presumably there are a modest number of events, it seems=20 a good trade to aggregate the table, while requiring explicit reference to=20 each event. Yours, Joel M. Halpern 2005 Message-Id: Date: Mon, 20 Jun 2005 11:43:19 +0800 From: "Wang,Weiming" Subject: Re: packet redirect as a core LFB MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwgYW5kIEpvZWwsDQoNCkl0IHNlZW1zIHRoYXQgd2UgYWdyZWUgd2VsbCB0aGF0IGEgcm Vk aXJlY3RvciBpbiBGRSBpcyBhbiBMRkIuIE5vdyB0aGUgb25seSBxdWVzdGlvbiBpcyBpZiB3ZS Bz aG91bGQgdXNlIGEgc3BlY2lmaWMgcmVkaXJlY3QgUEwgbWVzc2FnZSBvciBub3QuIEkgdW5kZX Jz dGFuZCBKb2VsJ3MgJ3Byb3RvY29sJyB0aG91Z2h0IGFzIHVzaW5nIHN1Y2ggUEwgbWVzc2FnZS wg d2hpbGUgSmFtYWwncyAnZXZlbnQnIHRob3VnaHQgYXMgbm90IHVzaW5nIHN1Y2ggUEwgbWVzc2 Fn ZSwgYW0gSSByaWdodD8NCg0KSXQgbGV0IG1lIGFncmVlZCB0aGUgJ2V2ZW50JyBzY2hlbWUgd2 Fz IGEgZ29vZCBzb2x1dGlvbiBmb3Igc2V2ZXJhbCBkYXlzLCBiZWZvcmUgSSBub3RpY2VkIGEgYm ln IHByb2JsZW0gd2l0aCBpdC4gVGhlIHByb2JsZW0gaXMsIGhvdyB0aGVuIHdlIHJlY29nbml6ZS B0 aGUgcmVkaXJlY3QgZGF0YSBmcm9tIGdlbmVyYWwgY29udHJvbCBkYXRhIGF0IHRoZSBUTUwgbG V2 ZWwgaWYgd2UgdXNlIGEgJ2V2ZW50JyB0byBzZW5kIHJlZGlyZWN0IGRhdGEgZnJvbSBGRSB0by BD RT8gQXMgeW91IGtub3csIHRvIHJlY29nbml6ZSBpdCBpcyBpbXBvcnRhbnQgZm9yIFRNTCB0by Bh dm9pZCBEb1MgYXR0YWNrIGZyb20gdGhlIHJlZGlyZWN0IGRhdGEuIA0KDQpUaGFua3MsDQpXZW lt aW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFkaS BT YWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gT24gRnJpLCAyMDA1LTE3LTA2IGF0IDE1OjI1IC 0w NDAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gV2UgbmVlZCB0byBkZWZpbmUgYW4gaW 50 ZXJvcGVyYWJsZSBtZWNoYW5pc20gZm9yIGZvcndhcmRpbmcgcGFja2V0cyBiZXR3ZWVuIA0KPi A+ IHRoZSBGRSBhbmQgdGhlIENFIChib3RoIGRpcmVjdGlvbnMpLiAgIA0KPiANCj4gYWdyZWVkLg 0K PiANCj4gPiBUaGlzIGlzIGEgcHJvdG9jb2wsIG5vdCBqdXN0IGFuIExGQi4gIA0KPiANCj4gQS By ZWRpcmVjdG9yIGxvb2tzIHRvIG1lIG1vcmUgbGlrZSBhbiBMRkIgdGhhbiBpdCBpcyBhIHByb3 Rv Y29sLg0KPiBDZXJ0YWlubHkgaXQgaXMgY29uZmlndXJlZCB2aWEgUEwgcHJvdG9jb2wgYW5kIG V2 ZW4gdGhvdWdoIGlzIG1vZGVsbGVkDQo+IGFzIGFuIExGQiBkb2VzbnQgaGF2ZSB0byBiZSBydW 5u aW5nIGluIHRoZSBmb3J3YXJkaW5nIHBhdGguDQo+IFtJdCBoYXMgYXR0cmlidXRlcyBzdWNoIG Fz IHdoZXJlIHRvIHNlbmQgdG8gZXRjLCB0aHJvd3MgZXZlbnRzIHN1Y2ggYXMNCj4gc2VuZGluZy B0 aG9zZSBwYWNrZXRzIHRvIHRoZSBDRSBhbmQgZGVwZW5kaW5nIG9uIGNhcGFiaWxpdHkgaXQgbW F5 IG5vdA0KPiBoYXZlIHNvbWUgZmVhdHVyZXMgZXRjXS4NCj4gT25lIGNvdWxkIGluIGZhY3QgYX Jn dWUgaXQgaXMgdHdvIExGQnMsIGEgY2xhc3NpZmllciB0aGF0IHNlbGVjdHMgYQ0KPiBwYWNrZX Qg YW5kIGFub3RoZXIgdGhhdCBzbGFwcyBhIGhlYWRlciBvbiBpdCBiZWZvcmUgc2hpcHBpbmcgaX Qu DQo+ICANCj4gPiBJdCBzZWVtcyB0byBtYWtlIG1vcmUgc2Vuc2UgaW4gdGhlIFBMIGFuZCBUTU ws IA0KPiA+IHJhdGhlciB0aGFuIGluIHNvbWUgTEZCIGRvY3VtZW50IHNvbWV3aGVyZS4NCj4gDQ o+ IFdoaWNoIHdvdWxkIGJlIGZpbmUgd2l0aCBtZS4gU2hvdWxkbnQgbWF0dGVyIHdoZXJlIGl0IG dv ZXMNCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCg== 2005 Message-Id: Date: Fri, 17 Jun 2005 23:46:53 +0800 From: Weiming Wang Subject: Re: packet redirect as a core LFB MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkknbSBhZnJhaWQgd2Ugc2hvdWxkIGF0IGxlYXN0IGhhdmUgc29tZSBmb3Jlc2 Vl aW5nIG9uIGhvdyBhIGNvcmUgTEZCIHdpbGwgZGVhbCB3aXRoIHRoZSByZWRpcmVjdGlvbiB3aX Ro b3V0IHVzaW5nIGEgc3BlY2lhbCBtZXNzYWdlIGJlZm9yZSB3ZSBkZWNpZGUgdG8gdGhyb3cgYX dh eSB0aGUgc3BlY2lhbCBtZXNzYWdlIHNjaGVtZS4gU2hhbGwgd2UgdXNlIHNvbWV0aGluZyBsaW tl IGEgcmVkaXJlY3QgZXZlbnQgbm90aWZpY2F0aW9uIHNlbnQgYnkgdGhlIGNvcmUgTEZCIG9yIG Fu eSBvdGhlciBtZWFucyB0aGVuPyANCg0KY2hlZXJzLA0Kd2VpbWluZw0KLS0tLS0gT3JpZ2luYW wg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT 4N Cg0KPiBGb2xrcywNCj4gDQo+IFNob3VsZCB3ZSBiZSB0aGlua2luZyBvZiBtb3ZpbmcgdGhlIH Jl ZGlyZWN0IHBhcnQgb3V0IG9mIHRoZSBwcm90b2NvbA0KPiBkcmFmdCBhcyB3ZWxsIGFuZCBtYW tp bmcgaXQgYSBjb3JlIExGQj8NCj4gDQo+IEl0IGNvdWxkIGRlZmluZXRlbHkgYmUgcmVmZXJlZC Bh cyBhIGNvcmUgTEZCIGFuZCB0aGVyZWZvcmUgY3JlYXRpbmcNCj4gc3BlYWNpYWwgbWVzc2FnZS B0 eXBlcyBmb3IgaXQgc2VlbXMgYSBsaXR0bGUgb3ZlcnplbG91cy4gSXQgbWF5IGFsc28NCj4gaG Vs cCBzcGVlZHVwIHRoZSBjbG9zdXJlIG9mIHRoZSBwcm90b2NvbCBkcmFmdC4NCj4gDQo+IGNoZW Vy cywNCj4gamFtYWw= 2005 Message-Id: Date: Fri, 17 Jun 2005 15:47:28 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: packet redirect as a core LFB Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-17-06 at 15:25 -0400, Joel M. Halpern wrote: > We need to define an interoperable mechanism for forwarding packets between > the FE and the CE (both directions). agreed. > This is a protocol, not just an LFB. A redirector looks to me more like an LFB than it is a protocol. Certainly it is configured via PL protocol and even though is modelled as an LFB doesnt have to be running in the forwarding path. [It has attributes such as where to send to etc, throws events such as sending those packets to the CE and depending on capability it may not have some features etc]. One could in fact argue it is two LFBs, a classifier that selects a packet and another that slaps a header on it before shipping it. > It seems to make more sense in the PL and TML, > rather than in some LFB document somewhere. Which would be fine with me. Shouldnt matter where it goes cheers, jamal 2005 Message-Id: Date: Fri, 17 Jun 2005 15:25:49 -0400 From: "Joel M. Halpern" Subject: Re: packet redirect as a core LFB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed We need to define an interoperable mechanism for forwarding packets between the FE and the CE (both directions). This is a protocol, not just an LFB. It seems to make more sense in the PL and TML, rather than in some LFB document somewhere. Yours, Joel At 09:40 AM 6/17/2005, Jamal Hadi Salim wrote: >Folks, > >Should we be thinking of moving the redirect part out of the protocol >draft as well and making it a core LFB? > >It could definetely be refered as a core LFB and therefore creating >speacial message types for it seems a little overzelous. It may also >help speedup the closure of the protocol draft. > >cheers, >jamal 2005 Message-Id: Date: Fri, 17 Jun 2005 11:58:27 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: packet redirect as a core LFB Comments: To: Weiming Wang Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-17-06 at 23:46 +0800, Weiming Wang wrote: > Jamal, > > I'm afraid we should at least have some foreseeing > on how a core LFB will deal with the redirection > without using a special message before we decide > to throw away the special message scheme. > Shall we use something like a redirect event > notification sent by the core LFB or any other means then? > By core LFB i meant it being an important LFB that must be implemented. This is in addition to the FE protocol LFB and FE Object LFB. We actually started to implement the redirect - after the discussion on the list where it is clear that we need this to be %100 compliant. This is in addition to the hardware scheme we currently use(that i described in some email). We are finding that, it infact has LFB properties. Example: - configure from CE->FE on what to filter, whether to totally redirect or just send a copy/mirror, and what port to redirect it on. - From FE->CE it is an event when a packet arrives - which is also part of the LFB definition. - Also injecting packets from the CE->FE is looked at as configure in what we are doing right now. - Capability (part of LFB definition) sounds useful too to describe what a specific redirect LFB can do etc. cheers, jamal 2005 Message-Id: Date: Fri, 17 Jun 2005 09:40:28 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: packet redirect as a core LFB Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Folks, Should we be thinking of moving the redirect part out of the protocol draft as well and making it a core LFB? It could definetely be refered as a core LFB and therefore creating speacial message types for it seems a little overzelous. It may also help speedup the closure of the protocol draft. cheers, jamal 2005 Message-Id: Date: Thu, 16 Jun 2005 22:18:55 +0800 From: Weiming Wang Subject: Re: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkZvciB0aGlzIGlzc3VlLCB0aGVyZSBzZWVtcyBvbmx5IGEgbGVmdCBxdWVzdG lv biB0aGF0IGlmIHdlIGNhbiBhdm9pZCBlbmNhcHN1bGF0aW5nIHJlZGlyZWN0ZWQgcGFja2V0cy B3 aXRoIFBMIGhlYWRlci4gQXMgZmFyIGFzIEkgY2FuIGNhdGNoLCBJIHNlZSB0aGF0IEhvcm11em Qs IEpvZWwsIGFuZCBJIGFyZSBtb3JlIHRlbmQgdG8gdXNpbmcgc3VjaCBlbmNhcHN1bGF0aW9uLC Bh bmQgeW91IGFuZCBtYXliZSBSb2JlcnQgbW9yZSB0ZW5kIG5vdCB0byB1c2UuIENvdWxkIHlvdS Bz aG93IG1vcmUgb24gdGhpcywgZXNwZWNpYWxseSB0aGUgc2NoZW1lIHlvdSB0cmllZCB0byB1c2 Ug aW4geW91ciBpbXBsZW1lbnRhdGlvbi4gSSBob3BlIHdlIGNvdWxkIGNsb3NlIHRoaXMgYWxzby Bh c2FwLg0KDQp0aGFua3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS 0g DQpGcm9tOiAiQXZyaSBEb3JpYSIgPHRyYWNrZXItZm9yY2VzQG1pcDQub3JnPg0KU3ViamVjdD og W2lzc3VlMzJdIFBhY2tldCBSZWRpcmVjdA0KDQogICAgICAgIFRob3VnaHQgMjogIFRoZXJlIG 1p Z2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQogICAgICAgICAgICAgICAgIC Ag IHJlZGlyZWN0ZWQ6IGRpcmVjdGx5IGJ5IGEgZm9yd2FyZGluZyBwYXRoLCBlLmcuLCBieQ0KIC Ag ICAgICAgICAgICAgICAgICBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiAgSW4gc3VjaCBhIGNhc2 Ug d2UgZG8gbm90DQogICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIH Nt YXJ0bmVzcy4gIFByb2JhYmx5IGEgbGluaw0KICAgICAgICAgICAgICAgICAgICBsYXllciBvci Bl dmVuIG5ldHdvcmsgbGV2ZWwgaGVhZGVyIGlzIGVub3VnaC4gIFRoZQ0KICAgICAgICAgICAgIC Ag ICAgICByZWNlaXZlciBkZW11eGVzIGl0IG9ubHkgYmFzZWQgb24gc29tZSBwcm90b2NvbCB0eX Bl DQogICAgICAgICAgICAgICAgICAgIGluIHRoZSBsaW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbn Nw b3J0IGxheWVyLiAgVGhlDQogICAgICAgICAgICAgICAgICAgIHByb3MgZm9yIHRoaXMgYXBwcm Fv Y2ggaXMgaXQgbWF5IHByb3ZpZGUgYSBmYXN0IGFuZA0KICAgICAgICAgICAgICAgICAgICBjb3 N0 LWVmZmVjdGl2ZSBwYXRoIGZvciBwYWNrZXQgcmVkaXJlY3QuICBUaGUgY29ucw0KICAgICAgIC Ag ICAgICAgICAgICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIHRoZS BG cA0KICAgICAgICAgICAgICAgICAgICByZWZlcmVuY2UgcG9pbnQgZGVmaW5pdGlvbiBpbiBGb3 JD RVMgZnJhbWV3b3JrLg0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogRWRpdG9yaWFsDQpkcmFmdD og ZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wNCm1lc3NhZ2VzOiA0OQ0Kbm9zeTogYXZyaQ0KcH Jp b3JpdHk6IE11c3QgZml4DQpzdGF0dXM6IE5vIGRpc2N1c3Npb24NCnRpdGxlOiBQYWNrZXQgUm Vk aXJlY3QNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fDQpGb3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aH R0 cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzMj4NCl9fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 2005 Message-Id: Date: Thu, 16 Jun 2005 18:33:16 +0200 From: Robert Haas Subject: Re: [issue54] correlator in the PL message header Comments: To: "Joel M. Halpern" , Weiming Wang MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The current practice seem to be for the Sequence Number (SN) in the=20 Messager Header of all Responses to be set to the same value as the SN=20 in the Message Header of the original message. Note that it is spelled=20 as a SHOULD in the draft for the Query Response and Event Notifs, and=20 not even mentioned at all for the Config Response, we need to correct=20 this ! Note that this behavior is expected at the FE AND at the CE (the CE may=20 generate Event Notification Responses). Hence what we called SN in the draft is actually used as a transaction=20 ID: it allows a response to be matched with the corresponding request,=20 and it is therefore impossible to ensure that all messages generated by=20 a sender to a receiver are numbered sequentially with this field unless=20 you exclude from the sequencing, for instance : - on the CE-to-FE direction: exclude Event Notif Responses - on the FE-to-CE direction: exclude Config and Query Responses (one=20 could choose to exclude instead the Packet Redir and Event Notification,=20 but then the Config and Query messages with ACK flag off on the CE-to-FE=20 direction must be excluded too otherwise they will create gaps on the=20 FE-to-CE direction) So, if the sequencing and transaction semantics are handled by the same=20 field (SN), then it can only apply to a subset of the messages.=20 Otherwise we have to introduce another field to handle proper sequencing=20 independently from the transaction ID, or we drop sequencing completely=20 and only keep the transaction semantics. What do you think ? Joel M. Halpern wrote: > Weiming, will it suffice for your purposes if there are two fields: > > 1) A sequence number. Filled in sequentially by the sender of the=20 > message. May be used by the receiver to detect gaps, misordering, etc. As mentioned above, this deviates from the current use of the sequence=20 number (=3Dtransaction ID). If the sequence number is now used for proper= =20 sequencing as you also seem to propose, then we have to introduce a=20 separate transaction ID. > 2) A request-ID field. On request messages, filled in by the request=20 > originator with any value suited to the requestors implementation and=20 > usage (may be a pointer, a counter, etc.) On response messages, this=20 > will be filled in with the value from the request that is being=20 > responded to? Agreed, this field remains opaque to the protocol; it is used like a=20 cookie. The only requirement is that the receiver (CE or FE) copies it=20 from requests into responses. I propose that this field is also 32 bits.=20 Note I dislike the term request-ID because it implies that each request=20 has a different ID. > > I understand that you argue that a (1) may be used to fill the purpose=20 > of (2). Can you live with two fields? > > Yours, > Joel > > PS: My personal opinion is that (1) could be covered by (2), but not=20 > the reverse. However, I can easily live with two fields. Note that I've shown above that you cannot cover (1) with (2), or only=20 for a chosen subset of the messages. 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: Thu, 16 Jun 2005 17:26:10 +0800 From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIE hh bHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpTdWJqZWN0OiBSZTogW2lzc3VlNTRdIG Nv cnJlbGF0b3IgaW4gdGhlIFBMIG1lc3NhZ2UgaGVhZGVyDQoNCg0KPiBXZWltaW5nLCB3aWxsIG l0 IHN1ZmZpY2UgZm9yIHlvdXIgcHVycG9zZXMgaWYgdGhlcmUgYXJlIHR3byBmaWVsZHM6DQo+IA 0K PiAxKSBBIHNlcXVlbmNlIG51bWJlci4gIEZpbGxlZCBpbiBzZXF1ZW50aWFsbHkgYnkgdGhlIH Nl bmRlciBvZiB0aGUgDQo+IG1lc3NhZ2UuICBNYXkgYmUgdXNlZCBieSB0aGUgcmVjZWl2ZXIgdG 8g ZGV0ZWN0IGdhcHMsIG1pc29yZGVyaW5nLCBldGMuDQo+IDIpIEEgcmVxdWVzdC1JRCBmaWVsZC 4g IE9uIHJlcXVlc3QgbWVzc2FnZXMsIGZpbGxlZCBpbiBieSB0aGUgcmVxdWVzdCANCj4gb3JpZ2 lu YXRvciB3aXRoIGFueSB2YWx1ZSBzdWl0ZWQgdG8gdGhlIHJlcXVlc3RvcnMgaW1wbGVtZW50YX Rp b24gYW5kIHVzYWdlIA0KPiAobWF5IGJlIGEgcG9pbnRlciwgYSBjb3VudGVyLCBldGMuKSAgDQ pb V2VpbWluZ10gRXZlbiBldmVudHVhbGx5IHdlIGRlY2lkZSB0byB1c2Ugc3VjaCByZXFldXN0LU lE IGZpZWxkLCBJIHN1Z2dlc3QgdGhlIHZhbHVlIGp1c3QgYmUgdmFsdWUgb2YgdGhlIHNlcXVlbm Nl IG51bWJlciBpbiB0aGUgbWVzc2FnZSwgd2hpY2ggaXMgdGhlIHNpbXBsZXN0IHdheSB0byBnZW 5l cmF0ZSB0aGUgdmFsdWUuDQoNCj5PbiByZXNwb25zZSBtZXNzYWdlcywgdGhpcyB3aWxsIGJlIA 0K PiBmaWxsZWQgaW4gd2l0aCB0aGUgdmFsdWUgZnJvbSB0aGUgcmVxdWVzdCB0aGF0IGlzIGJlaW 5n IHJlc3BvbmRlZCB0bz8NCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmd1ZSB0aGF0IG Eg KDEpIG1heSBiZSB1c2VkIHRvIGZpbGwgdGhlIHB1cnBvc2Ugb2YgDQo+ICgyKS4gIENhbiB5b3 Ug bGl2ZSB3aXRoIHR3byBmaWVsZHM/DQpDb21wYXJlZCB3aXRoIG9ubHkgb25lIGNvcnJlbGF0b3 Ig ZmllbGQsIHRoaXMgbW9yZSBmaXRzIG15IHRob3VnaHQsIHRob3VnaCBhcyBJIGFscmVheWQgYX Jn dWVkLCBpdCBzZWVtcyBhIGxpdHRsZSB0byB3YXN0ZSBzb21ldGhpbmcuDQoNClllcywgaWYgeW 91 IGFsbCB0aGluayB0aGlzIGlzICBhIGJldHRlciBzb2x1dGlvbiwgSSBjYW4gbGl2ZSB3aXRoIG l0 Lg0KDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBQUzogTXkgcGVyc29uYWwgb3BpbmlvbiBpcy B0 aGF0ICgxKSBjb3VsZCBiZSBjb3ZlcmVkIGJ5ICgyKSwgYnV0IG5vdCB0aGUgDQo+IHJldmVyc2 Uu ICBIb3dldmVyLCBJIGNhbiBlYXNpbHkgbGl2ZSB3aXRoIHR3byBmaWVsZHMuDQoNCltXZWltaW 5n XSBNeSB0aG91Z2h0IGlzIDIgY2FuIGJlIGNvdmVyZWQgYnkgMSwgYnV0IDEgY2FuIG9ubHkgcG Fy dGlhbGx5IGNvdmVyIDIuIEJ1dCBJJ20gYWZyYWlkIHRoaXMgbWF5IG9ubHkgYmUgYSBkZXNjcm lw dGlvbiBkaWZmZXJlbmNlLiBXZSBtYXkgbWVhbiB0aGUgc2FtZSB0aGluZy4gOiApDQoNClRoYW 5r cywNCldlaW1pbmcNCiANCg== 2005 Message-Id: Date: Thu, 16 Jun 2005 14:59:06 -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 Thu, 2005-16-06 at 14:34 -0400, Joel M. Halpern wrote: > I believe that the mandatory to implement standardized TML and PL must > include suitable encapsulation of redirect packets and congestion control > on their transfer. > The Source and Sink LFBs seem the right tool for the job. > > Now, someone can define an additional TML which provides what looks like > the right headers on the upper interface, but does not actually ad them to > the packet on the wire. And an FE could implement such a TML in a fashion > that did not ever try to create the headers. > But if that FE wants to interoperate with standard CEs, it also needs to > implement the mandatory-to-implement TML. Even if that requires that it > use the slow path. (That is also what one ought to expect from any FE that > claims to implement the RFCs.) > Is there any thing we can say about such a TML in the protocol draft or would that lead to confusion? cheers, jamal 2005 Message-Id: Date: Thu, 16 Jun 2005 14:34:51 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I believe that the mandatory to implement standardized TML and PL must include suitable encapsulation of redirect packets and congestion control on their transfer. The Source and Sink LFBs seem the right tool for the job. Now, someone can define an additional TML which provides what looks like the right headers on the upper interface, but does not actually ad them to the packet on the wire. And an FE could implement such a TML in a fashion that did not ever try to create the headers. But if that FE wants to interoperate with standard CEs, it also needs to implement the mandatory-to-implement TML. Even if that requires that it use the slow path. (That is also what one ought to expect from any FE that claims to implement the RFCs.) Yours, Joel At 11:04 AM 6/16/2005, Jamal Hadi Salim wrote: >On Thu, 2005-16-06 at 22:18 +0800, Weiming Wang wrote: > > Jamal, > > > > For this issue, there seems only a left question that > > if we can avoid encapsulating redirected packets with > > PL header. As far as I can catch, I see that Hormuzd, > > Joel, and I are more tend to using such encapsulation, > > and you and maybe Robert more tend not to use. Could > > you show more on this, especially the scheme you tried > > to use in your implementation. > > >The note is more on how pervasive do we want Forces to be i.e not >whether we disagree on gaving a forces redirect header. >In a minimal for interoperability, so that Roberts CE and Weimings FE >can talk nicely to each other, we MUST have the redirect header attached >by the sender so the receiver can properly intepret. Header in this case >would be the Forces redirect header. I dont think there is any >disagreement on that specific issue. At least there was never any on my >part; the other person talking about this was Furquan - who is >unfortunately away. > >On the note #32, to clarify, lets me point out the possibilities of >achieving this packet redirect between CE/FE in the real world: > >Possibility 1) If we can have the FE data path capable of attaching >Forces header/meta data and redirecting to CE - then this would be the >most effective and efficient way of doing things. Clearly you can >achieve this via a s/ware based FE or writing some NP microcode >to achieve this. > >Possibility 2) You cant redirect in the FE data path. In such a case the >second option is you are at least able to redirect to some CPU s/ware in >the FE which then wraps the Forces redirect header around such a packet >and sends it to the CE. This scheme is less effective than #1 above >mostly because most FEs out there have relatively slow CPUs that you >need to use for a lot of other things. It still, however, meets the >requirements for interoperability. Now if you cant do #1 and you cant do >#3 you are dead. You cant use such hardware for a forces FE and still >guarantee interop; but you MAY be able to still do it if you can do #3 >below. > >Possibility 3) Your FE hardware is capable of doing redirects >but not just able to add forces metadata to it. It may be able to add a >VLAN tag or something simple like that. This is very very common; a lot >of commodity ASICs and boxes can do this. In such a case if you are >configuring the FE and the CE you will need to create a mapping between >the Forces redirect header and whatever metadata that this legacy ASIC >can do. Of course both the FE and the CE would be expected to understand >such metadata translation. This is easy to do if you are creating both >the CE and the FE. >As a note: this doesnt exclude that your FE is capable of #2 above. Your >FE could be capable of #2 but you opt not to do it for efficiency >reasons (because you save CPU cycles by not sending to the CPU;->) >I claim that most people (this claim is verified by Furquan I believe) >will end up using #3. > >My concern as noted in the issue#32 is not to ignore #3 and enforce that >either #1 or #2 be used regardless. Because this will make Forces less >pervasive (trust me when i say that some people take what is written as >scripture and you fail the RFP laugh test if you dont have it >_righteously_ implemented in their definition); however, In the case of >JoeBlows FE and Weimings CE (assuming JoeBlow didnt work closely with >Weiming in building the NE) then either #1, or #2 MUST be implemented on >both sides. > >To close this issue, I was hoping to see some discussion or mention of >#3 in the draft so implementors understand it is a possibility (with the >repurcasions duly noted). > >cheers, >jamal 2005 Message-Id: Date: Thu, 16 Jun 2005 11:52:44 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: [issue22] Overview - Response Formatting Comments: cc: tracker-forces@mip4.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Can we work on closing issue #22? Knocking it off will allow us to resolve a few outstanding issues. Url is: http://www.mip4.org/issues/tracker/forces/issue22 cheers, jamal 2005 Message-Id: Date: Thu, 16 Jun 2005 11:04:23 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: Weiming Wang Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-16-06 at 22:18 +0800, Weiming Wang wrote: > Jamal, > > For this issue, there seems only a left question that > if we can avoid encapsulating redirected packets with > PL header. As far as I can catch, I see that Hormuzd, > Joel, and I are more tend to using such encapsulation, > and you and maybe Robert more tend not to use. Could > you show more on this, especially the scheme you tried > to use in your implementation. The note is more on how pervasive do we want Forces to be i.e not whether we disagree on gaving a forces redirect header. In a minimal for interoperability, so that Roberts CE and Weimings FE can talk nicely to each other, we MUST have the redirect header attached by the sender so the receiver can properly intepret. Header in this case would be the Forces redirect header. I dont think there is any disagreement on that specific issue. At least there was never any on my part; the other person talking about this was Furquan - who is unfortunately away. On the note #32, to clarify, lets me point out the possibilities of achieving this packet redirect between CE/FE in the real world: Possibility 1) If we can have the FE data path capable of attaching Forces header/meta data and redirecting to CE - then this would be the most effective and efficient way of doing things. Clearly you can achieve this via a s/ware based FE or writing some NP microcode to achieve this. Possibility 2) You cant redirect in the FE data path. In such a case the second option is you are at least able to redirect to some CPU s/ware in the FE which then wraps the Forces redirect header around such a packet and sends it to the CE. This scheme is less effective than #1 above mostly because most FEs out there have relatively slow CPUs that you need to use for a lot of other things. It still, however, meets the requirements for interoperability. Now if you cant do #1 and you cant do #3 you are dead. You cant use such hardware for a forces FE and still guarantee interop; but you MAY be able to still do it if you can do #3 below. Possibility 3) Your FE hardware is capable of doing redirects but not just able to add forces metadata to it. It may be able to add a VLAN tag or something simple like that. This is very very common; a lot of commodity ASICs and boxes can do this. In such a case if you are configuring the FE and the CE you will need to create a mapping between the Forces redirect header and whatever metadata that this legacy ASIC can do. Of course both the FE and the CE would be expected to understand such metadata translation. This is easy to do if you are creating both the CE and the FE. As a note: this doesnt exclude that your FE is capable of #2 above. Your FE could be capable of #2 but you opt not to do it for efficiency reasons (because you save CPU cycles by not sending to the CPU;->) I claim that most people (this claim is verified by Furquan I believe) will end up using #3. My concern as noted in the issue#32 is not to ignore #3 and enforce that either #1 or #2 be used regardless. Because this will make Forces less pervasive (trust me when i say that some people take what is written as scripture and you fail the RFP laugh test if you dont have it _righteously_ implemented in their definition); however, In the case of JoeBlows FE and Weimings CE (assuming JoeBlow didnt work closely with Weiming in building the NE) then either #1, or #2 MUST be implemented on both sides. To close this issue, I was hoping to see some discussion or mention of #3 in the draft so implementors understand it is a possibility (with the repurcasions duly noted). cheers, jamal 2005 Message-Id: Date: Thu, 16 Jun 2005 01:50:07 +0800 From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSG Fk aSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gT24gV2VkLCAyMDA1LTE1LTA2IGF0IDEwOj Q0 ICswMjAwLCBSb2JlcnQgSGFhcyB3cm90ZToNCj4gDQo+ID4gTWF5YmUgSSBkaWQgbm90IHVuZG Vy c3RhbmQgeW91ciBwb2ludCwgc28gbGV0J3MgdGFrZSBhIGNvbmNyZXRlIGV4YW1wbGU6DQo+IA 0K PiBbLi5dDQo+IFNvIGhlcmVzIGFuIGV4YW1wbGUgd2hlcmUgdGhlIHNlY29uZCAxNi8zMi1iaX Qg bnVtYmVyIHdpbGwgYmUgdXNlZnVsLg0KPiBUaGlzIHdhcyBhY3R1YWxseSB3ZWxsIHN1bW1hcm l6 ZWQgYnkgSm9lbCdzIG9uZSBwYXJhZ3JhcGhbMV0sIEkgYW0NCj4gaG9waW5nIHRoaXMgbWF5IG Fj dHVhbGx5IGhlbHAgcmF0aGVyIHRoYW4gY2F1c2UgY29uZnVzaW9uIDstPi4gVGhpcyBpcw0KPi B0 aGUgY2xvc2VzdCBpIGNhbiBnZXQgdG8gdGhlIHByb2JsZW0gbmV0bGluayBpcyBmYWNpbmcgdG 9k YXkuDQo+IA0KPiBUYWtlIGFuIGltcGxlbWVudGF0aW9uIHdoaWNoIGRvZXMgdGhlIGZvbGxvd2 lu ZzoNCj4gDQo+IE9uIHRoZSBDRSwgaXQgaGFzIHR3byBjb25uZWN0aW9ucyBiZXR3ZWVuIHRoZS BQ TCBhbmQgdGhlIFRNTA0KPiAobGV0cyBtYWtlIG5vIGFzc3VtcHRpb25zIG9mIHdoZXRoZXIgdG hl cmUgYXJlIGlzIG9uZSBvciBtb3JlDQo+IHByb2Nlc3Nlcy90YXNrcykuDQo+IE9uIHRoZSBGRS Ao YXNzdW1pbmcgZGlmZmVyZW50IHZlbmRvciBmcm9tIHRoZSBDRSksIHRoZSBpbXBsZW1lbnRhdG lv bg0KPiBoYXMgb25seSBvbmUgUEwtVE1MIGNvbm5lY3Rpb24uDQo+IA0KPiBPbiB0aGUgQ0UsIH Nv bWV0aGluZyBhdCBQTCBzZW5kcyBhIG1lc3NhZ2UgdmlhIG9uZSBvZiB0aGUgdHdvIFBMIGxldm Vs DQo+IGNvbm5lY3Rpb25zIHRvIHRoZSBDRSAtIGNhbGwgaXQgY29ubmVjdGlvbiBZIChhbmQgdG hl IG90aGVyIGlzDQo+IGNvbm5lY3Rpb24gWikuDQo+IFNvIFRNTCBncmFicyB0aGlzIG1lc3NhZ2 Us IHNlbmRzIGl0IHRvIHRoZSBjb3JyZWN0IEZFIGJhc2VkIG9uIEZFSUQuDQo+IEZFIHJlc3Bvbm Rz IGJhY2suIFRNTCBncmFicyByZXNwb25zZSBhbmQgbm93IGhhcyB0byBtdXggaXQgdG8gdGhlDQ o+ IGNvcnJlY3QgUEwgY29ubmVjdGlvbi4gSG93IGRvZXMgaXQgZG8gdGhpcz8NCg0KRmlyc3RseS wg SSdtIG5vdCBzdXJlIGlmIHRoZSB0d28gUEwtVE1MIGNvbm5lY3Rpb25zIGFjdHVhbGx5IGltcG x5 LCBkbyB5b3UgaW1wbHkgdGhleSdsIGhhdmUgZGlmZmVyZW50IGFuZCBpbmRlcGVuZGFudCBTTi Bv ciBjb3JyZWxhdG9yIGdlbmVyYXRvcj8gSSBzdXBwb3NlIGVpdGhlciBTTiBvciBjb3JyZWxhdG 9y IHNob3VsZCBhbGwgYmUgY29uc2lzdGVudGx5IG1haW50YWluZWQgYnkgb25lIFBMIGNvcmUuDQ oN ClNlY29uZGx5LCBJIGRvbid0IHNlZSBhbnkgZGlmZmljdWx0eSB0byBkZW11eCByZXNwb25zZX Mg aW4gc3VjaCBjYXNlLiBJdCdzIGp1c3QgYnkgdGhlIFNOIGZpZWxkIHdoaWNoIGFjdHMgYXMgYS Bj b3JyZWxhdG9yLCBjb25zaWRlcmluZyBjb3JyZWxhdG9ycyBnZW5lcmF0ZWQgYnkgdGhlIFBMIG Nv cmUgYXJlIGFsd2F5cyBpbiB0aGlzIGNhc2UuIE1heWJlIEkgc3RpbGwgbWlzcyBzb21ldGhpbm c/ DQoNCj4gDQo+IE9uZSBhbnN3ZXIgaXMgdGhlIFRNTCBtYWludGFpbnMgYSBsb3Qgb2YgUEwgbG V2 ZWwga25vd2xlZGdlLiBCdXQgdGhpcyBpcw0KSSBhY3R1YWxseSB0aGluayBzdWNoIGRlbXV4IH No b3VsZCBiZSBkb25lIGJ5IGEgdW5pcXVlIFBMIGNvcmUgcmF0aGVyIHRoYW4gYnkgVE1MKHMpLi AN Cg0KPiBjbGVhcmx5IGJhZCBhYnN0cmFjdGlvbi4gQW5vdGhlciBhbnN3ZXIgaXMgdG8gdGVsbC B0 aGUgaW1wbGVtZW50b3INCj4gIm5vIHlvdSBjYW50IGRvIHRoYXQgLSB0aG91IHNoYWx0IGltcG xl bWVudCBhIHNpbmdsZSBwcm9jZXNzIi4gVGhhdHMgYQ0KPiBiYWQgdGhpbmcgdG8gc2F5IGJlY2 F1 c2UgaXQgbWF5IGxpbWl0IHRoZSBpbXBsZW1lbnRhdGlvbiBvbmx5IHRvIHNvbWUNCj4gc3BlY2 lm aWMgT1NlcyBvciBpdCBtYXkgbWFrZSBmb3IgYW4gaW5lZmZpY2llbnQgaW1wbGVtZW50YXRpb2 4g b24gc29tZQ0KPiBPU2VzLiBJIGNvdWxkIGdpdmUgYSBmZXcgbW9yZSB3YXlzIHRvIGltcGxlbW Vu dCB0aGlzIC0gbm9uZSB3aGljaCBhcmUNCj4gImNsZWFuIi4gDQo+IA0KPiBPdXIgaW1wbGVtZW 50 YXRpb24gYXQgdGhlIG1vbWVudCB3b3JrcyBmaW5lIGJlY2F1c2Ugd2UgaGF2ZSBhIHNpbmdsZQ 0K PiBwcm9jZXNzL3Rhc2sgd2hlcmUgYWxsIFBMIG1lc3NhZ2VzIGdldCBtdXhlZCB0byBhbmQgYS Bz aW5nbGUgUEwtVE1MDQo+IGNvbm5lY3Rpb24uIA0KVGhlcmUgbWlnaHQgYmUgbXVsdGlwbGUgUE wt VE1MIHRocmVhZHMgY3JlYXRlZCwgYnV0IHRoZXNlIHRocmVhZHMgc2hvdWxkIGJlIGFsbCB1bm Rl ciBjb250cm9sIG9mIG9ubHkgb25lIHByb2Nlc3MsIHRoYXQgaXMsIHRoZSBjb3JlIFBMIHByb2 Nl c3MuIFRvIHRyeSB0byBwYXJhbGxlbGl6ZSB0aGUgY29yZSBwcm9jZXNzIG1heSBiZSB2ZXJ5IG Rp ZmZpY3V0IGFuZCBtYXkgYWxzbyBiZSBwcm9ibGVtYXRpYy4gT2YgY291cnNlLCB0aGVyZSBtYX kg YmUgbXVsdGlwbGUgUEwgYXBwbGljYXRpb24gcHJvY2Vzc2VzIHRob3VnaC4gDQoNClRoYW5rcy wN CldlaW1pbmcNCg0KPldlIGNhbiB0aGVyZWZvcmUgbGl2ZSB3aXRoIHRoZSBjb21tYW5kIGNvcm Vs YXRvciBiZWluZyB0aGUNCj4gc2VxdWVuY2UgbnVtYmVyLiBQZXJoYXBzIHdoYXQgd2UgbmVlZC B0 byBjYWxsIHRoZSBvdGhlciBudW1iZXIgaXMNCj4gcHJvY2VzcyBjb3JyZWxhdG9yIG9yIGNvbn Rl eHQ/IE1heWJlIGl0cyBhbGwgaW4gdGhlIG5hbWluZz8gDQo+IA0KPiBjaGVlcnMsDQo+IGphbW Fs DQo+IA0KPiBbMV0gDQo+ICJBIFNlcXVlbmNlIG51bWJlciBzaG91bGQgaGF2ZSBhIGRpZmZlcm Vu dCBzZXF1ZW50aWFsIHZhbHVlIGhhcyBJIGhhbmQgDQo+IG1lc3NhZ2VzIGZyb20gdGhlIFBMIH Rv IHRoZSBUTUwuDQo+IEEgY29ycmVsYXRvciBzaG91bGQgaGF2ZSBkaXN0aW5jdCB2YWx1ZXMgZm 9y IGRpc3RpbmN0IHJlcXVlc3RzLCBhbmQNCj4gcmVwbGllcyBzaG91bGQgaGF2ZSB0aGUgdmFsdW Ug ZnJvbSB0aGUgcmVxdWVzdC4NCj4gVGhlc2UgYXJlIG5vdCB0aGUgc2FtZSBwcm9wZXJ0eS4gIF Ro ZXkgbWF5IGV2ZW4gYmUgaW4gY29uZmxpY3QuIg== 2005 Message-Id: Date: Thu, 16 Jun 2005 01:19:20 +0800 From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpUaGFua3MgZm9yIGEgbW9yZSBkZXRhaWxlZCBleHBsYWluYXRpb24uDQoNCi 0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUm9iZXJ0IEhhYXMiIDxyaGFAen Vy aWNoLmlibS5jb20+DQoNCldlaW1pbmcsDQoNCk1heWJlIEkgZGlkIG5vdCB1bmRlcnN0YW5kIH lv dXIgcG9pbnQsIHNvIGxldCdzIHRha2UgYSBjb25jcmV0ZSBleGFtcGxlOg0KDQotPiByZXF1ZX N0 IGZyb20gQ0UgdG8gRkUsIFNOIDUNCjwtIHJlc3BvbnNlIGZyb20gRkUgdG8gQ0UsIFNOIDUgKD Ug aXMgaW1wb3NlZCBieSB0aGUgQ0UsIG5lY2Vzc2FyeSBmb3IgDQpjb3JyZWxhdGlvbiBhbmQvb3 Ig c2VxdWVuY2luZyByZWFzb25zKQ0KLT4gcmVxdWVzdCBmcm9tIENFIHRvIEZFLCBTTiA2IChBQ0 sg ZmxhZyBvZmYpDQpubyByZXNwb25zZSBmcm9tIEZFIHRvIENFDQotPiByZXF1ZXN0IGZyb20gQ0 Ug dG8gRkUsIFNOIDcNCjwtIHJlc3BvbnNlIGZyb20gRkUgdG8gQ0UsIFNOIDcNCi4uLiBzbyB5b3 Ug c2VlIGFib3ZlIHRoYXQgdGhlIENFIHdvdWxkIGhhdmUgdG8gZXhwZWN0IGhvbGVzIGluIHRoZS AN CnNlcXVlbmNlIG51bWJlcnMgY29taW5nIGJhY2sgZnJvbSB0aGUgRkUuDQpbV2VpbWluZ11JIG Fn cmVlIHRoZXJlIGlzIGEgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmcgdG8gc3VjaCBhIGNhc2UuIE kg ZG9uJ3QgdGhpbmsgdGhlIHJlc3BvbnNlIG1lc3NhZ2Ugd2lsbCAgcmVzdWx0IGluIGEgc2VxdW Vu Y2UgbnVtYmVyIGhvbGUgZm9yIHRoZSBDRSwgYmVjYXVzZSBJIG9ubHkgZXhwZWN0IHRvIGRlZm lu ZSBhIHNlcXVlbmNlIG51bWJlciB0aGF0IGlzIHVzZWQgdG8gbWFyayB0aGUgb3JkZXIgb2YgbW Vz c2FnZXMgdGhlIENFIG9yaWdpbmFsbHkgZ2VuZXJhdGVzICwgd2hpY2ggc2hvdWxkIGV4Y2x1ZG Ug cmVzcG9uc2UgbWVzc2FnZXMuICBJbiBhbm90aGVyIHdvcmQsIHdlIHdpbGwgZGVmaW5lIHRoYX Qg cmVzcG9uc2UgbWVzc2FnZXMgb25seSB0YWtlIGEgZmllbGQgdGhhdCBpcyBvbmx5IGZvciBjb3 Jy ZWxhdGluZy4gWWVzLCBzdWNoIGEgZGVmaW5pdGlvbiBvZiBhIFNOIHdpbGwgYmUgcHJvYmxlbW F0 aWMgaWYgdGhlIFNOIGhhdmUgdG8gYmUgdXNlZCBieSBUTUwgZm9yIFRNTCBsZXZlbCBmbG93IG Nv bnRyb2wsIGJ1dCBzdWNoIFNOIHVzYWdlIGhhcyBhbHJlYWR5IGJlZW4gZXhjbHVkZWQuICBXZS Bv bmx5IGxlYXZlIFNOIGZvciBQTCBsZXZlbCB1c2UuIE15IHRob3VnaHQgaXMgc3VjaCBTTiBpcy B1 c2VmdWwgYW5kIGlzIGFsc28gZW5vdWdoLiANCg0KLi4uIGJ1dCBpbiBhZGRpdGlvbiwgdGhlcm Ug aXMgYW5vdGhlciBwYXJhbGxlbCBzZXF1ZW5jZSB0aGF0IHRoZSBDRSBoYXMgDQp0byBkaXN0aW 5n dWlzaDoNCi0+IHBhY2tldCByZWRpcmVjdCBtZXNzYWdlcyBhbmQvb3IgZXZlbnQgbm90aWZpY2 F0 aW9ucyBhcmUgc2VudCBmcm9tIEZFIA0KdG8gQ0UsIFNOIDExLCAxMiwgMTMsIDE0IC4uLiAoZG Vj aWRlZCBieSB0aGUgRkUpDQouLi4gdGhpcyBtZWFucyB0aGF0LCBpbiBhZGRpdGlvbiB0byB0aG Ug YWRkZWQgY29tcGxleGl0eSBvZiBtYWludGFpbmluZyANCnR3byBwYXJhbGxlbCBzZXF1ZW5jZX Ms IHlvdSBjYW5ub3QgZW5mb3JjZSBhbnkgb3JkZXJpbmcgYmV0d2VlbiB0aGUgDQpjb21tYW5kIH Jl c3BvbnNlcyBhbmQgdGhlIHBhY2tldCByZWRpcmVjdGlvbi9ldmVudCBub3RpZmljYXRpb25zIC g9 Ym90aCANCnNlcXVlbmNlcyBhcmUgaW5kZXBlbmRlbnQpLg0KW1dlaW1pbmddIE5vdGUgdGhhdC B3 ZSBhbHNvIGhhdmUgdG8gbWFpbnRhaW4gdHdvIGNvcnJlbGF0b3JzLCBvbmUgaXMgZm9yIENFIG Fu ZCBhbm90aGVyIGlzIGZvciBGRSwgdGhlcmVmb3JlLCB0byBoYXZlIHR3byBTTiBwYXJhbGxlbG x5 IG1haW50YWluZWQgc2VlbXMgdW5hdm9pZGFibGUuICBNb3Jlb3ZlciwgaWYgd2Ugc2VwYXJhdG Ug Y29ycmVsYXRvciBmcm9tIFNOLCB3ZSB0aGVuIG5lZWQgdG8gbWFpbnRhaW4gZm91ciBwYXJhbW V0 ZXJzIGZvciB0aGVtLiAgVG8gIG1lcmdlIGNvcnJlbGF0b3IgYW5kIFNOIHRvZ2V0aGVyIGlzIG Fj dHVhbGx5IGEgdmVyeSBzaW1wbGUgdHJlYXRtZW50LCB0aGF0IGlzLCB0byBsZXQgYSBjb3JyZW xh dG9yIGJlIGdlbmVyYXRlZCBzZXF1ZW50aWFsbHkgcmF0aGVyIHRoYW4gcmFuZG9tbHksIHdpdG hv dXQgYWRkaW5nIGFueSBvdGhlciBjb21wbGV4aXR5LCB3aGVyZWFzIGJlbmlmaXRzIGZyb20gIG l0 IGlzIGdyZWF0OiB0byBlYXNlIHRoZSBnZW5lcmF0aW9uIG9mIGEgY29ycmVsYXRvciBpbiBzb2 1l IHdheSBhcyB3ZWxsIGFzIHByb3ZpZGluZyBhIHNlcXVlbnRpYWwgaW5mb3JtYXRpb24gZm9yIH Nv cnRzIG9mIG1lc3NhZ2VzLCB3aGljaCBhcmUgdXNlZnVsIGluIHNvbWUgY2FzZXMuDQoNCk1vcm Vv dmVyLCBjb25zaWRlciB0aGUgY2FzZSBmb3Igd2hpY2ggdGhlIENFIGlzIHBpcGVsaW5pbmcgY2 9t bWFuZHMgDQooPXNlbmRpbmcgbW9yZSB0aGFuIG9uZSBjb21tYW5kIGF0IGEgdGltZSwgaS5lLi wg bm90IHdhaXRpbmcgZm9yIGVhY2ggDQpyZXNwb25zZSBiZWZvcmUgc2VuZGluZyB0aGUgbmV4dC Bj b21tYW5kKSwgdGhlbiB0aGluZ3MgYmVjb21lIHJlYWxseSANCmhhaXJ5IC4uLg0KW1dlaW1pbm dd IEFzIEkgbWVudGlvbmVkLCBpbiB0aGlzIGNhc2UsIHdlIHNob3VsZCBkZWZpbmUgdG8gbGV0IH Ro ZSByZXNwb25zZSBTTiAoYXMgdGhlIGNvcnJlbGF0b3IpIGVpdGhlciB3aXRoIHRoZSBwaXBlbG lu ZWQgY29tbWFuZHMnIGZpcnN0IG1lc3NhZ2Ugb3IgbGFzdCBtZXNzYWdlLiBGb3IgaW5zdGFuY2 Us IA0KMS4gQ0Ugc2VuZHMgYSBwaXBlbGluZSBtZXNzYWdlIHdpdGggU04gb2YgMjEsIDIyLCAyMy wg MjQsIDI1LCB0aGVuIHdhaXQgZm9yIHRoZSBjb21taXRtZW50IHJlc3BvbnNlIGZvciB0aGUgZX hj dXRpb24uDQoyLiBGRSB0aGVuIG1heSBlaXRoZXIgcmVzcG9uc2UgYSBtZXNzYWdlIHdpdGggU0 49 MjEsIG9yIFNOPTI1LCBqdXN0IGFzIHdlJ2QgbGlrZSB0byBkZWZpbmUuIFBlcnNvbmFsbHkgSS B0 aGluayB0byBkZWZpbmUgdGhlIGxhc3QgU04gYXMgdGhlIGJhdGNoIHJlc3BvbnNlIG1heSBiZS Bi ZXR0ZXIuDQoNClRoYW5rcywNCldlaW1pbmcNCg== 2005 Message-Id: Date: Wed, 15 Jun 2005 14:56:11 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-16-06 at 01:50 +0800, Weiming Wang wrote: > Firstly, I'm not sure if the two PL-TML connections actually > imply, do you imply they'l have different and independant SN or > correlator generator? I suppose either SN or correlator should > all be consistently maintained by one PL core. > > Secondly, I don't see any difficulty to demux responses in such > case. It's just by the SN field which acts as a correlator, considering > correlators generated by the PL core are always in this case. Maybe I > still miss something? [..] > > Our implementation at the moment works fine because we have a single > > process/task where all PL messages get muxed to and a single PL-TML > > connection. > There might be multiple PL-TML threads created, but these threads > should be all under control of only one process, that is, the core > PL process. Yes, thats how we do it in our implementation today (i.e with one process)- what worries me is the enforcement of such implementation. Robert and I have come up with two different approaches on how to implement: i would say it is therefore insufficient to say there would be one "core PL" mux point since his approach is to implement one process per LFB. Unless, that is, we are willing to sign on it and say "you will only implement this way". If we are going to say that we should say it in the draft. Then i will be sure my FE will interop with Roberts CE. The reason is: We actually may have more than one app on the CE which _in my view_ may have totaly independent things they configure at the FE. And in my view, each such app should be able to use Forces as a transport and not need to coordinate any sequence numbers. If you call each app a context, then the correlator maps to the context. And in each context the whole range of sequence numbers (I am begining to think this is a bad name) is available. For our implementation, the only value such a context correlator would add is reduced state at the CE. For Roberts, it would i suppose complete his. cheers, jamal 2005 Message-Id: Date: Wed, 15 Jun 2005 14:41:44 -0400 From: "Joel M. Halpern" Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Weiming, will it suffice for your purposes if there are two fields: 1) A sequence number. Filled in sequentially by the sender of the message. May be used by the receiver to detect gaps, misordering, etc. 2) A request-ID field. On request messages, filled in by the request originator with any value suited to the requestors implementation and usage (may be a pointer, a counter, etc.) On response messages, this will be filled in with the value from the request that is being responded to? I understand that you argue that a (1) may be used to fill the purpose of (2). Can you live with two fields? Yours, Joel PS: My personal opinion is that (1) could be covered by (2), but not the reverse. However, I can easily live with two fields. 2005 Message-Id: Date: Wed, 15 Jun 2005 12:51:59 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: Robert Haas Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Wed, 2005-15-06 at 10:44 +0200, Robert Haas wrote: > Maybe I did not understand your point, so let's take a concrete example: [..] So heres an example where the second 16/32-bit number will be useful. This was actually well summarized by Joel's one paragraph[1], I am hoping this may actually help rather than cause confusion ;->. This is the closest i can get to the problem netlink is facing today. Take an implementation which does the following: On the CE, it has two connections between the PL and the TML (lets make no assumptions of whether there are is one or more processes/tasks). On the FE (assuming different vendor from the CE), the implementation has only one PL-TML connection. On the CE, something at PL sends a message via one of the two PL level connections to the CE - call it connection Y (and the other is connection Z). So TML grabs this message, sends it to the correct FE based on FEID. FE responds back. TML grabs response and now has to mux it to the correct PL connection. How does it do this? One answer is the TML maintains a lot of PL level knowledge. But this is clearly bad abstraction. Another answer is to tell the implementor "no you cant do that - thou shalt implement a single process". Thats a bad thing to say because it may limit the implementation only to some specific OSes or it may make for an inefficient implementation on some OSes. I could give a few more ways to implement this - none which are "clean". Our implementation at the moment works fine because we have a single process/task where all PL messages get muxed to and a single PL-TML connection. We can therefore live with the command corelator being the sequence number. Perhaps what we need to call the other number is process correlator or context? Maybe its all in the naming? cheers, jamal [1] "A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict." 2005 Message-Id: Date: Wed, 15 Jun 2005 10:44:22 +0200 From: Robert Haas Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Weiming, Weiming Wang wrote: >Robort, > >----- Original Message -----=20 >From: "Robert Haas" > >Weiming, >I agree with 1 and 2, but I would not merge the two into the same=20 >sequence number concept. As an example, according to your suggestion,=20 >event notifications and packet redirections should be numbered according= =20 >to a different sequence than response messages for which the numbering=20 >is imposed by the CE.=20 >[Weiming] I didn't think like this. Why the response message should be= numbered by an CE here? =20 > > =20 > Maybe I did not understand your point, so let's take a concrete example: -> request from CE to FE, SN 5 <- response from FE to CE, SN 5 (5 is imposed by the CE, necessary for=20 correlation and/or sequencing reasons) -> request from CE to FE, SN 6 (ACK flag off) no response from FE to CE -> request from CE to FE, SN 7 <- response from FE to CE, SN 7 ... so you see above that the CE would have to expect holes in the=20 sequence numbers coming back from the FE. ... but in addition, there is another parallel sequence that the CE has=20 to distinguish: -> packet redirect messages and/or event notifications are sent from FE=20 to CE, SN 11, 12, 13, 14 ... (decided by the FE) ... this means that, in addition to the added complexity of maintaining=20 two parallel sequences, you cannot enforce any ordering between the=20 command responses and the packet redirection/event notifications (=3Dboth= =20 sequences are independent). Moreover, consider the case for which the CE is pipelining commands=20 (=3Dsending more than one command at a time, i.e., not waiting for each=20 response before sending the next command), then things become really=20 hairy ... Please send a concrete example to describe how you propose to operate. Regards, -Robert >So the CE would have to maintain two independent=20 >parallel sequences. This is unnecessary complexity to me. >[Weiming] I may miss something, but what I think of for this case is we = never have two sequences to maintain in one same CE or FE. We only have= one SN for one CE and one SN for one FE. Note that we don't need to main= tain a SN for any response messages then.=20 > >Thanks, >Weiming > >Regards, >-Robert > >Weiming Wang wrote: > > =20 > >>My opinion is: >> >>1. Function to correlate a request to a response is necessary. >> Seems no one objecting to this. >> >>2. PL message sequential numbering is also necessary >> One of the reason now I can think of is for packet redirect message= s. Note that we haven't make a reliability reqirement for packet redirect= ion, while the sequence of redirected packets are useful for these packet= s applications. >> >>3. It can fulfill the function 1) well by defining that a response mess= age should always have the same SN with the request to reply, hence we on= ly need one field that is called sequence number.=20 >> >>P.S.=20 >>1. Sequence number should be maintained per CE and FE separately, and t= he message type uniquely recognize a message as a response message, there= fore there will be no opaque in the Sequence number maintaince.=20 >>2. Sequence number of an event from FE is generated by the FE, while re= sponse of the event (if any) should have the same sequence number as the = event to response.=20 >>3. A response to batching messages to meet two-phase-commits will have = the same SN as that of the first message or the last message in the batch= , just as what we'd like to define. >> >>Thanks, >>Weiming >> >> >>=20 >> >> =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: Wed, 15 Jun 2005 08:55:15 +0800 From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header Comments: To: Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Um9ib3J0LA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvYmVydC BI YWFzIiA8cmhhQHp1cmljaC5pYm0uY29tPg0KDQpXZWltaW5nLA0KSSBhZ3JlZSB3aXRoIDEgYW 5k IDIsIGJ1dCBJIHdvdWxkIG5vdCBtZXJnZSB0aGUgdHdvIGludG8gdGhlIHNhbWUgDQpzZXF1ZW 5j ZSBudW1iZXIgY29uY2VwdC4gQXMgYW4gZXhhbXBsZSwgYWNjb3JkaW5nIHRvIHlvdXIgc3VnZ2 Vz dGlvbiwgDQpldmVudCBub3RpZmljYXRpb25zIGFuZCBwYWNrZXQgcmVkaXJlY3Rpb25zIHNob3 Vs ZCBiZSBudW1iZXJlZCBhY2NvcmRpbmcgDQp0byBhIGRpZmZlcmVudCBzZXF1ZW5jZSB0aGFuIH Jl c3BvbnNlIG1lc3NhZ2VzIGZvciB3aGljaCB0aGUgbnVtYmVyaW5nIA0KaXMgaW1wb3NlZCBieS B0 aGUgQ0UuIA0KW1dlaW1pbmddIEkgZGlkbid0ICAgdGhpbmsgbGlrZSB0aGlzLiBXaHkgdGhlIH Jl c3BvbnNlIG1lc3NhZ2Ugc2hvdWxkIGJlIG51bWJlcmVkIGJ5IGFuIENFIGhlcmU/ICANCg0KU2 8g dGhlIENFIHdvdWxkIGhhdmUgdG8gbWFpbnRhaW4gdHdvIGluZGVwZW5kZW50IA0KcGFyYWxsZW wg c2VxdWVuY2VzLiBUaGlzIGlzIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkgdG8gbWUuDQpbV2VpbW lu Z10gSSBtYXkgbWlzcyBzb21ldGhpbmcsIGJ1dCB3aGF0IEkgdGhpbmsgb2YgZm9yIHRoaXMgY2 Fz ZSBpcyB3ZSBuZXZlciBoYXZlIHR3byBzZXF1ZW5jZXMgdG8gbWFpbnRhaW4gaW4gb25lIHNhbW Ug IENFIG9yIEZFLiAgV2Ugb25seSBoYXZlIG9uZSBTTiBmb3Igb25lIENFIGFuZCBvbmUgU04gZm 9y IG9uZSBGRS4gTm90ZSB0aGF0IHdlIGRvbid0IG5lZWQgdG8gbWFpbnRhaW4gYSBTTiBmb3IgYW 55 IHJlc3BvbnNlIG1lc3NhZ2VzIHRoZW4uIA0KDQpUaGFua3MsDQpXZWltaW5nDQoNClJlZ2FyZH Ms DQotUm9iZXJ0DQoNCldlaW1pbmcgV2FuZyB3cm90ZToNCg0KPk15IG9waW5pb24gaXM6DQo+DQ o+ MS4gIEZ1bmN0aW9uIHRvIGNvcnJlbGF0ZSBhIHJlcXVlc3QgdG8gYSByZXNwb25zZSBpcyBuZW Nl c3NhcnkuDQo+ICAgIFNlZW1zIG5vIG9uZSBvYmplY3RpbmcgdG8gdGhpcy4NCj4NCj4yLiBQTC Bt ZXNzYWdlIHNlcXVlbnRpYWwgbnVtYmVyaW5nIGlzIGFsc28gbmVjZXNzYXJ5DQo+ICAgIE9uZS Bv ZiAgdGhlIHJlYXNvbiBub3cgSSBjYW4gdGhpbmsgb2YgaXMgZm9yIHBhY2tldCByZWRpcmVjdC Bt ZXNzYWdlcy4gTm90ZSB0aGF0IHdlIGhhdmVuJ3QgbWFrZSBhIHJlbGlhYmlsaXR5IHJlcWlyZW 1l bnQgZm9yIHBhY2tldCByZWRpcmVjdGlvbiwgd2hpbGUgdGhlIHNlcXVlbmNlIG9mIHJlZGlyZW N0 ZWQgcGFja2V0cyBhcmUgdXNlZnVsIGZvciB0aGVzZSBwYWNrZXRzIGFwcGxpY2F0aW9ucy4NCj 4N Cj4zLiBJdCBjYW4gZnVsZmlsbCB0aGUgZnVuY3Rpb24gMSkgd2VsbCBieSBkZWZpbmluZyB0aG F0 IGEgcmVzcG9uc2UgbWVzc2FnZSBzaG91bGQgYWx3YXlzIGhhdmUgdGhlIHNhbWUgU04gd2l0aC B0 aGUgcmVxdWVzdCB0byByZXBseSwgaGVuY2Ugd2Ugb25seSBuZWVkIG9uZSBmaWVsZCB0aGF0IG lz IGNhbGxlZCBzZXF1ZW5jZSBudW1iZXIuIA0KPg0KPlAuUy4gDQo+MS4gU2VxdWVuY2UgbnVtYm Vy IHNob3VsZCBiZSBtYWludGFpbmVkIHBlciBDRSBhbmQgRkUgc2VwYXJhdGVseSwgYW5kIHRoZS Bt ZXNzYWdlIHR5cGUgdW5pcXVlbHkgcmVjb2duaXplIGEgbWVzc2FnZSBhcyBhIHJlc3BvbnNlIG 1l c3NhZ2UsIHRoZXJlZm9yZSB0aGVyZSB3aWxsIGJlIG5vIG9wYXF1ZSBpbiB0aGUgU2VxdWVuY2 Ug bnVtYmVyIG1haW50YWluY2UuIA0KPjIuIFNlcXVlbmNlIG51bWJlciBvZiBhbiBldmVudCBmcm 9t IEZFIGlzIGdlbmVyYXRlZCBieSB0aGUgRkUsIHdoaWxlIHJlc3BvbnNlIG9mIHRoZSBldmVudC Ao aWYgYW55KSBzaG91bGQgaGF2ZSB0aGUgc2FtZSBzZXF1ZW5jZSBudW1iZXIgYXMgdGhlIGV2ZW 50 IHRvIHJlc3BvbnNlLiANCj4zLiBBIHJlc3BvbnNlIHRvIGJhdGNoaW5nIG1lc3NhZ2VzIHRvIG 1l ZXQgdHdvLXBoYXNlLWNvbW1pdHMgd2lsbCBoYXZlIHRoZSBzYW1lIFNOIGFzIHRoYXQgb2YgdG hl IGZpcnN0IG1lc3NhZ2Ugb3IgdGhlIGxhc3QgbWVzc2FnZSBpbiB0aGUgYmF0Y2gsIGp1c3QgYX Mg d2hhdCB3ZSdkIGxpa2UgdG8gZGVmaW5lLg0KPg0KPlRoYW5rcywNCj5XZWltaW5nDQo+DQo+DQ o+ ICANCj4NCg0KLS0gDQpEci4gUm9iZXJ0IFIuIEhhYXMNCklCTSBadXJpY2ggUmVzZWFyY2ggTG Fi b3JhdG9yeQ0KU+R1bWVyc3RyYXNzZSA0DQpDSC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbm QN CnBob25lICs0MS00NC03MjQtODY5OCAgZmF4ICs0MS00NC03MjQtODU3OCAgaHR0cDovL3d3dy 56 dXJpY2guaWJtLmNvbS9+cmhh 2005 Message-Id: Date: Tue, 14 Jun 2005 23:13:52 +0800 From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 TXkgb3BpbmlvbiBpczoNCg0KMS4gIEZ1bmN0aW9uIHRvIGNvcnJlbGF0ZSBhIHJlcXVlc3QgdG 8g YSByZXNwb25zZSBpcyBuZWNlc3NhcnkuDQogICAgU2VlbXMgbm8gb25lIG9iamVjdGluZyB0by B0 aGlzLg0KDQoyLiBQTCBtZXNzYWdlIHNlcXVlbnRpYWwgbnVtYmVyaW5nIGlzIGFsc28gbmVjZX Nz YXJ5DQogICAgT25lIG9mICB0aGUgcmVhc29uIG5vdyBJIGNhbiB0aGluayBvZiBpcyBmb3IgcG Fj a2V0IHJlZGlyZWN0IG1lc3NhZ2VzLiBOb3RlIHRoYXQgd2UgaGF2ZW4ndCBtYWtlIGEgcmVsaW Fi aWxpdHkgcmVxaXJlbWVudCBmb3IgcGFja2V0IHJlZGlyZWN0aW9uLCB3aGlsZSB0aGUgc2VxdW Vu Y2Ugb2YgcmVkaXJlY3RlZCBwYWNrZXRzIGFyZSB1c2VmdWwgZm9yIHRoZXNlIHBhY2tldHMgYX Bw bGljYXRpb25zLg0KDQozLiBJdCBjYW4gZnVsZmlsbCB0aGUgZnVuY3Rpb24gMSkgd2VsbCBieS Bk ZWZpbmluZyB0aGF0IGEgcmVzcG9uc2UgbWVzc2FnZSBzaG91bGQgYWx3YXlzIGhhdmUgdGhlIH Nh bWUgU04gd2l0aCB0aGUgcmVxdWVzdCB0byByZXBseSwgaGVuY2Ugd2Ugb25seSBuZWVkIG9uZS Bm aWVsZCB0aGF0IGlzIGNhbGxlZCBzZXF1ZW5jZSBudW1iZXIuIA0KDQpQLlMuIA0KMS4gU2VxdW Vu Y2UgbnVtYmVyIHNob3VsZCBiZSBtYWludGFpbmVkIHBlciBDRSBhbmQgRkUgc2VwYXJhdGVseS wg YW5kIHRoZSBtZXNzYWdlIHR5cGUgdW5pcXVlbHkgcmVjb2duaXplIGEgbWVzc2FnZSBhcyBhIH Jl c3BvbnNlIG1lc3NhZ2UsIHRoZXJlZm9yZSB0aGVyZSB3aWxsIGJlIG5vIG9wYXF1ZSBpbiB0aG Ug U2VxdWVuY2UgbnVtYmVyIG1haW50YWluY2UuIA0KMi4gU2VxdWVuY2UgbnVtYmVyIG9mIGFuIG V2 ZW50IGZyb20gRkUgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBGRSwgd2hpbGUgcmVzcG9uc2Ugb2YgdG hl IGV2ZW50IChpZiBhbnkpIHNob3VsZCBoYXZlIHRoZSBzYW1lIHNlcXVlbmNlIG51bWJlciBhcy B0 aGUgZXZlbnQgdG8gcmVzcG9uc2UuIA0KMy4gQSByZXNwb25zZSB0byBiYXRjaGluZyBtZXNzYW dl cyB0byBtZWV0IHR3by1waGFzZS1jb21taXRzIHdpbGwgaGF2ZSB0aGUgc2FtZSBTTiBhcyB0aG F0 IG9mIHRoZSBmaXJzdCBtZXNzYWdlIG9yIHRoZSBsYXN0IG1lc3NhZ2UgaW4gdGhlIGJhdGNoLC Bq dXN0IGFzIHdoYXQgd2UnZCBsaWtlIHRvIGRlZmluZS4NCg0KVGhhbmtzLA0KV2VpbWluZw0K 2005 Message-Id: Date: Tue, 14 Jun 2005 17:36:23 +0200 From: Robert Haas Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Weiming, I agree with 1 and 2, but I would not merge the two into the same=20 sequence number concept. As an example, according to your suggestion,=20 event notifications and packet redirections should be numbered according=20 to a different sequence than response messages for which the numbering=20 is imposed by the CE. So the CE would have to maintain two independent=20 parallel sequences. This is unnecessary complexity to me. Regards, -Robert Weiming Wang wrote: >My opinion is: > >1. Function to correlate a request to a response is necessary. > Seems no one objecting to this. > >2. PL message sequential numbering is also necessary > One of the reason now I can think of is for packet redirect message= s. Note that we haven't make a reliability reqirement for packet redirect= ion, while the sequence of redirected packets are useful for these packet= s applications. > >3. It can fulfill the function 1) well by defining that a response messa= ge should always have the same SN with the request to reply, hence we onl= y need one field that is called sequence number.=20 > >P.S.=20 >1. Sequence number should be maintained per CE and FE separately, and th= e message type uniquely recognize a message as a response message, theref= ore there will be no opaque in the Sequence number maintaince.=20 >2. Sequence number of an event from FE is generated by the FE, while res= ponse of the event (if any) should have the same sequence number as the e= vent to response.=20 >3. A response to batching messages to meet two-phase-commits will have t= he same SN as that of the first message or the last message in the batch,= just as what we'd like to define. > >Thanks, >Weiming > > > =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, 14 Jun 2005 07:39:39 -0700 From: "Putzolu, David" Subject: Issue closure MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570EE.E48988B1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C570EE.E48988B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 The following issues on the ForCES issue tracker are pending closure. This means that the mailing list has a final opportunity to review them prior to them being considered closed. Please read all of the issues referred to below. If there are any concerns or questions about the proposed closure, please reply to the list by Monday, June 20. =20 http://www.mip4.org/issues/tracker/forces/issue6 http://www.mip4.org/issues/tracker/forces/issue11 http://www.mip4.org/issues/tracker/forces/issue12 http://www.mip4.org/issues/tracker/forces/issue18 http://www.mip4.org/issues/tracker/forces/issue21 http://www.mip4.org/issues/tracker/forces/issue25 http://www.mip4.org/issues/tracker/forces/issue30 http://www.mip4.org/issues/tracker/forces/issue35 =20 Thanks, David ------_=_NextPart_001_01C570EE.E48988B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The following issues on the ForCES issue tracker are = pending closure.  This means that the mailing list has a final opportunity = to review them prior to them being considered closed.  Please read all = of the issues referred to below.  If there are any concerns or questions = about the proposed closure, please reply to the list by Monday, June = 20.

 

http://www.mip4= .org/issues/tracker/forces/issue6

http://www.mip= 4.org/issues/tracker/forces/issue11

http://www.mip= 4.org/issues/tracker/forces/issue12

http://www.mip= 4.org/issues/tracker/forces/issue18

http://www.mip= 4.org/issues/tracker/forces/issue21

http://www.mip= 4.org/issues/tracker/forces/issue25

http://www.mip= 4.org/issues/tracker/forces/issue30

http://www.mip= 4.org/issues/tracker/forces/issue35

 

Thanks,

David

------_=_NextPart_001_01C570EE.E48988B1-- 2005 Message-Id: Date: Mon, 13 Jun 2005 16:22:37 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Putzolu, David" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Mon, 2005-13-06 at 11:32 -0700, Putzolu, David wrote: > Small question on the size of the seq# and correlator# sizes. > > The sizes should be large enough to unambiguously distinguish different > messages (for the correlator) and order different messages (for a > sequence number). > > It seems to me both a 16 bit and a 32 bit length will eventually roll > over, so we need to deal with roll over no matter what. If that is the > case, I wonder if we can get away with 16 (or 24) bit values for either > one? > > For sequence numbering, if we assume 500 bytes to store a message and > all related context, a 2^16 messages would require 32MB of buffering, > which is pretty significant. 2^24 would require a very large amount - > so it feels to me that a full 32 bits is not needed. > > For a correlator it seems to me to depend on how many simultaneous > active transactions are expected. This also feels like a scenario where > a full 32 bits is not needed. > Agreed. If i was to handwave i would say a 16 bit number would be sufficient for the correlator. 32 bit is sufficient for a sequence number I would think. > The above being said, I am mindful of the risk of being overly > conservative in such decisions, so I am not sure whether going shorter > than 32 is a good idea or not. What has been the implementation > experience with Netlink and other protocols such as GSMP? > Netlink is currently overloading the 32 bit sequence number on a per-process level for a correlator; this is currently causing some headaches in the case of conflicts and in particular when you have more than one socket open by the same process (anology would be if you had more than one connection between PL and TML at say the CE - not far off if you look at Roberts model of implementation). The result is the kernel does some funky things by changing the PID (equivalent to FEID) for multiple users coming from the same process. Under such conflicts the ability to use netlink for IPC breaks. [The good news is you can work around it by using getsockname() syscall to find out what real values the kernel overrides for you. This would have been real easy to resolve if netlink had a correlator in its header - wed just ask the kernel not to be clever]. It's a good lesson is the summary. cheers, jamal 2005 Message-Id: Date: Mon, 13 Jun 2005 14:15:12 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Khosravi, Hormuzd M" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Mon, 2005-13-06 at 11:01 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > The TML sequence number is a transport level one and really has nothing > to do with PL level. A PL level sequence could in fact be multiple > transport level sequence numbers. > > [HK] I did not see any reason from you regarding why to retain the SN, > just that we should do it. We need to have a good technical reasons in > the draft for the different protocol fields. > Are you sure you read my email, Hormuzd?;-> I quoted Joels email because it gave a very good summary > I did see a good technical reason from Weiming for the SN, > 1. For messages like Packet redirect messages, transport order of which > may not > strictly required, but the sequence of the redirected packets still make > sense to > the applications of the packets. > > If this is the case, I would vote for having both SN & Correlator in the > header. > So we can close this issue, I guess...unless there are any other > concerns. > Lets wait for Weiming to respond and close it i think. cheers, jamal 2005 Message-Id: Date: Mon, 13 Jun 2005 13:29:00 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Deleganes, Ellen M" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Mon, 2005-13-06 at 08:36 -0700, Deleganes, Ellen M wrote: > I also agree that a correlator field looks to be useful. Given that at > least a few people are arguing that a requirement of the TML is to > guarantee in order delivery, the correlator field appears to be more > useful than the sequence number field. > > The argument seems to be more whether two fields are needed, not whether > a correlator field is useful. > > Perhaps the better way to ask is which option is preferred, to determine > if there is consensus: > 1) Correlator field only > 2) Sequence number field only > 3) Both > > (I vote for option 1) A sequence number could be used as a correlator. That's what we are doing today in our implementation for example. But that in itself is making some assumption about the implementation details and to a small degree OS level details[1]. Infact, given our implementation today we may never need the corellator number - although on occasion i do worry about transactional issues and Ha when we get to it. It would certainly ease the state maintainance we do if we had it; OTOH, if forces was already released as an RFC i could live without it. We are not at that stage yet and i dont wanna impose how we implement onto Robert. Despite the above, I think Joel put it best in one of his emails, to quote: "A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict." The TML sequence number is a transport level one and really has nothing to do with PL level. A PL level sequence could in fact be multiple transport level sequence numbers. The correlator is, to be precise, opaque to the receiver (typically FE) whereas the sequence number could be intepreted. cheers, jamal Unfortunately, such assumptions could get us in trouble and i would rather give up 32 bits now than regret later. [To compare with the callback model and the associated correlators in the NPF APIs model where we are currenlty working around assumptions (such as a flat memory space OS or the implementation using multithreading).] 2005 Message-Id: Date: Mon, 13 Jun 2005 11:32:44 -0700 From: "Putzolu, David" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Small question on the size of the seq# and correlator# sizes. The sizes should be large enough to unambiguously distinguish different messages (for the correlator) and order different messages (for a sequence number). It seems to me both a 16 bit and a 32 bit length will eventually roll over, so we need to deal with roll over no matter what. If that is the case, I wonder if we can get away with 16 (or 24) bit values for either one?=20 For sequence numbering, if we assume 500 bytes to store a message and all related context, a 2^16 messages would require 32MB of buffering, which is pretty significant. 2^24 would require a very large amount - so it feels to me that a full 32 bits is not needed. =20 For a correlator it seems to me to depend on how many simultaneous active transactions are expected. This also feels like a scenario where a full 32 bits is not needed. The above being said, I am mindful of the risk of being overly conservative in such decisions, so I am not sure whether going shorter than 32 is a good idea or not. What has been the implementation experience with Netlink and other protocols such as GSMP? Thanks, David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, June 12, 2005 8:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. >=20 Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header.=20 cheers, jamal 2005 Message-Id: Date: Mon, 13 Jun 2005 11:32:42 -0700 From: "Putzolu, David" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that FE should not make any assumptions about the correlator values. While the CE may make them sequential (or choose them using any other algorithm it wishes), the FE should not rely on it. This is both to allow the CE implementor freedom and in order to make the FE more robust - if the spec mandated that the correlators be sequential, and the FE relied on that property, a CE with a bug in the sequence would cause FE failure. A more robust FE would not rely on the sequence (under the be liberal in what you accept guideline). Given this, it is better to simply remove the constraint that the CE make them sequential. I've found correlators/cookies to be useful in similar contexts as this, so I support putting one in. For sequencing, I prefer to rely on the TML for this, as it is not clear to me why one would want to lift it out of the TML. Cheers, David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 13, 2005 6:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Ok, folks lets put closure to this: so far the stick-finger-in-the-air answer i am seeing to the question "should we add a correlator field in the main header in addition to existing sequence number?" Jamal: 100% yes Robert: 100% yes Joel: 65% yes - Joel can we get a boolean from you? Hormuzd: 100% no Weiming:Not sure where you stand. cheers, jamal On Mon, 2005-13-06 at 07:31 -0400, Joel M. Halpern wrote: > Actually, I would prefer to put as few restrictions as possible on the > creator of the correlator, so as to allow the most implementation freedom. >=20 > Hence, the only MUST would be that a responder MUST put the correlator from=20 > a request into the response. >=20 > It seems like "A requestor SHOULD NOT reuse the correlator from outstanding=20 > requests for different requests." makes sense. I would not want to make=20 > that a MUST. >=20 > An receiver MUST NOT apply any semantics to received correlators. >=20 > Sequence information is either derivable from the TML or should be in a=20 > separate field. > Yours, > Joel >=20 > At 11:30 PM 6/12/2005, Wang,Weiming wrote: > >Firstly , I think even if we use it only as a correlator, the number should > >sitll not be generated randomly, rather sequencially. Secondly, it therefore > >menas we actually doesn't pay too much by introducing the Sequential Number in > >while without loosing the correlator function. Thirdly, it maybe too early to > >say a SN is not at all useful for the protocol PL level. For this point, I > >suppose we should distinguish the idea of the protocol message sequence=20 > >from the > >TML transport sequence a little. I can curretnly see two cases where=20 > >protocol SN > >may make senses to PL thought not to TML: > > > >1. For messages like Packet redirect messages, transport order of which=20 > >may not > >strictly requred, but the sequence of the redirected packets still make=20 > >sense to > >the applications of the packets. > > > >2. Usually, core PL process runs in a multi-thread mode, in this case, a=20 > >SN can > >act well as a tracker for the process. This can be used at PL-TML interface PL > >side as well as the TML side. This may also be used for CE or FE failover=20 > >case > >like graceful restart. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >I agree, this was along the lines of my previous suggestion. I don't see > >the reason for having both a sequence number and a correlator....SN > >should not be needed by the PL since the TML provides reliability which > >guarantees in-order delivery (acc to the definition). Would you agree? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, June 12, 2005 8:00 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Actually, I would prefer to change the name. > > > >A Sequence number should have a different sequential value has I hand > >messages from the PL to the TML. > >A correlator should have distinct values for distinct requests, and > >replies > >should have the value from the request. > >These are not the same property. They may even be in conflict. > > > >Note that a request originator is capable of remembering the sequence in > > > >which it sends requests. > >Thus, for most purposes a correlator will do more than a sequence > >number. > >What a correlator does not provide is the ability to compare the order > >of a > >received even and a received response. If some TML may disorder things, > > > >that would be lost information. > >If that is a big deal, we need two fields. > > > >But we can not simply treat the sequence number as the correlator. > > > >Yours, > >Joel > > > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > > >Ok, so you're saying we should use the Sequence number as a Correlator. > > >If that is the case then we are in agreement, I think. We should update > > >the text. > > > > > >Let me know if I misunderstood you, > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Saturday, June 11, 2005 8:14 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >----- Original Message ----- > > >From: "Khosravi, Hormuzd M" > > > > > >Yes, a Correlator is useful and currently we have been using the > > >Sequence number as correlator. I don't see any other use of the > >Sequence > > >number since reliability is provided by the TML. I think we should > > >change Sequence number to correlator in the draft and update the > > >description accordingly unless there is some use for a sequence number. > > > > > >[Weiming] I think it's too early to say the SN is only for correlation. > > >currently I don't think we should a hundred percent to rely on TML for > > >thinks > > >like sequential ordering. As a safer mode, I still prefer to have it > > >as its > > >original name of Sequence Number. Correlating request/reply messages > > >should > > >only be one of its functions. > > > > > >thanks, > > >Weiming > > > > > >BTW, issue 47 looks like the same one...we should close one of these > > >issues. > > > > > >regards > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Friday, June 10, 2005 9:12 AM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >Robert, > > > > > >----- Original Message ----- > > >From: "Robert Haas" > > > > > >New submission from Robert Haas : > > > > > >Adding a correlator seems useful: response messages can be matched to > > >the > > >request messages even if pipelining and reordering occurs. > > >It seems that some are currently using the sequence number as a > > >correlator: > > >this can be dangerous, and not suitable for event notifications > >messages > > >(nothing to correlate with). > > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > > >let the > > >response have the same SN as the sender. If so, I cannot follow well > > >why it is > > >dangerous and not suit for event notifications. Could you clarify this > > >more? > > > > > >Thanks. > > >Weiming > > > > > >But this introduces the risk of flooding an FE with too many commands > >as > > >there > > >is no windowing mechanism in place (yet). > > > > > >---------- > > >category: Technical > > >draft: draft-ietf-forces-protocol > > >messages: 129 > > >nosy: rha > > >priority: Should fix > > >status: No discussion > > >title: correlator in the PL message header > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ 2005 Message-Id: Date: Mon, 13 Jun 2005 11:30:05 +0800 From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header Firstly , I think even if we use it only as a correlator, the number should sitll not be generated randomly, rather sequencially. Secondly, it therefore menas we actually doesn't pay too much by introducing the Sequential Number in while without loosing the correlator function. Thirdly, it maybe too early to say a SN is not at all useful for the protocol PL level. For this point, I suppose we should distinguish the idea of the protocol message sequence from the TML transport sequence a little. I can curretnly see two cases where protocol SN may make senses to PL thought not to TML: 1. For messages like Packet redirect messages, transport order of which may not strictly requred, but the sequence of the redirected packets still make sense to the applications of the packets. 2. Usually, core PL process runs in a multi-thread mode, in this case, a SN can act well as a tracker for the process. This can be used at PL-TML interface PL side as well as the TML side. This may also be used for CE or FE failover case like graceful restart. Cheers, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" I agree, this was along the lines of my previous suggestion. I don't see the reason for having both a sequence number and a correlator....SN should not be needed by the PL since the TML provides reliability which guarantees in-order delivery (acc to the definition). Would you agree? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, June 12, 2005 8:00 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Actually, I would prefer to change the name. A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict. Note that a request originator is capable of remembering the sequence in which it sends requests. Thus, for most purposes a correlator will do more than a sequence number. What a correlator does not provide is the ability to compare the order of a received even and a received response. If some TML may disorder things, that would be lost information. If that is a big deal, we need two fields. But we can not simply treat the sequence number as the correlator. Yours, Joel At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: >Ok, so you're saying we should use the Sequence number as a Correlator. >If that is the case then we are in agreement, I think. We should update >the text. > >Let me know if I misunderstood you, >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Saturday, June 11, 2005 8:14 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >Yes, a Correlator is useful and currently we have been using the >Sequence number as correlator. I don't see any other use of the Sequence >number since reliability is provided by the TML. I think we should >change Sequence number to correlator in the draft and update the >description accordingly unless there is some use for a sequence number. > >[Weiming] I think it's too early to say the SN is only for correlation. >currently I don't think we should a hundred percent to rely on TML for >thinks >like sequential ordering. As a safer mode, I still prefer to have it >as its >original name of Sequence Number. Correlating request/reply messages >should >only be one of its functions. > >thanks, >Weiming > >BTW, issue 47 looks like the same one...we should close one of these >issues. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Friday, June 10, 2005 9:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Robert, > >----- Original Message ----- >From: "Robert Haas" > >New submission from Robert Haas : > >Adding a correlator seems useful: response messages can be matched to >the >request messages even if pipelining and reordering occurs. >It seems that some are currently using the sequence number as a >correlator: >this can be dangerous, and not suitable for event notifications messages >(nothing to correlate with). >[Weiming] I'm not sure if you mean to use the SN as a correlator is to >let the >response have the same SN as the sender. If so, I cannot follow well >why it is >dangerous and not suit for event notifications. Could you clarify this >more? > >Thanks. >Weiming > >But this introduces the risk of flooding an FE with too many commands as >there >is no windowing mechanism in place (yet). > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 129 >nosy: rha >priority: Should fix >status: No discussion >title: correlator in the PL message header > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Mon, 13 Jun 2005 11:01:35 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: cc: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jamal,=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim The TML sequence number is a transport level one and really has nothing to do with PL level. A PL level sequence could in fact be multiple transport level sequence numbers.=20 [HK] I did not see any reason from you regarding why to retain the SN, just that we should do it. We need to have a good technical reasons in the draft for the different protocol fields. I did see a good technical reason from Weiming for the SN, 1. For messages like Packet redirect messages, transport order of which may not strictly required, but the sequence of the redirected packets still make sense to the applications of the packets. If this is the case, I would vote for having both SN & Correlator in the header. So we can close this issue, I guess...unless there are any other concerns. regards Hormuzd 2005 Message-Id: Date: Mon, 13 Jun 2005 10:34:58 -0700 From: "Deleganes, Ellen M" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should have been clearer. When I voted for option 1, I didn't mean to imply the sequence number field is overloaded to mean the same thing as the correlator. I agree that the correlator should not be tied to the sequence number. It should be up to the issuer of the requester to assign a correlator to the request, which is echoed in the response. There seems to be some question as to whether a sequence number is needed. If the sequence number is required, then I would change my vote to option 3 (both fields). Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 13, 2005 10:29 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue54] correlator in the PL message header On Mon, 2005-13-06 at 08:36 -0700, Deleganes, Ellen M wrote: > I also agree that a correlator field looks to be useful. Given that at > least a few people are arguing that a requirement of the TML is to > guarantee in order delivery, the correlator field appears to be more > useful than the sequence number field. >=20 > The argument seems to be more whether two fields are needed, not whether > a correlator field is useful. >=20 > Perhaps the better way to ask is which option is preferred, to determine > if there is consensus: > 1) Correlator field only > 2) Sequence number field only > 3) Both >=20 > (I vote for option 1) A sequence number could be used as a correlator. That's what we are doing today in our implementation for example.=20 But that in itself is making some assumption about the implementation details and to a small degree OS level details[1]. Infact, given our implementation today we may never need the corellator number - although on occasion i do worry about transactional issues and Ha when we get to it. It would certainly ease the state maintainance we do if we had it; OTOH, if forces was already released as an RFC i could live without it. We are not at that stage yet and i dont wanna impose how we implement onto Robert. Despite the above, I think Joel put it best in one of his emails, to quote: "A Sequence number should have a different sequential value has I hand=20 messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict." The TML sequence number is a transport level one and really has nothing to do with PL level. A PL level sequence could in fact be multiple transport level sequence numbers.=20 The correlator is, to be precise, opaque to the receiver (typically FE) whereas the sequence number could be intepreted. cheers, jamal Unfortunately, such assumptions could get us in trouble and i would rather give up 32 bits now than regret later. [To compare with the callback model and the associated correlators in the NPF APIs model where we are currenlty working around assumptions (such as a flat memory space OS or the implementation using multithreading).] 2005 Message-Id: Date: Mon, 13 Jun 2005 09:01:07 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Ok, folks lets put closure to this: so far the stick-finger-in-the-air answer i am seeing to the question "should we add a correlator field in the main header in addition to existing sequence number?" Jamal: 100% yes Robert: 100% yes Joel: 65% yes - Joel can we get a boolean from you? Hormuzd: 100% no Weiming:Not sure where you stand. cheers, jamal On Mon, 2005-13-06 at 07:31 -0400, Joel M. Halpern wrote: > Actually, I would prefer to put as few restrictions as possible on the > creator of the correlator, so as to allow the most implementation freedom. > > Hence, the only MUST would be that a responder MUST put the correlator from > a request into the response. > > It seems like "A requestor SHOULD NOT reuse the correlator from outstanding > requests for different requests." makes sense. I would not want to make > that a MUST. > > An receiver MUST NOT apply any semantics to received correlators. > > Sequence information is either derivable from the TML or should be in a > separate field. > Yours, > Joel > > At 11:30 PM 6/12/2005, Wang,Weiming wrote: > >Firstly , I think even if we use it only as a correlator, the number should > >sitll not be generated randomly, rather sequencially. Secondly, it therefore > >menas we actually doesn't pay too much by introducing the Sequential Number in > >while without loosing the correlator function. Thirdly, it maybe too early to > >say a SN is not at all useful for the protocol PL level. For this point, I > >suppose we should distinguish the idea of the protocol message sequence > >from the > >TML transport sequence a little. I can curretnly see two cases where > >protocol SN > >may make senses to PL thought not to TML: > > > >1. For messages like Packet redirect messages, transport order of which > >may not > >strictly requred, but the sequence of the redirected packets still make > >sense to > >the applications of the packets. > > > >2. Usually, core PL process runs in a multi-thread mode, in this case, a > >SN can > >act well as a tracker for the process. This can be used at PL-TML interface PL > >side as well as the TML side. This may also be used for CE or FE failover > >case > >like graceful restart. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >I agree, this was along the lines of my previous suggestion. I don't see > >the reason for having both a sequence number and a correlator....SN > >should not be needed by the PL since the TML provides reliability which > >guarantees in-order delivery (acc to the definition). Would you agree? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, June 12, 2005 8:00 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Actually, I would prefer to change the name. > > > >A Sequence number should have a different sequential value has I hand > >messages from the PL to the TML. > >A correlator should have distinct values for distinct requests, and > >replies > >should have the value from the request. > >These are not the same property. They may even be in conflict. > > > >Note that a request originator is capable of remembering the sequence in > > > >which it sends requests. > >Thus, for most purposes a correlator will do more than a sequence > >number. > >What a correlator does not provide is the ability to compare the order > >of a > >received even and a received response. If some TML may disorder things, > > > >that would be lost information. > >If that is a big deal, we need two fields. > > > >But we can not simply treat the sequence number as the correlator. > > > >Yours, > >Joel > > > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > > >Ok, so you're saying we should use the Sequence number as a Correlator. > > >If that is the case then we are in agreement, I think. We should update > > >the text. > > > > > >Let me know if I misunderstood you, > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Saturday, June 11, 2005 8:14 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >----- Original Message ----- > > >From: "Khosravi, Hormuzd M" > > > > > >Yes, a Correlator is useful and currently we have been using the > > >Sequence number as correlator. I don't see any other use of the > >Sequence > > >number since reliability is provided by the TML. I think we should > > >change Sequence number to correlator in the draft and update the > > >description accordingly unless there is some use for a sequence number. > > > > > >[Weiming] I think it's too early to say the SN is only for correlation. > > >currently I don't think we should a hundred percent to rely on TML for > > >thinks > > >like sequential ordering. As a safer mode, I still prefer to have it > > >as its > > >original name of Sequence Number. Correlating request/reply messages > > >should > > >only be one of its functions. > > > > > >thanks, > > >Weiming > > > > > >BTW, issue 47 looks like the same one...we should close one of these > > >issues. > > > > > >regards > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Friday, June 10, 2005 9:12 AM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >Robert, > > > > > >----- Original Message ----- > > >From: "Robert Haas" > > > > > >New submission from Robert Haas : > > > > > >Adding a correlator seems useful: response messages can be matched to > > >the > > >request messages even if pipelining and reordering occurs. > > >It seems that some are currently using the sequence number as a > > >correlator: > > >this can be dangerous, and not suitable for event notifications > >messages > > >(nothing to correlate with). > > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > > >let the > > >response have the same SN as the sender. If so, I cannot follow well > > >why it is > > >dangerous and not suit for event notifications. Could you clarify this > > >more? > > > > > >Thanks. > > >Weiming > > > > > >But this introduces the risk of flooding an FE with too many commands > >as > > >there > > >is no windowing mechanism in place (yet). > > > > > >---------- > > >category: Technical > > >draft: draft-ietf-forces-protocol > > >messages: 129 > > >nosy: rha > > >priority: Should fix > > >status: No discussion > > >title: correlator in the PL message header > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ 2005 Message-Id: Date: Mon, 13 Jun 2005 08:36:02 -0700 From: "Deleganes, Ellen M" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree that a correlator field looks to be useful. Given that at least a few people are arguing that a requirement of the TML is to guarantee in order delivery, the correlator field appears to be more useful than the sequence number field. The argument seems to be more whether two fields are needed, not whether a correlator field is useful. Perhaps the better way to ask is which option is preferred, to determine if there is consensus: 1) Correlator field only 2) Sequence number field only 3) Both (I vote for option 1) Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 13, 2005 6:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue54] correlator in the PL message header Ok, folks lets put closure to this: so far the stick-finger-in-the-air answer i am seeing to the question "should we add a correlator field in the main header in addition to existing sequence number?" Jamal: 100% yes Robert: 100% yes Joel: 65% yes - Joel can we get a boolean from you? Hormuzd: 100% no Weiming:Not sure where you stand. cheers, jamal On Mon, 2005-13-06 at 07:31 -0400, Joel M. Halpern wrote: > Actually, I would prefer to put as few restrictions as possible on the > creator of the correlator, so as to allow the most implementation freedom. >=20 > Hence, the only MUST would be that a responder MUST put the correlator from=20 > a request into the response. >=20 > It seems like "A requestor SHOULD NOT reuse the correlator from outstanding=20 > requests for different requests." makes sense. I would not want to make=20 > that a MUST. >=20 > An receiver MUST NOT apply any semantics to received correlators. >=20 > Sequence information is either derivable from the TML or should be in a=20 > separate field. > Yours, > Joel >=20 > At 11:30 PM 6/12/2005, Wang,Weiming wrote: > >Firstly , I think even if we use it only as a correlator, the number should > >sitll not be generated randomly, rather sequencially. Secondly, it therefore > >menas we actually doesn't pay too much by introducing the Sequential Number in > >while without loosing the correlator function. Thirdly, it maybe too early to > >say a SN is not at all useful for the protocol PL level. For this point, I > >suppose we should distinguish the idea of the protocol message sequence=20 > >from the > >TML transport sequence a little. I can curretnly see two cases where=20 > >protocol SN > >may make senses to PL thought not to TML: > > > >1. For messages like Packet redirect messages, transport order of which=20 > >may not > >strictly requred, but the sequence of the redirected packets still make=20 > >sense to > >the applications of the packets. > > > >2. Usually, core PL process runs in a multi-thread mode, in this case, a=20 > >SN can > >act well as a tracker for the process. This can be used at PL-TML interface PL > >side as well as the TML side. This may also be used for CE or FE failover=20 > >case > >like graceful restart. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >I agree, this was along the lines of my previous suggestion. I don't see > >the reason for having both a sequence number and a correlator....SN > >should not be needed by the PL since the TML provides reliability which > >guarantees in-order delivery (acc to the definition). Would you agree? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, June 12, 2005 8:00 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Actually, I would prefer to change the name. > > > >A Sequence number should have a different sequential value has I hand > >messages from the PL to the TML. > >A correlator should have distinct values for distinct requests, and > >replies > >should have the value from the request. > >These are not the same property. They may even be in conflict. > > > >Note that a request originator is capable of remembering the sequence in > > > >which it sends requests. > >Thus, for most purposes a correlator will do more than a sequence > >number. > >What a correlator does not provide is the ability to compare the order > >of a > >received even and a received response. If some TML may disorder things, > > > >that would be lost information. > >If that is a big deal, we need two fields. > > > >But we can not simply treat the sequence number as the correlator. > > > >Yours, > >Joel > > > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > > >Ok, so you're saying we should use the Sequence number as a Correlator. > > >If that is the case then we are in agreement, I think. We should update > > >the text. > > > > > >Let me know if I misunderstood you, > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Saturday, June 11, 2005 8:14 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >----- Original Message ----- > > >From: "Khosravi, Hormuzd M" > > > > > >Yes, a Correlator is useful and currently we have been using the > > >Sequence number as correlator. I don't see any other use of the > >Sequence > > >number since reliability is provided by the TML. I think we should > > >change Sequence number to correlator in the draft and update the > > >description accordingly unless there is some use for a sequence number. > > > > > >[Weiming] I think it's too early to say the SN is only for correlation. > > >currently I don't think we should a hundred percent to rely on TML for > > >thinks > > >like sequential ordering. As a safer mode, I still prefer to have it > > >as its > > >original name of Sequence Number. Correlating request/reply messages > > >should > > >only be one of its functions. > > > > > >thanks, > > >Weiming > > > > > >BTW, issue 47 looks like the same one...we should close one of these > > >issues. > > > > > >regards > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Friday, June 10, 2005 9:12 AM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >Robert, > > > > > >----- Original Message ----- > > >From: "Robert Haas" > > > > > >New submission from Robert Haas : > > > > > >Adding a correlator seems useful: response messages can be matched to > > >the > > >request messages even if pipelining and reordering occurs. > > >It seems that some are currently using the sequence number as a > > >correlator: > > >this can be dangerous, and not suitable for event notifications > >messages > > >(nothing to correlate with). > > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > > >let the > > >response have the same SN as the sender. If so, I cannot follow well > > >why it is > > >dangerous and not suit for event notifications. Could you clarify this > > >more? > > > > > >Thanks. > > >Weiming > > > > > >But this introduces the risk of flooding an FE with too many commands > >as > > >there > > >is no windowing mechanism in place (yet). > > > > > >---------- > > >category: Technical > > >draft: draft-ietf-forces-protocol > > >messages: 129 > > >nosy: rha > > >priority: Should fix > > >status: No discussion > > >title: correlator in the PL message header > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ 2005 Message-Id: Date: Mon, 13 Jun 2005 07:31:40 -0400 From: "Joel M. Halpern" Subject: Re: [issue54] correlator in the PL message header Comments: To: "Wang,Weiming" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Actually, I would prefer to put as few restrictions as possible on the creator of the correlator, so as to allow the most implementation freedom. Hence, the only MUST would be that a responder MUST put the correlator from a request into the response. It seems like "A requestor SHOULD NOT reuse the correlator from outstanding requests for different requests." makes sense. I would not want to make that a MUST. An receiver MUST NOT apply any semantics to received correlators. Sequence information is either derivable from the TML or should be in a separate field. Yours, Joel At 11:30 PM 6/12/2005, Wang,Weiming wrote: >Firstly , I think even if we use it only as a correlator, the number should >sitll not be generated randomly, rather sequencially. Secondly, it therefore >menas we actually doesn't pay too much by introducing the Sequential Number in >while without loosing the correlator function. Thirdly, it maybe too early to >say a SN is not at all useful for the protocol PL level. For this point, I >suppose we should distinguish the idea of the protocol message sequence >from the >TML transport sequence a little. I can curretnly see two cases where >protocol SN >may make senses to PL thought not to TML: > >1. For messages like Packet redirect messages, transport order of which >may not >strictly requred, but the sequence of the redirected packets still make >sense to >the applications of the packets. > >2. Usually, core PL process runs in a multi-thread mode, in this case, a >SN can >act well as a tracker for the process. This can be used at PL-TML interface PL >side as well as the TML side. This may also be used for CE or FE failover >case >like graceful restart. > >Cheers, >Weiming > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >I agree, this was along the lines of my previous suggestion. I don't see >the reason for having both a sequence number and a correlator....SN >should not be needed by the PL since the TML provides reliability which >guarantees in-order delivery (acc to the definition). Would you agree? > > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, June 12, 2005 8:00 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Actually, I would prefer to change the name. > >A Sequence number should have a different sequential value has I hand >messages from the PL to the TML. >A correlator should have distinct values for distinct requests, and >replies >should have the value from the request. >These are not the same property. They may even be in conflict. > >Note that a request originator is capable of remembering the sequence in > >which it sends requests. >Thus, for most purposes a correlator will do more than a sequence >number. >What a correlator does not provide is the ability to compare the order >of a >received even and a received response. If some TML may disorder things, > >that would be lost information. >If that is a big deal, we need two fields. > >But we can not simply treat the sequence number as the correlator. > >Yours, >Joel > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > >Ok, so you're saying we should use the Sequence number as a Correlator. > >If that is the case then we are in agreement, I think. We should update > >the text. > > > >Let me know if I misunderstood you, > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > >Sent: Saturday, June 11, 2005 8:14 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >Yes, a Correlator is useful and currently we have been using the > >Sequence number as correlator. I don't see any other use of the >Sequence > >number since reliability is provided by the TML. I think we should > >change Sequence number to correlator in the draft and update the > >description accordingly unless there is some use for a sequence number. > > > >[Weiming] I think it's too early to say the SN is only for correlation. > >currently I don't think we should a hundred percent to rely on TML for > >thinks > >like sequential ordering. As a safer mode, I still prefer to have it > >as its > >original name of Sequence Number. Correlating request/reply messages > >should > >only be one of its functions. > > > >thanks, > >Weiming > > > >BTW, issue 47 looks like the same one...we should close one of these > >issues. > > > >regards > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > >Sent: Friday, June 10, 2005 9:12 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Robert, > > > >----- Original Message ----- > >From: "Robert Haas" > > > >New submission from Robert Haas : > > > >Adding a correlator seems useful: response messages can be matched to > >the > >request messages even if pipelining and reordering occurs. > >It seems that some are currently using the sequence number as a > >correlator: > >this can be dangerous, and not suitable for event notifications >messages > >(nothing to correlate with). > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > >let the > >response have the same SN as the sender. If so, I cannot follow well > >why it is > >dangerous and not suit for event notifications. Could you clarify this > >more? > > > >Thanks. > >Weiming > > > >But this introduces the risk of flooding an FE with too many commands >as > >there > >is no windowing mechanism in place (yet). > > > >---------- > >category: Technical > >draft: draft-ietf-forces-protocol > >messages: 129 > >nosy: rha > >priority: Should fix > >status: No discussion > >title: correlator in the PL message header > > > >___________________________________________________ > >Forces issue tracker > > > >___________________________________________________ 2005 Message-Id: Date: Sun, 12 Jun 2005 12:22:51 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jamal, Do you see a good reason to keep a SN? I don't see one since the TML provides reliability. If there is another reason, let us know...otherwise we should get rid of the SN. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, June 12, 2005 8:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. >=20 Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header.=20 cheers, jamal 2005 Message-Id: Date: Sun, 12 Jun 2005 12:20:32 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree, this was along the lines of my previous suggestion. I don't see the reason for having both a sequence number and a correlator....SN should not be needed by the PL since the TML provides reliability which guarantees in-order delivery (acc to the definition). Would you agree? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, June 12, 2005 8:00 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Actually, I would prefer to change the name. A Sequence number should have a different sequential value has I hand=20 messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies=20 should have the value from the request. These are not the same property. They may even be in conflict. Note that a request originator is capable of remembering the sequence in which it sends requests. Thus, for most purposes a correlator will do more than a sequence number. What a correlator does not provide is the ability to compare the order of a=20 received even and a received response. If some TML may disorder things, that would be lost information. If that is a big deal, we need two fields. But we can not simply treat the sequence number as the correlator. Yours, Joel At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: >Ok, so you're saying we should use the Sequence number as a Correlator. >If that is the case then we are in agreement, I think. We should update >the text. > >Let me know if I misunderstood you, >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Saturday, June 11, 2005 8:14 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >Yes, a Correlator is useful and currently we have been using the >Sequence number as correlator. I don't see any other use of the Sequence >number since reliability is provided by the TML. I think we should >change Sequence number to correlator in the draft and update the >description accordingly unless there is some use for a sequence number. > >[Weiming] I think it's too early to say the SN is only for correlation. >currently I don't think we should a hundred percent to rely on TML for >thinks >like sequential ordering. As a safer mode, I still prefer to have it >as its >original name of Sequence Number. Correlating request/reply messages >should >only be one of its functions. > >thanks, >Weiming > >BTW, issue 47 looks like the same one...we should close one of these >issues. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Friday, June 10, 2005 9:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Robert, > >----- Original Message ----- >From: "Robert Haas" > >New submission from Robert Haas : > >Adding a correlator seems useful: response messages can be matched to >the >request messages even if pipelining and reordering occurs. >It seems that some are currently using the sequence number as a >correlator: >this can be dangerous, and not suitable for event notifications messages >(nothing to correlate with). >[Weiming] I'm not sure if you mean to use the SN as a correlator is to >let the >response have the same SN as the sender. If so, I cannot follow well >why it is >dangerous and not suit for event notifications. Could you clarify this >more? > >Thanks. >Weiming > >But this introduces the risk of flooding an FE with too many commands as >there >is no windowing mechanism in place (yet). > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 129 >nosy: rha >priority: Should fix >status: No discussion >title: correlator in the PL message header > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Sun, 12 Jun 2005 11:36:47 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. > Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header. cheers, jamal 2005 Message-Id: Date: Sun, 12 Jun 2005 11:14:03 +0800 From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header ----- Original Message ----- From: "Khosravi, Hormuzd M" Yes, a Correlator is useful and currently we have been using the Sequence number as correlator. I don't see any other use of the Sequence number since reliability is provided by the TML. I think we should change Sequence number to correlator in the draft and update the description accordingly unless there is some use for a sequence number. [Weiming] I think it's too early to say the SN is only for correlation. currently I don't think we should a hundred percent to rely on TML for thinks like sequential ordering. As a safer mode, I still prefer to have it as its original name of Sequence Number. Correlating request/reply messages should only be one of its functions. thanks, Weiming BTW, issue 47 looks like the same one...we should close one of these issues. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, June 10, 2005 9:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Sun, 12 Jun 2005 11:00:25 -0400 From: "Joel M. Halpern" Subject: Re: [issue54] correlator in the PL message header Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Actually, I would prefer to change the name. A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict. Note that a request originator is capable of remembering the sequence in which it sends requests. Thus, for most purposes a correlator will do more than a sequence number. What a correlator does not provide is the ability to compare the order of a received even and a received response. If some TML may disorder things, that would be lost information. If that is a big deal, we need two fields. But we can not simply treat the sequence number as the correlator. Yours, Joel At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: >Ok, so you're saying we should use the Sequence number as a Correlator. >If that is the case then we are in agreement, I think. We should update >the text. > >Let me know if I misunderstood you, >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Saturday, June 11, 2005 8:14 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >Yes, a Correlator is useful and currently we have been using the >Sequence number as correlator. I don't see any other use of the Sequence >number since reliability is provided by the TML. I think we should >change Sequence number to correlator in the draft and update the >description accordingly unless there is some use for a sequence number. > >[Weiming] I think it's too early to say the SN is only for correlation. >currently I don't think we should a hundred percent to rely on TML for >thinks >like sequential ordering. As a safer mode, I still prefer to have it >as its >original name of Sequence Number. Correlating request/reply messages >should >only be one of its functions. > >thanks, >Weiming > >BTW, issue 47 looks like the same one...we should close one of these >issues. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Friday, June 10, 2005 9:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Robert, > >----- Original Message ----- >From: "Robert Haas" > >New submission from Robert Haas : > >Adding a correlator seems useful: response messages can be matched to >the >request messages even if pipelining and reordering occurs. >It seems that some are currently using the sequence number as a >correlator: >this can be dangerous, and not suitable for event notifications messages >(nothing to correlate with). >[Weiming] I'm not sure if you mean to use the SN as a correlator is to >let the >response have the same SN as the sender. If so, I cannot follow well >why it is >dangerous and not suit for event notifications. Could you clarify this >more? > >Thanks. >Weiming > >But this introduces the risk of flooding an FE with too many commands as >there >is no windowing mechanism in place (yet). > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 129 >nosy: rha >priority: Should fix >status: No discussion >title: correlator in the PL message header > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Sat, 11 Jun 2005 20:19:14 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: "Wang,Weiming" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, so you're saying we should use the Sequence number as a Correlator. If that is the case then we are in agreement, I think. We should update the text. Let me know if I misunderstood you, Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Saturday, June 11, 2005 8:14 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header ----- Original Message ----- From: "Khosravi, Hormuzd M" Yes, a Correlator is useful and currently we have been using the Sequence number as correlator. I don't see any other use of the Sequence number since reliability is provided by the TML. I think we should change Sequence number to correlator in the draft and update the description accordingly unless there is some use for a sequence number. [Weiming] I think it's too early to say the SN is only for correlation. currently I don't think we should a hundred percent to rely on TML for thinks like sequential ordering. As a safer mode, I still prefer to have it as its original name of Sequence Number. Correlating request/reply messages should only be one of its functions. thanks, Weiming BTW, issue 47 looks like the same one...we should close one of these issues. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, June 10, 2005 9:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Sat, 11 Jun 2005 19:29:48 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: cc: "Wang,Weiming" , Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, a Correlator is useful and currently we have been using the Sequence number as correlator. I don't see any other use of the Sequence number since reliability is provided by the TML. I think we should change Sequence number to correlator in the draft and update the description accordingly unless there is some use for a sequence number. BTW, issue 47 looks like the same one...we should close one of these issues. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, June 10, 2005 9:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Sat, 11 Jun 2005 00:11:54 +0800 From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 20:55:29 -0400 From: "Joel M. Halpern" Subject: Re: [issue55] Execution text replacement Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Looks good to me. Joel At 04:09 PM 6/10/2005, Jamal Hadi Salim wrote: >New submission from Jamal Hadi Salim : > >The following text is suggested replacement for the execution >section. Joel I hope i have caught you still there. I have downplayed that >text a little - so hopefully that should resolve it. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >files: operationrequest.txt >messages: 131 >nosy: jamal >priority: Must fix >status: Text proposed >title: Execution text replacement > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 20:09:00 +0000 From: Jamal Hadi Salim Subject: [issue55] Execution text replacement Content-Type: multipart/mixed; boundary="81.224.201.50.33.14587.1118434140.553.1" MIME-Version: 1.0 --81.224.201.50.33.14587.1118434140.553.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : The following text is suggested replacement for the execution section. Joel I hope i have caught you still there. I have downplayed that text a little - so hopefully that should resolve it. ---------- category: Technical draft: draft-ietf-forces-protocol files: operationrequest.txt messages: 131 nosy: jamal priority: Must fix status: Text proposed title: Execution text replacement ___________________________________________________ Forces issue tracker ___________________________________________________ --81.224.201.50.33.14587.1118434140.553.1 Content-Type: text/plain Content-Disposition: attachment; filename="operationrequest.txt" Content-Transfer-Encoding: 7bit 3.3.1.1 Execution ------------------ There are 3 execution modes that could be requested for a batch of operations spanning on one or more LFB selectors: a) Transactional execute-all-or-none b) Loose transactional execute-until-failure c) non-transactional continue-execute-on-failure 3.3.1.1.1 "all-or-none" Atomic transaction A transaction maybe atomic: a) within an FE alone * example updating multiple tables which are dependent on each other. If updating one fails, then any others already updated must be undone. b) across the NE. Example updating the same type of table(s) that are interdependent across several FEs (such as L3 forwarding related tables). 3.3.1.1.1.1 Transaction definition We define a transaction as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties[ACID], defined as: o *Atomicity*. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. o *Consistency*. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. o *Isolation*. A transaction in process and not yet committed must remain isolated from any other transaction. o *Durability*. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state. There are cases where the CE knows exact memory and implementation details of the FE such as in the case of a FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations maybe simplified further by extra computation at the CE. We do not discuss this view further other than to mention it in not dissallowed. For the purpose of interopability, we define a classical transactional protocol known as two phase commit which meets the ACID properties to be used for transactions. 3.3.1.1.1.2 Transaction protocol A 2PC starts with a START | ATOMIC flag on its first message of a transaction. A transaction may span multiple messages. It is up to the CE to keep track of the different seq #s making up a transaction. This may then be followed by more messages which are part of the same atomic transaction. [editorial note: Should we talk about correlators as markers for different transactions?] Any failure notified by the FE causes the CE to execute an ABORT to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. The transaction commitment phase is signalled by an empty DONE msg type. TBD: We may need an ABORT message(used for rollback purposes) or maybe a DONE with an ABORT flag to undo will suffice. 3.3.1.1.1.3 Recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the DONE message has left the CE and before it has received all the responses, (possibly the DONE never reached the FEs). At this point it is known that none of the operations failed but it is presumed that the data has not yet been made durable by the FEs. The means of detecting such failures may include loss of heartbeat (within the scope of ForCES) or mechanisms outside the scope of ForCES. When the associations are re-established, the CE will discover a transaction in an intermediate state. Some FEs will have made the data durable and closed the transaction; others may have failed while doing so, and may, or may not, still have that data. At this point the transaction enters the recovery phase. The CE re-issues an empty DONE message to all FEs involved in the transaction. Those that completed the transaction confirm this to the CE. Those that did not, commit the data and confirm this to the CE. An FE that has lost all records of the transaction MUST reply with status UNKNOWN and the actions subsequently taken by the CE are implementation dependent. This requires knowledge at both the CE and FE; not sure how to signal it. Global flags: ATOMIC, START, ABORT? (used by 2PC) New msg type: DONE, ABORT?(used by 2PC) 3.3.1.1.2 continue-execute-on-failure Several independent operations are targeted at one or more LFB selectors by the CE. Execution continues at the FE even when one or more operations fail. This mode is signalled by a missing ATOMIC flag. Explicit failures are indicated back to the CE if requested. 3.3.1.1.3 Loose transactional execute-until-failure In which all operations are executed on FE sequentially until first failure. The rest of the operations are not executed but everything upto failed is not undone unlike the case of all-or-none execution. flag: GOTON (global) 3.3.1.1.4 Relation to Multipart messages Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. There has to be consistency across the multi parts of the messages. In other words the first message starting with mode #1 above, implies the rest do. Any inconsitency implies a cancelled transaction in which all messages are dropped and the sender NACKED. $Log: operationrequest.txt,v $ Revision 1.2 2005/06/10 19:38:28 hadi sent to the list - reworded the two schools of thought - changed naming convention of goto-N and one-of-N , Revision 1.1 2005/06/06 16:29:58 hadi Initial revision --81.224.201.50.33.14587.1118434140.553.1-- 2005 Message-Id: Date: Fri, 10 Jun 2005 16:21:24 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Ok, there are two issues as i see it: 1) showing what is possible. Thats the goal of the example. 2) Showing whats sensible given what we know at the moment. This is what you are striving for. We should show #2 first, but we should show the possibilities next. If we think it is ridiculous/absurd to have that flexibilty then the grammar shouldnt allow it - otherwise it's a poor design. cheers, jamal On Fri, 2005-10-06 at 14:53 +0200, Robert Haas wrote: > I don't mean the example is illegal, I only think it is absurd, but I > may be missing sth. > What about the following example of a tree with two branches ? I guess > what I am saying is that a reasonable design would try to make the > branches as short as possible. > 2005 Message-Id: Date: Fri, 10 Jun 2005 16:01:14 +0000 From: Robert Haas Subject: [issue54] correlator in the PL message header Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the=20 request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator:=20 this can be dangerous, and not suitable for event notifications messages=20 (nothing to correlate with). But this introduces the risk of flooding an FE with too many commands as th= ere=20 is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 15:02:20 -0700 From: "Putzolu, David" Subject: FW: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, draft submission deadlines are coming! -David =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ietf-secretariat@ietf.org Sent: Thursday, June 09, 2005 9:00 PM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France=20 There are two (2) Internet-Draft cutoff dates for the 63rd=20 IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 July 11th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Tuesday,=20 July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, August 1st at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or=20 revised Internet-Draft after their respective cutoff deadlines, then=20 your document will be retained and posted when Internet-Draft=20 processing resumes. You will no longer be required to resubmit the=20 document. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce 2005 Message-Id: Date: Fri, 10 Jun 2005 14:53:30 +0200 From: Robert Haas Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: hadi@znyx.com Comments: cc: tracker-forces@mip4.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I don't mean the example is illegal, I only think it is absurd, but I=20 may be missing sth. What about the following example of a tree with two branches ? I guess=20 what I am saying is that a reasonable design would try to make the=20 branches as short as possible. T =3D SET-CREATE | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T =3D Path-data | | | | | + -- flags | | + -- IDCount | | + -- IDs | | + -- T =3D KEYINFO | | | + -- KEY_ID | | | + -- KEY_DATA | | | | | + -- T =3D DATARAW | | + -- data | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | + -- T =3D KEYINFO | | + -- KEY_ID | | + -- KEY_DATA | | | + -- T =3D DATARAW | + -- data=20 Regards, -Robert Jamal Hadi Salim wrote: >On Fri, 2005-10-06 at 14:14 +0200, Robert Haas wrote: > =20 > >>Here is what I mean: in the example below (excerpt from Fig. 11), a=20 >>reasonable approach would be to have a single longer path-data instead=20 >>of 3 segmented ones. But if the tree had more branches, for instance=20 >>under the first path-data segment or the second one, then I would=20 >>understand why one would do so. So the current example is a bad example= =20 >>to my mind. Or am I missing sth ? >> >> =20 >> > >The motivation behind fig 11 is to show the different nesting levels a >path could take to get to the target path. >Can you redraw it so that we still show the deep nesting? >I actually didnt follow you completely - theres nothing i could see in >that tree that indicates it has few branches. > >cheers, >jamal > > > =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: Fri, 10 Jun 2005 14:14:17 +0200 From: Robert Haas Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: hadi@znyx.com Comments: cc: tracker-forces@mip4.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Here is what I mean: in the example below (excerpt from Fig. 11), a=20 reasonable approach would be to have a single longer path-data instead=20 of 3 segmented ones. But if the tree had more branches, for instance=20 under the first path-data segment or the second one, then I would=20 understand why one would do so. So the current example is a bad example=20 to my mind. Or am I missing sth ? Regards, -Robert T =3D SET-CREATE | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | + -- T =3D KEYINFO | | + -- KEY_ID | | + -- KEY_DATA | | | + -- T =3D DATARAW | + -- data | | Jamal Hadi Salim wrote: >On Fri, 2005-10-06 at 08:21 +0000, Robert Haas wrote: > =20 > >>New submission from Robert Haas : >> >>Sec 6.1.1.1.6 SET and GET Relationship >>[...] >>Fig. 11: Sample operation layout >> >>Why is the path-data segmented 3 times for the SET-CREATE operation ? I= =20 >>thought that this was necessary only each time a different KEY was used= ? >>May need a better example ... >> >> =20 >> > >You must mean "6.1.2 Protocol Visualization" >The grammar says: >. >. >PATH-DATA-TLV :=3D PATH [DATA] >PATH :=3D flags IDcount IDs [SELECTOR] >.. >DATA :=3D DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV >. >. > >I dont see any thing that makes it illegal. Did we have some discussion = which >reached a conclusion that it can only be done via KEY? > >cheers, >jamal > > > =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: Fri, 10 Jun 2005 12:52:16 +0000 From: Weiming Wang Subject: [issue53] How a path should be defined in Packet Redirect Message? Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Weiming Wang : in draft-ietf-forces-protocol-03.txt Section 6.8 Packet Redirect Message, The operation TLV is defined as: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D PAYLOAD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path(or Sequence Number?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Redirected Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26 Path(or Sequence Number?): [Under discussion and TBD] The question is how the Path should be defined here? ---------- category: Technical draft: draft-ietf-forces-protocol messages: 119 nosy: weiming priority: Must fix status: Text proposed title: How a path should be defined in Packet Redirect Message? ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 11:48:21 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Multiple processes in the CE talking to the same FE LFBs Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 09:15 -0400, Joel M. Halpern wrote: > I would put the correlator in the main header. This would be fine with me. I have no immediate use for it; Lets hear what other folks have to say. cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 09:23:34 -0400 From: "Joel M. Halpern" Subject: Re: [issue49] Sec 6.1.1.1.6 SET and GET Relationship Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The example looks right. The path indicates the whole table. Therefore the whole table will be replaced with one where the entries are the same as they were at the time of the get. Yours, Joel At 07:53 AM 6/10/2005, Jamal Hadi Salim wrote: >On Fri, 2005-10-06 at 08:19 +0000, Robert Haas wrote: > > New submission from Robert Haas : > > > > Sec 6.1.1.1.6 SET and GET Relationship > > [...] > > 2. When dumping a whole table in a GET, the GET-RESPONSE, merely > editing the T > > to be SET will endup overwritting the table. > > > > I had a syntax error reading the sentence above ... > >The intent was to describe the exception to the rule of converting the >GET-RESPONSE to a SET. > >1. If you are dump a table using a GET >2. The GET-RESPONSE will contain a path to the table >3. Merely editing the GET-RESPONSE to be a SET would imply overwritting >the existing table defined in the path. > >Perhaps we should provide an example for clarity? > >Joel, can you look at example 4 in the appendix in relation to this? > >cheers, >jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 09:15:37 -0400 From: "Joel M. Halpern" Subject: Re: Multiple processes in the CE talking to the same FE LFBs Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I would put the correlator in the main header. Not only is it useful if the CE is multiple processes, but it is useful if the FE can respond to pipelined requests out of order. (Suppose that some operations require long hardware manipulation, and some just update a table. One could easily have responses come back out of order. The correlator makes that a non-issue. The absence of the correlator in HTTP makes some things "interesting".) Yours, Joel At 07:00 AM 6/10/2005, Jamal Hadi Salim wrote: > > On the other hand, Request - Response correlators are a very good idea, > for > > many reasons. > > > >Where would you stick the correlator in the message in such a case? >Is it a TLV in the top hierachy or would there be another 32 bit in the >main header? > >We have not so far needed the correlator so far for the simple reason >that we have a _single process_ - so all messages get the opportunity to >be demux from a single point. We do use the sequence number as a >correlator when we have some app using the NPF APIs over forces in >particular. >Regardless: should be noted that this(single process/task) is >implementation detail i.e that there are other ways to implement. >It is more efficient for us to implement a single task - but i do wonder >about implementations that have multi processes. Our coding has not yet >got to HA, but i have been worried at times while doodling on paper that >we may need something akin to a second 32 bit number. >Now if one was to use TIPC as a TML, TIPC would take care of this >demuxing amongst multi processes since it is inheritenly good at IPCs >(thats where the IPC in TIPC comes from ;->). But again that would be >implementation specific. > >cheers, >jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 09:15:34 +0000 From: Robert Haas Subject: [issue52] Association Setup Response Message: unclear use of SHOW Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : 6=2E4.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 ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 09:08:51 -0400 From: "Joel M. Halpern" Subject: Re: [issue46] Up to 8 priorities supported by the TML Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I think there are two issues here. I don't think that we wanted to require that all TMLs be able to handle 8 different priorities. We expected that some would handle only two. On the other hand, I think we did want to require that the TML give different handling to some levels. To make that useful, we may want to specify a little more (like, if the TML does two levels that 0-3 go in one level and 4-7 go in the other.) Yours, Joel At 04:13 AM 6/10/2005, Robert Haas wrote: >New submission from Robert Haas : > >Sec 4 >[...] >It is expected that the TML will be able to handle up to 8 priority levels >needed by the PL layer and will provide preferential treatment. > >Writing "up to" means that the TML may support no priorities at all too. Is >this what we intended to say ? Clarify and write MAY, SHOULD or MUST. > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 103 >nosy: rha >priority: Should fix >status: No discussion >title: Up to 8 priorities supported by the TML > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:24:04 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 14:14 +0200, Robert Haas wrote: > Here is what I mean: in the example below (excerpt from Fig. 11), a > reasonable approach would be to have a single longer path-data instead > of 3 segmented ones. But if the tree had more branches, for instance > under the first path-data segment or the second one, then I would > understand why one would do so. So the current example is a bad example > to my mind. Or am I missing sth ? > The motivation behind fig 11 is to show the different nesting levels a path could take to get to the target path. Can you redraw it so that we still show the deep nesting? I actually didnt follow you completely - theres nothing i could see in that tree that indicates it has few branches. cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 08:23:04 +0000 From: Robert Haas Subject: [issue51] Operation Summary table Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : 6=2E10 Operation Summary In the table, change "Event" in the "Operation" column by "Report" in order= to=20 be consistent with the prior descriptions. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 108 nosy: rha priority: Should fix status: No discussion title: Operation Summary table ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:21:48 +0000 From: Robert Haas Subject: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 6.1.1.1.6 SET and GET Relationship [=2E..] Fig. 11: Sample operation layout Why is the path-data segmented 3 times for the SET-CREATE operation ? I=20 thought that this was necessary only each time a different KEY was used ? May need a better example ... ---------- category: Technical draft: draft-ietf-forces-protocol messages: 107 nosy: rha priority: Should fix status: No discussion title: Fig.11 Sample operation layout: successive breakdown of the path-data ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:19:58 +0000 From: Robert Haas Subject: [issue49] Sec 6.1.1.1.6 SET and GET Relationship Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 6.1.1.1.6 SET and GET Relationship [=2E..] 2=2E When dumping a whole table in a GET, the GET-RESPONSE, merely editing = the T=20 to be SET will endup overwritting the table. I had a syntax error reading the sentence above ... ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 106 nosy: rha priority: Should fix status: No discussion title: Sec 6.1.1.1.6 SET and GET Relationship ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:18:55 +0000 From: Robert Haas Subject: [issue48] Data Packing Rules: addressing tables Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 6.1.1.1.1 Data Packing Rules [=2E..] When a table is refered in the PATH (ids), then the RAWDATA's V will contai= n=20 that tables row content prefixed by its 32 bit index/ subscript OTOH, when=20 SELECTOR flags are 00, the PATH may contain an index pointing to a row in=20 table; in such a case, the RAWDATA's V will only contain the content with t= he=20 index in order to avoid ambiguity.=20 This paragraph is far from clear ... maybe correct "PATH flags" instead=20 of "SELECTOR flags" as there are no flags defined in the SELECTOR. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 105 nosy: rha priority: Should fix status: No discussion title: Data Packing Rules: addressing tables ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:16:54 +0000 From: Robert Haas Subject: [issue47] PDU sequence number, use of correlator Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 5.1 Common Header [=2E..] Sequence [number is] Unique to a PDU. So a response message will have a different sequence number than the origin= al=20 request message. This is OK as long as nobody tries to use the Sequence num= ber=20 as a correlator for request/responses ... Should we introduce a request/response correlator ? ---------- category: Technical draft: draft-ietf-forces-protocol messages: 104 nosy: rha priority: Should fix status: No discussion title: PDU sequence number, use of correlator ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:13:50 +0000 From: Robert Haas Subject: [issue46] Up to 8 priorities supported by the TML Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 4 [=2E..] It is expected that the TML will be able to handle up to 8 priority levels=20 needed by the PL layer and will provide preferential treatment. Writing "up to" means that the TML may support no priorities at all too. Is=20 this what we intended to say ? Clarify and write MAY, SHOULD or MUST. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 103 nosy: rha priority: Should fix status: No discussion title: Up to 8 priorities supported by the TML ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:11:03 +0000 From: Robert Haas Subject: [issue45] Definition of inter-TML protocol level schemes Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 4 TML Requirements [=2E..] As an example they could be defined to be delivered via hardware or inter- = TML=20 protocol level schemes. = =20 Where did we define what "inter-TML" means ? ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 102 nosy: rha priority: Should fix status: No discussion title: Definition of inter-TML protocol level schemes ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:07:58 +0000 From: Robert Haas Subject: [issue44] FE, CE, and FE protocol LFBs Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 3.3.2 FE, CE, and FE protocol LFBs syntax problem: All PL messages follow the LFB structure as this provides more flexibility = for=20 future enhancements. This means maintanance and configurability of FEs, NE,= as=20 well as the protocol require a fit in the LFB architecture. For this reason=20 special LFBs are created to accomodate this need. I would rephrase the paragraph as follows (hopefully more clear :) All PL messages operate on LFB structures as this provides more flexibility=20 for future enhancements. This means that maintenance and configurability of=20 FEs, NE, as well as the ForCES protocol itself must be expressed in terms o= f=20 this LFB architecture. For this reason special LFBs are created to accomoda= te=20 this need. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 101 nosy: rha priority: Should fix status: Text proposed title: FE, CE, and FE protocol LFBs ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 08:04:47 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 08:21 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 6.1.1.1.6 SET and GET Relationship > [...] > Fig. 11: Sample operation layout > > Why is the path-data segmented 3 times for the SET-CREATE operation ? I > thought that this was necessary only each time a different KEY was used ? > May need a better example ... > You must mean "6.1.2 Protocol Visualization" The grammar says: . . PATH-DATA-TLV := PATH [DATA] PATH := flags IDcount IDs [SELECTOR] .. DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV . . I dont see any thing that makes it illegal. Did we have some discussion which reached a conclusion that it can only be done via KEY? cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 07:53:28 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue49] Sec 6.1.1.1.6 SET and GET Relationship Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 08:19 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 6.1.1.1.6 SET and GET Relationship > [...] > 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing the T > to be SET will endup overwritting the table. > > I had a syntax error reading the sentence above ... The intent was to describe the exception to the rule of converting the GET-RESPONSE to a SET. 1. If you are dump a table using a GET 2. The GET-RESPONSE will contain a path to the table 3. Merely editing the GET-RESPONSE to be a SET would imply overwritting the existing table defined in the path. Perhaps we should provide an example for clarity? Joel, can you look at example 4 in the appendix in relation to this? cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 07:43:12 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue48] Data Packing Rules: addressing tables Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 08:18 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 6.1.1.1.1 Data Packing Rules > [...] > When a table is refered in the PATH (ids), then the RAWDATA's V will contain > that tables row content prefixed by its 32 bit index/ subscript OTOH, when > SELECTOR flags are 00, the PATH may contain an index pointing to a row in > table; in such a case, the RAWDATA's V will only contain the content with the > index in order to avoid ambiguity. > > This paragraph is far from clear ... maybe correct "PATH flags" instead > of "SELECTOR flags" as there are no flags defined in the SELECTOR. Yes, that text may not be very clear that early in the draft - I cant think of a better way to say it - suggest some text. And they are "PATH flags" not SELECTOR flags (which at some point was actually the correct term to use). As a note, the text bullet: "As an example a 16 bit value will have an extra 16 bit pad ..." should be indented. cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 07:24:51 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue46] Up to 8 priorities supported by the TML Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 08:13 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 4 > [...] > It is expected that the TML will be able to handle up to 8 priority levels > needed by the PL layer and will provide preferential treatment. > > Writing "up to" means that the TML may support no priorities at all too. Is > this what we intended to say ? Clarify and write MAY, SHOULD or MUST. > There may be cases where the underlying transport and hence the TML is not capable of 8 levels even when the PL wishes it to be so. Unless we define the semantics of the prioritization to mean between PL and TML. cheers, jamal PS:- I am responding to as many tracked issues which have shown up so we can reach faster closure. 2005 Message-Id: Date: Fri, 10 Jun 2005 07:20:26 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue45] Definition of inter-TML protocol level schemes Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Fri, 2005-10-06 at 08:11 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 4 TML Requirements > [...] > As an example they could be defined to be delivered via hardware or inter- TML > protocol level schemes. > > Where did we define what "inter-TML" means ? > I may have been responsible for that text; it was intended to mean between two or more TML processes on different CE/FEs. Could probably explicitly say so instead? cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 07:16:44 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue44] FE, CE, and FE protocol LFBs Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain I agree - the new text provides more clarity. cheers, jamal On Fri, 2005-10-06 at 08:07 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 3.3.2 FE, CE, and FE protocol LFBs > > syntax problem: > All PL messages follow the LFB structure as this provides more flexibility for > future enhancements. This means maintanance and configurability of FEs, NE, as > well as the protocol require a fit in the LFB architecture. For this reason > special LFBs are created to accomodate this need. > > I would rephrase the paragraph as follows (hopefully more clear :) > > All PL messages operate on LFB structures as this provides more flexibility > for future enhancements. This means that maintenance and configurability of > FEs, NE, as well as the ForCES protocol itself must be expressed in terms of > this LFB architecture. For this reason special LFBs are created to accomodate > this need. > > ---------- > category: Editorial > draft: draft-ietf-forces-protocol > messages: 101 > nosy: rha > priority: Should fix > status: Text proposed > title: FE, CE, and FE protocol LFBs > > ___________________________________________________ > Forces issue tracker > > ___________________________________________________ 2005 Message-Id: Date: Fri, 10 Jun 2005 07:00:46 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Multiple processes in the CE talking to the same FE LFBs Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-09-06 at 09:22 -0400, Joel M. Halpern wrote: > I don;t think there should be higher layer demux in the sense below. > I believe that the ForCES messges will need to be processed by the ForCES > interface, turned into meaningful information for the CE internal > activities, and passed on to the relevant component(s). > > In general, I think that the selection of which component is interested in > ForCES information is going to be based on semantics, not on demux > identifiers in the message. > > Note that specifically as drawn in the diagram it would be exceedingly > unlikely for OSPF, RIP, and BGP to interact directly with LFBs. They will > interact with some form of RIB, which in turn (at least logically) drives > some sort of FIB process. > To carry the example further, if one also has MPLS one can easily imagine > FE notifications which are of interest to both the FIB and LIB > activities. and the FE would have no reasonable way of even knowing > that. Explicit demux seems the wrong answer. > > > On the other hand, Request - Response correlators are a very good idea, for > many reasons. > Where would you stick the correlator in the message in such a case? Is it a TLV in the top hierachy or would there be another 32 bit in the main header? We have not so far needed the correlator so far for the simple reason that we have a _single process_ - so all messages get the opportunity to be demux from a single point. We do use the sequence number as a correlator when we have some app using the NPF APIs over forces in particular. Regardless: should be noted that this(single process/task) is implementation detail i.e that there are other ways to implement. It is more efficient for us to implement a single task - but i do wonder about implementations that have multi processes. Our coding has not yet got to HA, but i have been worried at times while doodling on paper that we may need something akin to a second 32 bit number. Now if one was to use TIPC as a TML, TIPC would take care of this demuxing amongst multi processes since it is inheritenly good at IPCs (thats where the IPC in TIPC comes from ;->). But again that would be implementation specific. cheers, jamal 2005 Message-Id: Date: Fri, 10 Jun 2005 06:27:58 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue40] BLKINFO Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Thu, 2005-09-06 at 21:07 -0700, Putzolu, David wrote: > (hat off) > I am in agreement with Joel, I'd prefer to only add optimizations after > we get some operational experience that shows where the bottlenecks really are. > We still have BLOCK operations in our implementation and it is useful - so you could say we have operational experience. However, for the sake of progress(so we can last call) and hopefully without need to repeat the discussion we already had on the list: Can we find a way to allow for proprietary implementations to do BLK without much difficulty while at the same time not affecting the protocol itself for anyone else? Would a capability announcement by the FE do it? cheers, jamal 2005 Message-Id: Date: Thu, 9 Jun 2005 21:07:08 -0700 From: "Putzolu, David" Subject: Re: [issue40] BLKINFO Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (hat off)=20 I am in agreement with Joel, I'd prefer to only add optimizations after = we get some operational experience that shows where the bottlenecks = really are. -David -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, June 09, 2005 6:04 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue40] BLKINFO I am still not convinced of the value, and would prefer to defer BLOCK=20 constructs until we have some experience to know what enhancements we=20 really need. Yours, Joel At 08:57 AM 6/9/2005, Robert Haas wrote: >I just re-read the relevant thread =C3 propos BLOCK selector. It seems = that=20 >besides Jamal and myself, nobody else declared whether the proposal=20 >(repeated below) would be satisfactory and should be included in the=20 >draft. Please let us know. >Regards, >-Robert > > From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)": > >As an alternative, couldn't we just add a flag to the BLOCK selector to = >distinguish the two cases ? > >- BLOCK REPLICATE, with only the all-to-all semantic >- BLOCK LIST, with only the one-to-one semantic. > >So while processing a ForCES message, one does not have to infer the=20 >meaning of BLOCK based on the content (is it all-to-all or one-to-one). = >Instead the flag will tell immediately. > > >Avri Doria wrote: > >>New submission from Avri Doria : >> >>* NOTE! NOTE! There is a selector known as BLKINFO that is left >> out of this doc for now that will be revisted later. BLKINFO >> is defined as: >> * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV = :=3D >> [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A >> PathData can only have one selector either a KEYINFO TLV or a >> BLKINFO TLV (i.e not both). >> >>Revisit before PS or after? >> >>---------- >>category: Editorial >>draft: draft-ietf-forces-protocol >>messages: 58 >>nosy: avri >>priority: May fix >>status: No discussion >>title: BLKINFO >> >>___________________________________________________ >>Forces issue tracker >> >>___________________________________________________ >> >> >> > >-- >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/~rha 2005 Message-Id: Date: Thu, 9 Jun 2005 15:05:38 +0200 From: Robert Haas Subject: Multiple processes in the CE talking to the same FE LFBs MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Re-reading the draft I realize that we show in Fig. 2 how multiple=20 processes (OSPF, RIP, etc) interface with the ForCES layer, but we never=20 explain how the demuxing occurs. Some exchanges in this old thread=20 suggested to use PL sequence number, PL message types, and/or LFB=20 Instance IDs as a means to correlate and demux a ForCES response to the=20 appropriate process that sent the request. One could even store the=20 entire request messages and event registrations in order to match=20 responses appropriately. Such solutions are mere by-products (not to say=20 hacks ;-) Another solution consists in adding a correlator in the CE-originated PL=20 messages that must be returned in the FE responses and event notification= s. I am interested to hear how others have addressed this issue. Regards, -Robert Robert Haas wrote: > Hormuzd, > > Khosravi, Hormuzd M wrote: > >> Robert, >> >> My comments on this inline.... >> -----Original Message----- >> From: Forwarding and Control Element Separation >> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >> >> Coming back to implementation issues that fire up in the protocol: >> >> In the case of a single active CE, there can be multiple processes=20 >> "hiding" behind the same CE ID, i.e., a process updating firewalling=20 >> rules and another process updating the routing table, in parallel. We=20 >> must be able to: >> >> 1) correlate at the CE the responses from the FE with the commands=20 >> that were originated by each process. >> 2) forward at the CE FE-event notifications to the appropriate=20 >> processes that registered for it. >> >> So if the CE ID is the same for all these processes, something is=20 >> missing in the protocol to support 1) and 2) ... Unless the ForCES=20 >> PL decides to use different TCP/UDP ports for each process (I=20 >> wouldn't recommend this), but this will anyway not solve 2). >> >> [HK] This is more of an implementation issue than a protocol issue in = my >> opinion. You could have the ForCES protocol daemon demuxing between >> different processes using a shim layer with standard IPC. The shim lay= er >> would take care of translating requests from different processes to >> different ForCES protocol message types, sequence nos, etc. Let me kno= w >> if this sounds reasonable or I am missing something here? >> =20 >> > How far did you go with your implementation of demuxing ? In our case,=20 > we found that relying on sequence numbers or message types is not=20 > useful when you want to direct an event notification coming from the=20 > FE to the appropriate process in the CE. But maybe you found a way to=20 > solve that ? > > I hope that with our implementations we will find not only=20 > implementation issues, but protocol issues too. I doubt we can get the=20 > protocol right on the first shot. > >> >> BTW, the multi-CE problem is something one should still think of=20 >> while defining the model. Although the requirements draft only talks=20 >> of a single active CE for each FE, it is a scalability issue if I=20 >> can't run the firewalling and routing processes on two different=20 >> boxes (i.e. two CEs). So let's at least consider the impact of the=20 >> multi-manager problem >> >> on the model so we don't close all the doors for future support. >> >> [HK] I agree with Joel on this. I believe this is something which can = be >> addresses in a later rev of the protocol draft. We should focus on >> getting the basic protocol messages/encoding correct at this point. Th= at >> itself is not a straight forward task cause of the many tradeoffs. We >> can come back to the multi-CE issue in the next version of the protoco= l. >> >> =20 >> > I would treat this the same way we treated the keys: make provision=20 > for multi-CE support in the model as early as possible as it may=20 > otherwise become more difficult to include it later. > > For instance, whenever CEs register for events: the model should not=20 > only indicate with a boolean if a CE has registered to be notified=20 > when the event occurs, but also include a list of the CEs that have=20 > registered for the same event. Limited complexity for the model,=20 > almost no additional complexity for the protocol. > > Regards, > -Robert > >> Regards >> Hormuzd >> >> Joel M. Halpern wrote: >> >> =20 >> >>> I thought we had agreed that for now we would focus on a single activ= e >>> =20 >> >> >> =20 >> >>> CE per FE> An FE that wants to be managed by several CEs is (I=20 >>> thought) to pretend it is several FEs, probably with distinct >>> =20 >> >> resources. >> =20 >> >>> The multi-manager problem is very very messy. >>> >>> =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: Thu, 9 Jun 2005 14:57:23 +0200 From: Robert Haas Subject: Re: [issue40] BLKINFO Comments: cc: Forces issue tracker MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I just re-read the relevant thread =C3=A0 propos BLOCK selector. It seems= =20 that besides Jamal and myself, nobody else declared whether the proposal=20 (repeated below) would be satisfactory and should be included in the=20 draft. Please let us know. Regards, -Robert From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)": As an alternative, couldn't we just add a flag to the BLOCK selector to=20 distinguish the two cases ? - BLOCK REPLICATE, with only the all-to-all semantic - BLOCK LIST, with only the one-to-one semantic. So while processing a ForCES message, one does not have to infer the=20 meaning of BLOCK based on the content (is it all-to-all or one-to-one).=20 Instead the flag will tell immediately. =20 Avri Doria wrote: >New submission from Avri Doria : > >* NOTE! NOTE! There is a selector known as BLKINFO that is left > out of this doc for now that will be revisted later. BLKINFO > is defined as: > * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=3D > [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A > PathData can only have one selector either a KEYINFO TLV or a > BLKINFO TLV (i.e not both). > >Revisit before PS or after? > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 58 >nosy: avri >priority: May fix >status: No discussion >title: BLKINFO > >___________________________________________________ >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: Thu, 9 Jun 2005 14:56:14 +0200 From: Robert Haas Subject: Re: draft-ietf-forces-protocol-03.txt Comments: To: avri@psg.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Avri, All, I took a fresh look at the draft and noted the following errors and/or=20 inconsistencies. Regards, -Robert Sec 3.3.2 FE, CE, and FE protocol LFBs syntax problem: All PL messages follow the LFB structure as this provides more=20 flexibility for future enhancements. This means maintanance and=20 configurability of FEs, NE, as well as the protocol require a fit in the=20 LFB architecture. For this reason special LFBs are created to accomodate=20 this need. I would rephrase the paragraph as follows (hopefully more clear :) All PL messages operate on LFB structures as this provides more=20 flexibility for future enhancements. This means that maintenance and=20 configurability of FEs, NE, as well as the ForCES protocol itself must=20 be expressed in terms of this LFB architecture. For this reason special=20 LFBs are created to accomodate this need. typo: The FE Protocol LFB also contains the various ForCES ID to be used:=20 unicast IDs a table of the PL multicast IDs the FE must be listening to. =20 ^ add "and" after=20 "unicast IDs". Sec 4 TML Requirements As an example they could be defined to be delivered via hardware or=20 inter- TML protocol level schemes. =20 ^ where did we define what=20 "inter-TML" means ? It is expected that the TML will be able to handle up to 8 priority=20 levels needed by the PL layer and will provide preferential treatment. =20 ^ writing "up to" means that the TML may support no priorities at=20 all too. Is this what we intended to say ? Sec 5.1 Common Header Sequence [number is] Unique to a PDU. So a response message will have a different sequence number than the=20 original request message. This is OK as long as nobody tries to use the=20 Sequence number as a correlator for request/responses ... Sec 6.1.1.1.1 Data Packing Rules Sorry, but the paragraph below is far from clear ... maybe correct=20 "PATH flags" instead of "SELECTOR flags" as there are no flags defined=20 in the SELECTOR. But this remains still obscure. When a table is refered in the PATH (ids), then the RAWDATA's V will=20 contain that tables row content prefixed by its 32 bit index/ subscript=20 OTOH, when SELECTOR flags are 00, the PATH may contain an index pointing=20 to a row in table; in such a case, the RAWDATA's V will only contain the=20 content with the index in order to avoid ambiguity. Sec 6.1.1.1.6 SET and GET Relationship I had a syntax error reading the sentence below ... 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing=20 the T to be SET will endup overwritting the table. Fig. 11: Sample operation layout Why is the path-data segmented 3 times for the SET-CREATE operation ? I=20 thought that this was necessary only each time a different KEY was used ? Sec 6.3 Semantics of message Direction Note that the semantics of the message direction are different for=20 event notifications originated at the CE LFB: in that case the LFB=20 selector points to the event of the CE. Sec 6.4.2 Association Setup Response Message There is no reason to have SHOW operations about the FE object and/or=20 FE protocol object here. I don't understand this and would rather use a=20 separate CONFIG message to set the HBI ,for instance. 6.4.3 Association Teardown Message What is this new operation type FEReason ? 6.10 Operation Summary In the table, change "Event" in the "Operation" column by "Report" in=20 order to be consistent with the prior descriptions. avri@psg.com wrote: > Hi, > > on june 02 i tried to submit the latest draft to the id editor. but=20 > it was rejected because i mentioned rfc 3668 instead of bcp79. =20 > unfortunately i was away from email and did not see this rejection=20 > until this morning. > > i have resubmitted it. and hopefully this time have correctly dealt=20 > with the bureaucratic minutia. but in case i haven't, or in the=20 > meantime, a copy can be found in: > http://psg.com/~avri/forces/draft-ietf-forces-protocol-03.txt > > a. > > --=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, 9 Jun 2005 09:22:31 -0400 From: "Joel M. Halpern" Subject: Re: Multiple processes in the CE talking to the same FE LFBs Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable I don;t think there should be higher layer demux in the sense below. I believe that the ForCES messges will need to be processed by the ForCES=20 interface, turned into meaningful information for the CE internal=20 activities, and passed on to the relevant component(s). In general, I think that the selection of which component is interested in= =20 ForCES information is going to be based on semantics, not on demux=20 identifiers in the message. Note that specifically as drawn in the diagram it would be exceedingly=20 unlikely for OSPF, RIP, and BGP to interact directly with LFBs. They will= =20 interact with some form of RIB, which in turn (at least logically) drives=20 some sort of FIB process. To carry the example further, if one also has MPLS one can easily imagine=20 FE notifications which are of interest to both the FIB and LIB=20 activities. and the FE would have no reasonable way of even knowing=20 that. Explicit demux seems the wrong answer. On the other hand, Request - Response correlators are a very good idea, for= =20 many reasons. Yours, Joel M. Halpern At 09:05 AM 6/9/2005, Robert Haas wrote: >Re-reading the draft I realize that we show in Fig. 2 how multiple=20 >processes (OSPF, RIP, etc) interface with the ForCES layer, but we never=20 >explain how the demuxing occurs. Some exchanges in this old thread=20 >suggested to use PL sequence number, PL message types, and/or LFB Instance= =20 >IDs as a means to correlate and demux a ForCES response to the=20 >appropriate process that sent the request. One could even store the entire= =20 >request messages and event registrations in order to match responses=20 >appropriately. Such solutions are mere by-products (not to say hacks ;-) > >Another solution consists in adding a correlator in the CE-originated PL=20 >messages that must be returned in the FE responses and event notifications. > >I am interested to hear how others have addressed this issue. > >Regards, >-Robert > > >Robert Haas wrote: > >>Hormuzd, >> >>Khosravi, Hormuzd M wrote: >> >>>Robert, >>> >>>My comments on this inline.... >>>-----Original Message----- >>>From: Forwarding and Control Element Separation >>>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >>> >>>Coming back to implementation issues that fire up in the protocol: >>> >>>In the case of a single active CE, there can be multiple processes=20 >>>"hiding" behind the same CE ID, i.e., a process updating firewalling=20 >>>rules and another process updating the routing table, in parallel. We=20 >>>must be able to: >>> >>>1) correlate at the CE the responses from the FE with the commands that= =20 >>>were originated by each process. >>>2) forward at the CE FE-event notifications to the appropriate=20 >>>processes that registered for it. >>> >>>So if the CE ID is the same for all these processes, something is=20 >>>missing in the protocol to support 1) and 2) ... Unless the ForCES PL=20 >>>decides to use different TCP/UDP ports for each process (I wouldn't=20 >>>recommend this), but this will anyway not solve 2). >>> >>>[HK] This is more of an implementation issue than a protocol issue in my >>>opinion. You could have the ForCES protocol daemon demuxing between >>>different processes using a shim layer with standard IPC. The shim layer >>>would take care of translating requests from different processes to >>>different ForCES protocol message types, sequence nos, etc. Let me know >>>if this sounds reasonable or I am missing something here? >>> >>How far did you go with your implementation of demuxing ? In our case, we= =20 >>found that relying on sequence numbers or message types is not useful=20 >>when you want to direct an event notification coming from the FE to the=20 >>appropriate process in the CE. But maybe you found a way to solve that ? >> >>I hope that with our implementations we will find not only implementation= =20 >>issues, but protocol issues too. I doubt we can get the protocol right on= =20 >>the first shot. >> >>> >>>BTW, the multi-CE problem is something one should still think of while=20 >>>defining the model. Although the requirements draft only talks of a=20 >>>single active CE for each FE, it is a scalability issue if I can't run=20 >>>the firewalling and routing processes on two different boxes (i.e. two=20 >>>CEs). So let's at least consider the impact of the multi-manager problem >>> >>>on the model so we don't close all the doors for future support. >>> >>>[HK] I agree with Joel on this. I believe this is something which can be >>>addresses in a later rev of the protocol draft. We should focus on >>>getting the basic protocol messages/encoding correct at this point. That >>>itself is not a straight forward task cause of the many tradeoffs. We >>>can come back to the multi-CE issue in the next version of the protocol. >>> >>> >>I would treat this the same way we treated the keys: make provision for=20 >>multi-CE support in the model as early as possible as it may otherwise=20 >>become more difficult to include it later. >> >>For instance, whenever CEs register for events: the model should not only= =20 >>indicate with a boolean if a CE has registered to be notified when the=20 >>event occurs, but also include a list of the CEs that have registered for= =20 >>the same event. Limited complexity for the model, almost no additional=20 >>complexity for the protocol. >> >>Regards, >>-Robert >> >>>Regards >>>Hormuzd >>> >>>Joel M. Halpern wrote: >>> >>> >>> >>>>I thought we had agreed that for now we would focus on a single active >>>> >>> >>> >>> >>> >>>>CE per FE> An FE that wants to be managed by several CEs is (I=20 >>>>thought) to pretend it is several FEs, probably with distinct >>>> >>> >>>resources. >>> >>> >>>>The multi-manager problem is very very messy. >>>> >>>> >>> >>> >>> >>> > >-- >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: Thu, 9 Jun 2005 09:09:15 -0400 From: "Joel M. Halpern" Subject: Protocol Document TML Description Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The protocol document, in section 3.1.2 states: However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. That is not out usual definition of interoperability. In order to actually ensure interoperability, we must have (at least) one mandatory to implement TML. This document should say that. I believe that the mandatory to implement TML will need to include congestion control for both the control and FE-CE data paths. Given the (quite reasonable) objections that have been raised to shipping the data packets over TCP or SCTP, it seems to me that the only reasonable choice for the mandatory to implement TML is TCP or SCTP for the control aspect, and DCCP for the data forwarding aspect. Yours, Joel M. Halpern 2005 Message-Id: Date: Thu, 9 Jun 2005 09:03:59 -0400 From: "Joel M. Halpern" Subject: Re: [issue40] BLKINFO Comments: To: Robert Haas Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable I am still not convinced of the value, and would prefer to defer BLOCK=20 constructs until we have some experience to know what enhancements we=20 really need. Yours, Joel At 08:57 AM 6/9/2005, Robert Haas wrote: >I just re-read the relevant thread =C3 propos BLOCK selector. It seems= that=20 >besides Jamal and myself, nobody else declared whether the proposal=20 >(repeated below) would be satisfactory and should be included in the=20 >draft. Please let us know. >Regards, >-Robert > > From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)": > >As an alternative, couldn't we just add a flag to the BLOCK selector to=20 >distinguish the two cases ? > >- BLOCK REPLICATE, with only the all-to-all semantic >- BLOCK LIST, with only the one-to-one semantic. > >So while processing a ForCES message, one does not have to infer the=20 >meaning of BLOCK based on the content (is it all-to-all or one-to-one).=20 >Instead the flag will tell immediately. > > >Avri Doria wrote: > >>New submission from Avri Doria : >> >>* NOTE! NOTE! There is a selector known as BLKINFO that is left >> out of this doc for now that will be revisted later. BLKINFO >> is defined as: >> * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=3D >> [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A >> PathData can only have one selector either a KEYINFO TLV or a >> BLKINFO TLV (i.e not both). >> >>Revisit before PS or after? >> >>---------- >>category: Editorial >>draft: draft-ietf-forces-protocol >>messages: 58 >>nosy: avri >>priority: May fix >>status: No discussion >>title: BLKINFO >> >>___________________________________________________ >>Forces issue tracker >> >>___________________________________________________ >> >> >> > >-- >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/~rha 2005 Message-Id: Date: Wed, 8 Jun 2005 17:32:26 +0200 From: avri@psg.com Subject: Re: [issue43] Editorial- change GET to SET in section 6.5 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit fixed in -03 a. 2005 Message-Id: Date: Tue, 7 Jun 2005 23:44:43 +0800 From: Weiming Wang Subject: Re: [issue37] TBD - FE Protocol Attributes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KU29ycnkuIFllcywgdGhlIEZFIExGQiBoYXMgbW9yZSBkb25lIHRoYW4gdGhlIH By b3RvY29sIExGQi4gSSBtb3JlIG1lYW50IHRoZSBwcm90b2NvbCBMRkIuICBXaGF0IEknbSBhIG xp dHRsZSB3b3JyaWVkIHRoZSB3YXkgdGhlIExGQiBkZWZpbml0aW9uIG1heSBkZWxheSB0aGUgcH Jv dG9jb2wgbGllcyBpbjoNCg0KMS4gU29tZSBvZiB0aGUgYXR0cmlidXRlcyBtYXkgaGlnaGx5IH Jl bGF0ZSB0byBvdGhlciBkZWZpbml0aW9ucywgbGlrZSBUTUwgZGVmaW5pdGlvbnMuIFRoaXMgbW Vh bnMgaXQgIHRpZ2h0bHkgdGllcyB0aGUgcHJvdG9jb2wgd29yayB0byB0aGVtLCAgSSB0aGluay B3 ZSBzaG91bGQgb25seSBoYXZlIGEgbG9vc2UgdGllLiBBbmQgc29tZSBhdHRyaWJ1dGVzIG1heS Bi ZSBxdWl0ZSBoYXJkIHRvIGdvIHRvIHRoZSBiaXQgbGV2ZWwgZGVmaW5pdGlvbnMgY3VycmVudG x5 Lg0KDQoyLiBUbyBwdXQgdGhlIGF0dHJpYnV0ZSBkZWZpbml0aW9ucyBpbiB0aGUgcHJvdG9jb2 wg YWxzbyBsaW1pdHMgdGhlIGF0dHJpYnV0ZXMgdG8gd2hhdCB3ZSBjYW4gdGhpbmsgb2YgY3Vycm Vu dGx5LiAgVGhlIGV4dGVuc2lvbiBtYXkgYmVjb21lIGEgcHJvYmxlbS4gQW5kIHdlIG1heSBhbH Nv IGhhdmUgbXVjaCBhcmd1ZW1lbnQgb2Ygd2hpY2ggYXR0cmlidXRlIHNob3VsZCBiZSBkZWZpbm Vk LiANCg0KWWVzLCB5b3UgbWVudGlvbmVkIG1hbnkgcHJvdG9jb2xzIG1heSBydW4gd2l0aG91dC BN SUJzLiAgV2hlcmVhcyBJJ20gc2ltcGx5IHRyeWluZyB0byBzZWUgdGhlIHBvc3NpYmlsaXR5IG 9m IGEgcmVsYXRpb24gbGlrZSBhbiBJUCBwcm90b2NvbCB3aXRoIHRoZSBBc3NpZ25lZCBOdW1iZX Is IHRob3VnaHQgSSdtIG5vdCB2ZXJ5IHN1cmUgb2YgdGhlIGlkZWEuDQoNCnRoYW5rcywNCldlaW 1p bmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhhbH Bl cm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpUbzogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0 Bt YWlsLnpqZ3N1LmVkdS5jbj47IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50Oi BU dWVzZGF5LCBKdW5lIDA3LCAyMDA1IDEyOjA2IFBNDQpTdWJqZWN0OiBSZTogW2lzc3VlMzddIF RC RCAtIEZFIFByb3RvY29sIEF0dHJpYnV0ZXMNCg0KDQo+IEkgbXVzdCBiZSBtaXNzaW5nIHNvbW V0 aGluZy4gIEZvciB0aGUgRkUgTEZCIHdlIGhhdmUgbmFtZXMsIGRhdGEgdHlwZXMsIGFuZCANCj 4g ZmFpcmx5IGdvb2QgZGVzY3JpcHRpb25zIG9mIG1vc3Qgb2YgdGhlIGF0dHJpYnV0ZXMuICBUaG 9z ZSB3ZXJlIGluIHRoZSBsYXN0IA0KPiBwdWJsaXNoZWQgbW9kZWwgZHJhZnQuICBUaGV5IGFyZS Bi YXNpY2FsbHkgdGhlIHNhbWUgYXMgdGhlIG9uZXMgaW4gdGhlIEZFIA0KPiBTY2hlbWEgZG9jdW 1l bnQsIHdpdGggY2xlYW51cC4NCj4gDQo+IFRoZSBldmVudHMgYXJlIGdvaW5nIHRvIHRha2Ugc2 9t ZSB3b3JrLiAgQnV0IG5vdCBhbiBhYnN1cmQgYW1vdW50IG9mIHdvcmsuDQo+IA0KPiBZb3Vycy wN Cj4gSm9lbA0KPiANCj4gQXQgMDk6MzkgUE0gNi82LzIwMDUsIFdhbmcsV2VpbWluZyB3cm90ZT oN Cj4gPk5vdGUgdGhhdCB3ZSBub3cgb25seSBoYXZlIG5hbWVzIGZvciBtb3N0IG9mIHRoZSBDb3 Jl LUxGQiBhdHRyaWJ1dGVzLiBUbyBtYWtlDQo+ID5zcGVjaWZpYyBkZWZpbml0aW9ucyBmb3IgdG hl c2UgYXR0cmlidXRlcyB3aWxsIHN0aWxsIHRha2UgYSBsb25nIHdheSB0byANCj4gPmdvLCBJJ2 0N Cj4gPmFmcmFpZC4NCj4gDQo+IA== 2005 Message-Id: Date: Tue, 7 Jun 2005 11:43:11 +0200 From: avri@psg.com Subject: draft-ietf-forces-protocol-03.txt Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, on june 02 i tried to submit the latest draft to the id editor. but it was rejected because i mentioned rfc 3668 instead of bcp79. unfortunately i was away from email and did not see this rejection until this morning. i have resubmitted it. and hopefully this time have correctly dealt with the bureaucratic minutia. but in case i haven't, or in the meantime, a copy can be found in: http://psg.com/~avri/forces/draft-ietf-forces-protocol-03.txt a. 2005 Message-Id: Date: Tue, 7 Jun 2005 09:39:15 +0800 From: "Wang,Weiming" Subject: Re: [issue37] TBD - FE Protocol Attributes Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" > > Lets put it this way, if it will _not_ delay the two main drafts from > going last call, i have no objections to the two core LFBs to be split > and merged in the protocol and Model LFB. My impression so far has been > they are almost there. But reading Weiming's email i sense his opinion > is that it's not ready at all. Note that we now only have names for most of the Core-LFB attributes. To make specific definitions for these attributes will still take a long way to go, I'm afraid. I tend to agree with you that IF it will not greatly block the process, to put the protocol LFB in the protocol draft is ok to me. As a resut, we then need to try to define them now. cheers, Weiming 2005 Message-Id: Date: Tue, 7 Jun 2005 08:42:04 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue37] TBD - FE Protocol Attributes Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Mon, 2005-06-06 at 22:57 -0400, Joel M. Halpern wrote: > I just can't come up with a good reason to use alias in the FE LFB, so > there won't be an example of its use in the document. The definition and > description of alias will be there, since the working group seems to have > accepted the need. > What about the idea of publishing a NOOP LFB that could be used as an exercise for demonstrating the different semantics? We already had such a LFB initially to demonstrate a few things and was used for basic interop back in San Diego. cheers, jamal 2005 Message-Id: Date: Tue, 7 Jun 2005 00:06:12 -0400 From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: "Wang,Weiming" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I must be missing something. For the FE LFB we have names, data types, and fairly good descriptions of most of the attributes. Those were in the last published model draft. They are basically the same as the ones in the FE Schema document, with cleanup. The events are going to take some work. But not an absurd amount of work. Yours, Joel At 09:39 PM 6/6/2005, Wang,Weiming wrote: >Note that we now only have names for most of the Core-LFB attributes. To make >specific definitions for these attributes will still take a long way to >go, I'm >afraid. 2005 Message-Id: Date: Mon, 6 Jun 2005 23:26:42 +0800 From: Weiming Wang Subject: Re: [issue30] Event subscription Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwsIA0KDQpWZXJ5IGdsYWQgdG8gc2VlIHlvdSBhZ2FpbiA6KQ0KDQpUaGUgb3JpZ2luYW wg cXVlc3Rpb24gaXMgImlmIGFsbCBldmVudHMgc2hvdWxkIGJlIHN1YnNjcmliYWJsZSBvciBub3 Qi LiBCeSBzYXlpbmcgaXQgZG9lcyBub3QgcmVsYXRlIHRvIHRoZSBwcm90b2NvbCwgSSBhY3R1YW xs eSB0aG91Z2h0IHRoYXQgdGhlIHByb3RvY29sIG9ubHkgbmVlZCB0byBwcm92aWRlIHRoZSBwcm 90 b2NvbCBzZW1hbnRpY3MgZm9yIHRoZSBzdWJzY3JpcHRpb24gaWYgdGhlIGV2ZW50cyBhcmUgc3 Vi c2NyaWJhYmxlLCBidXQgYW4gZXZlbnQgaXMgc3Vic2NyaWJhYmxlIG9yIG5vdCBzdGlsbCBoYX Zl IHRvIGJlIGRlZmluZWQgaW4gdGhlIG1vZGVsIGRlZmluaXRpb25zIGZvciB0aGUgZXZlbnQuIE lu IGFub3RoZXIgd29yZCwgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gZG9lcyBub3QgY2FyZS Bp ZiBhbiBldmVudCBpcyBzdWJzY3JpYmFiYWwgb3Igbm90LiBJZiBpdCBpcyBub3QgYSBzdWJzY3 Jp YmFibGUgZXZlbnQgd2hpbGUgaXQgd2VyZSB0cmllZCB0byBzdWJzY3JpYmUsIGFuIGVycm9yIH dp bGwgcmV0dXJuLiANCg0KVGhpcyBpcyBjYW4gYWxzbyBiZSBkZXNjcmliZWQgYXMgImlmIGFuIF hN TCBkZWZpbml0aW9uIGZvciBhbiBldmVudCBuZWVkIHRvIGhhdmUgdGhlIGF0dHJpYnV0ZSBhcy Ai U1VCU0NSSUJBQkxFL1VOU1VCU0NSSUJBQkxFIiBvciBub3QuDQoNClJlZ2FyZGluZyB0aGUgaX Nz dWUgaXRzZWxmLCBJIHBlcnNvbmFsbHkgaW5jbGluZSB0byBoYXZlIGFsbCAgZXZlbnRzIHN1Yn Nj cmliYWJsZSwgd2hpY2gsIGFzIEpvZWwgcG9pbnRlZCBvdXQsIHdpbGwgbGVhZCB0byBhIHZlcn kg Y2xlYXIgZ3JhbW1hciwgYW5kIGFsbCBldmVudHMgc2hvdWxkIGJlIG9mZiB3aGVuIHN5c3RlbS Bp cyBmaXJzdCBib290ZWQuIFRoaXMgYWxzbyBtZWFucyB0aGUgWE1MIGRlZmluaXRpb24gZm9yIG Fu IGV2ZW50IGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBhbiBhdHRyaWJ1dGUgYXMgIlNVQlNDUklCQU JM RS9VTlNVQlNDUklCQUJMRSIuDQoNCkNoZWVycywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYW wg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT 4N CiANCj4gSGkgV2VpbWluZywNCj4gDQo+IE9uIEZyaSwgMjAwNS0wMy0wNiBhdCAyMjozNSArMD gw MCwgV2VpbWluZyBXYW5nIHdyb3RlOg0KPiA+IE5vdCBzdXJlIGlmIHRoaXMgaXNzdWUgY2FuIG Jl IGNsb3NlZCBieSBsZWF2aW5nIGl0IGZvciBtb2RlbCB0ZWFtIHRvIGRlY2lkZS4gDQo+ID4gQW N0 dWFsbHkgaXQgZG9lcyBub3QgcmVsYXRlIHRvIHRoZSBwcm90b2NvbCAgc3BlY2lmaWNhdGlvbi B2 ZXJ5IG11Y2guDQo+IA0KPiBUaGUgcHJvdG9jb2wgaGFzIHRvIHByb3ZpZGUgdGhlIHNlbWFudG lj cyB0byBhbGxvdyBmb3IgZXZlbnRzLg0KPiBXaHkgZG8geW91IHNheSAiaXQgZG9lcyBub3Qgcm Vs YXRlIHRvIHRoZSBwcm90b2NvbCI/DQo+IA0KPiBjaGVlcnMsDQo+IGphbWFsDQo+IA== 2005 Message-Id: Date: Mon, 6 Jun 2005 22:57:30 -0400 From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I just can't come up with a good reason to use alias in the FE LFB, so there won't be an example of its use in the document. The definition and description of alias will be there, since the working group seems to have accepted the need. Yours, Joel At 08:50 PM 6/6/2005, Jamal Hadi Salim wrote: >No aliases in general or just if FE LFB doesnt make it in? 2005 Message-Id: Date: Mon, 6 Jun 2005 20:54:55 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Response formating Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-zf0ne6ISeLGDsYQxyHed" --=-zf0ne6ISeLGDsYQxyHed Content-Transfer-Encoding: 7bit Content-Type: text/plain Folks, In regards to section 3.3.1.2 Response formating which we didnt close before last release. There has been no text in the draft, but i have gathered discussion so far in text and i am attaching them. If people can read the text it and comment, it would help in closing this topic. cheers, jamal --=-zf0ne6ISeLGDsYQxyHed Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=operationresponse.txt Content-Type: text/plain; name=operationresponse.txt; charset=UTF-8 In the master slave-relationship the CE instructs one or more FEs on how to execute operations(sec 3.3.1.1 - Execution) and how to report back the results(3.3.1.2). This document captures discussions so far on response from FE->CE. Should be noted that there maybe extrenous schemes described here for completion sake more than religious opinion. We should pick schemes that will be sufficient to cover what are foreseen as the major cases. 3.xxx Responses: --------------- The CE expects the FE to report back the results of the when it asks for them. The CE also tells the FE to format them in a certain way. The reporting and its formating are still constrained by the execution requests. These are controlled by the ACK indicators(2 bit) 3.xx.1 Full response. Essentially what sent is responded to in full with status of whether it failed or succeeded. This is paranoia mode which uses a lot more bandwidth than other modes Use case: Allows sender to validate what was sent. **** Editorial note: Remove the above, consensus is that it seems to be rejected so far - just here temporarily incase someone needs it and missed the discussion. I cant remember the reason for rejection. Was it bandwidth consumption? Joel? 3.xx.2 Partial response: 3.xx.2.1 Basic In this scenario, the failed operations are returned in the PL message. For each failed operation that has failed, the operational flag is set to indicate an error. In the case of success, no operations are returned. a) If we allow the error codes being returned are simple pass/failed type then setting operational path flag level in my opinion should suffice. b) There should be a a shortcut in the main header flags which says "you need to look at the operational level further because we have errors". The NACK flag should suffice to indicate this in the main header. 3.xx.2.2 More than Basic Proposed by both Weiming and Joel: Introduce RESULT TLV to describe the results of a SET operation. The RESULT TLV will have more data in it than what 3.2.1 is proposing. Do these results make sense for DEL as well? The idea behind this is you want to know if the in the case of "Execute-until-failure" loose transaction or "continue-execute-on-failure" independent operations which one failed and why. 3.2.1 doesnt tell you why. Use case for 3.xx.2 : Useful when execution success is certain and reliable delivery since saves on bandwidth. 3.xx.3 brief or no notification a) One may not care at all about the SET result. b) one may care only to know if the PL message got at the other end. In which case a main header ACK to ensure that the FE received a message is sufficient. c) one may ask to be told only when theres an error that happened. Flags: NACK only Use case a) and b): Example unidirectional heartbeat. A more involved heartbeat would occasionally ask for acknowledgement or a full response(a pong to the ping). $Log: operationresponse.txt,v $ Revision 1.1 2005/06/06 17:37:18 hadi Initial revision Revision 1.1 2005/02/10 03:31:42 hadi Initial revision --=-zf0ne6ISeLGDsYQxyHed-- 2005 Message-Id: Date: Mon, 6 Jun 2005 20:50:14 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue37] TBD - FE Protocol Attributes Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Mon, 2005-06-06 at 11:19 -0400, Joel M. Halpern wrote: > I tend to disagree. > > With regard to the FE LFB and the model draft, my concrete concern is that > a human being reading the model draft without the FE LFB will not > understand how a CE can actually make use of the model. We could just say > that there is an FE LFB (class 1, instance 1), that it has the basic > information the CE needs, and leave the details to another draft. But I am > pretty sure that will leave readers confused. As a minor related note, > including the FE LFB will give me an easy way to provide an example LFB > definition, including information about properties for access control. (I > won't be able to get alias in.) No aliases in general or just if FE LFB doesnt make it in? > I currently intend to also include some > events (LFB Creation, LFB Deletion, Capability change, are the ones I think > belong.) > This would be useful to show; but also if we can have some attribute change being shown as an event - it would be more complete. > With regard to the protocol, it is probably not as big an issue. After > all, we have a long tradition of putting instrumentation for protocols in > other documents (MIBs). The difference is that most protocols can run > without their MIB. Can we run the forces protocol without the Forces > Protocol LFB? (We can not run the model / protocol without the FE LFB.) The protocol needs the FE Protocol LFB from what ive seen so far. Lets put it this way, if it will _not_ delay the two main drafts from going last call, i have no objections to the two core LFBs to be split and merged in the protocol and Model LFB. My impression so far has been they are almost there. But reading Weiming's email i sense his opinion is that it's not ready at all. cheers, jamal 2005 Message-Id: Date: Mon, 6 Jun 2005 15:15:18 +0800 From: "Wang,Weiming" Subject: Re: [issue37] TBD - FE Protocol Attributes Joel, David, and Robert, I have some thoughts, some by my experience with GRMP: 1. Defining things like LFB attributes in details in the protocol docuement will really leads the document to a comlex one. 2. Currently, we may be a little far away from accurately defining these attributes. 3. Therefore, will eventually bottleneck the protocol document from going to last call. I actually incline to strip all that are related to LFB definitions from current protocol docuement, while only leaving it for open discussion later that "whether they go to model document or to a specific one for LFB definitions used by protocol" . Thanks, Weiming ----- Original Message ----- From: "Putzolu, David" (hat off) The approach you propose Joel makes sense to me technically, and it is also a nice partitioning of the work :) -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, June 03, 2005 11:29 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes A reasonable question. My current take is that the FE LFB should come with the model document, and the FE-protocol LFB should be defined by the protocol document. However, this is something on which reasonable people can easily differ, and I am open to alternatives. Yours, Joel At 10:50 AM 6/3/2005, Weiming Wang wrote: >It seems we need to first decide "who should define the LFBs like FE-LFB, >FE-protocol-LFB, this protocol document or elsewhere" before trying to >decide this issue. > >thanks, >Weiming 2005 Message-Id: Date: Mon, 6 Jun 2005 11:19:33 -0400 From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I tend to disagree. With regard to the FE LFB and the model draft, my concrete concern is that a human being reading the model draft without the FE LFB will not understand how a CE can actually make use of the model. We could just say that there is an FE LFB (class 1, instance 1), that it has the basic information the CE needs, and leave the details to another draft. But I am pretty sure that will leave readers confused. As a minor related note, including the FE LFB will give me an easy way to provide an example LFB definition, including information about properties for access control. (I won't be able to get alias in.) I currently intend to also include some events (LFB Creation, LFB Deletion, Capability change, are the ones I think belong.) With regard to the protocol, it is probably not as big an issue. After all, we have a long tradition of putting instrumentation for protocols in other documents (MIBs). The difference is that most protocols can run without their MIB. Can we run the forces protocol without the Forces Protocol LFB? (We can not run the model / protocol without the FE LFB.) Yours, Joel At 09:01 AM 6/6/2005, Jamal Hadi Salim wrote: >I am about 60% in agreement with Weiming. Infact, thats what i was >stating before the last IETF meeting. I even have a draft called "Core >LFBs" to prove it ;-> > >Actually the main valid reason that Weiming provides is #3. We need to >get both the protocol and Model drafts to last call and moving this out >will help speed things up. I believe the core LFBs should still be >mentioned in the two drafts but not elucidated. > >cheers, >jamal > >On Mon, 2005-06-06 at 15:15 +0800, Wang,Weiming wrote: > > Joel, David, and Robert, > > > > I have some thoughts, some by my experience with GRMP: > > 1. Defining things like LFB attributes in details in the protocol > docuement will > > really leads the document to a comlex one. > > 2. Currently, we may be a little far away from accurately defining these > > attributes. > > 3. Therefore, will eventually bottleneck the protocol document from > going to > > last call. > > > > I actually incline to strip all that are related to LFB definitions > from current > > protocol docuement, while only leaving it for open discussion later that > > "whether they go to model document or to a specific one for LFB > definitions used > > by protocol" . > > > > Thanks, > > Weiming > > ----- Original Message ----- > > From: "Putzolu, David" > > > > (hat off) > > > > The approach you propose Joel makes sense to me technically, and it is > > also a nice partitioning of the work :) > > > > -David > > > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > Sent: Friday, June 03, 2005 11:29 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes > > > > A reasonable question. > > > > My current take is that the FE LFB should come with the model document, > > and > > the FE-protocol LFB should be defined by the protocol document. > > However, this is something on which reasonable people can easily differ, > > > > and I am open to alternatives. > > > > Yours, > > Joel > > > > At 10:50 AM 6/3/2005, Weiming Wang wrote: > > >It seems we need to first decide "who should define the LFBs like > > FE-LFB, > > >FE-protocol-LFB, this protocol document or elsewhere" before trying to > > > > >decide this issue. > > > > > >thanks, > > >Weiming 2005 Message-Id: Date: Mon, 6 Jun 2005 09:28:22 -0700 From: "Deleganes, Ellen M" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had removed the detailed descriptions of the core LFBs from the model document for the very reason that Jamal has pointed out. However, we need to define the core LFBs to the point where we all feel confident that the protocol and the model will support at least the most common ones. I think we are mostly there, but would like to get other opinions as well. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 06, 2005 6:02 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue37] TBD - FE Protocol Attributes I am about 60% in agreement with Weiming. Infact, thats what i was stating before the last IETF meeting. I even have a draft called "Core LFBs" to prove it ;-> Actually the main valid reason that Weiming provides is #3. We need to get both the protocol and Model drafts to last call and moving this out will help speed things up. I believe the core LFBs should still be mentioned in the two drafts but not elucidated. cheers, jamal On Mon, 2005-06-06 at 15:15 +0800, Wang,Weiming wrote: > Joel, David, and Robert, >=20 > I have some thoughts, some by my experience with GRMP: > 1. Defining things like LFB attributes in details in the protocol docuement will > really leads the document to a comlex one. > 2. Currently, we may be a little far away from accurately defining these > attributes. > 3. Therefore, will eventually bottleneck the protocol document from going to > last call. >=20 > I actually incline to strip all that are related to LFB definitions from current > protocol docuement, while only leaving it for open discussion later that > "whether they go to model document or to a specific one for LFB definitions used > by protocol" . >=20 > Thanks, > Weiming > ----- Original Message ----- > From: "Putzolu, David" >=20 > (hat off) >=20 > The approach you propose Joel makes sense to me technically, and it is > also a nice partitioning of the work :) >=20 > -David >=20 >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Friday, June 03, 2005 11:29 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes >=20 > A reasonable question. >=20 > My current take is that the FE LFB should come with the model document, > and > the FE-protocol LFB should be defined by the protocol document. > However, this is something on which reasonable people can easily differ, >=20 > and I am open to alternatives. >=20 > Yours, > Joel >=20 > At 10:50 AM 6/3/2005, Weiming Wang wrote: > >It seems we need to first decide "who should define the LFBs like > FE-LFB, > >FE-protocol-LFB, this protocol document or elsewhere" before trying to >=20 > >decide this issue. > > > >thanks, > >Weiming 2005 Message-Id: Date: Mon, 6 Jun 2005 09:01:49 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue37] TBD - FE Protocol Attributes Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain I am about 60% in agreement with Weiming. Infact, thats what i was stating before the last IETF meeting. I even have a draft called "Core LFBs" to prove it ;-> Actually the main valid reason that Weiming provides is #3. We need to get both the protocol and Model drafts to last call and moving this out will help speed things up. I believe the core LFBs should still be mentioned in the two drafts but not elucidated. cheers, jamal On Mon, 2005-06-06 at 15:15 +0800, Wang,Weiming wrote: > Joel, David, and Robert, > > I have some thoughts, some by my experience with GRMP: > 1. Defining things like LFB attributes in details in the protocol docuement will > really leads the document to a comlex one. > 2. Currently, we may be a little far away from accurately defining these > attributes. > 3. Therefore, will eventually bottleneck the protocol document from going to > last call. > > I actually incline to strip all that are related to LFB definitions from current > protocol docuement, while only leaving it for open discussion later that > "whether they go to model document or to a specific one for LFB definitions used > by protocol" . > > Thanks, > Weiming > ----- Original Message ----- > From: "Putzolu, David" > > (hat off) > > The approach you propose Joel makes sense to me technically, and it is > also a nice partitioning of the work :) > > -David > > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Friday, June 03, 2005 11:29 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes > > A reasonable question. > > My current take is that the FE LFB should come with the model document, > and > the FE-protocol LFB should be defined by the protocol document. > However, this is something on which reasonable people can easily differ, > > and I am open to alternatives. > > Yours, > Joel > > At 10:50 AM 6/3/2005, Weiming Wang wrote: > >It seems we need to first decide "who should define the LFBs like > FE-LFB, > >FE-protocol-LFB, this protocol document or elsewhere" before trying to > > >decide this issue. > > > >thanks, > >Weiming 2005 Message-Id: Date: Mon, 6 Jun 2005 08:55:26 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue30] Event subscription Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi Weiming, On Fri, 2005-03-06 at 22:35 +0800, Weiming Wang wrote: > Not sure if this issue can be closed by leaving it for model team to decide. > Actually it does not relate to the protocol specification very much. The protocol has to provide the semantics to allow for events. Why do you say "it does not relate to the protocol"? cheers, jamal 2005 Message-Id: Date: Fri, 3 Jun 2005 22:50:12 +0800 From: Weiming Wang Subject: Re: [issue37] TBD - FE Protocol Attributes MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgd2UgbmVlZCB0byBmaXJzdCBkZWNpZGUgIndobyBzaG91bGQgZGVmaW5lIHRoZS BM RkJzIGxpa2UgRkUtTEZCLCBGRS1wcm90b2NvbC1MRkIsIHRoaXMgcHJvdG9jb2wgZG9jdW1lbn Qg b3IgZWxzZXdoZXJlIiAgYmVmb3JlIHRyeWluZyB0byBkZWNpZGUgdGhpcyBpc3N1ZS4NCg0KdG hh bmtzLA0KV2VpbWluZw0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBdn Jp IERvcmlhIiA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQpUbzogPEZPUkNFU0BQRUFDSC5FQV NF LkxTT0ZULkNPTT4NClNlbnQ6IE1vbmRheSwgTWF5IDIzLCAyMDA1IDI6NTAgQU0NClN1YmplY3 Q6 IFtpc3N1ZTM3XSBUQkQgLSBGRSBQcm90b2NvbCBBdHRyaWJ1dGVzDQoNCg0KTmV3IHN1Ym1pc3 Np b24gZnJvbSBBdnJpIERvcmlhIDxhdnJpQGFjbS5vcmc+Og0KDQo2LjIuMQ0KDQogICBvICBGRS BQ cm90b2NvbCBhdHRyaWJ1dGVzIChjYW4gYmUgcmVhZCBhbmQgc2V0KToNCiAgICAgICogIEN1cn Jl bnQgdmVyc2lvbiBvZiB0aGUgRm9yQ0VTIHByb3RvY29sDQoNCg0KDQoNCkRvcmlhIChjby1lZG l0 b3IpICAgICAgICAgRXhwaXJlcyBBcHJpbCA0LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlID Mx XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBGb3JDRVMgICAgICAgICAgIC Ag ICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICAgICAqICBDdXJyZW50IHZlcnNpb24gb2YgdG hl IEZFIG1vZGVsDQogICAgICAqICBGRSB1bmljYXN0IElEDQogICAgICAqICBGRSBtdWx0aWNhc3 Qg SUQocykgKGxpc3QpDQogICAgICAqICBBc3NvY2lhdGlvbiBFeHBpcnkgVGltZXINCiAgICAgIC og IEhlYXJ0YmVhdCBJbnRlcnZhbA0KICAgICAgKiAgUHJpbWFyeSBDRQ0KICAgICAgKiAgRkUgZm Fp bG92ZXIgYW5kIHJlc3RhcnQgcG9saWN5DQogICAgICAqICBDRSBmYWlsb3ZlciBhbmQgcmVzdG Fy dCBwb2xpY3kNCiAgICAgDQogICAgICAgICBUQkQ6ICAgRGVmaW5lIGRlZmF1bHQgdmFsdWVzIG Zv ciBlYWNoIGF0dHJpYnV0ZSB3aGVyZQ0KICAgICAgICAgICAgICAgIGFwcGxpY2FibGUuDQoNCi 0t LS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNobmljYWwNCmRyYWZ0OiBkcmFmdC1pZXRmLWZvcmNlcy 1w cm90b2NvbA0KbWVzc2FnZXM6IDU1DQpub3N5OiBhdnJpDQpwcmlvcml0eTogTXVzdCBmaXgNCn N0 YXR1czogTm8gZGlzY3Vzc2lvbg0KdGl0bGU6IFRCRCAtIEZFIFByb3RvY29sIEF0dHJpYnV0ZX MN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQ pG b3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aHR0cDovL3 d3 dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzNz4NCl9fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 2005 Message-Id: Date: Fri, 3 Jun 2005 22:45:33 +0800 From: Weiming Wang Subject: Re: [issue36] Note: - FE and CE Failover Comments: To: Forces issue tracker MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkF2cmkgRG9yaWEiIDx0cm Fj a2VyLWZvcmNlc0BtaXA0Lm9yZz4NCg0KTmV3IHN1Ym1pc3Npb24gZnJvbSBBdnJpIERvcmlhID xh dnJpQGFjbS5vcmc+Og0KDQo2LjIuMQ0KDQogICAgICAqICBDdXJyZW50IHZlcnNpb24gb2YgdG hl IEZFIG1vZGVsDQogICAgICAqICBGRSB1bmljYXN0IElEDQogICAgICAqICBGRSBtdWx0aWNhc3 Qg SUQocykgKGxpc3QpDQogICAgICAqICBBc3NvY2lhdGlvbiBFeHBpcnkgVGltZXINCiAgICAgIC og IEhlYXJ0YmVhdCBJbnRlcnZhbA0KICAgICAgKiAgUHJpbWFyeSBDRQ0KICAgICAgKiAgRkUgZm Fp bG92ZXIgYW5kIHJlc3RhcnQgcG9saWN5DQogICAgICAqICBDRSBmYWlsb3ZlciBhbmQgcmVzdG Fy dCBwb2xpY3kNCiAgICAgICAgIE5vdGU6ICBJcyB0aGVyZSBhIGRpZmZlcmVuY2UgYmV0d2Vlbi B0 aGUgQ0UgYW5kIEZFIGZhaWxvdmVyDQogICAgICAgICAgICAgICAgcG9saWNpZXM/DQoNCltXZW lt aW5nXSBDRSBmYWlsb3ZlciBwb2xpY3kgdGVsbHMgaG93IEZFIGFjdHMgaWYgaXQgZmluZHMgdG hl IENFIGZhaWxzLCB3aGlsZSBGRSBmYWlsb3ZlciBhbmQgcmVzdGFydCBwb2xpY3kgdGVsbHMgaG 93 IEZFIHNob3VsZCBhY3QgdG8gcmVzdGFydCBmcm9tIGEgZmFpbG92ZXIgc3RhdGUuICANCg0KLS 0t LS0tLS0tLQ0KY2F0ZWdvcnk6IEVkaXRvcmlhbA0KZHJhZnQ6IGRyYWZ0LWlldGYtZm9yY2VzLX By b3RvY29sDQptZXNzYWdlczogNTQNCm5vc3k6IGF2cmkNCnByaW9yaXR5OiBNdXN0IGZpeA0Kc3 Rh dHVzOiBObyBkaXNjdXNzaW9uDQp0aXRsZTogTm90ZTogLSBGRSBhbmQgQ0UgRmFpbG92ZXINCg 0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGb3 Jj ZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aHR0cDovL3d3dy 5t aXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzNj4NCl9fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 2005 Message-Id: Date: Fri, 3 Jun 2005 22:39:34 +0800 From: Weiming Wang Subject: Re: [issue31] Necessity of Notification Response Message Comments: cc: Forces issue tracker MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgdGhvdWdodCBpcyBpZiB3ZSBkZWNpZGUgbm90IHRvIGhhdmUgYSB1bmlmb3JtbHkgZm9ybW F0 ZWQgQUNLIG1lc3NhZ2UgaW4gdGhlIHByb3RvY29sIG1lc3NhZ2VzLCB3ZSBtYXkgbmVlZCBzdW No IGV2ZW50IG5vdGlmaWNhdGlvbiByZXNwb25zZSBtZXNzYWdlLg0KDQp0aGFua3MsDQpXZWltaW 5n DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkF2cmkgRG9yaWEiIDx0cm Fj a2VyLWZvcmNlc0BtaXA0Lm9yZz4NCg0KTmV3IHN1Ym1pc3Npb24gZnJvbSBBdnJpIERvcmlhID xh dnJpQGFjbS5vcmc+Og0KDQo2LjcuMg0KDQogIEVkaXRvcmlhbCBOb3RlOiAgVGhlcmUgaXMgYS Bk ZWJhdGUgb24gd2hldGhlciB0aGUgRXZlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgTm90aW Zp Y2F0aW9uIFJlc3BvbnNlIE1lc3NhZ2UgaXMgbmVjZXNzYXJ5IG9yDQogICAgICAgICAgICAgIC Ag ICAgICAgIG5vdC4gIFRoZSBwcm8gZm9yIGl0IGlzIHNvbWUgZXZlbnQgbm90aWZpY2F0aW9uDQ og ICAgICAgICAgICAgICAgICAgICAgIHNlbmRlcnMgbWF5IGJlIGludGVyZXN0ZWQgaW4ga25vd2 lu ZyBpZiByZWNlaXZlcnMNCiAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSBoYWQgc3VjY2Vzcy 91 bnN1Y2Nlc3MgcmVjZXB0aW9ucyBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgZXZlbn Rz IG9yIG5vdC4gIEFuIGFsdGVybmF0aXZlIHRvIGdlbmVyYXRlIHN1Y2gNCiAgICAgICAgICAgIC Ag ICAgICAgICAgcmVzcG9uc2UgaXMgZm9yIHRoZSBwcm90b2NvbCB0byBkZWZpbmUgYQ0KICAgIC Ag ICAgICAgICAgICAgICAgICB1bml2ZXJzYWwgQUNLIG1lc3NhZ2Ugc28gdGhhdCBpdCBjYW4gYW N0 IGFzDQogICAgICAgICAgICAgICAgICAgICAgIHJlc3BvbnNlcyBmb3IgYW55IHR5cGVzIG9mIG 1l c3NhZ2VzIGFzIHdlbGwgYXMNCiAgICAgICAgICAgICAgICAgICAgICAgdGhlIGV2ZW50IG5vdG lm aWNhdGlvbiBtZXNzYWdlcywgd2hlbiB0aGUgbWVzc2FnZQ0KICAgICAgICAgICAgICAgICAgIC Ag ICBzZW5kZXJzIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgd2hldGhlciB0aGUNCiAgICAgIC Ag ICAgICAgICAgICAgICAgbWVzc2FnZXMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZC Bv ciBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgKGRpZmZlcmVudCBmcm9tIHRoZSByZXNwb2 5z ZXMgZm9yIHRoZSBtZXNzYWdlDQogICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3Npbmcgcm Vz dWx0cykuDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNobmljYWwNCmRyYWZ0OiBkcmFmdC 1p ZXRmLWZvcmNlcy1wcm90b2NvbA0KbWVzc2FnZXM6IDQ4DQpub3N5OiBhdnJpDQpwcmlvcml0eT og TXVzdCBmaXgNCnN0YXR1czogTm8gZGlzY3Vzc2lvbg0KdGl0bGU6IE5lY2Vzc2l0eSBvZiBOb3 Rp ZmljYXRpb24gUmVzcG9uc2UgTWVzc2FnZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX18NCkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFja2VyLW Zv cmNlc0BtaXA0Lm9yZz4NCjxodHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vlcy90cmFja2VyL2Zvcm Nl cy9pc3N1ZTMxPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fX19fDQo= 2005 Message-Id: Date: Fri, 3 Jun 2005 22:35:19 +0800 From: Weiming Wang Subject: Re: [issue30] Event subscription Comments: cc: Forces issue tracker MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHN1cmUgaWYgdGhpcyBpc3N1ZSBjYW4gYmUgY2xvc2VkIGJ5IGxlYXZpbmcgaXQgZm9yIG 1v ZGVsIHRlYW0gdG8gZGVjaWRlLiBBY3R1YWxseSBpdCBkb2VzIG5vdCByZWxhdGUgdG8gdGhlIH By b3RvY29sICBzcGVjaWZpY2F0aW9uIHZlcnkgbXVjaC4NCg0KV2VpbWluZw0KLS0tLS0gT3JpZ2 lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBdnJpIERvcmlhIiA8dHJhY2tlci1mb3JjZXNAbW lw NC5vcmc+DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NClNlbnQ6IE1vbmRheS wg TWF5IDIzLCAyMDA1IDI6MjkgQU0NClN1YmplY3Q6IFtpc3N1ZTMwXSBFdmVudCBzdWJzY3JpcH Rp b24NCg0KDQpOZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPGF2cmlAYWNtLm9yZz46DQ oN CjYuNw0KDQogICBFZGl0b3JpYWwgTm90ZTogIFRoZXJlIGlzIGFuIGFyZ3VtZW50IHRoYXQgaX Qg aXMgcHJlZmVyYWJsZSB0byBoYXZlDQogICAgICAgICAgICAgICAgICAgIGFsbCBldmVudHMgc3 Vi c2NyaWJhYmxlLg0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkcmFmdDogZH Jh ZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wNCm1lc3NhZ2VzOiA0Nw0Kbm9zeTogYXZyaQ0KcHJpb3 Jp dHk6IE11c3QgZml4DQpzdGF0dXM6IE5vIGRpc2N1c3Npb24NCnRpdGxlOiBFdmVudCBzdWJzY3 Jp cHRpb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9f X19fDQpGb3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aH R0 cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzMD4NCl9fX19fX1 9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 2005 Message-Id: Date: Fri, 3 Jun 2005 14:28:55 -0400 From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: Weiming Wang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed A reasonable question. My current take is that the FE LFB should come with the model document, and the FE-protocol LFB should be defined by the protocol document. However, this is something on which reasonable people can easily differ, and I am open to alternatives. Yours, Joel At 10:50 AM 6/3/2005, Weiming Wang wrote: >It seems we need to first decide "who should define the LFBs like FE-LFB, >FE-protocol-LFB, this protocol document or elsewhere" before trying to >decide this issue. > >thanks, >Weiming 2005 Message-Id: Date: Fri, 3 Jun 2005 14:27:05 -0400 From: "Joel M. Halpern" Subject: Re: [issue30] Event subscription Comments: To: Weiming Wang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed My current inclination is that the definition of an event identifies the subscription point, that all events are subscribable, and that by default all subscriptions are off. This creates a clean, simple, understandable, operting mode. The assumption that lead me to this is simply that without a CE there is no point in a notification, and if there is a CE, he can determine what he wants to register for. Any race condition is handled by the CE getting the information he needs about current state. Yours, Joel At 10:35 AM 6/3/2005, Weiming Wang wrote: >Not sure if this issue can be closed by leaving it for model team to >decide. Actually it does not relate to the protocol specification very much. > >Weiming >----- Original Message ----- >From: "Avri Doria" >Sent: Monday, May 23, 2005 2:29 AM >Subject: [issue30] Event subscription > > >New submission from Avri Doria : > >6.7 > > Editorial Note: There is an argument that it is preferable to have > all events subscribable. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 47 >nosy: avri >priority: Must fix >status: No discussion >title: Event subscription 2005 Message-Id: Date: Fri, 3 Jun 2005 11:39:33 -0700 From: "Putzolu, David" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (hat off) The approach you propose Joel makes sense to me technically, and it is also a nice partitioning of the work :) -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, June 03, 2005 11:29 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes A reasonable question. My current take is that the FE LFB should come with the model document, and=20 the FE-protocol LFB should be defined by the protocol document. However, this is something on which reasonable people can easily differ, and I am open to alternatives. Yours, Joel At 10:50 AM 6/3/2005, Weiming Wang wrote: >It seems we need to first decide "who should define the LFBs like FE-LFB,=20 >FE-protocol-LFB, this protocol document or elsewhere" before trying to >decide this issue. > >thanks, >Weiming 2005 Message-Id: Date: Fri, 3 Jun 2005 07:20:40 +0000 From: Hormuzd Khosravi Subject: [issue43] Editorial- change GET to SET in section 6.5 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Hormuzd Khosravi : In sections 6.5.1, 6.5.2, the figures show GET command being used in Config=20 messages. This should be changed to SET in both sub-sections. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 62 nosy: hormuzdk priority: Must fix status: Text proposed title: Editorial- change GET to SET in section 6.5 ___________________________________________________ Forces issue tracker ___________________________________________________