From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 1 21:14:58 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h91KEc4x001032 for ; Wed, 1 Oct 2003 21:14:38 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h91KEcCj001030 for ip-dvb-subscribed-users; Wed, 1 Oct 2003 21:14:38 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h91KE850000991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Oct 2003 21:14:09 +0100 (BST) Message-ID: <3F7B3592.5000908@erg.abdn.ac.uk> Date: Wed, 01 Oct 2003 21:14:10 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: 58th IETF Meeting Information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk For those of you who are not on the general IETF list, here's a reminder of the meeting details. The main conference hotel is booked, but there are still palces at other hotels. I intend to call a meeting at the IETF, and will tell you the date and time when the meeting enters the programme. Best wishes, Gorry Fairhurst > Registration for the 58th IETF Meeting is now open. > Information can be found on the IETF web site at: > http://www.ietf.org/meetings/IETF-58.html > > MEETING SITE AND HOTEL ACCOMODATIONS: > Minneapolis Hilton and Towers > 1001 Marquette Avenue > Minneapolis, MN 55403 USA > Tel: 1-612-376-1000/1-800-445-8667 > Fax: 1-612-397-4875 > http://www.hilton.com/en/hi/hotels/index.jhtml?ctyhocn=MSPMHHH From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 1 21:26:08 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h91KPf4x001540 for ; Wed, 1 Oct 2003 21:25:41 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h91KPfE5001539 for ip-dvb-subscribed-users; Wed, 1 Oct 2003 21:25:41 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h91KPI50001521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Oct 2003 21:25:19 +0100 (BST) Message-ID: <3F7B3830.3040106@erg.abdn.ac.uk> Date: Wed, 01 Oct 2003 21:25:20 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Call for Papers: IJCN Content-Type: multipart/mixed; boundary="------------050605080102070203060308" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------050605080102070203060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There will be a Special Issue of the International Journal of Computer Networks devoted to "Internet over Digital Broadcast Video Networks". This seems very close to the topics discussed on this list, so I warmly invite you to consider submission of a paper. Those interesed, are referred to the attached call for papers. Best wishes, Gorry Fairhurst --------------050605080102070203060308 Content-Type: multipart/appledouble; boundary="------------ad030205080308090207020506"; x-mac-type="5738424E"; x-mac-creator="4D535744"; name="IJCN-2004.doc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IJCN-2004.doc" --------------ad030205080308090207020506 Content-Type: application/applefile Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAADAAAAVgAAAA0AAAAJAAAAYwAAACAAAAAI AAAAgwAAABAAAAAEAAAAkwAAAAAAAAACAAAAkwAAAR5JSkNOLTIwMDQuZG9jVzhCTk1TV0QA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHDgCRBw4B8kttDAAHDgLAAAABAAAAAQAAAAAAAAAA HgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAB4Dwk00BRcAAAAcAB7/ /w== --------------ad030205080308090207020506 Content-Type: application/octet-stream; name="IJCN-2004.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="IJCN-2004.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALgAAAAAA AAAAEAAAMAAAAAEAAAD+////AAAAAC0AAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAsUAJBAAA+BK/AAAAAAABEQABAAEABgAA vA8AAA4AamJqYpgKmAoAAAAAAAAAAAAAAAAAAAAAAAAJBBYAJhgAAPJoAQDyaAEAvAkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAPoAAAAAAAAA+gAAAPoAAAAAAAAA+gAAAAAAAAD6AAAA AAAAAPoAAAAAAAAA+gAAABQAAAAAAAAAAAAAACoBAAAAAAAAKgEAAAAAAAAqAQAAAAAAACoB AAAAAAAAKgEAAAwAAAA2AQAADAAAACoBAAAAAAAABggAAK4BAABOAQAAKAAAAHYBAAAAAAAA dgEAAAAAAAB2AQAAAAAAAHYBAAAAAAAAdgEAACIAAACYAQAADAAAAKQBAAAIAAAAwwcAAAIA AADFBwAAAAAAAMUHAAAAAAAAxQcAAAAAAADFBwAAAAAAAMUHAAAAAAAAxQcAACwAAAC0CQAA IAIAANQLAAB+AAAA8QcAABUAAAAAAAAAAAAAAAAAAAAAAAAA+gAAAAAAAACsAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAB2AQAAAAAAAHYBAAAAAAAArAEAAAAAAACsAQAAAAAAAPEHAAAAAAAA CAIAAAAAAAD6AAAAAAAAAPoAAAAAAAAAdgEAAAAAAAAAAAAAAAAAAHYBAAAAAAAATgEAAAAA AAAIAgAAAAAAAAgCAAAAAAAACAIAAAAAAACsAQAAOgAAAPoAAAAAAAAAdgEAAAAAAAD6AAAA AAAAAHYBAAAAAAAAwwcAAAAAAAAAAAAAAAAAAAgCAAAAAAAADgEAAA4AAAAcAQAADgAAAPoA AAAAAAAA+gAAAAAAAAD6AAAAAAAAAPoAAAAAAAAArAEAAAAAAADDBwAAAAAAAAgCAAC6AgAA CAIAAAAAAADCBAAAHgAAAI8HAAAYAAAA+gAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtwcAAAAAAAAAAAAA AAAAAEIBAAAMAAAA4ueguwAAAAAqAQAAAAAAACoBAAAAAAAA5gEAACIAAACnBwAACAAAAAAA AAAAAAAAtwcAAAwAAAAGCAAAAAAAAAYIAAAAAAAArwcAAAgAAABSDAAAAAAAAAgCAAAAAAAA UgwAAAAAAAC3BwAAAAAAAAgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABADDAA8A5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDYWxs IGZvciBQYXBlcnMNSW50ZXJuYXRpb25hbCBKb3VybmFsIG9mIENvbXB1dGVyIE5ldHdvcmtz DVNwZWNpYWwgSXNzdWUNDUludGVybmV0IG92ZXIgRGlnaXRhbCBCcm9hZGNhc3QgVmlkZW8g TmV0d29ya3MNRWRpdG9yczogTWFyaWUtSm9z6SBNb250cGV0aXQsIG1qbW9udHBldGl0LmNv bSBhbmQNR29ycnkgRmFpcmh1cnN0LCBVbml2ZXJzdGl0eSBvZiBBYmVyZGVlbg0NRGlnaXRh bCBWaWRlbyBCcm9hZGNhc3RpbmcgKERWQikgdGVjaG5vbG9naWVzIGFyZSB3aWRlbHkgdXNl ZCBvdmVyIGJyb2FkY2FzdCBtZWRpYSB0aGF0IGluY2x1ZGUgc2F0ZWxsaXRlIChEVkItUyks IGNhYmxlIChEVkItQyBhbmQgT3BlbiBDYWJsZSkgYW5kIHRlcnJlc3RyaWFsIChEVkItVCku IFRoZXkgcHJvdmlkZSB1bmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9ucyBmcm9tIHRoZSBj b250ZW50IHByb3ZpZGVyIHRvIHRoZSBlbmQgdXNlci4gIFRoZSByZXR1cm4gY2hhbm5lbCBj YW4gYmUgZWl0aGVyIHZpYSBhIHRlcnJlc3RyaWFsIHRlY2hub2xvZ3kgb3IgdmlhIHNhdGVs bGl0ZSAoRFZCIHJldHVybiBjaGFubmVsIHN5c3RlbSBvciBSQ1MpLiBDdXJyZW50IHN0YW5k YXJkcyBkZWZpbmUgYSBsaW5rIGxheWVyIHByb3RvY29sIHRvIGVuYWJsZSB0cmFuc21pc3Np b24gb2YgdGhlIGRpZ2l0YWwgbXVsdGltZWRpYSBjb250ZW50LiBNb3JlIGFuZCBtb3JlLCBo b3dldmVyLCBEVkIgaXMgdXNlZCB0byBidWlsZCBJbnRlcm5ldC1jb21wYXRpYmxlIG5ldHdv cmtzLiBJbiBvcmRlciB0byBkbyB0aGlzIGFuIE1QRUctMiBUcmFuc3BvcnQgU3RyZWFtIGNl bGwgaXMgdXNlZCBhcyBhIJNjb250YWluZXKUIGZvciB0aGUgSVAgcGFja2V0cyB3aXRoIGFu IGFkZGVkIGVuY2Fwc3VsYXRpb24gaGVhZGVyIHRvIGFsbG93IHRoZSBpbmZvcm1hdGlvbiB0 byBiZSBhZGVxdWF0ZWx5IHByb2Nlc3NlZC4gIE92ZXIgdGhlIHllYXJzIGEgbnVtYmVyIG9m IGVuY2Fwc3VsYXRpb24gbWV0aG9kcyBoYXZlIGJlZW4gZXhwbG9yZWQgdG8LdHJhbnNtaXQg ZGF0YSBvdmVyIGJyb2FkY2FzdCBtZWRpYS4goFRoZSBjdXJyZW50IHN0YW5kYXJkIGZvciBE VkIgaXMgdGhlC011bHRpLVByb3RvY29sIEVuY2Fwc3VsYXRpb24gKE1QRSkuIFdoaWxlIHRo aXMgbWF5IGJlIHVzZWQgdG8gc2VuZCBJbnRlcm5ldCBQYWNrZXRzLCB0aGVyZSBhcmUgZnVy dGhlciBpc3N1ZXMgdGhhdCBhcmlzZSB3aGVuIHVzZWQgdG8gYnVpbGQgYW4gSW50ZXJuZXQg U2VydmljZS4goFN1Y2ggaXNzdWVzIGFyZSBhbiBhY3RpdmUgcmVzZWFyY2ggdG9waWMsIGFu ZCBoYXZlIHJlY2VpdmVkIHJlY2VudCBhdHRlbnRpb24gaW4gdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpIGNvbW11bml0eS4gSW4gYWRkaXRpb24sIHJlY2Vu dCBlZmZvcnRzIGhhdmUgYmVlbiBkZWRpY2F0ZWQgdG8gbWFraW5nIERWQiBhIG1vcmUgZHlu YW1pYyBuZXR3b3JrIHdpdGggcHJvdG9jb2xzIGZvciBhZGRyZXNzIHJlc29sdXRpb24gYW5k IG11bHRpY2FzdCBncm91cCBtYW5hZ2VtZW50IHRvIGNvbXBsZW1lbnQgY3VycmVudCBzb2x1 dGlvbiB0aGF0IHVzZSB0YWJsZSBiYXNlZCBtZXRob2RzLiBGaW5hbGx5LCB0aGUgc3VwcG9y dCBmb3IgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpIGFuZCBzZWN1cml0eSBzZXJ2aWNlIGlz IGFsc28gYWN0aXZlbHkgcHVyc3VlZC4NDVRoaXMgc3BlY2lhbCBpc3N1ZSBpbnRlbmRzIHRv IHJldmlldyBjdXJyZW50IElQIG92ZXIgRFZCIHJlc2VhcmNoIGFuZCBlc3RhYmxpc2ggd2hh dCB0aGUgc3RhdHVzIG9mIHRoaXMgaW1wb3J0YW50IHRlY2hub2xvZ3kgaXMgaW4gdGhlIGRl cGxveW1lbnQgb2YgdGhlIGJyb2FkYmFuZCBuZXR3b3JrcyBvZiB0aGUgbmVhciBmdXR1cmUu IFRvcGljcyBhZGRyZXNzZWQgYnkgdGhlIHNwZWNpYWwgaXNzdWUgaW5jbHVkZSAoYnV0IGFy ZSBub3QgbGltaXRlZCB0byk6DXN5c3RlbSBkZXNpZ24gYW5kIHNjZW5hcmlvcw1EVkIgYW5k IE1QRUctMiBuZXR3b3JraW5nIHRlY2hub2xvZ2llcw1lbmNhcHN1bGF0aW9uIGFuZCBoYXJk d2FyZS9zb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbnMgZm9yIElQdjQgYW5kIHY2DWFkZHJlc3Mg cmVzb2x1dGlvbg1tdWx0aWNhc3QgZ3JvdXAgbWFuYWdlbWVudA1xdWFsaXR5IG9mIHNlcnZp Y2UgaXNzdWVzDXNpbXVsYXRpb24gb2YgRFZCIG5ldHdvcmtzDXN0YW5kYXJkaXphdGlvbiBl ZmZvcnRzDQ1NYW51c2NyaXB0cyBzaG91bGQgYmUgc2VudCB2aWEgZW1haWwgdG8gZWl0aGVy Og0TIEhZUEVSTElOSyAibWFpbHRvOm1hcmllQG1qbW9udHBldGl0LmNvbSIgARRtYXJpZUBt am1vbnRwZXRpdC5jb20VIG9yIBMgSFlQRVJMSU5LICJtYWlsdG86Z29ycnlAZXJnLmFiZG4u YWMudWsiIAEUZ29ycnlAZXJnLmFiZG4uYWMudWsVDQ1EZWFkbGluZXM6DUZ1bGwgcGFwZXJz OiBKYW51YXJ5IDFzdCAyMDAzIA1SZXZpZXdzIHJldHVybmVkOiBGZWJydWFyeSAxNXRoICAy MDA0DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAASAYAAEoG AAB5BgAAggYAAOIOAADjDgAADQ8AAA4PAAAPDwAAJA8AACUPAAApDwAAKg8AAFMPAABUDwAA VQ8AAGkPAABqDwAAbA8AAHcPAACNDwAAjw8AAJUPAACWDwAAsw8AALUPAAC8DwAA+fTq4tvK vanKoMq9yr2MyqDK2+LbhNt824TbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8+KgFDShYAT0oDAFFKAwAPQ0oWAEgqAU9KAwBRSgMA JwIIgQNq2wAAAAYIAT4qAUIqAUNKGgBPSgQAUUoEAFUIAXBoAAAAABAwSg8AQ0oaAE9KBABR SgQAACcCCIEDagAAAAAGCAE+KgFCKgFDShoAT0oEAFFKBABVCAFwaAAAAAAYPioBQioBQ0oa AE9KBABRSgQAcGgAAAAAACEDagAAAAA+KgFCKgFDShoAT0oEAFFKBABVCAFwaAAAAAAMQ0oW AE9KAwBRSgMAAA82CIFDShYAT0oDAFFKAwASNQiBPioBQ0ocAE9KAwBRSgMAAAhPSgMAUUoD AAALNQiBT0oDAFFKAwAAGwAGAAAQBgAAOwYAAEkGAABKBgAAeQYAAKwGAADVBgAA1gYAAKYM AACnDAAArw0AAMsNAADyDQAANg4AAEkOAABkDgAAfg4AAJkOAACxDgAAsg4AAOIOAABrDwAA bA8AAHcPAACWDwAAvA8AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMA AEMkAQAFAAAPhGgBXoRoAQUAAAomAAtGAQAABAAAAyQBYSQBAAEAAAAaAAYAABAGAAA7BgAA SQYAAEoGAAB5BgAArAYAANUGAADWBgAApgwAAKcMAACvDQAAyw0AAPINAAA2DgAASQ4AAGQO AAB+DgAAmQ4AALEOAACyDgAA4g4AAGsPAABsDwAAdw8AAJYPAAC8DwAAAAAAAAAAAAAAAAD8 9vDq5N7Y0gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACggBAAkBCgcAAAAACggBAAkBCgYAAAAA CggBAAkBCgUAAAAACggBAAkBCgQAAAAACggBAAkBCgMAAAAACggBAAkBCgIAAAAACggBAAkB CgEAAAAABQgBAAkBABokABaQAYAxkGgBH7DQLyCw4D0hsAUHIrAFByOQbgQkkG4EJbAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANsAAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABYAAABtAGEAcgBpAGUAQABtAGoAbQBvAG4AdABw AGUAdABpAHQALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQs6AAAAbQBhAGkAbAB0AG8AOgBt AGEAcgBpAGUAQABtAGoAbQBvAG4AdABwAGUAdABpAHQALgBjAG8AbQAAANcAAABEAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABUAAABnAG8AcgByAHkAQABlAHIAZwAuAGEA YgBkAG4ALgBhAGMALgB1AGsAAADgyep5+brOEYyCAKoAS6kLOAAAAG0AYQBpAGwAdABvADoA ZwBvAHIAcgB5AEAAZQByAGcALgBhAGIAZABuAC4AYQBjAC4AdQBrAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABEACgABAGkADwACAAAAAAAAACgA AEDx/wIAKAAMAAYATgBvAHIAbQBhAGwAAAACAAAACABDShgAbUgJBAAAAAAAAAAAAAAAAAAA AAAAADwAQUDy/6EAPAAMARYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAA RgBvAG4AdAAAAAAAAAAAAAAAAAAoAFVAogDxACgAAAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAA BgA+KgFCKgI4AFZAogABATgAAAARAEYAbwBsAGwAbwB3AGUAZABIAHkAcABlAHIAbABpAG4A awAAAAYAPioBQioMAAAAALwJAAAGAAAYAAAAAP////8BAAAABCH//wEAoHqZAAAAAAC8CQAA AAAAAAAAAAYAALwPAAAJAAAAAAYAALwPAAAKAAAAAAYAALwPAAALAAAA4ggAAA4JAAAkCQAA KQkAAFQJAABpCQAAvAkAABNYFAEVhBNYFAEVjP//AQAAAA0AXwBIAGwAdAA0ADYAMwA1ADMA MwAzADcAMwBXCQAAvgkAAAAAAEBZCQAAvgkAAAAAAACsAAAAsQAAALIAAAC7AAAAvQAAAMgA AAByBgAAdQYAAL4JAAAHABwABwAcAAcAHAAHABwABwAAAAAAmQgAAKgIAACxCQAAuwkAAL4J AAAHADoABwA6AAcA//8KAAAAFABNAGEAcgBpAGUALQBKAG8AcwBlACAATQBvAG4AdABwAGUA dABpAHQAAAALAEgAYQByAHIAeQAgAFIAdQBkAGkAbgBIAEMAOgBcAEUAaQBnAGUAbgBlAF8A RABhAHQAZQBpAGUAbgBcAEMAbwBtAHAAdQB0AGUAcgBOAGUAdABzAE0AYQBnAFwAUwBwAGUA YwBpAGEAbAAgAEkAcwBzAHUAZQBzAFwARABWAEIAXABDAGEAbABsACAAZgBvAHIAIABQAGEA cABlAHIAcwAuAGQAbwBjAAsASABhAHIAcgB5ACAAUgB1AGQAaQBuAEkAQwA6AFwARQBpAGcA ZQBuAGUAXwBEAGEAdABlAGkAZQBuAFwAQwBvAG0AcAB1AHQAZQByAE4AZQB0AHMATQBhAGcA XABTAHAAZQBjAGkAYQBsACAASQBzAHMAdQBlAHMAXABEAFYAQgBcAEMAYQBsAGwAIABmAG8A cgAgAFAAYQBwAGUAcgBzADIALgBkAG8AYwALAEgAYQByAHIAeQAgAFIAdQBkAGkAbgBJAEMA OgBcAEUAaQBnAGUAbgBlAF8ARABhAHQAZQBpAGUAbgBcAEMAbwBtAHAAdQB0AGUAcgBOAGUA dABzAE0AYQBnAFwAUwBwAGUAYwBpAGEAbAAgAEkAcwBzAHUAZQBzAFwARABWAEIAXABDAGEA bABsACAAZgBvAHIAIABQAGEAcABlAHIAcwAyAC4AZABvAGMABwBFAFIARwAgAFUAbwBBADoA IABPAFMAWAAmAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoAVQBzAGUAcgBzADoAZwBvAHIA cgB5ADoARABlAHMAawB0AG8AcAA6AEMAYQBsAGwAIABmAG8AcgAgAFAAYQBwAGUAcgBzADIA LgBkAG8AYwABAHQZaFJ0xYiM/w//D/8P/w//D/8P/w//D/8PEAAAAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oAAFBKAABRSgAAbygAAQAt AAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5P SgUAUUoFAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+E cAgRhJj+FcYFAAFwCAZehHAIYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBv KACHaAAAAACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAAFRgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBgBRSgYAbygAh2gAAAAA iEgAAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6E sBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA ABUYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K BgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAdBloUgAAAAAAAAAAAAAAAP///////wEAAAAA AP//AQAAAAAAAAAAAL4JAAABAAAA/0ADgAEAuwkAALsJAADw7lkFmACYALsJAAAAAAAAuwkA AAAAAAD9AAAApwRSAwIQAAAAAAAAALwJAABgAAAMAEAAAAcAAABHBpABAAAAAgIGAwUEBQID AAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1BpABAgAAAgAFAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwA AAAzBpABAAAAAgsGBAICAgICAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAA NwaQAQAAAAILBgQDBQQEAgAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAFYAZQByAGQAYQBuAGEA AABDBpABAAAAAAAAAAD/+AAAAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAATAB1AGMAaQBkAGEA IABHAHIAYQBuAGQAZQAAAD8GkAEAAAAAAAAAAP/4AAAAAAADAAAAAAAAAAAAAAAAAQAAAAAA AABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7BpABAgAABQIBAgEIBAgHAAAAABAAAAAAAAAA AAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAAiAAQAcQiIAADw0AIAAGgBAAAAAHq1 eKZVDXpmAAAAAAUABwAAAFEBAACDBwAAAQADAAAABAADEBAAAABaAQAAuAcAAAEAAwAAABAA AAAAAAAAQQIA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BQduBLQAtACBgTIwAAARABkAZAAAABkAAAA5CQAAEgkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAsQgAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAABAAwAAAAAAAABA APAQAN8DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAA8AQwBhAGwA bAAgAGYAbwByACAAUABhAHAAZQByAHMAAAAAAAAAFABNAGEAcgBpAGUALQBKAG8AcwBlACAA TQBvAG4AdABwAGUAdABpAHQABwBFAFIARwAgAFUAbwBBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAQAAAOCF n/L5T2gQq5EIACsns9kwAAAAgAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAALAAAAAEAAAA vAAAAAUAAADcAAAABgAAAOgAAAAHAAAA9AAAAAgAAAAEAQAACQAAABQBAAASAAAAIAEAAAoA AAA8AQAADAAAAEgBAAANAAAAVAEAAA4AAABgAQAADwAAAGgBAAAQAAAAcAEAABMAAAB4AQAA AgAAABAnAAAeAAAAEAAAAENhbGwgZm9yIFBhcGVycwAeAAAAAQAAAABhbGweAAAAFQAAAE1h cmllLUpvc2UgTW9udHBldGl0ACAAMR4AAAABAAAAAGFyaR4AAAABAAAAAGFyaR4AAAAHAAAA Tm9ybWFsAG8eAAAACAAAAEVSRyBVb0EAHgAAAAIAAAA1AEcgHgAAABQAAABNaWNyb3NvZnQg V29yZCAxMC4xAEAAAAAA6lb6AAAAAEAAAAAA/AAS8GjDAUAAAAAA3k2HWYjDAQMAAAABAAAA AwAAAFEBAAADAAAAgwcAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOX CAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5IAQAABAEAAAwAAAABAAAAaAAAAA8AAABwAAAA BQAAAIgAAAAGAAAAkAAAABEAAACYAAAAFwAAAKAAAAALAAAAqAAAABAAAACwAAAAEwAAALgA AAAWAAAAwAAAAA0AAADIAAAADAAAAOQAAAACAAAAECcAAB4AAAANAAAAIE1KTW9udHBldGl0 AGkAZQMAAAAQAAAAAwAAAAMAAAADAAAAOQkAAAMAAAByCQoACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAAeEAAAAQAAABAAAABDYWxsIGZvciBQYXBlcnMADBAAAAIAAAAeAAAA BgAAAFRpdGxlAAMAAAABAAAAAAAoAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEA AAACAAAADAAAAF9QSURfSExJTktTAAIAAAAQJwAAQQAAAOAAAAAMAAAAAwAAADEAYwADAAAA AwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHAAAAG0AYQBpAGwAdABvADoAZwBvAHIAcgB5AEAA ZQByAGcALgBhAGIAZABuAC4AYQBjAC4AdQBrAAAAHwAAAAEAAAAAAKqwAwAAAAgAPgADAAAA AAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHQAAAG0AYQBpAGwAdABvADoAbQBhAHIAaQBlAEAA bQBqAG0AbwBuAHQAcABlAHQAaQB0AC4AYwBvAG0AAAAAAB8AAAABAAAAAACqsAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwA AAD+////DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAAP7///8WAAAAFwAAABgAAAAZAAAA GgAAABsAAAAcAAAA/v///x4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAD+////JgAAACcA AAAoAAAAKQAAACoAAAArAAAALAAAAP7////9////LwAAAP7////+/////v////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////// //8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAAAFQgliiMMBMQAAAIAAAAAAAAAA RABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAANAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUAAAAAEAAAAAAAAFcAbwByAGQARABvAGMA dQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB AgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYY AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAdAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAAEAAAAAAAAAEAQwBvAG0A cABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////wEA/v8CAAEA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9j dW1lbnQA/v///05CNlcQAAAAV29yZC5Eb2N1bWVudC44AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --------------ad030205080308090207020506-- --------------050605080102070203060308-- From owner-ip-dvb@erg.abdn.ac.uk Mon Oct 6 09:47:22 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h968kxpa006076 for ; Mon, 6 Oct 2003 09:46:59 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h968kwvf006075 for ip-dvb-subscribed-users; Mon, 6 Oct 2003 09:46:58 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h968kApb006034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Oct 2003 09:46:12 +0100 (BST) Message-ID: <3F812BDE.6030609@erg.abdn.ac.uk> Date: Mon, 06 Oct 2003 09:46:22 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Call for Papers: IJCN - More Information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Several people have enquired to me about the call for papers in the forth-coming Special Issue of IJCN. Those of you not familiar with the The International Journal of Computer and Telecommunications Networking, you may like to look at the following web page (where there is details of submission and also information about previous Special Issues): http://www.elsevier.nl/locate/comnet Gorry P.S. Thanks for those who spotted the deadline for submission, is of course early 2004, not 2003. > There will be a Special Issue of the International > Journal of Computer Networks devoted to > "Internet over Digital Broadcast Video Networks". This > seems very close to the topics discussed on this list, > so I warmly invite you to consider submission of a paper. > Those interesed, are referred to the attached call for papers. From owner-ip-dvb@erg.abdn.ac.uk Mon Oct 6 09:51:33 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h968o3pa006241 for ; Mon, 6 Oct 2003 09:50:03 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h968o2Oj006240 for ip-dvb-subscribed-users; Mon, 6 Oct 2003 09:50:02 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h968nJpb006173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Oct 2003 09:49:19 +0100 (BST) Message-ID: <3F812C9A.2090203@erg.abdn.ac.uk> Date: Mon, 06 Oct 2003 09:49:30 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: FYI: Internet-Draft Cutoff Dates for Minneapolis, MN, USA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk NOTE: There are two (2) Internet-Draft Cutoff dates October 20th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, October 20th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, October 13th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of October 20th will NOT be accepted. October 27th: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, October 27th, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_58.html From owner-ip-dvb@erg.abdn.ac.uk Tue Oct 7 19:52:24 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h97Ipvpa000409 for ; Tue, 7 Oct 2003 19:51:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h97IpvWg000408 for ip-dvb-subscribed-users; Tue, 7 Oct 2003 19:51:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h97IpTpb000385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Oct 2003 19:51:30 +0100 (BST) Message-ID: <3F830B54.4090001@erg.abdn.ac.uk> Date: Tue, 07 Oct 2003 19:52:04 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: [Fwd: I-D ACTION:draft-fair-ipdvb-ule-01.txt] Content-Type: multipart/mixed; boundary="------------040106010405080708050209" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------040106010405080708050209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I'm pleased to announce the latest draft of the ULE spec. The author's main aim in publishing this rev. a long way before the ID cut-off for the next IETF is to stimulate feedback on the design decisions taken so far (of course, things may change if there's a good case) and to ask for help with the next stage. This is still a work in progress, and there are still many cases we need to clarify, and quite a few minor issues to be fixed with the text. One or two important design decisions will also be needed soon. Please review and email the authors and/or list. Best wishes Gorry Fairhurst ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-fair-ipdvb-ule-01.txt Pages : 29 Date : 2003-10-7 The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fair-ipdvb-ule-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fair-ipdvb-ule-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------040106010405080708050209 Content-Type: message/external-body; x-mac-type="0"; x-mac-creator="0"; name="draft-fair-ipdvb-ule-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-fair-ipdvb-ule-01.txt" Content-Type: text/plain Content-ID: <2003-10-7110948.I-D@ietf.org> --------------040106010405080708050209-- From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 8 08:23:54 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h987Mvpa029453 for ; Wed, 8 Oct 2003 08:22:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h987MvLJ029452 for ip-dvb-subscribed-users; Wed, 8 Oct 2003 08:22:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h987Lqpa029402 for ; Wed, 8 Oct 2003 08:21:52 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 58AD8660 for ; Wed, 8 Oct 2003 09:21:52 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 448D66E8; Wed, 8 Oct 2003 09:21:52 +0200 (CEST) Message-ID: <3F83BBDC.50203@6wind.com> Date: Wed, 08 Oct 2003 09:25:16 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: ULE-01 : last byte(s) precision X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk OK, the PP using the last available byte has been cleared ! And there are no more case with the lenght/end_inidcator being split over 2 TS cells, but ... 5.3 != 5.3.1 "If there is at least two remaining bytes ...." "... and a TS packet has more than two bytes of unused payload" so >2 or >=2 ? so if there is 2 bytes left, and a PP not already set, I see it has to start on a next TS cell, but if the PP is already set, does the new SNDU start in the same TS packet ? From the exemple A.2 (SNDU D) I would think yes, but from the text I have a doubt. More over in the exemple section a case should be shown, that packing with a PP creation is not done when there is only two bytes left, for it would split the length, this can be shown with in the exemple A.2 SNDU D : 184 bytes (instead of 185) SNDU E , which lead to : .... PP=0 +-----+------+------+- -+------+------+------+ | HDR | 0x00 | C000 | ... | C180 | D000 | D001 | +-----+---*--+-*----+- -+------+------+------+ PUSI=1 * * ****** End Indicator +-----+------+- -+------+------+------+ | HDR | D002 | ... | D183 | 0xFF | 0xFF | +-----+------+- -+------+------+------+ PUSI=0 PP=0 +-----+------+------+- | HDR | 0x00 | E000 | ... +-----+---*--+-*----+- PUSI=1 * * ****** Your thoughts ? Best wishes. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 8 08:19:50 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h987JMpa029290 for ; Wed, 8 Oct 2003 08:19:22 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h987JL7P029287 for ip-dvb-subscribed-users; Wed, 8 Oct 2003 08:19:21 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h987Ikpa029247 for ; Wed, 8 Oct 2003 08:18:46 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 0DEE3660 for ; Wed, 8 Oct 2003 09:18:46 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id DAAEF6BE; Wed, 8 Oct 2003 09:18:45 +0200 (CEST) Message-ID: <3F83BB22.2040509@6wind.com> Date: Wed, 08 Oct 2003 09:22:10 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: ULE-01 : minor correction X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Some minor remarks/corrections about the -01 version of ULE. 1) bit R 4.1 reserved field "the value of this bit MUST be checked ignored" I think it is "the value of this bit MUST be ignored" am I correct ? 2) example in 4.7.5 type = 0x0800, should be type = 0x0001 Regards Alain -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 8 08:22:58 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h987Lrpa029406 for ; Wed, 8 Oct 2003 08:21:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h987LrIb029405 for ip-dvb-subscribed-users; Wed, 8 Oct 2003 08:21:53 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h987LFpa029381 for ; Wed, 8 Oct 2003 08:21:16 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 0EC745CE for ; Wed, 8 Oct 2003 09:21:16 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id EE141646; Wed, 8 Oct 2003 09:21:15 +0200 (CEST) Message-ID: <3F83BBB8.5040603@6wind.com> Date: Wed, 08 Oct 2003 09:24:40 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: ULE-01 : Destination Address Field X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk About the Destination Address Field : 1) Destination Indicator For early implementors, a position for this flag should be chosen quickly ! For exempel, it could be possible to catch another bit out of the Length Field. It leaves 14 bits for the lengh field itself, allowing 16K SNDU .----------------------- SNDU ------------------------. +---+---+-----------------------------------------+--------+ | D | R | Length | Type | PDU | CRC-32 | +---+---+-----------------------------------------+--------+ 4.x Destination Field The most significant bit of the Length Field is a flag indicating the presence of a destination field, with the following semantic : 1 : destination field absent 0 : destination field present One exception is transmission of an End Indicator (see 4.y), in which this bit MUST be set to the value of 1. And so th Length Field description would become "A 15-bit value that ..." --> "A 14-bit value that ..." 2) Presence of Destination Address Field "This field MUST be carried for IP unicast packets destined to routers" This may be a little bit too much, and in contradiction wtih the following sentence : "MAY omit ... receivers able to use a discriminator field (e.g. the destination address)" in the case the Receiver is a CPE that know what network is behind him (P::/48), it cans filter packet on this basis, hence it is able to discriminate without MAC @, even if it is a router. Now to the question how does the encapsulator know about this, I think it can be solved because there is some address resolution (static, table, whatever) that provides P::/48 --> PID,MAC If MAC == 00:00:00:00:00:00, the the encapsulator omit the destination address field At in the receiver side, there must be a configuration knob to allow/forbid IP(v6)-SNDU packets to be acepted without Destination Address field present. In the described case, if the receiver is in a position, where it CAN SAFELY filter out of the destination IP(v6) address, it allows the recpetion of such SNDU In the case where the receiver has not enough knowledge to filter properly at IP-level, the knob is off, and all IP(v6) packets sent within an SNDU without the destination Address Field are silently discard. Of course the (knob == 1) has to be in sync with the (MAC@ == 0) ! So I would say: "This field SHOULD be carried for IP unicast packets destined to ..." Your thoughts ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 8 18:22:54 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h98HLXpa024217 for ; Wed, 8 Oct 2003 18:21:33 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h98HLXmK024216 for ip-dvb-subscribed-users; Wed, 8 Oct 2003 18:21:33 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h98HL3pa024179 for ; Wed, 8 Oct 2003 18:21:04 +0100 (BST) Received: from copernicus ([68.163.160.35]) by out004.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20031008172059.EZLG25700.out004.verizon.net@copernicus> for ; Wed, 8 Oct 2003 12:20:59 -0500 Message-ID: <01c701c38dc0$8e786d00$b402a8c0@copernicus> From: "Marie-Jose Montpetit" To: References: <3F83BBB8.5040603@6wind.com> Subject: Re: ULE-01 : Destination Address Field Date: Wed, 8 Oct 2003 13:21:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [68.163.160.35] at Wed, 8 Oct 2003 12:20:59 -0500 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Alain: snip/snip > Now to the question how does the encapsulator know about this, I > think it can be solved because there is some address resolution > (static, table, whatever) that provides P::/48 --> PID,MAC I don't want to start too much of a debate here but the problem I think is there is not a unique and universally used adress resolution mechanism that we can entirely rely on. Or do you have one? I guess you have read the AR draft; this is currently also investigated by other people including ETSI. Static (I call it pre-determined) is easy of course but not appropriate for all networks and does not fully support traffic engineering. The current standardised approach is the use of tables - INT for example that does address mapping/advertising. Those are received every 10 seconds in satellites (even less often on the other networks); it works but could lack the dynamics we want. The "whatever", an on demand, is really what is needed ;-) I guess for the moment the ULE draft should maybe not rely on "what we think the other system is using" or on non-existent solutions. We intend to streamline and update the AR draft to address these issues. Marie-Jose From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 9 08:38:21 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h997btpa027102 for ; Thu, 9 Oct 2003 08:37:55 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h997btJY027101 for ip-dvb-subscribed-users; Thu, 9 Oct 2003 08:37:55 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h997bUpa027087 for ; Thu, 9 Oct 2003 08:37:30 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 5011865F for ; Thu, 9 Oct 2003 09:37:30 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 3877A5AC; Thu, 9 Oct 2003 09:37:30 +0200 (CEST) Message-ID: <3F851106.5030308@6wind.com> Date: Thu, 09 Oct 2003 09:40:54 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : Destination Address Field References: <3F83BBB8.5040603@6wind.com> <01c701c38dc0$8e786d00$b402a8c0@copernicus> In-Reply-To: <01c701c38dc0$8e786d00$b402a8c0@copernicus> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Marie-Jose Montpetit wrote: > Alain: > snip/snip > >>Now to the question how does the encapsulator know about this, I >>think it can be solved because there is some address resolution >>(static, table, whatever) that provides P::/48 --> PID,MAC > > I don't want to start too much of a debate here but the problem I think is > there is not a unique and universally used adress resolution mechanism that > we can entirely rely on. Or do you have one? I guess you have read the AR > draft; this is currently also investigated by other people including ETSI. No I don't have one :-( But what I had in mind was, not to rely on specific address resolution mecanism, bur rather on a reserved MAC@ value such as 0:0:0:0:0:0 whose meaning would be "don't insert the MAC@ and save 6 bytes". This was just and idea, and I admit the ULE draft shouldn't rely on it. The only thing I had in mind, was to relax the condition on the MAC@ : "This field MUST be carried for IP unicast packets destined to ..." - "Unless explicitly configured for some IP networks, this field MUST be carried for IP unicast packets destined to ..." - "Unless explicitly configured, receiving routers MUST discard unicast IP packets received in SNDU without Destination Address Field" The rest of the discusionn is more relevant to th AR draft. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 9 12:55:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99Bsvpa007883 for ; Thu, 9 Oct 2003 12:54:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h99Bsv2X007882 for ip-dvb-subscribed-users; Thu, 9 Oct 2003 12:54:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99BsOpb007843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Oct 2003 12:54:25 +0100 (BST) Message-ID: <3F854C71.6090201@erg.abdn.ac.uk> Date: Thu, 09 Oct 2003 12:54:25 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : minor correction References: <3F83BB22.2040509@6wind.com> In-Reply-To: <3F83BB22.2040509@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thanks for NiTs, the more we spot and fix, the better the ID is! (1) Receivers MUST ignore this bit... i.e. the semantics of this bit is still to determined by this group. (2) This was a mistake The type should be 0x0001 to agree with the current text. Both of these have now been corrected in my working copy. Gorry alain.ritoux@6wind.com wrote: > Some minor remarks/corrections about the -01 version of ULE. > > 1) bit R > 4.1 reserved field > "the value of this bit MUST be checked ignored" > > I think it is "the value of this bit MUST be ignored" > am I correct ? > > 2) example in 4.7.5 > type = 0x0800, should be type = 0x0001 > > > Regards > Alain From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 9 14:06:09 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99D5Ipa010998 for ; Thu, 9 Oct 2003 14:05:18 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h99D5IDK010995 for ip-dvb-subscribed-users; Thu, 9 Oct 2003 14:05:18 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (indigo-mac.erg.abdn.ac.uk [139.133.207.14]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99D3lpa010902 for ; Thu, 9 Oct 2003 14:03:48 +0100 (BST) Message-ID: <3F855CB8.DAF37BE5@erg.abdn.ac.uk> Date: Thu, 09 Oct 2003 14:03:53 +0100 From: Mahesh Sooriyabandara Organization: Electronics Reasearch Group, University of Aberdeen X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Alain, It's a good question! Clearly we need more text: There are three concerns on the use of unused bytes in a TS-packet. (i) No PP (i.e. when PUSI =0) and 1 B remaining (this is fixed in ULE -01, i.e. by skipping is there is <2B remaining). If PP is not set, the remaining one byte can not be used for packing in any case. But if PP is set and use of remaining 1 byte for packing depends on whether splitting of "end indicator" (case ii) and/or " length field" (case iii) is allowed. (ii) No split "end indicator" if we skip when {0,1} bytes remaining (as in ULE -01, i.e. by skipping is there is <2B remaining). (iii) No split Length field if {0,1,2} bytes when PUSI set and {0,1,2,3) bytes when PUSI was not originally set. That would mean skipping if there is <4B remaining! A discussion on each of the three cases should help resolve the ambiguity in the current text. Adding another example is a good idea anyway - we first need to decide if this is OPTIONAL or REQUIRED behaviour. -Mahesh alain.ritoux@6wind.com wrote: > OK, the PP using the last available byte has been cleared ! > And there are no more case with the lenght/end_inidcator > being split over 2 TS cells, but ... > > 5.3 != 5.3.1 > "If there is at least two remaining bytes ...." > "... and a TS packet has more than two bytes of unused payload" > > so >2 or >=2 ? > > so if there is 2 bytes left, and a PP not already set, I see > it has to start on a next TS cell, but if the PP is already set, > does the new SNDU start in the same TS packet ? From the exemple > A.2 (SNDU D) I would think yes, but from the text I have a doubt. > > More over in the exemple section a case should be shown, that packing > with a PP creation is not done when there is only two bytes left, for > it would split the length, this can be shown with in the exemple A.2 > SNDU D : 184 bytes (instead of 185) > SNDU E , which lead to : > > .... > PP=0 > +-----+------+------+- -+------+------+------+ > | HDR | 0x00 | C000 | ... | C180 | D000 | D001 | > +-----+---*--+-*----+- -+------+------+------+ > PUSI=1 * * > ****** > End Indicator > +-----+------+- -+------+------+------+ > | HDR | D002 | ... | D183 | 0xFF | 0xFF | > +-----+------+- -+------+------+------+ > PUSI=0 > > PP=0 > +-----+------+------+- > | HDR | 0x00 | E000 | ... > +-----+---*--+-*----+- > PUSI=1 * * > ****** > > Your thoughts ? > > Best wishes. > Alain. > -- > Alain RITOUX > Tel +33-1-39-30-92-32 > Fax +33-1-39-30-92-11 > visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 9 15:05:31 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99E4mpa013557 for ; Thu, 9 Oct 2003 15:04:48 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h99E4ms1013555 for ip-dvb-subscribed-users; Thu, 9 Oct 2003 15:04:48 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99E3xpa013497 for ; Thu, 9 Oct 2003 15:03:59 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 05F9E3C2 for ; Thu, 9 Oct 2003 16:04:00 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id D70EB639; Thu, 9 Oct 2003 16:03:59 +0200 (CEST) Message-ID: <3F856B9C.5080108@6wind.com> Date: Thu, 09 Oct 2003 16:07:24 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> <3F855CB8.DAF37BE5@erg.abdn.ac.uk> In-Reply-To: <3F855CB8.DAF37BE5@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Mahesh Sooriyabandara wrote: > Alain, > > It's a good question! > Clearly we need more text: > > There are three concerns on the use of unused bytes in a TS-packet. > > (i) No PP (i.e. when PUSI =0) and 1 B remaining (this is fixed in ULE > -01, i.e. by skipping is there is <2B remaining). > If PP is not set, the remaining one byte can not be used for packing in > any case. OK this is set. > But if PP is set and use of remaining 1 byte for packing depends on > whether splitting of "end indicator" (case ii) and/or " length field" > (case iii) > is allowed. > (ii) No split "end indicator" if we skip when {0,1} bytes remaining (as > in ULE -01, i.e. by skipping is there is <2B remaining). OK as well. > > (iii) No split Length field if {0,1,2} bytes when PUSI set and {0,1,2,3) > > bytes when PUSI was not originally set. That would mean skipping if > there is <4B remaining! No, I think it is one byte less. I think splitting length and/or end-indicator is a bad idea because the receiver must in such case, when there is nor more SNDU, the receive a next TS cell to discover that there was nothing more ! the way to work that seems good to me is : PP set, 0,1 bytes left --> new TS-cell PP set, >= 2 bytes left --> pack in this TS-cell PP not set, 0,1,2 bytes left --> new TS-cell PP not set, >=3 bytes left --> pack in this TS-cell which can be "coded" as follow -In the sender : if (PUSI == 1) Needed = 2; else Needed = 3; if (packing_allowed && (bytes_letf >= Needed)) { if (PUSI == 0) { set PUSI = 1; insert_payload_pointer(); } sart_new_SNDU_in_this_TS(); } else { padd_with_0xff(); SNDU_in_new_TS_cell(); } -In the receiver, after an SNDU completion : if (remaing_bytes < 2) ignore_last_bytes(); else { if (first_two_bytes == 0xffff) ignore_last_bytes(); else { /* * Here we even know the SNDU length */ start_SNDU_reass(); } } Here is a text that I think would remove all ambiguity, and that needs not detail the sub-case is PP alreay set or not ... "If the first two bytes of an SNDU can not be put in in TS-cell, then, a new TS cell MUST be started." your thoughts ? Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 9 17:06:49 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99G68pa018790 for ; Thu, 9 Oct 2003 17:06:08 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h99G67al018788 for ip-dvb-subscribed-users; Thu, 9 Oct 2003 17:06:07 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (indigo-mac.erg.abdn.ac.uk [139.133.207.14]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99G5Wpa018746 for ; Thu, 9 Oct 2003 17:05:32 +0100 (BST) Message-ID: <3F858751.FB2A5F0F@erg.abdn.ac.uk> Date: Thu, 09 Oct 2003 17:05:38 +0100 From: Mahesh Sooriyabandara Organization: Electronics Reasearch Group, University of Aberdeen X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> <3F855CB8.DAF37BE5@erg.abdn.ac.uk> <3F856B9C.5080108@6wind.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk ..snip > > > (iii) No split Length field if {0,1,2} bytes when PUSI set and {0,1,2,3) > > > > bytes when PUSI was not originally set. That would mean skipping if > > there is <4B remaining! > No, I think it is one byte less. Yes, ofcourse it should be one less, my mistake > I think splitting length and/or end-indicator is a bad idea > because the receiver must in such case, when there is nor more > SNDU, the receive a next TS cell to discover that there was nothing > more ! I also think it may not be worth to add extra complexity to receiver code for (1 or 2)/184 gain. But what exactly is the real penalty if we choose to allow splitting of length field and/or end indicator? > the way to work that seems good to me is : > PP set, 0,1 bytes left --> new TS-cell > PP set, >= 2 bytes left --> pack in this TS-cell > PP not set, 0,1,2 bytes left --> new TS-cell > PP not set, >=3 bytes left --> pack in this TS-cell Agree ..snip > Here is a text that I think would remove all ambiguity, and that > needs not detail the sub-case is PP alreay set or not ... > > "If the first two bytes of an SNDU can not be put in in TS-cell, > then, a new TS cell MUST be started." This looks good to me. However, may be it is useful to explicitly state the reason for this two bytes decision (details of the PP set or not set case). - Mahesh From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 9 17:54:41 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99Grrpa020879 for ; Thu, 9 Oct 2003 17:53:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h99GrqmE020878 for ip-dvb-subscribed-users; Thu, 9 Oct 2003 17:53:52 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h99Gqspa020829 for ; Thu, 9 Oct 2003 17:52:54 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id B87176CB for ; Thu, 9 Oct 2003 18:52:55 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id A1F57799; Thu, 9 Oct 2003 18:52:55 +0200 (CEST) Message-ID: <3F859334.8050100@6wind.com> Date: Thu, 09 Oct 2003 18:56:20 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> <3F855CB8.DAF37BE5@erg.abdn.ac.uk> <3F856B9C.5080108@6wind.com> <3F858751.FB2A5F0F@erg.abdn.ac.uk> In-Reply-To: <3F858751.FB2A5F0F@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Mahesh Sooriyabandara wrote: > > ... snip ... > > I also think it may not be worth to add extra complexity to receiver code for > > (1 or 2)/184 gain. > > But what exactly is the real penalty if we choose to allow splitting of > length > field and/or end indicator? - more complexity in the code of the receiver, because it has to keep a sort of new state for an SNDU which is currently being in the reass process and whose length is still not known. - in case of end of packing, the end-indicator needs an extra TS-cell to be transmitted. well, that's not overkilling, but I don't think the 1 byte gain (in only some cases) is really worth the effort. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Fri Oct 10 09:42:31 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9A8fcpa028545 for ; Fri, 10 Oct 2003 09:41:38 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9A8fcDI028544 for ip-dvb-subscribed-users; Fri, 10 Oct 2003 09:41:38 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9A8f0pb028510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Oct 2003 09:41:01 +0100 (BST) Message-ID: <3F86709C.30607@erg.abdn.ac.uk> Date: Fri, 10 Oct 2003 09:41:00 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> <3F855CB8.DAF37BE5@erg.abdn.ac.uk> <3F856B9C.5080108@6wind.com> <3F858751.FB2A5F0F@erg.abdn.ac.uk> <3F859334.8050100@6wind.com> In-Reply-To: <3F859334.8050100@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk alain.ritoux@6wind.com wrote: > Mahesh Sooriyabandara wrote: > >> >> ... snip ... > > > > >> I also think it may not be worth to add extra complexity to receiver >> code for >> >> (1 or 2)/184 gain. >> >> But what exactly is the real penalty if we choose to allow splitting of >> length >> field and/or end indicator? > > > - more complexity in the code of the receiver, because it has to > keep a sort of new state for an SNDU which is currently being > in the reass process and whose length is still not known. The current spec says the sender *MAY* choose to do this, either based on policy, or some otehr rules. So if the sender wishes to never fragment the length, this is allowed, that's currently a design choice for the encapsulation gateway. So the issue you speak of is a receiver simplification. I worry about the breadth of implementation experience here. Is this important enougth to add a mandatory rule to require the sender to do this? - I'd like to understand more. > > - in case of end of packing, the end-indicator needs an extra > TS-cell to be transmitted. Not so, the current spec says the receiver MUST discard any TS-Packet Payload with only one byte remaining, when looking for a new start of SNDU. > > > well, that's not overkilling, but I don't think the 1 byte gain (in > only some cases) is really worth the effort. > > Alain. Gorry From owner-ip-dvb@erg.abdn.ac.uk Fri Oct 10 09:37:46 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9A8Zdpa028287 for ; Fri, 10 Oct 2003 09:35:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9A8ZchX028286 for ip-dvb-subscribed-users; Fri, 10 Oct 2003 09:35:39 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9A8XJpb028181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Oct 2003 09:33:20 +0100 (BST) Message-ID: <3F866ECE.6030807@erg.abdn.ac.uk> Date: Fri, 10 Oct 2003 09:33:18 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> <3F855CB8.DAF37BE5@erg.abdn.ac.uk> <3F856B9C.5080108@6wind.com> <3F858751.FB2A5F0F@erg.abdn.ac.uk> In-Reply-To: <3F858751.FB2A5F0F@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk My comments in-line too. Mahesh Sooriyabandara wrote: >..snip > > > >>>(iii) No split Length field if {0,1,2} bytes when PUSI set and {0,1,2,3) >>> >>>bytes when PUSI was not originally set. That would mean skipping if >>>there is <4B remaining! >>> >>> >>No, I think it is one byte less. >> >> > >Yes, ofcourse it should be one less, my mistake > > Agreed, this would require >=3B of space remaining in a TS Packet payload. >>I think splitting length and/or end-indicator is a bad idea >>because the receiver must in such case, when there is nor more >>SNDU, the receive a next TS cell to discover that there was nothing >>more ! >> >> > >I also think it may not be worth to add extra complexity to receiver code for > >(1 or 2)/184 gain. > >But what exactly is the real penalty if we choose to allow splitting of >length >field and/or end indicator? > > > Does someone wish to offer text to describe this trade-off? >>the way to work that seems good to me is : >> PP set, 0,1 bytes left --> new TS-cell >> PP set, >= 2 bytes left --> pack in this TS-cell >> PP not set, 0,1,2 bytes left --> new TS-cell >> PP not set, >=3 bytes left --> pack in this TS-cell >> >> > >Agree > >..snip > > > >>Here is a text that I think would remove all ambiguity, and that >>needs not detail the sub-case is PP alreay set or not ... >> >>"If the first two bytes of an SNDU can not be put in in TS-cell, >>then, a new TS cell MUST be started." >> >> >This looks good to me. > Seems to match the argument above. >However, may be it is useful to explicitly state the >reason for this two bytes decision (details of the PP set or not set case). > I'd agree - some text saying *why* you wish to have the length field all in one packet would be good. > >- Mahesh > > > Gorry Fairhurst From owner-ip-dvb@erg.abdn.ac.uk Fri Oct 10 10:42:39 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9A9fjpa001134 for ; Fri, 10 Oct 2003 10:41:45 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9A9fibj001133 for ip-dvb-subscribed-users; Fri, 10 Oct 2003 10:41:45 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9A9f2pa001098 for ; Fri, 10 Oct 2003 10:41:06 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 8A9B0640 for ; Fri, 10 Oct 2003 11:41:02 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 7B472646; Fri, 10 Oct 2003 11:41:02 +0200 (CEST) Message-ID: <3F867F7B.7020100@6wind.com> Date: Fri, 10 Oct 2003 11:44:27 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: ULE-01 : last byte(s) precision References: <3F83BBDC.50203@6wind.com> <3F855CB8.DAF37BE5@erg.abdn.ac.uk> <3F856B9C.5080108@6wind.com> <3F858751.FB2A5F0F@erg.abdn.ac.uk> <3F859334.8050100@6wind.com> <3F86709C.30607@erg.abdn.ac.uk> In-Reply-To: <3F86709C.30607@erg.abdn.ac.uk> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry Fairhurst wrote: >> - more complexity in the code of the receiver, because it has to >> keep a sort of new state for an SNDU which is currently being >> in the reass process and whose length is still not known. > > > The current spec says the sender *MAY* choose to do this, either based > on policy, or some otehr rules. So if the sender wishes to never > fragment the length, this is allowed, that's currently a design choice > for the encapsulation gateway. Yes but if the packing is optionnal for the sender, its processing by the receiver is mandatory, because it cannot know wether the sender is packing-enabled or not, or wether it preforms lenght-split or not. ** well I realize it has no importance, see below > ... snip ... > So the issue you speak of is a receiver simplification. I worry about > the breadth of implementation experience here. Is this important > enougth to add a mandatory rule to require the sender to do this? - I'd > like to understand more. > >> >> - in case of end of packing, the end-indicator needs an extra >> TS-cell to be transmitted. > > > Not so, the current spec says the receiver MUST discard any TS-Packet > Payload with only one byte remaining, when looking for a new start of SNDU. OK I missed that point. Indeed the before-the-last paragraph of 5.2.2 need that the sender behave acordingly i.e. : "If there is either 0 or 1 byte of payload data remaining in the TS Packet after completion of the Current SNDU, the receiver MUST discard this remaining TS payload, and wait for the next TS Packet with the PUSI value set to 1 (the Idle State). " ==> The sender MUST NOT start a SNDU if it cannot put at least 2 bytes. because if only one byte can be stored, it will be dropped by the receiver. This more or less the same thing as > "If the first two bytes of an SNDU can not be put in in TS-cell, > then, a new TS cell MUST be started." >> [extract from the following Gorry'smail] >> I'd agree - some text saying *why* you wish to have the length field >> all in one packet would be good. Indeed in that case, the fact that length is not split is no more a goal, but a consquence fo the rule the sender has to apply, to conform to the receiver expectation Cheers. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Sun Oct 12 15:25:25 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9CEP0pa002288 for ; Sun, 12 Oct 2003 15:25:00 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9CEP0xL002281 for ip-dvb-subscribed-users; Sun, 12 Oct 2003 15:25:00 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.7] (maxp31.abdn.ac.uk [139.133.7.190]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9CENkpd002206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 12 Oct 2003 15:23:58 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 05 Jan 1970 07:00:50 +0100 Subject: Request for agenda items for IETF-58 Minneapolis From: Gorry Fairhurst To: Message-ID: <7C2B5922.D34%gorry@erg.abdn.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I've requested a meeting slot for IETF-58 (although this may not yet appear in the programme). My tentative agenda is based on the previous BoF agenda, but the group would welcome relevant contributions on any topics addressed by the Charter and/or published Ids, or implementation issues. If you wish to contribute brief presentations on these topics and/or their relationship to DVB, ATSC, and other ISO-MPEG-based standards please EMAIL DIRECTLY TO: gorry@erg.abdn.ac.uk Please also do let me know if you intend to submit a new ID on this subject. I'll send out a proposed Agenda at the start of the week starting 20th October. Gorry From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 15 10:57:37 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9F9vFpa013363 for ; Wed, 15 Oct 2003 10:57:15 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9F9vFBq013362 for ip-dvb-subscribed-users; Wed, 15 Oct 2003 10:57:15 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9F9uhpb013334 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 15 Oct 2003 10:56:46 +0100 (BST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9F9ugd08789 for ; Wed, 15 Oct 2003 12:56:43 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 12:56:42 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:56:41 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:56:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Multicast Session/Service/etc discovery & announcement Date: Wed, 15 Oct 2003 12:56:38 +0300 Message-ID: <2BF0AD29BC31FE46B788773211440431038165E6@trebe003.europe.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast Session/Service/etc discovery & announcement Thread-Index: AcOS9gsoVA8cELvBTy+SKp1fLS1jzg== From: To: , , , , Cc: X-OriginalArrivalTime: 15 Oct 2003 09:56:39.0866 (UTC) FILETIME=[A11B89A0:01C39302] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id h9F9vCQn013358 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Does our current effort to summarize multicast service discovery requirements in MMUSIC meet your needs? Internet Media Guide requirements: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt Clearly, exchanging/announcing session/etc parameters effects joining (SSM and ASM), involves security risks and enable multicast content services - like streaming media and file delivery. So any comments, criticisms, ideas and beers are welcome. (Speaking of service announcements, does Minneapolis offer the same excellent range of Ales as San Francisco?) Cheers, Rod. From owner-ip-dvb@erg.abdn.ac.uk Thu Oct 16 18:51:02 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9GHmqpa009135 for ; Thu, 16 Oct 2003 18:48:52 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9GHmpOJ009130 for ip-dvb-subscribed-users; Thu, 16 Oct 2003 18:48:52 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9GHlqpa008791 for ; Thu, 16 Oct 2003 18:47:52 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 06F195F9 for ; Thu, 16 Oct 2003 19:47:52 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id DFEA96C7; Thu, 16 Oct 2003 19:47:51 +0200 (CEST) Message-ID: <3F8EDA96.2000700@6wind.com> Date: Thu, 16 Oct 2003 19:51:18 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: ULE, and CRC-32 X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Some questions about the CRC-32, because I'm a little bit confused. I think many of you are familiars with that CRC-32 stuff, so I need their help ;-) If I understand correctly, the CRC-32 is computed over : [ ENCAP_HDR ][ IP datagram ][0x00 0x00 0x00 0x00] with an initial crc set to [A B C D] the "Initial Register Value" of the Author's note", and then XORed with a [E F G H] value. Then what is sent is : [ ENCAP_HDR ][ IP datagram ][CRC-32-MSB-first] An then in the receiver, the [CRC-32] must be replaced by [0x00 0x00 0x00 0x00] to achieve the same computation, and then make comparison between the 2. ==> is this OK ? In some old memories on the reception side, computing directly over [ ENCAP_HDR ][ IP datagram ][CRC-32-MSB-first] should give a 0 a result : ==> is true or have I just dreamt of it ? In the source from FreeBSD - the initial value is 0xff 0xff 0xff 0xff - the final result is XORed with 0xff 0xff 0xff 0xff ==> I think this a classical calculation, can we adopt the same ? Thanks for your help. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Tue Oct 21 11:11:20 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9LAAhJO003274 for ; Tue, 21 Oct 2003 11:10:43 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9LAAget003273 for ip-dvb-subscribed-users; Tue, 21 Oct 2003 11:10:42 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9LA9tJP003223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Oct 2003 11:09:56 +0100 (BST) Message-ID: <3F9505F4.7020104@erg.abdn.ac.uk> Date: Tue, 21 Oct 2003 11:09:56 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: [Fwd: 58th IETF] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk For those who wish to participate in the meeting, and haved not yet booked: -------- Original Message -------- Subject: 58th IETF Resent-Date: Mon, 20 Oct 2003 20:20:26 +0100 Resent-From: Alastair Matthews Resent-To: Gorry Fairhurst Date: Mon, 20 Oct 2003 14:29:25 -0400 From: ietf-secretariat@ietf.org To: IETF-Announce: ; Just a reminder that the pre-registration and pre-payment cutoff is Friday October 31, 2003. You can register on line at: http://www.ietf.org/meetings/IETF-58.html The Draft Agenda and list of registered attendees (updated Friday, October 17, 2003) can also be found at: http://www.ietf.org/meetings/IETF-58.html From owner-ip-dvb@erg.abdn.ac.uk Tue Oct 21 13:02:15 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9LC0GJO008250 for ; Tue, 21 Oct 2003 13:00:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9LC0FiC008248 for ip-dvb-subscribed-users; Tue, 21 Oct 2003 13:00:16 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.2] (host213-122-84-246.in-addr.btopenworld.com [213.122.84.246]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9LBvLJP008032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2003 12:57:25 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 21 Oct 2003 12:57:23 +0100 Subject: IESG WG Review: IP over DVB (ipdvb) From: Alastair Matthews To: CC: Message-ID: In-Reply-To: <200310202001.QAA27193@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk FYI This didn't make the list as the iesg secretary address wrong. ip-dvb@erg.abdn.ac.uka.cnri.reston.va.us A. ------ Forwarded Message > From: The IESG > Date: Mon, 20 Oct 2003 16:01:31 -0400 > To: IETF-Announce: ; > Cc: new-work@ietf.org, ip-dvb@erg.abdn.ac.uka.cnri.reston.va.us > Subject: WG Review: IP over DVB (ipdvb) > > A new IETF working group has been proposed in the Internet Area. > The IESG has not made any determination as yet. The following description > was submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by October 27th. > > IP over DVB (ipdvb) > ------------------- > > Current Status: Proposed Working Group > > Description of Working Group: > > The MPEG-2 Transport Stream provides a transmission network that has become > widely use to support digital TV broadcast, including: DVB, ATSC, ISDB-T. > These, and related standards, define a set of commercially available > components that are increasingly being used to provide a general-purpose > packet transmission network. MPEG-2 Transport networks are being used to > build IP networks to supplement broadcast TV/audio services and also provide > one-way and two-way IP-only subnetworks. > > There is a need to define an efficient standardised encapsulation for IPv4 > and IPv6 datagrams, and to recommend procedures for supporting protocols. > Examples include dynamic address resolution, multicast group membership > reporting and possibly management information tables and MIBs. Documents > will be defined that describe protocols required to build a complete > IPv4/IPv6 unicast/multicast services, and the mappings required to perform > dynamic address resolution. The primary purpose of this working group is to > develop a set of Internet Drafts and where appropriate to progress these as > either Internet Informational RFCs or Standards track RFCs. > > The current list of work items is: > > 1. Issue an Internet Draft specifying Requirements and Framework for > supporting IP services via MPEG-2 transmission networks. Such requirements > should consider the range of platforms currently (or anticipated to be) in > use. This draft will be submitted to the IESG for possible publication as > an Informational RFC. > > 2. The working group will investigate and design an efficient encapsulation > method for IPv4/IPv6, and advance this via the IESG to a standards-track > RFC. The design needs to consider the need for MAC addresses, the potential > need for synchronisation between streams, support for IPv6 and multicast > services, and support for multiple gateways (feeds). > > 3. The working group will consider the options for unicast and multicast > address resolution. A working group Internet Draft will define a framework > and recommend appropriate address resolution mechanisms for IPv4 and IPv6 > using both the existing Multi-Protocol Encapsulation and any new > encapsulation developed by the working group. Consideration will be paid to > existing standards, and the cases for IPv6 and IPv4 will be described. This > document will be submitted to the IESG for publication as an Informational > RFC. > > 4. A working group Internet Draft will be written to recommend a set of > dynamic address resolution procedures for IPv6. It will describe the > protocol and syntax of the information exchanged. This work may be based on > an extension to the Neighbor Discovery (ND) protocol to support MPEG-2 > transmission, and include specific optimisations for broadcast networks. > This document will be submitted to the IESG for publication as a > standards-track RFC. > > 5. If there is a need for further supporting protocols, it will consider a > possible recharter under the guidance of the IESG. Examples in this area > include, the negotiation/association of IP QoS with MPEG-2 transport > streams, address resolution for IPv4, and the need for SNMP MIBs. > > > > ------ End of Forwarded Message From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 11:10:49 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MAAUYv028094 for ; Wed, 22 Oct 2003 11:10:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9MAAUKo028093 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 11:10:30 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MAABYv028078 for ; Wed, 22 Oct 2003 11:10:11 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 32675DF for ; Wed, 22 Oct 2003 12:10:11 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 225365AC; Wed, 22 Oct 2003 12:10:11 +0200 (CEST) Message-ID: <3F965853.5050102@6wind.com> Date: Wed, 22 Oct 2003 12:13:39 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: Re: IESG WG Review: IP over DVB (ipdvb) References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk >> >>IP over DVB (ipdvb) >> ... Snip >> >>The current list of work items is: >> >>1. Issue an Internet Draft specifying Requirements and Framework for >>supporting IP services via MPEG-2 transmission networks. Such requirements So, its is more IP-over-MPEG2 rather tah IP-over-DVB. Am I correct ? >> ... Snip >>2. The working group will investigate and design an efficient encapsulation >>method for IPv4/IPv6, and advance this via the IESG to a standards-track >>RFC. The design needs to consider the need for MAC addresses, the potential >>need for synchronisation between streams, support for IPv6 and multicast ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is there not a risk of mixing different layers ? because this notion is more a DVB one ? Are the systems over MPEG-2 such as DVB, ATSC, ISDB-T ... compatible in terms of stream synchronisation ? Anyway, what is the purpose of such sync between IP flows and other streams ? or between IP flows ? shouldn't it be more a pb to be solved at application and/or transport level (using RTP) rather than at a newtork level ? Well, I maybe I missed some importants points, but if this feature is important/needed/whatever, why is it not in the requirement draft ? Regards. Alain -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 14:02:01 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MD1JYv004971 for ; Wed, 22 Oct 2003 14:01:19 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9MD1IWq004970 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 14:01:19 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MD0NYw004934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Oct 2003 14:00:24 +0100 (BST) Message-ID: <3F967F67.2010203@erg.abdn.ac.uk> Date: Wed, 22 Oct 2003 14:00:23 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: IESG WG Review: IP over DVB (ipdvb) - Synchronised delivery of IP packets References: <3F965853.5050102@6wind.com> In-Reply-To: <3F965853.5050102@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I believe you're asing for more detai of the synchronised delivery service... See in-line comments, below. alain.ritoux@6wind.com wrote: > >>> >>> IP over DVB (ipdvb) >> > > >>> ... Snip >>> The current list of work items is: >>> >>> 1. Issue an Internet Draft specifying Requirements and Framework for >>> supporting IP services via MPEG-2 transmission networks. Such >>> requirements >> > > So, its is more IP-over-MPEG2 rather tah IP-over-DVB. Am I correct ? Yes, that always was the case. > > >>> ... Snip >>> 2. The working group will investigate and design an efficient >>> encapsulation >>> method for IPv4/IPv6, and advance this via the IESG to a >>> standards-track >>> RFC. The design needs to consider the need for MAC addresses, the >>> potential >>> need for synchronisation between streams, support for IPv6 and >>> multicast >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Is there not a risk of mixing different layers ? because this notion is > more a DVB one ? To ensure we speak of the same thing the current requirements id (page 12) says: "The standard PES Packet as defined in table 2-18 of [ISO- MPEG] can also be used as a container for data packets. The two values for the stream_id are "private_stream_1" and "private_stream_2". The private_stream_2 permits the use of the short PES header with limited overhead. This makes it attractive for publicly accessible multicast distribution services. The private_stream_1 makes available the scrambling control and the timing and clock reference features of the PES layer. The PES_data_packet_header_length will be used in this context to insert stuffing bytes. This is an important aspect since the payload can be aligned to 32-bit word boundaries. " I agree this is an MPEG-TS attrribute for PES-format streams. Both DVB and the ATSC Data Broadcast Standard describe how this may be used (each with differing levels of detail). At the moment the proposed charter says we should consider this need, and assess the impact on the design of the encapsulation procdure. I have a question to implementors and potnetial users is do they envisage the need for this to be supported in the IETf-supplied encapsulation. if so please send potential use cases to the list!!! > > > Are the systems over MPEG-2 such as DVB, ATSC, ISDB-T ... compatible in > terms of stream synchronisation ? > > Anyway, what is the purpose of such sync between IP flows and other > streams ? or between IP flows ? shouldn't it be more a pb to be solved > at application and/or transport level (using RTP) rather than at a > newtork level ? Not necessarily so, RTP can provide synchnosiation, but this isn't the same. > > > Well, I maybe I missed some importants points, but if this feature is > important/needed/whatever, why is it not in the requirement draft ? Correct, we need text, are you offering text? Does anyone else have text we can use to update the requirements draft with use-cases for this type of service? > > > Regards. > Alain > From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 15:07:31 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9ME6VYv008027 for ; Wed, 22 Oct 2003 15:06:31 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9ME6Uxo008026 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 15:06:30 +0100 (BST) Message-Id: <200310221406.h9ME6Uxo008026@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f From: The IESG To: ip-dvb@erg.abdn.ac.uk Subject: WG Review: IP over DVB (ipdvb) Date: Wed, 22 Oct 2003 09:55:36 -0400 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner: Found to be clean A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 27th. IP over DVB (ipdvb) ------------------- Current Status: Proposed Working Group Description of Working Group: The MPEG-2 Transport Stream provides a transmission network that has become widely use to support digital TV broadcast, including: DVB, ATSC, ISDB-T. These, and related standards, define a set of commercially available components that are increasingly being used to provide a general-purpose packet transmission network. MPEG-2 Transport networks are being used to build IP networks to supplement broadcast TV/audio services and also provide one-way and two-way IP-only subnetworks. There is a need to define an efficient standardised encapsulation for IPv4 and IPv6 datagrams, and to recommend procedures for supporting protocols. Examples include dynamic address resolution, multicast group membership reporting and possibly management information tables and MIBs. Documents will be defined that describe protocols required to build a complete IPv4/IPv6 unicast/multicast services, and the mappings required to perform dynamic address resolution. The primary purpose of this working group is to develop a set of Internet Drafts and where appropriate to progress these as either Internet Informational RFCs or Standards track RFCs. The current list of work items is: 1. Issue an Internet Draft specifying Requirements and Framework for supporting IP services via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be submitted to the IESG for possible publication as an Informational RFC. 2. The working group will investigate and design an efficient encapsulation method for IPv4/IPv6, and advance this via the IESG to a standards-track RFC. The design needs to consider the need for MAC addresses, the potential need for synchronisation between streams, support for IPv6 and multicast services, and support for multiple gateways (feeds). 3. The working group will consider the options for unicast and multicast address resolution. A working group Internet Draft will define a framework and recommend appropriate address resolution mechanisms for IPv4 and IPv6 using both the existing Multi-Protocol Encapsulation and any new encapsulation developed by the working group. Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. This document will be submitted to the IESG for publication as an Informational RFC. 4. A working group Internet Draft will be written to recommend a set of dynamic address resolution procedures for IPv6. It will describe the protocol and syntax of the information exchanged. This work may be based on an extension to the Neighbor Discovery (ND) protocol to support MPEG-2 transmission, and include specific optimisations for broadcast networks. This document will be submitted to the IESG for publication as a standards-track RFC. 5. If there is a need for further supporting protocols, it will consider a possible recharter under the guidance of the IESG. Examples in this area include, the negotiation/association of IP QoS with MPEG-2 transport streams, address resolution for IPv4, and the need for SNMP MIBs. From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 15:10:11 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9ME9b9R008224 for ; Wed, 22 Oct 2003 15:09:37 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9ME9bdf008222 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 15:09:37 +0100 (BST) Message-Id: <200310221409.h9ME9bdf008222@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f From: The IESG To: ip-dvb@erg.abdn.ac.uk Subject: WG Review: IP over DVB (ipdvb) Date: Wed, 22 Oct 2003 09:55:36 -0400 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-ERG-MailScanner: Found to be clean A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 27th. IP over DVB (ipdvb) ------------------- Current Status: Proposed Working Group Description of Working Group: The MPEG-2 Transport Stream provides a transmission network that has become widely use to support digital TV broadcast, including: DVB, ATSC, ISDB-T. These, and related standards, define a set of commercially available components that are increasingly being used to provide a general-purpose packet transmission network. MPEG-2 Transport networks are being used to build IP networks to supplement broadcast TV/audio services and also provide one-way and two-way IP-only subnetworks. There is a need to define an efficient standardised encapsulation for IPv4 and IPv6 datagrams, and to recommend procedures for supporting protocols. Examples include dynamic address resolution, multicast group membership reporting and possibly management information tables and MIBs. Documents will be defined that describe protocols required to build a complete IPv4/IPv6 unicast/multicast services, and the mappings required to perform dynamic address resolution. The primary purpose of this working group is to develop a set of Internet Drafts and where appropriate to progress these as either Internet Informational RFCs or Standards track RFCs. The current list of work items is: 1. Issue an Internet Draft specifying Requirements and Framework for supporting IP services via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be submitted to the IESG for possible publication as an Informational RFC. 2. The working group will investigate and design an efficient encapsulation method for IPv4/IPv6, and advance this via the IESG to a standards-track RFC. The design needs to consider the need for MAC addresses, the potential need for synchronisation between streams, support for IPv6 and multicast services, and support for multiple gateways (feeds). 3. The working group will consider the options for unicast and multicast address resolution. A working group Internet Draft will define a framework and recommend appropriate address resolution mechanisms for IPv4 and IPv6 using both the existing Multi-Protocol Encapsulation and any new encapsulation developed by the working group. Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. This document will be submitted to the IESG for publication as an Informational RFC. 4. A working group Internet Draft will be written to recommend a set of dynamic address resolution procedures for IPv6. It will describe the protocol and syntax of the information exchanged. This work may be based on an extension to the Neighbor Discovery (ND) protocol to support MPEG-2 transmission, and include specific optimisations for broadcast networks. This document will be submitted to the IESG for publication as a standards-track RFC. 5. If there is a need for further supporting protocols, it will consider a possible recharter under the guidance of the IESG. Examples in this area include, the negotiation/association of IP QoS with MPEG-2 transport streams, address resolution for IPv4, and the need for SNMP MIBs. From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 15:58:05 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MEvd9R010346 for ; Wed, 22 Oct 2003 15:57:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9MEvdnx010345 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 15:57:39 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MEuo9R010300 for ; Wed, 22 Oct 2003 15:56:50 +0100 (BST) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id B0AD36AA for ; Wed, 22 Oct 2003 16:56:50 +0200 (CEST) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 7BB725AC; Wed, 22 Oct 2003 16:56:50 +0200 (CEST) Message-ID: <3F969B82.9050501@6wind.com> Date: Wed, 22 Oct 2003 17:00:18 +0200 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: Re: IESG WG Review: IP over DVB (ipdvb) - Synchronised delivery of IP packets References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry Fairhurst wrote: > > I believe you're asing for more detai of the synchronised delivery > service... Yes !! > > To ensure we speak of the same thing the current requirements id (page > 12) says: > > "The standard PES Packet as defined in table 2-18 of [ISO- > MPEG] can also be used as a container for data packets. The > two values for the stream_id are "private_stream_1" and > "private_stream_2". The private_stream_2 permits the use of > the short PES header with limited overhead. This makes it > attractive for publicly accessible multicast distribution > services. The private_stream_1 makes available the scrambling > control and the timing and clock reference features of the > PES layer. The PES_data_packet_header_length will be used in > this context to insert stuffing bytes. This is an important > aspect since the payload can be aligned to 32-bit word > boundaries. " Ah ! I understood it was part of description of data-streaming ! but not a req itself. because PES packets may not be available in any system using MPEG-2 ? > At the moment the proposed charter says we should consider this need, > and assess the impact on the design of the encapsulation procdure. OK : it must be looked, which doesn't mean it will be a requirement for the encapsulation method. >> Well, I maybe I missed some importants points, but if this feature is >> important/needed/whatever, why is it not in the requirement draft ? > > > Correct, we need text, are you offering text? Sorry, no:-( I don't really grab the importance of such sync, neither I'm really sure of its deepest implications. I don't see any use-case either > Does anyone else have text we can use to update the requirements draft > with use-cases for this type of service? Yep, it would be very helpfull understanding the real goal. Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 17:05:26 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MG4B9R013880 for ; Wed, 22 Oct 2003 17:04:11 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9MG4Aqe013879 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 17:04:11 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mail2.mh.se (mail2.mh.se [193.10.250.15]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MG2Y9R013790 for ; Wed, 22 Oct 2003 17:02:34 +0100 (BST) Received: from eproxy.personal.mh.se (eproxy.mh.se [10.3.1.25]) by mail2.mh.se (8.12.10/8.12.10) with ESMTP id h9MG2Yvn001231 for ; Wed, 22 Oct 2003 18:02:34 +0200 (MEST) Received: from Gargamel.forv.mh.se (unverified) by eproxy.personal.mh.se (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Wed, 22 Oct 2003 18:02:34 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: SV: Call for Papers: IJCN - More Information X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 22 Oct 2003 18:02:34 +0200 Message-ID: <5DBC99864755D311BD7800902786A0B806DA4A38@gargamel.forv.mh.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Papers: IJCN - More Information Thread-Index: AcOL6KP0zgiFUFQyQUye8tbrsuwqrgMq1ehw From: "Eriksson Magnus" To: X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id h9MG47pD013875 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear Gorry Fairhurst, I am interested in contributing to the IJCN special issue on IP over DVB. My intention is to write about "Performance bounds of dynamic radio resource management schemes for cellular unicasting services over DVB-T". It would be my 6th publication related to this topic. However, there is no call-for-papers available on the net, and the author guidelines that I have found are not very detailed. I just want to check if there is some additional information available. 1. How many pages or words do you require/accept/recommend? 2. If the paper would contain an extensive amount of equations and simulation result plots, would that be considered as disadvantageous in the reviewing? Do you prefer "magazine style" papers? 3. Are there any recommended MS Word template available for the camera ready version? Sincerely, Magnus Eriksson Mid Sweden University / Royal inst. of technology |-----Ursprungligt meddelande----- |Från: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] |Skickat: den 6 oktober 2003 10:46 |Till: ip-dvb@erg.abdn.ac.uk |Ämne: Call for Papers: IJCN - More Information | | |Several people have enquired to me about the call for papers in the |forth-coming Special Issue of IJCN. | |Those of you not familiar with the The International Journal of Computer |and Telecommunications Networking, you may like to look at the following |web page (where there is details of submission and also information |about previous Special Issues): | |http://www.elsevier.nl/locate/comnet | |Gorry | | |P.S. Thanks for those who spotted the deadline for submission, |is of course early 2004, not 2003. | | | > There will be a Special Issue of the International | > Journal of Computer Networks devoted to | > "Internet over Digital Broadcast Video Networks". This | > seems very close to the topics discussed on this list, | > so I warmly invite you to consider submission of a paper. | | > Those interesed, are referred to the attached call for papers. Call for Papers International Journal of Computer Networks Special Issue Internet over Digital Broadcast Video Networks Editors: Marie-José Montpetit, mjmontpetit.com and Gorry Fairhurst, Universtity of Aberdeen Digital Video Broadcasting (DVB) technologies are widely used over broadcast media that include satellite (DVB-S), cable (DVB-C and Open Cable) and terrestrial (DVB-T). They provide unidirectional communications from the content provider to the end user. The return channel can be either via a terrestrial technology or via satellite (DVB return channel system or RCS). Current standards define a link layer protocol to enable transmission of the digital multimedia content. More and more, however, DVB is used to build Internet-compatible networks. In order to do this an MPEG-2 Transport Stream cell is used as a "container" for the IP packets with an added encapsulation header to allow the information to be adequately processed. Over the years a number of encapsulation methods have been explored to transmit data over broadcast media. The current standard for DVB is the Multi-Protocol Encapsulation (MPE). While this may be used to send Internet Packets, there are further issues that arise when used to build an Internet Service. Such issues are an active research topic, and have received recent attention in the Internet Engineering Task Force (IETF) community. In addition, recent efforts have been dedicated to making DVB a more dynamic network with protocols for address resolution and multicast group management to complement current solution that use table based methods. Finally, the support for Quality of Service (QoS) and security service is also actively pursued. This special issue intends to review current IP over DVB research and establish what the status of this important technology is in the deployment of the broadband networks of the near future. Topics addressed by the special issue include (but are not limited to): - system design and scenarios - DVB and MPEG-2 networking technologies - encapsulation and hardware/software implementations for IPv4 and v6 - address resolution - multicast group management - quality of service issues - simulation of DVB networks - standardization efforts Manuscripts should be sent via email to either: marie@mjmontpetit.com or gorry@erg.abdn.ac.uk Deadlines: Full papers: January 1st 2003 Reviews returned: February 15th 2004 From owner-ip-dvb@erg.abdn.ac.uk Wed Oct 22 20:30:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MJTj9R021937 for ; Wed, 22 Oct 2003 20:29:45 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9MJTiRY021934 for ip-dvb-subscribed-users; Wed, 22 Oct 2003 20:29:44 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9MJSf9S021872 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 22 Oct 2003 20:28:41 +0100 (BST) Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1ACOeH-0006T7-00 for ip-dvb@erg.abdn.ac.uk; Wed, 22 Oct 2003 20:28:01 +0100 Date: Wed, 22 Oct 2003 20:28:00 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: IPDVB Subject: Re: IESG WG Review: IP over DVB (ipdvb) In-Reply-To: <3F965853.5050102@6wind.com> Message-ID: References: <3F965853.5050102@6wind.com> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1ACOeH-0006T7-00*SSdDJSoGf2E* (SECM, UniS) X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk On Wed, 22 Oct 2003 alain.ritoux@6wind.com wrote: > >> ... Snip > >> > >>The current list of work items is: > >> > >>1. Issue an Internet Draft specifying Requirements and Framework for > >>supporting IP services via MPEG-2 transmission networks. Such requirements > > So, its is more IP-over-MPEG2 rather tah IP-over-DVB. Am I correct ? I would say IP-over-MPEG transport streams in general (MPEG-4 is out there, there are others. MPEG-7, anyone?) > >> ... Snip > >>2. The working group will investigate and design an efficient encapsulation > >>method for IPv4/IPv6, and advance this via the IESG to a standards-track > >>RFC. The design needs to consider the need for MAC addresses, the potential > >>need for synchronisation between streams, support for IPv6 and multicast > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Is there not a risk of mixing different layers ? because this notion is > more a DVB one ? > > Are the systems over MPEG-2 such as DVB, ATSC, ISDB-T ... compatible in > terms of stream synchronisation ? > > Anyway, what is the purpose of such sync between IP flows and other > streams ? multiplexing of different traffic types. > or between IP flows ? shouldn't it be more a pb to be solved > at application and/or transport level (using RTP) rather than at a > newtork level ? RTP can't solve it; you're already IP at that point.. L. From owner-ip-dvb@erg.abdn.ac.uk Fri Oct 24 10:31:45 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9O9VKan017582 for ; Fri, 24 Oct 2003 10:31:20 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9O9VKuh017581 for ip-dvb-subscribed-users; Fri, 24 Oct 2003 10:31:20 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9O9Uoao017551 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 24 Oct 2003 10:30:52 +0100 (BST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9O9UoI22991 for ; Fri, 24 Oct 2003 12:30:50 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 12:30:50 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 12:30:48 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 24 Oct 2003 12:30:48 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 24 Oct 2003 12:30:48 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IP over DVB (ipdvb) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 24 Oct 2003 12:30:43 +0300 Message-ID: <2BF0AD29BC31FE46B7887732114404310357E6D9@trebe003.europe.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: IP over DVB (ipdvb) Thread-Index: AcOYpkfc7xZ9Du0iRhyZlGM4ZXIsOQAkHaAw From: To: , X-OriginalArrivalTime: 24 Oct 2003 09:30:48.0893 (UTC) FILETIME=[825F96D0:01C39A11] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id h9O9VIco017578 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk It would be helpful for the IPoverDVB charter to position itself with respect to existing standards. It would be extremely helpful to show how this IPoverDVB would complement the existing standards and where it would attempt to replace them (in what niches and in what time frame) For instance, DVB has a data broadcasting standard which gives an IP in MPEG-2 encapsulation method (commonly called MPE), which is both working and deployed. This was based on commercial requirements and is reasonably efficient (down to 3% overhead for Ethernet MTU - http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/refs/mpe-ohead.pdf). It is unclear, in the charter, whether the proposed WG aims to change the existing deployments, be used for all future deployments or be optimised for special purpose deployments as an alternative to MPE. The risk of not positioning the IPoverDVB WG with respect to these existing technologies and standards is that the proposed WG may be seen as a competing solution which could fragment a fragile market place. From talking with Gorry, I've been convinced that the proposed WG does _not_ intend to fight it out with existing standards, rather fulfil the requirements of niche applications and open up the debate on a common "IP over MPEG-2" solution in the long term future. If I am wrong on this, I would be grateful if someone were to fill in the picture. In anycase, the ambiguity over the proposed WG's direction and objective is easy to see, and needs eliminating. Unfortunately, most people involved with IP over DVB deployments don't have the privilege to have been exposed to this IETF/BOF, and talking to those involved, from the very beginning. So it would be extremely helpful to spell out explicitly how this proposed WG relates to existing standards (and thus markets), and which new and existing markets/commercial requirements it is focused on. This would ensure that any conflicts with existing markets are known (and hopefully minimised) so that existing commercial interests do not inhibit the charter's support. In practice this is about adding a paragraph to the charter to make these things clear. If I got the idea of the proposed WG right (i.e. there are no errors in what I said above), I'd be happy to help craft this paragraph. (I just wanted to point out this most fundamental need before getting into specifics of the charter). Cheers, Rod. > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of ext The IESG > Sent: Wednesday, October 22, 2003 4:56 PM > To: ip-dvb@erg.abdn.ac.uk > Subject: WG Review: IP over DVB (ipdvb) > > > > A new IETF working group has been proposed in the Internet Area. > The IESG has not made any determination as yet. The > following description > was submitted, and is provided for informational purposes > only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by > October 27th. > > IP over DVB (ipdvb) > ------------------- > > Current Status: Proposed Working Group > > Description of Working Group: > > The MPEG-2 Transport Stream provides a transmission network > that has become > widely use to support digital TV broadcast, including: DVB, > ATSC, ISDB-T. > These, and related standards, define a set of commercially available > components that are increasingly being used to provide a > general-purpose > packet transmission network. MPEG-2 Transport networks are > being used to > build IP networks to supplement broadcast TV/audio services > and also provide > one-way and two-way IP-only subnetworks. > > There is a need to define an efficient standardised > encapsulation for IPv4 > and IPv6 datagrams, and to recommend procedures for > supporting protocols. > Examples include dynamic address resolution, multicast group > membership > reporting and possibly management information tables and > MIBs. Documents > will be defined that describe protocols required to build a complete > IPv4/IPv6 unicast/multicast services, and the mappings > required to perform > dynamic address resolution. The primary purpose of this > working group is to > develop a set of Internet Drafts and where appropriate to > progress these as > either Internet Informational RFCs or Standards track RFCs. > > The current list of work items is: > > 1. Issue an Internet Draft specifying Requirements and Framework for > supporting IP services via MPEG-2 transmission networks. Such > requirements > should consider the range of platforms currently (or > anticipated to be) in > use. This draft will be submitted to the IESG for possible > publication as > an Informational RFC. > > 2. The working group will investigate and design an > efficient encapsulation > method for IPv4/IPv6, and advance this via the IESG to a > standards-track > RFC. The design needs to consider the need for MAC addresses, > the potential > need for synchronisation between streams, support for IPv6 > and multicast > services, and support for multiple gateways (feeds). > > 3. The working group will consider the options for unicast > and multicast > address resolution. A working group Internet Draft will > define a framework > and recommend appropriate address resolution mechanisms for > IPv4 and IPv6 > using both the existing Multi-Protocol Encapsulation and any new > encapsulation developed by the working group. Consideration > will be paid to > existing standards, and the cases for IPv6 and IPv4 will be > described. This > document will be submitted to the IESG for publication as an > Informational > RFC. > > 4. A working group Internet Draft will be written to > recommend a set of > dynamic address resolution procedures for IPv6. It will describe the > protocol and syntax of the information exchanged. This work > may be based on > an extension to the Neighbor Discovery (ND) protocol to support MPEG-2 > transmission, and include specific optimisations for > broadcast networks. > This document will be submitted to the IESG for publication as a > standards-track RFC. > > 5. If there is a need for further supporting protocols, it > will consider a > possible recharter under the guidance of the IESG. Examples > in this area > include, the negotiation/association of IP QoS with MPEG-2 transport > streams, address resolution for IPv4, and the need for SNMP MIBs. > > > > > > > > > From owner-ip-dvb@erg.abdn.ac.uk Mon Oct 27 13:11:31 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9RDAxan004608 for ; Mon, 27 Oct 2003 13:10:59 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9RDAws9004607 for ip-dvb-subscribed-users; Mon, 27 Oct 2003 13:10:58 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from proxy.6wind.com (proxy.ipv6.6wind.com [194.250.197.211]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9RDAcan004593 for ; Mon, 27 Oct 2003 13:10:39 GMT Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 42E803A7 for ; Mon, 27 Oct 2003 14:10:39 +0100 (CET) Received: from 6wind.com (vouvray.dev.6wind.com [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id D9854538 for ; Mon, 27 Oct 2003 14:10:38 +0100 (CET) Message-ID: <3F9D1A20.6030000@6wind.com> Date: Mon, 27 Oct 2003 14:14:08 +0100 From: alain.ritoux@6wind.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPDVB Subject: Re: ULE-01 : last byte(s) precision References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk To close the thread on the last bytes (i.e. SNU must have at least two bytes in a TS cell), here is a proposed text : in §5.3 third paragraph, replace "If there are at least two bytes remaining in the TS Packet payload after processing the Current SNDU and further PDUs are queued at an Encapsulator, it MAY append the bytes of the next SNDU directly to the preceding one before segmentation (figure 9)." by "After processing the Current SNDU, if further PDUs are queued at an Encapsulator, and there are at least two bytes remaining in the TS Packet payload available for the next SNDU, the Encapsulator MAY append the bytes of the next SNDU directly to the preceding one before segmentation (figure 9)." and in § 5.3.1 1st paragraph, replace "If more packets are waiting at the Encapsulator, and a TS Packet has more than two bytes of unused payload, it MAY start the next SNDU in the next available byte of the TS Packet payload. The PUSI MUST be set, if not already set. When an Encapsulator packs a further SNDU into an already formed TS Packet, this may require the PUSI value in the TS Packet header to be updated, also requiring a Payload Pointer to be inserted in the TS Packet." by "If more packets are waiting at the Encapsulator, it MAY start the next SNDU in the next available byte of the TS Packet payload. The PUSI MUST be set, if not already set. When an Encapsulator packs a further SNDU into an already formed TS Packet, this may require the PUSI value in the TS Packet header to be updated, also requiring a Payload Pointer to be inserted in the TS Packet. Packing procedure MUST NOT be done if it leads to store less than two bytes of the next SNDU in the current TS packet" Your thoughts ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.com From owner-ip-dvb@erg.abdn.ac.uk Mon Oct 27 23:07:53 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9RN7Oan026970 for ; Mon, 27 Oct 2003 23:07:24 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9RN7N58026968 for ip-dvb-subscribed-users; Mon, 27 Oct 2003 23:07:23 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from web25203.mail.ukl.yahoo.com (web25203.mail.ukl.yahoo.com [217.12.10.63]) by erg.abdn.ac.uk (8.12.10/8.12.10) with SMTP id h9RN6tan026942 for ; Mon, 27 Oct 2003 23:06:55 GMT Message-ID: <20031027230652.63553.qmail@web25203.mail.ukl.yahoo.com> Received: from [213.150.190.210] by web25203.mail.ukl.yahoo.com via HTTP; Tue, 28 Oct 2003 00:06:52 CET Date: Tue, 28 Oct 2003 00:06:52 +0100 (CET) From: =?iso-8859-1?q?ghommam=20mohsen?= Subject: ENC method To: ip-dvb@erg.abdn.ac.uk Cc: gorry@erg.abdn.ac.uk MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2062083657-1067296012=:62663" Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk --0-2062083657-1067296012=:62663 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello friends I have one question about the methode ENC using AF. I thing the apprach of using AF for application tht needs using synchronisation is wrong because the AF used by this metohd uses only 4 bytes and doesn't reserve any place to insert PCR information for synchronisation, so whers's the synchronisation is inserted?. So I thing yhat this method hasn't the sesn of synchronisation and I thing that ULE is enough to continue with --------------------------------- Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Testez le nouveau Yahoo! Mail --0-2062083657-1067296012=:62663 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello friends
I have one question about the methode ENC using AF. I thing the apprach of using AF for application tht needs using synchronisation is wrong because the AF used by this metohd uses only 4 bytes and doesn't reserve any place to insert PCR information for synchronisation, so whers's the synchronisation is inserted?. So I thing yhat this method hasn't the sesn of synchronisation and I thing that ULE is enough to continue with


Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail --0-2062083657-1067296012=:62663-- From owner-ip-dvb@erg.abdn.ac.uk Fri Oct 31 16:09:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9VG97an018039 for ; Fri, 31 Oct 2003 16:09:07 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9VG97uV018038 for ip-dvb-subscribed-users; Fri, 31 Oct 2003 16:09:07 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.7] (maxp30.abdn.ac.uk [139.133.7.189]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9VG8Dao017989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 31 Oct 2003 16:08:16 GMT User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 31 Oct 2003 16:08:40 +0000 Subject: Re: ULE-01 : last byte(s) precision From: Gorry Fairhurst To: Message-ID: In-Reply-To: <3F83BBDC.50203@6wind.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id h9VG95RS018035 Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Revised text for next rev. of ULE. Here is some new text suggested for the procedure for Encapsulation processing. This text is based on the long and frustrating thread on "last byte precision". We finally concluded the biggest problem was not with the algorithm, but with the structure of the document. I've worker with Hilmar and Alain to re-order the text from ULE-01 Section 5, and suggest we group all the paragraphs on encapsulation into one section (see below). If this seems good, we can group all the Receiver paragraphs similarly and insert a new section on the Receiver, and then close this thread. Best wishes, Gorry ----- SNDU Encapsulation When an Encapsulator has not previously sent a TS Packet for a specific TS Logical Channel, or after an idle period, it starts to send a SNDU in the first available TS Packet. This first TS Packet generated MUST carry a PUSI value of 1. It MUST also carry a Payload Pointer value of zero indicating the SNDU starts in the first available byte of the TS Packet payload. The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header. This value MUST be incremented by one for each TS Packet sent using a TS Logical Channel. If an Encapsulator decides NOT to immediately send another SNDU, it MUST transmit an End Indicator directly after the end of the SNDU. This procedure is known as Padding (figure 10). It informs the Receiver that there are no more SNDUs in this TS Packet payload. The End Indicator is followed by zero or more unused bytes until the end of the TS Packet payload. The unused bytes MUST be set to the value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The padding procedure trades decreased efficiency against improved latency. +-------------+ | SubNetwork | | DU 3 | +-------------+ \ \ \ \ \ \ +------+--------+--------+----------+ |MPEG-2| End of | 0xFFFF | Unused | |Header| SNDU 3 | | Bytes | +------+--------+--------+----------+ PUSI=0 End Indicator Figure 10: A TS Packet carrying the end of SNDU 3, followed by an End Indicator. If more packets are waiting at an Encapsulator, and a TS Packet has sufficient space remaining in the payload, it can follow the encapsulated SNDU with another SNDU using the next available byte of the TS Packet payload (see 5.2). This is called Packing (figure 11). +------------------+ +------------------+ | Subnetwork | | Subnetwork | | DU 1 | | DU 2 | +------------------+ +------------------+ \ \ / /\ \ \ / / \ \ \ / / \Š +------+--------+--------+----------+ |MPEG-2| Payload| end of | start of | |Header| Pointer| SNDU 1 | SNDU 2 | +------+--------+--------+----------+ | ^ PUSI=1 | | +--------------+ Figure 11: A TS Packet with the end of SNDU 1, followed by SNDU 2. Procedure for Padding and Packing Five possible actions may occur when an Encapsulator has completed encapsulation of an SNDU: (i) If the TS Packet has no remaining space, the Encapsulator transmits this TS Packet. It starts transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1, and a Payload Pointer value of 0x00.) (ii) If the TS Packet carrying the final part of a SNDU has one byte of unused payload, the Encapsulator MUST place the value 0xFF in this final byte, and transmit the TS Packet. This rule provides a simple mechanism to resolve the complex behaviour that may arise when the TS Packet has no PUSI set: To send another SNDU in the current TS Packet, would otherwise require the addition of a Payload Pointer that would consume the last remaining byte of TS Packet payload. The behaviour follows similar practice for other MPEG-2 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) (iii) If the TS Packet carrying the final part of a SNDU has exactly two bytes of unused payload, and the PUSI was NOT already set, the Encapsulator MUST place the value 0xFFFF in this final two bytes, providing an End Indicator, and transmit the TS Packet. This rule prevents fragmentation of the SNDU Length Field over two TS Packets. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) (iv) If the TS Packet has more than two bytes of unused payload, the Encapsulator MAY transmit this partially full TS Packet but MUST first place the value 0xFF in all remaining unused bytes (i.e. setting an End Indicator followed by padding). The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) (v) If at least two bytes are available for Payload data in the TS Packet payload (i.e. three bytes if the PUSI was NOT previously set, and two bytes if it was previously set), the Encapsulator MAY encapsulate further queued PDUs, by starting the next SNDU in the next available byte of the current TS Packet Payload. The PUSI MUST be set. When the Encapsulator packs further SNDUs into a TS Packet where the PUSI NOT already set, this requires the PUSI to be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted in the first byte directly following the TS Packet header. The value MUST be set to the position of the byte following the end of the first SNDU in the TS Packet payload. If no further PDUs are available, an Encapsulator MAY wait for additional PDUs to fill the incomplete TS Packet. The maximum period of time an Encapsulator can wait MUST be bounded and SHOULD be configurable by the user. If no additional PDUs are received after this period of time, it MUST insert an End Indicator instead (using rule iv). Use of the Packing method by an Encapsulation Gateway is optional, and may be determined on a per-session, per-packet, or per-SNDU basis. When a SNDU is less than the size of a TS Packet payload, a TS Packet may be formed that carries a PUSI value of one and also an End Indicator. From owner-ip-dvb@erg.abdn.ac.uk Fri Oct 31 17:22:37 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9VHMJan020796 for ; Fri, 31 Oct 2003 17:22:19 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.10/8.12.2/Submit) id h9VHMJJ2020795 for ip-dvb-subscribed-users; Fri, 31 Oct 2003 17:22:19 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.7] (maxp6.abdn.ac.uk [139.133.7.165]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.10/8.12.10) with ESMTP id h9VHJNao020681 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 17:21:57 GMT User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 31 Oct 2003 17:19:38 +0000 Subject: ULE Implementation plans. From: Gorry Fairhurst To: Gorry Fairhurst , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I know a number of companies are currently testing ULE implementations, or have said that they plan to implement ULE in the short-term. In the light of this, I'd like to allocate some Agenda time to feedback implementation experience... If you are planning do an implementation of the proposed encapsulation in the short-term (i.e. Possibly before it becomes an RFC), can you please let me know, and I'll add you to the list. Please also let me know: (i) Expected platform (including whether it is cable; terrestrial; serial interface; satellite; etc) (ii) If you have already started and now have some feedback that you can share with the WG. Please send to me, and I'll compile a list. Look forward to hearing from you, Gorry