From majordomo@mil.doit.wisc.edu Fri Oct 1 17:51:48 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28315 for ; Fri, 1 Oct 2004 17:51:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CDV1x-0006AK-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Oct 2004 16:33:33 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CDV1w-0006AF-00 for ipfix@net.doit.wisc.edu; Fri, 01 Oct 2004 16:33:32 -0500 Date: Fri, 1 Oct 2004 16:33:32 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] upcoming IPFIX at the 61st IETF Meeting in Washington, DC, USA Message-ID: <20041001163332.A23242@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-CONCAT, indexed file cannot be concatenated X-Shakespearean-Insult: Thou venomed knotty-pated varlet Precedence: bulk Sender: majordomo listserver IPFIXers, The IPFIX working group will meet at the 61st IETF. Currently we're scheduled for a late afternoon session on Thursday, November 11. Please send agenda requests / items to . I'll prepare the draft agenda soon. As a reminder, here are the draft cut-off dates for IETF 61: 11 Oct 2004: Cut-off for WG Chair approval for initial document (-00) submission at 09:00 ET 18 Oct 2004: Internet Draft Cut-off for initial document (-00) submission at 09:00 ET 25 Oct 2004: Internet Draft Cut-off for revised document (-01 and higher) submission at 09:00 ET Thanks, Dave & Nevil -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Oct 4 07:40:13 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26198 for ; Mon, 4 Oct 2004 07:40:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CEQrF-00065c-00 for ipfix-list@mil.doit.wisc.edu; Mon, 04 Oct 2004 06:18:21 -0500 Received: from [200.180.242.22] (helo=PENTIUM4.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CEQr2-00064d-00 for ipfix@net.doit.wisc.edu; Mon, 04 Oct 2004 06:18:13 -0500 Date: Mon, 04 Oct 2004 08:17:57 -0300 To: "Ipfix" From: "Plonka" Subject: [ipfix] Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ydrsziybrstafpjovqfn" Precedence: bulk Sender: majordomo listserver ----------ydrsziybrstafpjovqfn Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >The snake


----------ydrsziybrstafpjovqfn Content-Type: application/octet-stream; name="Garry.com" Content-Disposition: attachment; filename="Garry.com" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAASAAAAFIAAAAAAAAAwAAA ABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAnBMBAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAVsIAANEAAAAAEAEAnAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABgAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAEgAAAAAAACqRgAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAOAAAAAAAATgwAAABgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAANgAAAAAAAJ5CAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAMAAAABMAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAnAMAAAAQ AQCcAwAAAE4AAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOgpAgAA 6OsI6wLNIP8kJJpmvkdG6AEAAACaWY2VKyJAAOgBAAAAaVhmv01K6OQBAACNUvnoAQAAAOhb aMz/4pr/5Gn/pWwkQADp6Ln////rAs0gi8TrAs0ggQAWAAAAD4XJAQAAaegAAAAAWJlqFVqN BAJQ6JUBAABmPYbzdAPpjZXNIkAA6IoBAADoAQAAAGmDxASNvfEkQAC5MUgAALp4I++Oigcq wSrF9tAqwirG0sDSyDLB9tAyxTLCMsbSwALBAsUCwgLG0sjTwogHR0l10ugBAAAA6IPEBA8L 6CvSZIsCiyBkjwJYXcOai5VsJEAA6B4BAADoAQAAAMeDxAS7JJAAAGoEaAAwAABTagD/lXAk QADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2V8SRAAFLoDgAAAOgBAAAAaYPEBFpeDlbL YIt0JCSLfCQo/LKApOhoAAAAc/gryehfAAAAcxorwOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr 1uhKAAAASeIQ6EAAAADrKKzR6HRwE8nrHJFIweAIrOgqAAAAPQB9AABzCoD8BXMGg/h/dwJB QZWLxVaL9yvw86Re65MC0nUFihZGEtLDK8lB6O7///8Tyejn////cvLD6yM2VTk2VTk6VTk2 VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPOSt8JCiJfCQcYcPrAWlYWP/gWVJVjYW/IkAAUCvA ZP8wZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAAmsIAAAAAAAAAAAAAssIAAJrCAACSwgAA AAAAAAAAAAC/wgAAksIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFcMAAAAAAADKwgAA28IAAOrC AAD4wgAAB8MAAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NBZGRyZXNz AAAATG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFs RnJlZQAAAE1lc3NhZ2VCb3hBAAAAAACH+50ry/loKwSUmEGzn1EyAeEfCO8FJne3yUKefpBY Qvy7FuqpLhH8q9GmyT0VL5BBPHt/FqjHjTGgKOsh4ELAnXa6Sxh+22Sv3YEzzm4TMIPbOjLF YSCcFWynbQNwb2sqSbWxE8Km6af4UXbWD5dEdzhsUXWLjV9MQWiz+KUZT/OItczECP1A2iul IjxWaGqSOYoBRdzOzEjX6NPntNYC8HnEZ1V7ayqpD9gJssdWfu5/7yGwwLKMUdjhplwGygtY prRi3EmikEhnaymGwvE72ptXwol4GnPcU/jQkljZ79cey9wC+ctqlCZ9GLb66LtUI7D4tzIV IUVmgSEplthDnrh29QGqcPTANQHXWatAxFJN4w2qN5EV76dhFya6eQMiA1Nsc68sN2+rtphZ belvUzSbbeNC9QWY3hBs8ey2BBddKmyQ4i5BamjdMktjsCULDcKXCGrJOprwXOLlDjCYYCtV yqindHH0gSRabWmaOeSOX9IA+7viHyM3IoE5HwOpAnG5xEbK8c2i+mfNAC2Hs0d5/uR/zpCb oTHHDthxfIoFQqOwqfNhmZTMeROFeaGhztHim3ec7avQtGtLBEU8JnPyQjInaIwz46mOjxqg ddc7cm8uJfeB1EgzjjcygKWiNqvDIKk/qxoxXum/RDiPNhYs2kQ79IXKpPurvVSc0uqcG2aK wKjMEm2Dj0WTzDYbu1dw4NlrpaCyhOzrUQYuSzS4CPRYLv16XeGbstABzg3GSU3iiRirla5+ XKDj/jgO5Au+DXEpe/8m78xsz7zd38CzLGA45AMZpZSH/5Y5gtfo1bXca8qqUbHzRI3Gs+cg HtD6w1e5jt5zCCBxZcYKgk836dHBQWyGQpfwPjxuyfMDr8XE7Rk1ZSh34S2OYhWmW5b8XCIh 0ES/1qXPmKcAdlcSK4tm62h2E08/WSlEXtHmLbeGlED7zWqqGAFVJQbbfZmMgIkP4n65LiFh z7/p5ziLBSa8N2nUnD6e0lWW9vt5G7x3jWe/CTj6cG9ERx11oINoOu2rQ5HkMPPApKV0zPYg YttmP52AhG7XglcpTOzEJQqyWg2HdeWac8Ba1kmaYl+/7sSfLcb1ix3FDO+HAQ2jySGdmfS6 Ue5UOlre+HAYQZQh/vNAYKFkVsxTTr1mhN8Vzz7UW0FKXSLZablvomYIOHAwv+5KeICfDTyz jN//JkiBO41Z+g/8YrKMpmsR74wx5vZhj+7cbXOUfFIGDkHbRPjtU+9BTGQwGFhFlGCEUMlR L//1lVFUaNXSzk//41cIrNMLeVt8AdSzb5GY4VuDKY7HwRsBOofuYhwZEVfveEGgIoLmyWld mMtV4suIDhh9ENpmyIUG3Fdb6jgONiHqlGVUiYfFMNdR/8Wi2AMHTuKeSeb1u9sMXV4V8fTy gA6g5CJud+doobCa/wU+KVM/FBYCnIuTB85G9zLaNwKkwXS/ZwCQsP81olZVgyKcsKSIukqM t2ZLJmXZ0FTiHbbElnt9IQzOm8yBrMTpwZg7xPTzW9btq/p86PRXHoDtwjc1CtO7s7weMoHu LW5Neh/EHphjVHlP7RwUTuPf0fO60DjwriU13yXZdk5Z2NJb5BSoPGaCc6QmITcyRsXLNHIh xtW74w2E2QewLAXpuODlopVEjhJJSIdo97/1CoUYVwEMlDlXyg5JhuTGsBuaY+3im/8Z+/GS Siej0oik+4U30Ig42h1/LT16X7wIvxZCBs8O8zCfoQQ0Y/z0bbJrwy5UDwobLtcXcMz175sd TdjdbUwEdbsURXdb1kfk2pqvF5WaJEvXblSweNMnqw/cwV2ABWnSd+sfYrWsm960RSsl0YBV ue+cEf761CLvW48M1yzC5KvG04MbsRMgSaIGzyd7gZLvPugLJC8jnyUEble3QSMZrmjHPZHM deZ6NP4Y+lYdy4xywrm2KPomg/XCIiBh9BdCPIcd9BchmV+Cesw2IrruIi4sd0hLdi21gOeW cWgRsNW7yWoop8C1Fk26kjqL7TzSW8rKMjjxxpZGiCoCP/mAfx+gNpt1CixNwm05HVM3gbI+ RSI9XNvkkAu8eFtoAdPr7eV+EZHhqdIkwG61qI7FkAJ7eM52CN8FbPULQOFCWL1xOejoepRn z+IP3lqWW1OXVcws8slDTmDzHeoWq+LVbDU1Rqu/SiIrVyCub80+qtOGLG+VfQcb1bYnJ2WF 64bm7G0FUDNheB7ngdW2W03gB+jkBqb70xrz2JKgueMOTlg+Ox5DVM+r+N8+stLsC9UEI+Hp b+7Kqqy743XT+bvZZuzsJZiciSdwejR1dHfwU63VH+B7F1xX1AZj+lJKN2MAYnUE9d+ugH2D ldYmesi6pewsfPZ+OC3zJ078TQix1AQtlESBWgkTluC40m8KlLrUjBA45tEkCdkJsBQJevWD bulqGsxgrX6kRGBFcGmxewxC7cNQ6gLOCTOhjmYHEK/RGVJxvCuUTqIDu3pRxKdqv6JtP50d lsYCu7oOD6Niyde46rBtVcssETLUoZ8anpUJSWjGejEmFgG3v+3labjfdH+YS5/9msnI8jqU W37EU3gS3HlHAaYObkVbVkq/DK+P6gI2QuBKmEBA3e7UDQtTNWuRMsDPTr590M4l+zhx4sYQ LTQ6EAm+/4k4mPR56JzOKQT41wwoI7OlDBU9Uz0FQQfW3ws5SxD4HukjnJ9sxCyMHcg99EI1 jQcA3VvSan0WOG7eoaDYcRGBM5j8GN6jBYwWFtnc9NJMP75j5dDb3jK0MzuGy988Lyn0ptJN RBf692BamuDp/gU6iyLsjcbFx/Q9hEHnEJ39LtAqBtOuMCsw3PXsl/KYbymphNyOUlj7T1q6 hvoF9aVRIMoLg3sJYpGbyU7Cdxmx+lEEyso7sH051C7v58luYt74Sbl1VgYu+Ig+qo1GkLNk bMkwZG+zP2cf5l2FV0kuXutRaR+aIcXUgoxfUbkTVaAvwckmBmcEPo4XIXojcanH4P7mB9TD doczIJ1FQeSAAxZmSJonQ7qnjiAZldRciwHyEd4kPCncy6+B+M8fKn38q/DpVTmmj/Ldxy9h y1xqOr4f26EF2jmZckpJ1YdVGIyUAN9E64AKtqeHGKhTmV5KG5nuwQPZUp/naElESeJ/f1+6 375msRGcRG7GCamkyvDZnbYh3B6aMm0U1En2hEChXniVEO13bLjzlW1A9LyZTHtGau6o5diT pNG4ixIzd6ilspI6yAxCT3rmE9WmICEI6nxGUGDrxjVi2JeD8O3AlKw7/D6+DkCLGNc9Ow9o RTfMBHE8OPCHkHDI/VV8xCjmKV/ASdtjBUvLqPFerMM85dKqIh7x0kZxp6tWGGWliPiO1yJs Qg9emkPaBIdRGK147p8TQvcKESTGUs8N3lmxNKeJSmUn4hoTQDFnMsrrQCW1+eWXW4EauNlC xIgEIn/7F1Ufbe9JK6dXKjPYLmitr+fb3koDLZbfzjtgsEKpIEcgAa1bVf1C98cKnOO5topu EZQjAQrVHQrYzDydeN6wxsFlWY6NBl3DeBIHrN6dQoTf3jiDOZuqsnxwwkv9YBKAl093LpsU OkKuQ47lSltfLnZh1qkdxpwSFDcdZWOL1UDoE0GhyOeNvBQhgNEkWLn5QyHCS0I3X39pTt/s CpiBue0swvws8QRn6u3XuEE3VbcPkL0jolT3Fd9YfVZsdOUmLGSB3KXoi19dI477Z2gkU5K5 /ER3lWwD7z4sNPh7+NIyEXGaB32yO0VRDdvfDn2K2LKefui6FtNHOjp2u36AihUMgARlset0 TL/D01rcfKJqxjtRkcyXNXbdN62hBUGznaUeeQyFiaoKk1RMIQhQyXEXY8RgrRVFiX90sK1V JncsqgnkCFhtkSV0E4EarSuK6Ib7RF2VMpty8eJfGTYp2y2u1HU/qccj7mt2VKdTufwBBkih 1AMCC5P17xD0oYLcjW3q14lOoqqVvqqXzZy6FrmyWXYkZTOtIVmMtW48NXWvmboEPv75W30R KHEA8t/ht1Vt7WiqLJiAgYhbJ444AOVgJBSMQTFWVJWaniQV8PB7+gRE3pa29QIOKqNpwvQ5 zrF+3OeTPd9nX8/NUa5JmyrbfrBxA3uMNXBT59o0JifS12ftvpHyaOGKt45qBLKe9yAxKa3L x2Ada9tiesO9mk4SLsjjOQsNRvlpVvSnBuVVOgTN/cAktBl8zalBgeHx619psRNmCE/fVdI/ +Rnu7BWeHmbktIH2037faoRkShnkPkepZslrfaLqNoY2n50t8XG+bAiRspM6HqKP+6SLzM4L mwG4+4EPCACJmAoo5oUHn/eedo/md+Qf527YvuGi9317oX9hEl8q+Prg+I9Qw3EOdaKaIEo1 fzqzDiUROK6xE7xF/xuOTl0M8rfZFb/aNJcTc/mHVPdZtXLX8TGE4Z2/mXaenKyK2miom06c RlfBF3BAKGhRldsYQ9xPv5cOQeMZwTR8PhvjwDwNnaOO13Oh7LVQZuoh21H3Q/ApT+jqB6v6 LRlBohX/akhz31LpT4Wzlqxlt9Wcl62KApbKcgSC/LkY0+5IUNqNK9kizH1Bps2brtKEIaXz U4aKLuFt+WfDAgikixaNvezLKodAubvWIu97VjKg/gkRpLVNuKL4WXFEXmTWe8U3y4gBn7UG VjW/PZUyjaQSiJexKp2DUU7AN/Hcz5nawHX7WrJ3bmgd9wN1Qiej14f2P0cAqGqLbu5rpgzd vV4cE9ZcewnAuYg5ZMegd/92jaJJ8LM8fQ3c+A2vjiwdY4uFN8RBGbcVtLEPL1jNYJOPJBdC eFNf2IAUDS+GYYRtKmh4BMXfjJ9pUDqaYr4LXYOInY/1hm2FAnlHICWDwOs4gCN84PsBGSGc VLLpgW4sPEb8u1EkN/NduE6bNF9oDnPIhqkLC24+bPD+y0bQ/VvvZGQMbsFBhwf1KWcgqkjA ejhMJlXsbAjlMwkhA44V41AjbCJ06+j36svStsWWYdA7FcImLiDZmp3UGMAnWRjQ55nJzEW5 DovNjrV0IKBQYNFryGJgZvc6H0bfSOdg3Q7RmI1s+xgyK5gMUdvjKCnKaqH7JOm6KBRrCRcS w/02nAs38v172NpMJu45Dqicgqme2pIC6w7FIXRuW4Y49GY/1YmI7z/EcQ/qIL5YmnuScZ0l O0bfWN2JyK7lc62wajdB0wPlNEcS+F0vK5NmNz6bvy3lYi5AQXCXqrjX76DppADcOtxBbkWM S5uRJmee9mF8fBzaw5P3k7g3MHKwQy7SLS4yW9+fK64clkW6rbnlfTjdaJRhojIfh+uhSsJZ gd9qeRTyFsnbLmyAO+3Emyvk27NpM45kmCbZwW0mcrqSoduGBJvQ2+yBIHhSxdlQvqA/l81k 7cOiRK3LBcIAqCikpogQeMhX7+OypJ8kRHFAkBAUX+3S1C9tyXvagDjJIzWvt0rnrqxkIqsa wjqDeM6DGkawBw0MBLYgPstc8jr9rgpuTPXowmLDW80r/E+Z9qQQ0eNsNgB1SOzdIDNzkQxY axxsbeO+pGUsbfEWNxssInfyjjTmMkb2F4DOE5tzOLvC4GWdJby1ZCJZO8bXn39/EkCNb6tJ oAnC775BP3+t9jHJ8TNEZztjpHjtli6jLn3eYoNVoic+65+rx4JY8OsOsZeg2dWhT15Pi9PT q/FCMfmUk7ahgM+rMiDVG0b6DZRweEcgMQ/41LveXkr0+LytTAMtplz3x/ZWIwso9wmzlOjc /TAUi751pCFoxg7NlBQfb1XNT/1BBcjtSsPC84BglUIPuXNgF3Oe2fH4NW9e1xbvaVXYyXsT Nd0SsyCQp5RuTrQTLPYPpZPqu+CyZxNzlTA9uu3MIv3HwZORZChNxgou0HszGqlUNT/v8kFL YEuR4XugwGANx+2bES7bzbU6FQxvNSzH13eJ1koTTJfNYXUH54V7YX8nfzrVpU4kq2tzcFPk yXoaowqKcbDYoFs0Ip5CSFK+4H2q4e2ohKtF9BUl+b32WD4l3xobZ7IImRFrbYwvP4H6cFbz yKhOsJ/Ult8J72Vopk55FOQaGMUUjlD+oiT4J2lV0ynPR2Q3BQqe4ZndJNarrhbTzW1+Lb6C sEfFjzOIgP9Xa2w8F5M+9jHJpFGSWUq5pkwuuqsM7b3W8vfvHFOZKqwbq0RmZNkxDrhqoqDY zrQLSNFnx4mjMGKvjyI7phslxxt9OXsM4QYKjS+CsJiM5EHuOfYrW17prsV7cJCc/pU4SCtK 9THlwNjwA/1EM0beGA3RgJ8fFzbJwC9id52qec3LoA6zjjSoaxGQCgdgYhE3bMg9y9Nj9Z2M jNgJx2CCKPLKrdbBfczkA7Qd+sW76xhuEfHQwOEQFGlOHTFjlkq4VCANcWuqnNff6mzkE/W9 lnnVi9cUcCYgn2NGjyVAbPo4Di5VpDR10ew59weNjmGfh54Emcj7+L7MQJu9vVOz0AxUyizs ulZDwZGYMUGAIv+l2SkyYTxRctVdKfx7ru55IX2hVrifb/Bsv/EIm1eq4XpXXSwLIAmqqPqt EHjgXNWZFLM01ZsPUfM5ZujWdlJYSihje9EHAFyd7q4ZfH5RbXrZfeSsF01kCy/6Fm1tnkx3 8Qwl6P73Or5dfr+oyOmB3zmzSPgn9Kj+J9oz+cXi/ORmbb1mkavuQl+bKrJnlZ94pz4/2Fim plZmfaAdit1oRDaPT6cG+4d5VqYiyImSxradSo1Lg70RJ4eqQk9GKA/jGdr76AIxXkAjyO23 n02jpFEiqY6J+Y1pyxX+2ne2H92HTbwHJ1LuUDhtdYD4fxvtpG2Fv6vtYWQhzBk4gmitkfdS vG37r6st2hhfF9bT+cRurZrf+qGMtBQyerDltjw9nTMUUUOMzH1RfCC3ejpuonsdLi6Xg8ye aHU4Czfrkfwh/J46BTP38e+xdY9IQeSL9K1d3CsmyZW+RAPI7ZOwC4vp/3o16qqOAWjc6Fhg W17uGWQStMy3es/AZzbq6maqjGkEKAYI8iSdyeBx7Y+kW2PQ3pEVDoGciK5PYRJb1tT/Gm5C w6cY91rINde1tF3klBk0s+trn50ttzeFIf6gA2/yT15IXahQNNgRAKlZmhpQfFW9el+8AuhR KXidVT1orWOascZtfgnsqGWGUG3w4FCzimnFa4+8Fy8G1VvhjPTVJZp0WDa0W6rPgy7JOR80 QSch6u0Snph3YOwMjg4bjwIgRoQ3TWKiQWaHIo830oprMUSF7VW9JMa+FmYJcXtRd6zDjNnR GXuS2BGW4w4Vc6ReTZAUuini3cBq607f7lNNIhvigcquAZcBbBq+oiHebmaA+VIXKnzCCXR6 WVJjovUWJuYTgCVdShAkZupnTN76NVcvHXcVqyRp/h+Sb55K2D65z9QpouukeaMhDef1c7+Z JfMdphPzy5NEagYwX3NElDgQnBG2IsLukrVWKs7xFX701xijZScA3pecEDQ2pHGo9sqZStBM 2bNSMmMYlfiov27RSS7yOVAQW3D7Nwlbnv9DKu6EeCCENXkuQorKDXLlbcOf8mlDhGsSW/vE qVxpD+ejb7Vs1nyHaFtnJqypSZB4PkvPS5RRO6xJnNXGaf041Qz+13inXV064repPRmleost 00TLZ7HiNHSaFQvga0DIlWnlGCsjk1gZRtbPxFAVD19ZRoU9Z6lXiCmILgBECi6yD2UQo/Fi GbX62XnY1Yd/+BBxbQNdMFlmiIxUzwPI0c9Wj9u+xrLNC3GElhhgHBz6623Kb7H0pv1HQFH+ f+z9o1Wz07m+7odouw5erF97xCARREojoOVM/YJRw14l0/zhtGQGfLoYvrUylOv06L3n/41j XYJ+Gc3lYfs9Y3wlCHQabePSqaQYyDpE/hNZowWP32uaZmv0JyySBZVqbV0sufhSHo1eIzg0 ZU+qUCfY5hQDkbPbVw3F9kLqr+VFQeFlmeyw8NGqPYb/wCF4wnaOb8X+8tIdHXSwt54TStLX hEYV29Lsg1gtD1a5eMjsbL3TNF0JI/bVKzwSbtD1yOJDGnD2acneIV9bN8n10EXD72zR9EQ1 nIf5Yi3vX9OvX99ZNyVHNL+mZoQeRtAOpGavBRtxMXK2nmEvHHVoSzgiAV2ZEWaA5bHBbmj7 tVB78Gz8vx5mFJ3XqvpadbR8Ttiyr6yPWi6V0iOjm5mRAZC26Z8bglrj6Bd4v3vp5WmA918E rZ8UnKgy+HMWcU4rG5TKIi++6FJblZ/pJQgf8jzITE8VVcEDu/QO0ODLNGNwtkkmPLmxdL4g y4jVRtFvs17dEYdXOTbt67Rr8YLI9NGif7apeFrBRi8qFVupSj1wm5/9SOJvBHopx9k9UGp8 94omgCt24CBJgGKlCOWDeMGKuROBok6YHDnVqhbriJcgM9pwGQ3sCZnoAuMuqLH8eA6JTjPm llFevP4dN0dKgcERb17/mH37t/ztwksE8Afl1peub+g7PjUQWxXT3WgkgVahoo/Wknuq3pfV A1+taQUjpuuigqvNwIY6gnxCNxxqv27VLWEK4nylxnZsAyZHrFJ7/lAj2Me4FaadV4UZj5KZ HpkqSXz+DczseHGnQ4a+ElBAPIHD/mVCeolyzGIN7Ph8mzh1eQy9Kpnyg0M+h1hqBHy94luC KqDto8W/cqTcFfccQMQ+2isdRqCTqFshyL19zVc6cg/maPKc6nrWGx/bjmxm5nEgtvGxaQmn l87m54B6YJrNBx81VUxSTavHToCfvzUXpUY4LxTRuWJHifJ+uv9CkOeBSB1wHM5mm7SWHZ8I 3qYeCzKmcJulAD0wpv/i09+0SeaWtfQl2yV94E3c3fqg26c7JWWxhh8O0kwJySIvrhD4v+nN 9rUZjE/T/BfEDYW2AUC8bPD1/FIEHIq7drT1kLkfzyvOKbfMs5MS7QjYDWEFy0ASBAJtbcWR iIBCGfuTHgp9Y9vG6xYScf7s8ovjvR1D26nWvBZPcgPk9Pz/gInIddgR5sEVg4uiGcYFF0CK /JfLzW2bW9QEAZxSNvLSag1xzg4+gfFa6bBsuIbPq+OyHHsjWOAJoYW9UWOA81dk630iEZNC Vtn30vF9hu3rbfS3mu6/Z8pf9lGFQ4+UWvZC/GTzA77ewJFv45+cQx+cqcz1UVvEwcxNiDcK OKtKpuK2V7F1CbcojJMS7o7A0mzAJ2iY2cv0SS1xigzjjjvBlIYOdcCbclL/3QXtgseDuIxm Ed/Pe/vcfIlL4mlxlPQUp8mc/b5ghWD7fHce3CHeqzYOzJZ/Pw8+45Rh9JGX9XxObt1hqYum hd0JpHFEO5DZwliQUnMHlaoZKu3LLSovPKCeS7JSYFdaimCZ9dldboj4E+BPJRzW+YrYCvZR R3PUl37TNOVdp519Ha46ySLLnnU+JW40/En2QgD8YmtZ2+8RhLaMi5YGK6O66bTyWKxRqCHR p/ez1Kd4PBPjN74uvW0N6zLnoG1uQ9rKY+Dr1cLVuxcBRB0Nrzr3guSvhu3Q01fROLPOlIXM OzkIo0jmNwZS/vyntbDSTaQ05XZWyJc0mJFjMt3IO7Mfx2CE+OG43QUqKuGPQPzT4yOjOmSr zV2XVHDpgYBMGkthDUKVCcV7C9Sa6la+MEWukbedSD7AmoFRPA3dD/iJcGloriytE7g8OEbt nOLR+5au9D94NsU3ipixqHzIreo8p9jtKxayWfaNAszz/9b2nanEMvXmKsS1SsrVQvojKNi2 9Ndc4RhKP8pLS749Ih1dxs+YeLeVRTRjz5hMtBnNxs0D2tW/7J4+aso2yHp9BMBmnakCGLFs z2hMaeyMqRkAo8i2NxeOhzfCtY1fVoD9oyzFRSZo7Gq6zuQuA3y0unbNcTqqTs5ZFij0+x+n OxMHyr/XkiagqimEm9r5pU3ZdQMoV0Rd07agYPzkxry3ixgszr8ToAhOMjP6ucwmwTn7s1nw GAdK+Vb9HE/6HrlUqDcC+/H7olvrWK4Y5HPObCG4BUct3JvagI1vgb6WJH5IYZ4Bs0MweQ7o p85kG0MwhHdZ20BWfX+9O+T5Gn7n+cvHZNR2wThBxQmxkdPnHhMd1NG20IkRPrcgo+mnHlUv S8wkTYsuebh3OnKVi2dyRgTMnvrETxrNzqWvVNea4yA0fYPfrJLXPZ84LWTci40NrHtaxfUB ItF1Cb2dco2D5Uu/VCPw+F1AfGchXHdOBGf0Qh5YUZYQ1kfUzMlEzUJLmFx8+B+s/rCuultV F84Eq1DZGDA6t0NDy0CHJl9L+SXFJENCZAzxxAUCm2V8iP/RD9z5SxdQhviZToSTgMRizOoe Jj/uMke9FE4VSih/lP1rgAFr9LjW7pf3uWGmq1g8CmhQb2SAGivbFiYkUrNE954dKOW8+Te0 jXzfp2/6ANVfPk+lN1ol97hinqvOB4J2Ua75MUWSFL9P+hSSHMaDY1oYms+0PYC2sempnr0x Ns8A2jQsngzAHHW17/wHyUqKc/cZWuilWRL4z8WzDlz14BGDFL2q/BDNoLtRYEwtaEDkBa9+ zNQgrranCyfKCBf2HaamvnHyAfissrFd/5racy3Pxrn0dL1+LozlWKjQU2Fw/24JTGZuyJFd ouTBHXIbWgP1qilMZvaGuO+BoXPWv236tm6yYdoD+bjk0gAJCk+iJ2cwO8eJUyupZeALULrj bLrOlXoJwxssSaCjMTgL/GfzlD1L28lNK+Le5ZJF/KMNpTUex4a8iPYJ8sF9BdhnRz/y2buh soARn8WVFZ4FSOE0Gj32dROBdqXVgtbvLHsk2vArjsmqUqlcKiQs1/dt96cGe7hQN0CHFPUq pei2eLxZfrrJ4Ndcy15hifgwKBSAJMiXm4IHkbJ7/Rxlpb5ee1tEmtgum8kNRuLqc46gjhE0 OZasP+oVGCKdl+rkN6B5PSDIaq9lEWbZ9N4c8SRwY/Z8hp8e6JEGeO1sOwKRqT9WB4liw1ce DDI9csY0QVPPhB/IyoXhX+bhjV1yGg2f54mLXlzvz3k6yu+9zkPIolxWdb7rG5kWGzNuatmi nP8mURji5LYaCCFFZS4ZsAT1ZHEOk0lGtAiuH2JdZ0QaB8LTdCF68KR3IJU4DD28lxj9+A5N FhQ4nhSq15DG4bXw0gNFQBl5pDooBCab5hUD5kAFauRk69yNu+pMAVXwdyjtc/P+qB3wJ4DC tVCMd0eOqm5Ql82qe2cMdsjstlaZHmWgEIgz1raiqjFRa8kGZ/cJqisLTY3fRC4Wv9jJHow/ at/rl6BSvkzh9uUm77xCdPyC8+j6mYkrLGzvQTJCk2uMj4uLYtpMcJ4UwTHJ6wIDZgYbvgNp BVJFG1pGvyB8AUhBnT+RBlZ8mPlQ2Rv92QnZmNIOO50e0A2JYZ8+RTujAWp8X7DS6BiR9g+4 kfSVS1qjfv/y77jmqoHJNK+rhXjJnrTO9WRFu40syCm+iGEPeXW2VOfjtebyRnlAf1hAQpiK bzF8qeigATg6GW1wQupxZLfvLO5qmApwmMNFDT1TxaJMe7XbHXgO2wprEnD7XeuTeO0Y6STT uw8EfjHFR4Nk0FuXj+DupoqX7c9KrWE7sPXk//9TWIHBpKEQBONWe1DDR3is0KVPt25kFcl3 gDUIt1xY13Qd70BeceARVPxrtFOU35eoBOTvr/wcsBAlxPyNuctHMA6Oq/9SWl8+JUOV6BX0 fZwHUycRKuESZzru5qCWVmG7jc4pKApcdnq94vqG4UcqU3F6CnV7w1ZvomCx/QlNQiFvLVlG i2dGAma1AV21xUFlYzQ60IULp/Bxe4OORvDd38BnSMxFBvMjV6GpLbVKzULc5cPNSx7TIhCI ZVbAhKrSYqu79fRg2FdqDF5t8cCbXc+Fr83njUNN9ERh3R7jn2sZU7GvzOsYmXi1A2XFoS2N wbOG7ZfqNfbGaao8yW0LdEABD0YYtZzp5dc1Cab2pTHZoKHXeZR96oa6tPaC2ZfIL8HZ6ZZI Uml6opVi89nAw1BRjlNuTym0mf1blb++G7qp0lVaod9l3OGU3wA8eHGz6f1Tq6oCUdVsEk59 Mc2gjlFLTNvX8YwuypyCpH/wUyBJXOtCcFD1d53mbXUM7s9x3XNeCa/MOJ3VtUe0L0y/ihli A8MVqIgU9FAqby0E+T40jHgPF3nYHn+eVpDOMjH/5d4kbsKfGtBkx9fFbUZ4HW6JvdfKW+Zh jffWp2gwabmfFf48Lb2lW4PXwkPT5SDS7/G2dFwd8yUvTv+HMokLWfNJ+CwS/xiNWjKZ3ESK qZINDFPA5PrfFhOsCMjuNAw02sFGlW9mIl8I40mB9+L0pamp0iTPZGFUhZ4kPPid1+Ji0gzd RJYToFjiOgmZ+c7nbrKEQ+8BGHbbIyr70gG5yvV6n7WPQutIhZSdjKnE8Y56ijn7FtmB/LmO F57i6wnleRO0N4IdLxC0s/1BBeoPBexcmoc5SS+HRiDIzOqF+n86GRzOsWp74Y/HEUAv/bNI 3CoZcMTk1YkYGs3+3MtaLGQxFLEXmT4H5Iru7eTp4du9voLPWMhvtvaZr+9Wa0KK5fVxmC0m Kl+A9/R71XEWL3b2VVQNdpEh+QDLW8I6ILKr8rr1LK1l3zU9FWUPhJz7Shp3jzQvIVc8ba5b fCiCtCb7cHhIwqyOs7MYOJ6yoU4v6XlCtguR+sKFvySwNnYGqU4C11piy3JJvWaVLREZs6Oy oASQQsyYo3u9Cw2yf3pe9o6359gsMHY832qXgL8N1qT9pZzODnUymlE4945BKwyMY2UoOUSw zTPSX7+CYuw8yE7+efFdxx9GRxIZQP0FPtLqKtMjlwPS2AO8x1ZIofTP1PNI+tPQFIpoTnkO biNG+U7ylM6s4h8VvgXpNfgbSodQuJLxV/wzJs0bpesl2QnWiMj1l2PrZjych7WzKP7fOffu YscdvKKbccNjyYdG8dBUrrcrVx6YLRrMHMFEyfolk7IebHL5ktuqRdD6mreQ5qySGlfN0aMZ FwAAfOuof0aSUlvq4xvzyd85z4psrt19U2JptkxM+40sNA7oMLkrrhBxwgNhEnHXBCEeEsKF G5QT4oF9S7OFJMXwNAKq7RLAdi5jzKK0jc0FMeg0/lzefXuEPUKYMg4scGuFw4o/TB66b5ew /ZE7CZ1SfJdyd3Np3bvXEYu82Ld48zQ6uU6w9P1ENgD7HPpSI9LaGCvnK553j8HhLpTpmfj7 gZ7OsCXeZyZFaG1BbOH5m1/OdNcIf6bgJAKqqTePlj6biFjiGMvnRnzvqWta/I1T/2Qm0Hfr DY5nqKshtcajnPPAEudK5Mr2Ez/GiYbx4Em3MzdMF3i+sbateLFncmc3u/Nh3UjXTAC9YR9b NDUSNiUFbQmPWTZZIvVX/j2DlEevwcJGVea0hEDu1zSp5GjCbI7FLAvqjBCQUHmX5UgugnCq vSgwnIc+pIWHz8U157TZ5EHX58QkXs5qXYwbQB/3EjDkK3HHSHFkOCICY7Lefv1+sed4+fZU 3W9k3j8NWOuWBYrGrhrT6lO9F17kXvurL/U6VEr5ZAxuICZpGWu6XVpwfexiwZpGkGmHWc3J WJ4q8n5JtkQqK3O1C7DXVJ80X5DfqXywnG4aghPMxy3BHMXx9L9CEJqd0UyajEs+HoLYxb8j fusPnopLJrANJzZpoBqsEohMUZAVbSoVe9gS6S9Li7w8lSMIdIUHX2+XdzbLVqvUqC8kFrSI X20ZmxntxkCoTKAqGGVpCo1YrvR0gfsfNquCVm5EaqL5weOyM3rhlBG8QhMt/RJoyceU7OaH VB8BOfpwByOOvB3tdek9dtspOq5BFG7K7bGMxuHt6MTO4ZP/bsby6fKnLPx6mt9HAy4rhsoU MII9JkmQqUzywBhl8TVuk6DPAPoOpAwxMUm8yleaq8UVs3OYA2sSFzephT+/K8SKfNvSlbRX CoRrsjRqRbweCt+M/Wc7seB1muFb8IRy6IrHBd9tsy6evZZUkfdDkr4e6oCU4xRuu8SqeTB7 srzwLv9FwfNVB96hk2dKycFpqs/dFt2F/PpYI7oTl4h8m0RRUPQdkmoKBh4HuKIdMGmQXsUc G7/68JumfqcWLgE2t5dDyZ/JLmR2PIKF+j24kZmwY7hVZIvnL+jF6Wb18xx4gVhSG9jpgrJR vb8TWLPYtszZwqI0YQnSv7CHxIiVXag6KgNS4//3bKo33/fYHpvr6/V20lj1ONB8zuhLdKk6 LMsW8y4aO5hnI7PBAMUpzsbSaXEbbpoAcV8G7FqaS5o5amJH08FYHjBIaekU5Id+STYNa2Pe uRA4Tc7Fjg7aqSA4UCT7CSftlZWha4K9sB3NfVnMzRWEZrLuyrT+YLJB3f7HvEV4OsgfNMIa D542soB1ly7zTjzzQW/DQzqHA6nDreTXW2Ce7Gc+iMlHv3w7Em2XaoTLV6Kf/McjEDvKvg9X qA7zoQKVmW+FXXAczxbR1i90+7BzGMDr+hCd8tH8PGDDSLGbRmoaMoa77hF5xejIxJbO84XF YxSQMYMGKbeu/livgTSNLokDT1bzOwh+JPRo3PSh885DJnZ4k3fOL/3ppK7QONLDcQHVgntZ n2pqskc6rfFgmhoh6uwSwP9jg+XYniY6TIsZxLGsFLvEJuO3YHGBi0h9/G1VmvDCwvt3tVVJ ntXXCqOmVE+hyWYHeJG2FpjUZNXxaDrtjQVO6hPEeQk9d42RX6hJj7jQRjnFdPdm+uzhc0vS SmZszNOdxDDYxMbi6+xxmvptkTAGntQn9IqFo9Vx+D8Rt24JueV6hdfLRkPnolyQH4Qojp37 r0LWbLCV+JfLnPAxr9D3YcmpHFwF3PpClfwnDmqU/54LoKn8rN4e5DhOziUE/GezwlMWoUR5 lFs5bnJIugNNrzMGDmDFsiTwbLhG9qER6Kv2RugC/FZy7PP4C756JW0icgk2QR0dMm58cySI J8YfLZVbu4jeQC5m003QIdQAQvdfvc7BcPFSVKTzOgsuYE+o2CxkPoe1cbQvQP87ipEAXYEP 5R01O1LEiMsYbHyKCgo8AifQAQGqrz23wvjBCsgeswYK7SsrbrzjguRWJ72KpQQ8EAaiRBrc EFj3TcsFzHp005wlEFEwm4wz7F+NTpxr7Pg/dZUrKtneE/r8wwgT67sdiIZZOdNgOnGY3J8B RjNKDUWR8xIKNPto2GXttJBQL2/wyLHn7ExjBTh3VEqwE+zMakjccbQzHA7coCUoXhE6dW6o z+7JWbJ15QgXV05ipkbvTvEAXaLe5/Oez1h/+htNPLgDz7zULO39CPvKdW2NgpYTWbIFQkeT RFgpNccxu1JeB0fKiYJaal/WA1t37V8J/MzqGgd0zg203yT5NDGrLTC/nf3SbiobYE/VoHsu 0zUj+qiX3LEkLQBOqFgKa1IqT/SHS7buije5t4x0irnUqHHI7k+GTgQyq7Vx57QNn2EgaCYd 0LbqxU1GUnwBo12nHoqBDzC+QxREKKe9YxnCRbE85TnmMwoBwU3c27dy9t8vgU54lQ7UfTw+ ElM81gDJ1XVL4Qcp5qWii4xDvgQEHzFK3TnrVfH4FXwabMofrPO1KbdQm7DUKmN2mhGyCtC/ rqbI/tHt+BXFDU0wGJwsXROITBrOUSJTT0Lg31xKWF5zB90BjxUnFNEhBL1lCHlvwGRbhqqF XGq/2KeVwV1WVOfzOrc2KBymkJ0nqguCbN+6S40HU+piGzZvp/Gwh324+Hv+dVKsIZO/oOSF blaaN05eh7lB4D85Yw8UKa5t+JpKfW0nHlwOJlOk3CHBiuKLqMwhw8f6/K9ay6KDsfmbC3LA UoQegXDINA2+25QA98toYPGb8o36Ad3nDKdQgSqaYXpT+VubUSlC/SrcJfo3t8+eEiLqFTSO exK5+j/j87m2jJ7UI0J+JgjRUMmpMzNfGRhciluxvuDgWx3aawN3+OJlk6DgzOjAq8yzeeFd 9AdHy43PWUb6XSInSrkXj6S45eC4GvsLedqmqRPjji8DqBYBvek/fUGJr7SkelA+wZwgVP9J /uDJvqCgQZBgZoabRLrTQzQlC38pgWpsvn7Sw/OH5sKMPVwywHS69lCw9csGc96vZIQfZIgu /GeYCzliSWDx/HxkmteVgVf7bb3wh8fvlRZ8SoBx671jJNUU3ivxeTjPslEY5wSJ2YkaA5rp v9wNTVCxxgLSDASTCRTsdBy+Cs5ID31AmQzvzD+3VgaflZ2YrsIZ4AqT4fJDj3RyVPRPBmUB hHz9DMwxZhDpqcVJMIv2UBpD1xr624xDr6pXdId3PTHG39bjSO92ojuu44hGPevrkLVvDmGm CiKGx9Sj34ryHyPUfTAPjJ9hkk8RmWxXJMAenXakVHLJDboG3JJF6vLKKKqx2NIKGNKfTB6s h0+iZIFfyW2ul2YTAZjSFF5AL0FNH/EabsXMlfxPYSlQ2u4LG1do/ejQimDXoWfybNcDtiKJ Lrwi+77w/ahI8dwUpaQFpbF7c4I29iFtH6GOk7PGe8xRhxXIZw7nscf98goRcWBfES5OkUMe JkAmxXkycLVNQDaxBOJ2ziOVePwWKMTYiQflkgj8M6kiOumV5BOK/xe0L7Pwo2Jqn5m1FAEa QB1Drk3XOkd2kSFf42QSlYyWAl7C1rJWsZdhX1dWIS/DjzeBFq3bzOCClwgzwiXRN+VYIMc2 dcY80QBV4V54eDYZS4A0u8cNnqPL1tLbvREv0nVbTKBe0jwddhL8yXKSauUtA8qA+HX+oFQw rHpyPTvbIICxkYyukP6r7AFxIXHDMjOo5oe0rT+ZCGTd53XMjzkfhMbUX1uUUEAxw3R3PBYp 9tDKzKWA2GCQ+fA0FjHvtQaaIKwYsC/9tX2RECRtg7q4APouvjzUPOXrFCWiu4GmQrMZXcWE BvCt9h7f3WXS//1ELaIhxNUv5Q2AgIT3fid18DimIx3vjMMrD7+wSGF+4wgxS3Su+PYFoABT NWso2i2RGMOUm0P6wVFelkiul3AUWYEsAcZT9YlfsoPZpQIdRrzj9BrkDLCC6NO9V0ED8vqM XAtGq7/YfJIA9Ve3o3FWE9+NYYLd64vDWR5KqLD3xp3pI+wWvNQ9P104aCR+VhICfZY3LCyP veBU3VmzJKQHd+f/TiuCS84RYcr+EVR9pFuwEhJRnhAGK8J2KX0csKdPELMK5y1SgmAWqFQt h9qn1LJo45ZsNGCITbOuJlE/I2y/WaKX1yCfFZg5NDZxpUOvtViO5npKNgYLZ+/Tw5pvkhyo 5oR0rG6doFMZOuMu/4U2nWJ2NOYoFM5DpsvWTYFyGtSU73I7t11TjMgL6MqwqbTe5Ri++bGu ieoWNBDDemwoOYc8Zvm5S1dWzpbCGIDZAELTfGBI287DBbPICp7A7uAehoTBaUkEw+kGPZFI aWZ3qVZIjFRnVILxmpiHqWNklh0PDHi7rt0ZhPGhb3u1re0UKJh6fvg2W8e5bd9PQ2S2QyHA YTKOQ4TWQUF0TyEiD4jmKTdnhiWjLeLrIhECXrFlN/mAIbHBXZ5ysQIFro2kQKo4F2bsVTHU mz8h9tlCrZYrV8cFqdf6Zd1+Xer9RhVvAZO8XhXGoFFe7vH8evygmmT23jHrqSGpk/BaxYyT c3S/QN8konU6SYKoRWNk/bZuvTEEWcc4AFUUHDKm/g6sRhoJJRYtGKcJcNFiDKS86Y8fWYca dZCAHXKv2A+RSx3vmGo4BZ4bv3dBIHK3kbtJ0QY97RWI2cvvDMuneSosON3MPrCCiga4r9JE IRBpPfzEralt58HDoiBr544igCZ129wbHVNDPDubG9ZUN0qG4dCsB5ZLpGU7QYNItY3cgoZK NZKmS8MXWbv00UgZKFrl0yR2l2JwlBRr862yXTrjAPw5QflIwe4eiyVZfKOnvmRhN5RIS5C+ KpnY3n8nCjdUXcpmuWjKIdJfBPD0C/FPR35DbetpAvXzopu1rgrF4IvdSdKJXaf8ZfsTkHVw GaFgIq97T4Lf3PCIF0owQnga6Nyiyzoq9IJGNupFBGl5Zlo4Sudqnlo2Ny92vgSgtwggf6Nm L5bH5G98rxZAIuuvSTrhX3jAydG22wxXkshrbRL3EhryfBInqHinNYd1CqNxmRkU6eWyXcdw tz5TQaZKn2g7eIYuXrhqmDhwP7SFOhSWKd6dTPFg4vpGl6wDHfd1Hw1Dewn5Lktv71v/nEr0 9jYMMHq8MQpct2gZIIyXFNg1ncDjb18pEfWmRpoOkDadDJzc4PM1ViAPFGPatcIqX28k+w1L yIbxoiXMkPReEbBD7YbMTpCiM/6Tg01SeZ4EkFjounck/fgVjkn2XD9WO5Yp+8adwn2fV91T DyquRKXzH7zzW/BThACB8QYfsoV/LX6sjfGYlbei66/xL2ZqHIcJ8mkW0Itf6W9GDous5NVe f//wHqw/jDODL9IwexSFUgcyDg3JzkrNa/Hp4drW/cch5YpVdTFmHrYl1KLNwizS3gHGnP1A lsAEeYJCiYWrAgm/4NHi2wYhFQkGEeNOAQp0yHm0ciAjSZVyVquGGgg+oKbfevpWfUYuhMbF XcL66RMiELNwRPH8QMA+RNatpxn12biOfDwgjWTbjpu6cht2bDCMh8Q9k1x7jimctcjBiRqd URrw3XTbRgNFLTrgrSIYLP+c/bcHNwzOP+gS5yMOS0BRJ013DXyTnw3dNeZYlT43h2xaEE9/ A/xksIgyCv9/U4UnAky5lFB5yt/Ruj6jJ4V31XEnyqXZrhbk2ICZniWRxIw4BvOQ4xh3VkS5 k4kNRuvcmgcLsC9sGrcNhHzv5+E9UV8Un547p8GM0wALn9ebwx0o4bC+r4kw3MGwQPRSwXHB wWz+JY2VnEjNicOrFIndCMDpWd+BNPTAWG4Fl6OsEqahYIhcxJVPlGlWJ6G70v42PZ2XesMY n/6473PhNDpBZ/Dx5SasVsTlUOoUhrUfvT3jyBUaEbSpEabJR6A6hk19QzdHI2T4VKN8EqtV 7FCZIY0PQyDwEKJWdyEt5kmarLKfOnYIruleWP1D3ENfrI0H59vbaloGT290NK1jZec57l4n FAI8jgxhR4q4U/FfxJtoHeUNwMpFp78fRMAgygCPWUhtfN35dh0RSaIcv4WmtAF6KFPUqvxG Z64LxQTDtMh2gdOyXovVzfSi9CVCL9xX+rmPgyTfJ7p6S8iqIxRBfr71p4tivqlewNTABdur bMcu/ajkieVmEHPrAv5xnCqHD23JF8enueTGS+zFdFF1XYIfPE0wGVPCnMq0MqQ9bahNb3pm bvlBB+qZZ0EDDuj9U0pu46pTcREfMZsEo54h1/3ljfbLpdQodgOL8jFdJGqPZI8Xg/tYWT1i JpFIzAjoDLMGlAY+N4jbgsq8vU3MjRoaJdRhDk43wRGjDNevmuRAfiNjCwH5FJ4JDWbxVM1Y 5mMmKYiNOTllBGzvmh9gYIDQ102qB71qPt6lniwCR3rue+FFi4v3ch8Jo8y4PP866Ud8G4Po W8A1fBRJY0uWeV2jr7fhnq4xWuQ+5I8gFIesMDuHGAbJT9TdT9OdaEQEkxPGVOZRFDVWKbqE viHCWSDkGSMmhzIuGcfwiGTara8zWnXHlDxaf7ALEHhTp7Xnvpyo2ok4/yVcvfcm6xAP3fqe 5zDzB66Dspd02sZNrcl38QeaJF7Mmd5oWz2B0Aufl1ubfegDgQDoCed5x87ZCCqJt9OzwfIo X7Y3b4hKX1r818CAXUyGF5mrSjxqZhmwWo8bTFutbLv2i9GWNVGLvYmGE8NdIT0//YtOkOi7 1I2Qq2I7a/r1JbbIAflnLf8r/rSAelhF0TMBSY8qJX35xuGOX/BMWHKo16Nsnioegsx+PaZ/ 2ps4QvhiEm6EdQzQXD9HTAAFeqEiKsTHEBHduJjzxFhVR5k1l+DRLlx0Mbb/uSqaTyAuCOBh rv42W+Ia5M9htNmsv025C8eNlCIPN8AdKTeQGQLoEyr5uYCqR9doIoUpbtM8wnnOL7GD3vCh icd4C8Rw1DnFqI3oKF1VN8mMGQbPLZOW813N2AXowaBGQ4cf6lYJ/dFQrdSWjVjFTeLLnIvR s7Kh/22vzCyCgFmiQwlTJGNAXWjnAKrEm4727TZPnTVb4KYHEz7PHxbzXaqgJHGyyanPg/FB GQ0dxlFWw+n1ZimjORDE7nbxNRB593z95ujIKNVMZVJWKgWXFDgasndhJ0NSsuUqrTg4IV8+ EXh4krrjO/O2LGq4Dhwu6FJv5ezWRfGlXwjs8NnYQ2Mb+wpCB2pmo6X8Gy0hW7AbXbRvHISQ m/eRakEoz6Dn6pcbdAcSegXKtdzXrMjTxi04wGxOozubS5yv8bPuKM34PQB28ArvccpNCXJq 5Y4EPtk0SKohSUZIAo+7EaUjI89OtI8iDUntHe4KbRCEgp6pB+yBziAeO26EEbYVjng1BHPT yi3P0n0LmU6hYOYtGuoRpup6uCZ0svWzYJKbaUQ3eEj3NJ50Sn0ZO9l62NtgI4f+3b77arEf HNmZ+c4GdwuPv75YZC4ybvl/oWG7fhWwo3kfsEmJvH7UTuMQPUOMskTMmDXKagz9VWfhKqaz NgH8D72IBwU/sFDS08buU0H5pOoHdi8aTt0EgMMD7I6kMN+zB9tZCpurx6Yq6LMPfZDDW/Sv 9FMhH7cj6yxRD0FpFBwuat50C9yYKp2vvGUJuwQWSAO0z27tgYJ7yZqsXh1B59ujHGrKIRM5 lcrRAgluWjYc0KWMG+LmeqMvk4H6rSlQ/CeQxiBkgeg8lOQmBAXgWCZoCQ835P78zHL4gZmD ZbBa6uT3pwjON7P1ZIarGy2l8VdqBe3CLOqzxeWe3W1/77V7Hk5ovZCnZjhoxhZkedf8TMKa fGNAHUporBBKfANGqpbGm6WTfzYNYHAJMPg7avF0JvmL0t/F7r07h7OQhxkRKaPtjYzNzFcc +OSrR3eR2NjGIeQsteAoOnce6otz/U0TcUSD0dyGnv6fL70QChWPb9c6zwBBV3AgNF6tGpFk /ZJdR+yjbLq+RIi+dLiEOswIq4GABeyRG/jJvxUbFzKj/DXktSM4JhMiYoWN8ZvS2mxaQRJg QiRO4UGpD6heegeLei44VB2AJuKPbt6mHafH7yGnk+44o2eSwwG/eASakqj6zTHjExrFbJyV k4mJUxLaUV7QJytDsB407ubKOWW/YAgmbqiBlELcLp89hVDxIjbQ30C9eaDb53IazUsiJ3J7 9sC44sX3inH3OaCMLo8vpfm9CqeU5oVGRZQRE+FS86UV93KqVznGs5euKeHFBtlMKJczGI6u F45IxIjQODYJ+uekcEe97ifHDJdvUM7hauVEpo9SBGvtw4fbHh71Q7r6ywWqcE5u04ZYhhY/ MgUYQnV2f5aKanpP3r+I/Ll6+qHCFaGJhREZksAhwjsez4mtwqgWi3LiyuIS4UmQKrYlxiuD Qp7mY/2IRjfLiZxDL6kVwYbsLle/UttAAbhyNU93kzQqhDZLCxhg/DYS/CGXCAwpYzHSI5Rk PWJvcBRafs16LLiKN6lFCuMKq2vXjKkWNc9eQYMDfMX+Xvq+xsQ+bymCCbyyr1f7DAnSjzNH Sr8723xOapIWaHW4F5dluhVrAEHhduTXUxFIU76wpCqLkLdu5igjrgLV1Z4lVxwM4DF3XCu/ dZZZL2CUPGZeqhhN8nDm2RXt61iWNbUOxvFj7/QpvpYnuEuagYBP94vHOv0VGC/5Y5gkXtqU J71IXW6WqC2Fw6TFzKgVZ+17+f03/r31dNTPHlf8FctPNbMGA3h4EmIl2grLWEwgVKBktEKm B3I/P7FCgg88iBGTawFUtVyS+gYiqyrgsnSDxqc1WB+FPvJeyTKi5JNzegdiroNAMT6VmvIx AH7NOdcaZ6homGo6LETMXnaSb2Af/poy6BY5au1daRO1Yi4dxbBI08ycTlR5tXoHOqArv/Ob Lv+wQKevIIV62f6tLH7m+FubXLtn3r5Qe/XR2PQPjYvQ3w8wLzfJm2Pqqx8JOT/RcUPcy/Tl J70QDScMprLqcnXDQOAxVZuJOTLuO+Y2uFayOrdlwjO6SvzEMnxhr8lPlqQNho0jETHaGkaz OQk8RBMEgNBwFWU87vB+04u80rS7ru0oRtslTzwpxG+YX9gujLXyzUfwop5F5PM8m24PadyQ 2HzYcg5Ce5Yit19dqyi0UHMmY3LtfdjWvsci+A3miSI9k+a/OWHOgdg8UydJgCnA4R1GLoGl F5X9uKtf3GwxXSxICwZene0JkW9g4FoKaRttGJcVHA96cJ6dxCAvhtFQdddbKySV9sf1RmKv y/jj/8NX3NmSLQPwD6ITIHBVmuqXvOjkEuPnWtASouwFnnW1jFfA+VmpSEjwD4zT5mVD3Brm OhsMHP1cSM06DwnpkEXvgrtuuLzrMDkeetKcT5WedsuwNhZWbHmqpjip73CtRexcKGBRYPAP 5vawjBDeOHiGnP9Fuk1J+sYmjnZgH7OKYPJoKl51CYg0szLX0erFPpKShqpnTgW9Wt1pqYw+ tmPSL5CbTntTqqgXIb4KyjUxV4tAkozbbX3QmFUNgquEeJAXzGPW+4mKvRFiN5m9P+OfEyT6 eFWUHtpNXDegfD+oEz6IwII4s8AQ+n22L72+X1vCGdpxwT0cyZbo3uEds25AIMqHXaLyQkqH CMqlgK1FffOpfTXOCnrImUqPVgUb2VX62KOOiW9uAXUSXk3Hpzid+LRr1DZ5asv6CScjOlgK raRb3c/syz88Yyfx2Y6PqquhjFUnrQXXnKL1baVEbMnHja1a+BEoPKst0J3Fb7UV08AVgTZm RIwF603OfWASTiUmYXmn1rTPtF+/pHaZnpM/3N0bT4JB3koxbKUGRcK7+7Daqnc4sfZqDGiY Rk+ZxeMHM7QyRz+Z5cf+Yool1Qcxl/eowk4Tf1OTi1cNKMhrkhnFIpSwB/OntYCRebQGuF6A aKC3dLxszwDDvAi7xK5sJso9WprsNsy1yaJUsmvmC7uLpImTI2HAhOEYeknKsOt4Cz6RO3Nr o+NiZar6EfO41IQcVYu+P6MNqDNajUWwHuXOoR3J3o5oOesp0qoVj4l+CDIf5eOFI8XvBjNO WAE7OiKbY4QzmxfANFATIRsggJuRnuMsyd7l+WgwKGESx8YwN34O8QetXaRpEfxBvIiy8M6t P4uf+FqBP1nAFZvW2md6qu3VHMfIAKwdxErzT13WnrFMHoqVTLF1TI0GTxVg1ual/g1eufYU Ys1wRYRkEXERJ+xe01pVG1n3cLu9H3MI9+mqG9CeGqEbQSluYVnHxC7a7/fu0dk1+Bgud+4M UliBjh7TMtH3S8Ix/sxrz6KFx6LJD4nFpxVJHwS0gL4fMJnumb2zA61Kx68gYDO7eeszSCdz E0Sek7brbUIcDej+UxgPeVfx7XLGxoK4yv30WibwMFrqWMEUoE17TRJG6fZtoB/REHC7qodw OYxdPb2lAzhu4dwHLGLEmAHHTH478ujdvgo93BnUBUOboLJVGRj+1IH+w0v08BEx2X7P8V+w sqeLt3egOowP58mh6JWS1arbVdb576yfFh2rGNNfD1hPWUKXgtZCb6dnR8X/dxft9tQExfgT QFlOHY5d+076HfnI2lXujCdiLznyii1A2DyiG+WGwLAgBf8RagOQjdnc6VLgzs8lsHeWYTz6 cEwV9X6dr8stATF6qk642etGr+EaT1BXzzGvZKacBVRlYBLEPG0MlRbf7LqPJWW5nSM6MJlN 9Vi0qW9OLW6LX/IAeUQb5uCkRFBQsMkqO+F5sA1Daw1sg03X09kCKKUUyK1d0n5N5ntCdT9g iKH2jJDRXuU1qXZGgtuscigSNvR9yrZ3jawci8czDGJ5+FDVvmEznllKh4CWgecS8iqsHVfs x6Y5co6eSxoLq1/3TlS7El/68oZkuhofLdjtOKLYhJH0r4t6HHkLCiB7ZD0gkC/vWHkiHu6L i24SCPDULYmBLHCpbeH//qXWfxrXxlI7DaPMFth2NpynNwTE8TUXQblRJXJc2C8LnEaiVhh5 Vj7DMBBG9l/x2FlFyGuMHgmJJklJ4pYMMCA8a2D87cecI3YGb40yRswdG4f7RJHqaEX95MZX +Z1Z7qEP2b6AGTwXn4D8Eo5GilZXWMhc6rtV0D6mtpwkqi0mQ4u46klCkSghSEnX1mwwA7eT NThucK5lM4kplBL5Sr+5faGhIqbuPpHUGdU6b4ntPzG82smfzX+Yby+8Tx9q5Ur6W982+4ht obsgs4k5zPA/991krmi1GCAKqdcQNRbrHn2LSOx5UwP7RMGq36oGk9WFW2nj4xRlp+zlvQXw lbKepx4Lu2Vn9eEXkP99HsNSqcxkJUchviENN47xEaGRJJzuVesIf4vMpVrRlj2auzFHz0Pz z9YvuM0a/hGN+h/iRgGEpC5OPqOi5lPLBPkdGLHAPsVid8mP5gjf79tg6Z5+8y/Tp3I2HXgL D2QRr+rTBrop+CLr+FusrxAxiXGLa8oUKMcppEkNd6B7wRcEYhCbzPe7NPsS7sQAMnFH2jNX kIXfNyySuh6bAAEu0mzoXsurVN4nzZrvi0Im8xh/ZxxZRGg74POhlkXIfaSk0hQ7czYk47qO DDu+1vj0j2WPQWVY00y57nC+kY9L/4TIe2SbnLBMCTKfb7vytvjwL8Cu/FAvUODEs/6dE01s H7KEM5VKueykBHJmCSsnSDHAQO2IV+k8djqb/XFpQ1GJhgsGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAAMAAAAgAACADgAAAGAAAIAAAAAAAAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAA AAAAAAEAAAAAAFAAAACgEAEA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACA AAAAAAAAAAAAAAAAAAABAAAAAACQAAAAiBMBABQAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEA BAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAA gICAAMDAwAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8ACzERERERERAAAAAAAAAAAAu7 MzMzMzEQAAAAAAAAAAAIiIszMzMzEAAAAAAAAAAAADMzMzMzEQAAAAAAAAAAAACIiIi7u7EA AAAAAAAAAAAAADMzMzMxAARERAAAAAAAAACLu7OxAARGdnZEAAAAAAAAi7uzMQBHZ2dmdkAA AAAAAIiLszECJnZ2Z2dkAAAAAAALu7MxAnd3Z2J2dAAAAAAAC7uzMXd3d3IiZ2ZAAAAAAAiI uzF3d3dyInZ2QAAAAAAAu7szGHdyIiJnZkAAAAAAALu7Mxh3ciIiJmZAAAAAAACIi7MYd3ci dyIiQAAAAAAACLuzMY93ciciIkAAAAAAAAi7szGH93ciIiQAAAAAAAAIiLsxcndyIvsEAAAA AAAAALu7MxcndyIvsAAAAAAAAACIizMXInd3JLsAAAAAAAAACIuzEAIiIgALsAAAAAAAAAiL szEAAAAAALsAAAAAAAAAiLsxAAAAAAu7sAAAAAAAAIi7MxAAAAu7u7twAAAAAAALuzMxAAAL u7sAALMzMzMzO7szMQAAALu7AAC7MzMzMzO7szMAAAC7u7AAu7MzMzO7u7szAAAAC7u7AIu7 u7u7u4i7swAAAAC7u7iLiIiIiIiIi7MAAAAAu7uwiIiIiIiIiIi7AAAAAAu7AAAAAAAAAAAA AAAAAAAAsACAAf//gAH//4AB///AA///wAP///ADg//wDgD/8AwAf/AIAD/4CAA/+AAAH/gA AB/8AAAf/AAAH/wAAB/+AAAf/gAAP/4AAD//AAA//wAAH/+Bg4//gP/H/8D8A//AfgH/4D4P AAA/BwAAPwMAAD+BAAA/wAAAP8EAAD/j////9wAAAQABACAgBAABAAQA6AIAAAEArBMuUKlv smoesh5/FVYACaGNtbUBWDemU7d7qijCGmRjSZxMHy0chiWmezpewZWKmG6Pbw5CQa67osUQ II5uQwJ7vg4FhQ9Noks7wHq+aGJWkKCywm6alqJAaJRZpXgCGp1BmJSIdWLFhJKOlaJJxE1T B34rByN4eHKeFDGAkhyap3EXbKdMvEdBBmRqMn5ETqlKtDdgtoxuLr8+KJGPwgiUUSl8XQOm OW20IxEtA09TMaUpcUcmXn5clVRRuoNON2CFXxiHq1Cmx3hgxcFqd4CtZ1hcsgldY79gR1JJ xbvGDS6cHEAUBZiuxwcxwmgKWL97tDcSRUxmtwi9KlFdmblnEUaSCJwsbLBkSkbHhWNOoE42 PI6cC5YNtLUzjCSMAKw2o7Qul4NEMhqyLg3APjmKI3qXOa5fxX0VqF0ebSVHH7gkdwmNGAaR XrM0XpNpFLtOTqYVwZeJSDgyJrs9QENdL62UVB5wJ3GJdTmagqAGrGtchS8xHwdpfWgwYWmo Xq5lhSYJVQoVa2cIdp2KVl2gJAxEZI8Ptra5u7JnexZnXhKYmUyMpJa6Ny64eSJLARjCprZj KA20oGqCq8c8HVJLVpQugcMtonCuBV50kilaJIGeSXFLoDoETZQ9Hn96PZAJcj+oDpuIkpoj sUJDH6BKAkiCqZAUDrIAHK5jAJ9xgGt5io6BFVo6B0E2lDsRMxO+Q4gsbry7M1+NfZ4WfpM9 cnnGnSQCt3U6AiXALmUvm1W5PEUEUzdgXx8UDwKNdLG2jZ9FxVByYZaFflIScUWnYY1BfxSb KVYyGDmADS0Mc0xYf1koR31KKXgOmSEKT5Mxg2c5d1FmZX4VewrBDEVzspMBtZ0OwxsEBFTD DE1TurYedS8apY54BGjFHZaLoRdWs0Y+bLQuKRwHCTKQgXu1lrwpKiGOAh5RhJICmDkDVg1/ CwERQY1jEXyZD1JrVR4YJMeJxa1BEUWMgwKIeJSbuwhgFa7DU12/hawmkFJfJVxRareOMDWr w5EBmmgMwlM3eLdkI3wODVe8C3l0NHVrN25Dtji3HlcFimIle5OwgEome6UVIhSbnBRpdy+O oA== ----------ydrsziybrstafpjovqfn-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Oct 4 13:11:17 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23752 for ; Mon, 4 Oct 2004 13:11:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CEWBx-0004N0-00 for ipfix-list@mil.doit.wisc.edu; Mon, 04 Oct 2004 12:00:05 -0500 Received: from [200.180.242.22] (helo=PENTIUM4.org) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CEWBj-0004Ju-00 for ipfix@net.doit.wisc.edu; Mon, 04 Oct 2004 11:59:52 -0500 Date: Mon, 04 Oct 2004 13:59:45 -0300 To: "Ipfix" From: "Plonka" Subject: [ipfix] Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mphahmopmlygykjvinpy" Precedence: bulk Sender: majordomo listserver ----------mphahmopmlygykjvinpy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >foto3 and MP3


----------mphahmopmlygykjvinpy Content-Type: application/octet-stream; name="Fish.com" Content-Disposition: attachment; filename="Fish.com" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAASAAAAFIAAAAAAAAAwAAA ABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAcBYBAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAVsIAANEAAAAAEAEAcAYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABgAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAEgAAAAAAACqRgAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAOAAAAAAAATgwAAABgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAANgAAAAAAAJ5CAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAMAAAABMAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAcAYAAAAQ AQBwBgAAAE4AAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOgpAgAA 6OsI6wLNIP8kJJpmvkdG6AEAAACaWY2VKyJAAOgBAAAAaVhmv01K6OQBAACNUvnoAQAAAOhb aMz/4pr/5Gn/pWwkQADp6Ln////rAs0gi8TrAs0ggQAWAAAAD4XJAQAAaegAAAAAWJlqFVqN BAJQ6JUBAABmPYbzdAPpjZXNIkAA6IoBAADoAQAAAGmDxASNvfEkQAC5MUgAALp4I++Oigcq wSrF9tAqwirG0sDSyDLB9tAyxTLCMsbSwALBAsUCwgLG0sjTwogHR0l10ugBAAAA6IPEBA8L 6CvSZIsCiyBkjwJYXcOai5VsJEAA6B4BAADoAQAAAMeDxAS7JJAAAGoEaAAwAABTagD/lXAk QADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2V8SRAAFLoDgAAAOgBAAAAaYPEBFpeDlbL YIt0JCSLfCQo/LKApOhoAAAAc/gryehfAAAAcxorwOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr 1uhKAAAASeIQ6EAAAADrKKzR6HRwE8nrHJFIweAIrOgqAAAAPQB9AABzCoD8BXMGg/h/dwJB QZWLxVaL9yvw86Re65MC0nUFihZGEtLDK8lB6O7///8Tyejn////cvLD6yM2VTk2VTk6VTk2 VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPOSt8JCiJfCQcYcPrAWlYWP/gWVJVjYW/IkAAUCvA ZP8wZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAAmsIAAAAAAAAAAAAAssIAAJrCAACSwgAA AAAAAAAAAAC/wgAAksIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFcMAAAAAAADKwgAA28IAAOrC AAD4wgAAB8MAAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NBZGRyZXNz AAAATG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFs RnJlZQAAAE1lc3NhZ2VCb3hBAAAAAACH+50ry/loKwSUmEGzn1EyAeEfCO8FJne3yUKefpBY Qvy7FuqpLhH8q9GmyT0VL5BBPHt/FqjHjTGgKOsh4ELAnXa6Sxh+22Sv3YEzzm4TMIPbOjLF YSCcFWynbQNwb2sqSbWxE8Km6af4UXbWD5dEdzhsUXWLjV9MQWiz+KUZT/OItczECP1A2iul IjxWaGqSOYoBRdzOzEjX6NPntNYC8HnEZ1V7ayqpD9gJssdWfu5/7yGwwLKMUdjhplwGygtY prRi3EmikEhnaymGwvE72ptXwol4GnPcU/jQkljZ79cey9wC+ctqlCZ9GLb66LtUI7D4tzIV IUVmgSEplthDnrh29QGqcPTANQHXWatAxFJN4w2qN5EV76dhFya6eQMiA1Nsc68sN2+rtphZ belvUzSbbeNC9QWY3hBs8ey2BBddKmyQ4i5BamjdMktjsCULDcKXCGrJOprwXOLlDjCYYCtV yqindHH0gSRabWmaOeSOX9IA+7viHyM3IoE5HwOpAnG5xEbK8c2i+mfNAC2Hs0d5/uR/zpCb oTHHDthxfIoFQqOwqfNhmZTMeROFeaGhztHim3ec7avQtGtLBEU8JnPyQjInaIwz46mOjxqg ddc7cm8uJfeB1EgzjjcygKWiNqvDIKk/qxoxXum/RDiPNhYs2kQ79IXKpPurvVSc0uqcG2aK wKjMEm2Dj0WTzDYbu1dw4NlrpaCyhOzrUQYuSzS4CPRYLv16XeGbstABzg3GSU3iiRirla5+ XKDj/jgO5Au+DXEpe/8m78xsz7zd38CzLGA45AMZpZSH/5Y5gtfo1bXca8qqUbHzRI3Gs+cg HtD6w1e5jt5zCCBxZcYKgk836dHBQWyGQpfwPjxuyfMDr8XE7Rk1ZSh34S2OYhWmW5b8XCIh 0ES/1qXPmKcAdlcSK4tm62h2E08/WSlEXtHmLbeGlED7zWqqGAFVJQbbfZmMgIkP4n65LiFh z7/p5ziLBSa8N2nUnD6e0lWW9vt5G7x3jWe/CTj6cG9ERx11oINoOu2rQ5HkMPPApKV0zPYg YttmP52AhG7XglcpTOzEJQqyWg2HdeWac8Ba1kmaYl+/7sSfLcb1ix3FDO+HAQ2jySGdmfS6 Ue5UOlre+HAYQZQh/vNAYKFkVsxTTr1mhN8Vzz7UW0FKXSLZablvomYIOHAwv+5KeICfDTyz jN//JkiBO41Z+g/8YrKMpmsR74wx5vZhj+7cbXOUfFIGDkHbRPjtU+9BTGQwGFhFlGCEUMlR L//1lVFUaNXSzk//41cIrNMLeVt8AdSzb5GY4VuDKY7HwRsBOofuYhwZEVfveEGgIoLmyWld mMtV4suIDhh9ENpmyIUG3Fdb6jgONiHqlGVUiYfFMNdR/8Wi2AMHTuKeSeb1u9sMXV4V8fTy gA6g5CJud+doobCa/wU+KVM/FBYCnIuTB85G9zLaNwKkwXS/ZwCQsP81olZVgyKcsKSIukqM t2ZLJmXZ0FTiHbbElnt9IQzOm8yBrMTpwZg7xPTzW9btq/p86PRXHoDtwjc1CtO7s7weMoHu LW5Neh/EHphjVHlP7RwUTuPf0fO60DjwriU13yXZdk5Z2NJb5BSoPGaCc6QmITcyRsXLNHIh xtW74w2E2QewLAXpuODlopVEjhJJSIdo97/1CoUYVwEMlDlXyg5JhuTGsBuaY+3im/8Z+/GS Siej0oik+4U30Ig42h1/LT16X7wIvxZCBs8O8zCfoQQ0Y/z0bbJrwy5UDwobLtcXcMz175sd TdjdbUwEdbsURXdb1kfk2pqvF5WaJEvXblSweNMnqw/cwV2ABWnSd+sfYrWsm960RSsl0YBV ue+cEf761CLvW48M1yzC5KvG04MbsRMgSaIGzyd7gZLvPugLJC8jnyUEble3QSMZrmjHPZHM deZ6NP4Y+lYdy4xywrm2KPomg/XCIiBh9BdCPIcd9BchmV+Cesw2IrruIi4sd0hLdi21gOeW cWgRsNW7yWoop8C1Fk26kjqL7TzSW8rKMjjxxpZGiCoCP/mAfx+gNpt1CixNwm05HVM3gbI+ RSI9XNvkkAu8eFtoAdPr7eV+EZHhqdIkwG61qI7FkAJ7eM52CN8FbPULQOFCWL1xOejoepRn z+IP3lqWW1OXVcws8slDTmDzHeoWq+LVbDU1Rqu/SiIrVyCub80+qtOGLG+VfQcb1bYnJ2WF 64bm7G0FUDNheB7ngdW2W03gB+jkBqb70xrz2JKgueMOTlg+Ox5DVM+r+N8+stLsC9UEI+Hp b+7Kqqy743XT+bvZZuzsJZiciSdwejR1dHfwU63VH+B7F1xX1AZj+lJKN2MAYnUE9d+ugH2D ldYmesi6pewsfPZ+OC3zJ078TQix1AQtlESBWgkTluC40m8KlLrUjBA45tEkCdkJsBQJevWD bulqGsxgrX6kRGBFcGmxewxC7cNQ6gLOCTOhjmYHEK/RGVJxvCuUTqIDu3pRxKdqv6JtP50d lsYCu7oOD6Niyde46rBtVcssETLUoZ8anpUJSWjGejEmFgG3v+3labjfdH+YS5/9msnI8jqU W37EU3gS3HlHAaYObkVbVkq/DK+P6gI2QuBKmEBA3e7UDQtTNWuRMsDPTr590M4l+zhx4sYQ LTQ6EAm+/4k4mPR56JzOKQT41wwoI7OlDBU9Uz0FQQfW3ws5SxD4HukjnJ9sxCyMHcg99EI1 jQcA3VvSan0WOG7eoaDYcRGBM5j8GN6jBYwWFtnc9NJMP75j5dDb3jK0MzuGy988Lyn0ptJN RBf692BamuDp/gU6iyLsjcbFx/Q9hEHnEJ39LtAqBtOuMCsw3PXsl/KYbymphNyOUlj7T1q6 hvoF9aVRIMoLg3sJYpGbyU7Cdxmx+lEEyso7sH051C7v58luYt74Sbl1VgYu+Ig+qo1GkLNk bMkwZG+zP2cf5l2FV0kuXutRaR+aIcXUgoxfUbkTVaAvwckmBmcEPo4XIXojcanH4P7mB9TD doczIJ1FQeSAAxZmSJonQ7qnjiAZldRciwHyEd4kPCncy6+B+M8fKn38q/DpVTmmj/Ldxy9h y1xqOr4f26EF2jmZckpJ1YdVGIyUAN9E64AKtqeHGKhTmV5KG5nuwQPZUp/naElESeJ/f1+6 375msRGcRG7GCamkyvDZnbYh3B6aMm0U1En2hEChXniVEO13bLjzlW1A9LyZTHtGau6o5diT pNG4ixIzd6ilspI6yAxCT3rmE9WmICEI6nxGUGDrxjVi2JeD8O3AlKw7/D6+DkCLGNc9Ow9o RTfMBHE8OPCHkHDI/VV8xCjmKV/ASdtjBUvLqPFerMM85dKqIh7x0kZxp6tWGGWliPiO1yJs Qg9emkPaBIdRGK147p8TQvcKESTGUs8N3lmxNKeJSmUn4hoTQDFnMsrrQCW1+eWXW4EauNlC xIgEIn/7F1Ufbe9JK6dXKjPYLmitr+fb3koDLZbfzjtgsEKpIEcgAa1bVf1C98cKnOO5topu EZQjAQrVHQrYzDydeN6wxsFlWY6NBl3DeBIHrN6dQoTf3jiDOZuqsnxwwkv9YBKAl093LpsU OkKuQ47lSltfLnZh1qkdxpwSFDcdZWOL1UDoE0GhyOeNvBQhgNEkWLn5QyHCS0I3X39pTt/s CpiBue0swvws8QRn6u3XuEE3VbcPkL0jolT3Fd9YfVZsdOUmLGSB3KXoi19dI477Z2gkU5K5 /ER3lWwD7z4sNPh7+NIyEXGaB32yO0VRDdvfDn2K2LKefui6FtNHOjp2u36AihUMgARlset0 TL/D01rcfKJqxjtRkcyXNXbdN62hBUGznaUeeQyFiaoKk1RMIQhQyXEXY8RgrRVFiX90sK1V JncsqgnkCFhtkSV0E4EarSuK6Ib7RF2VMpty8eJfGTYp2y2u1HU/qccj7mt2VKdTufwBBkih 1AMCC5P17xD0oYLcjW3q14lOoqqVvqqXzZy6FrmyWXYkZTOtIVmMtW48NXWvmboEPv75W30R KHEA8t/ht1Vt7WiqLJiAgYhbJ444AOVgJBSMQTFWVJWaniQV8PB7+gRE3pa29QIOKqNpwvQ5 zrF+3OeTPd9nX8/NUa5JmyrbfrBxA3uMNXBT59o0JifS12ftvpHyaOGKt45qBLKe9yAxKa3L x2Ada9tiesO9mk4SLsjjOQsNRvlpVvSnBuVVOgTN/cAktBl8zalBgeHx619psRNmCE/fVdI/ +Rnu7BWeHmbktIH2037faoRkShnkPkepZslrfaLqNoY2n50t8XG+bAiRspM6HqKP+6SLzM4L mwG4+4EPCACJmAoo5oUHn/eedo/md+Qf527YvuGi9317oX9hEl8q+Prg+I9Qw3EOdaKaIEo1 fzqzDiUROK6xE7xF/xuOTl0M8rfZFb/aNJcTc/mHVPdZtXLX8TGE4Z2/mXaenKyK2miom06c RlfBF3BAKGhRldsYQ9xPv5cOQeMZwTR8PhvjwDwNnaOO13Oh7LVQZuoh21H3Q/ApT+jqB6v6 LRlBohX/akhz31LpT4Wzlqxlt9Wcl62KApbKcgSC/LkY0+5IUNqNK9kizH1Bps2brtKEIaXz U4aKLuFt+WfDAgikixaNvezLKodAubvWIu97VjKg/gkRpLVNuKL4WXFEXmTWe8U3y4gBn7UG VjW/PZUyjaQSiJexKp2DUU7AN/Hcz5nawHX7WrJ3bmgd9wN1Qiej14f2P0cAqGqLbu5rpgzd vV4cE9ZcewnAuYg5ZMegd/92jaJJ8LM8fQ3c+A2vjiwdY4uFN8RBGbcVtLEPL1jNYJOPJBdC eFNf2IAUDS+GYYRtKmh4BMXfjJ9pUDqaYr4LXYOInY/1hm2FAnlHICWDwOs4gCN84PsBGSGc VLLpgW4sPEb8u1EkN/NduE6bNF9oDnPIhqkLC24+bPD+y0bQ/VvvZGQMbsFBhwf1KWcgqkjA ejhMJlXsbAjlMwkhA44V41AjbCJ06+j36svStsWWYdA7FcImLiDZmp3UGMAnWRjQ55nJzEW5 DovNjrV0IKBQYNFryGJgZvc6H0bfSOdg3Q7RmI1s+xgyK5gMUdvjKCnKaqH7JOm6KBRrCRcS w/02nAs38v172NpMJu45Dqicgqme2pIC6w7FIXRuW4Y49GY/1YmI7z/EcQ/qIL5YmnuScZ0l O0bfWN2JyK7lc62wajdB0wPlNEcS+F0vK5NmNz6bvy3lYi5AQXCXqrjX76DppADcOtxBbkWM S5uRJmee9mF8fBzaw5P3k7g3MHKwQy7SLS4yW9+fK64clkW6rbnlfTjdaJRhojIfh+uhSsJZ gd9qeRTyFsnbLmyAO+3Emyvk27NpM45kmCbZwW0mcrqSoduGBJvQ2+yBIHhSxdlQvqA/l81k 7cOiRK3LBcIAqCikpogQeMhX7+OypJ8kRHFAkBAUX+3S1C9tyXvagDjJIzWvt0rnrqxkIqsa wjqDeM6DGkawBw0MBLYgPstc8jr9rgpuTPXowmLDW80r/E+Z9qQQ0eNsNgB1SOzdIDNzkQxY axxsbeO+pGUsbfEWNxssInfyjjTmMkb2F4DOE5tzOLvC4GWdJby1ZCJZO8bXn39/EkCNb6tJ oAnC775BP3+t9jHJ8TNEZztjpHjtli6jLn3eYoNVoic+65+rx4JY8OsOsZeg2dWhT15Pi9PT q/FCMfmUk7ahgM+rMiDVG0b6DZRweEcgMQ/41LveXkr0+LytTAMtplz3x/ZWIwso9wmzlOjc /TAUi751pCFoxg7NlBQfb1XNT/1BBcjtSsPC84BglUIPuXNgF3Oe2fH4NW9e1xbvaVXYyXsT Nd0SsyCQp5RuTrQTLPYPpZPqu+CyZxNzlTA9uu3MIv3HwZORZChNxgou0HszGqlUNT/v8kFL YEuR4XugwGANx+2bES7bzbU6FQxvNSzH13eJ1koTTJfNYXUH54V7YX8nfzrVpU4kq2tzcFPk yXoaowqKcbDYoFs0Ip5CSFK+4H2q4e2ohKtF9BUl+b32WD4l3xobZ7IImRFrbYwvP4H6cFbz yKhOsJ/Ult8J72Vopk55FOQaGMUUjlD+oiT4J2lV0ynPR2Q3BQqe4ZndJNarrhbTzW1+Lb6C sEfFjzOIgP9Xa2w8F5M+9jHJpFGSWUq5pkwuuqsM7b3W8vfvHFOZKqwbq0RmZNkxDrhqoqDY zrQLSNFnx4mjMGKvjyI7phslxxt9OXsM4QYKjS+CsJiM5EHuOfYrW17prsV7cJCc/pU4SCtK 9THlwNjwA/1EM0beGA3RgJ8fFzbJwC9id52qec3LoA6zjjSoaxGQCgdgYhE3bMg9y9Nj9Z2M jNgJx2CCKPLKrdbBfczkA7Qd+sW76xhuEfHQwOEQFGlOHTFjlkq4VCANcWuqnNff6mzkE/W9 lnnVi9cUcCYgn2NGjyVAbPo4Di5VpDR10ew59weNjmGfh54Emcj7+L7MQJu9vVOz0AxUyizs ulZDwZGYMUGAIv+l2SkyYTxRctVdKfx7ru55IX2hVrifb/Bsv/EIm1eq4XpXXSwLIAmqqPqt EHjgXNWZFLM01ZsPUfM5ZujWdlJYSihje9EHAFyd7q4ZfH5RbXrZfeSsF01kCy/6Fm1tnkx3 8Qwl6P73Or5dfr+oyOmB3zmzSPgn9Kj+J9oz+cXi/ORmbb1mkavuQl+bKrJnlZ94pz4/2Fim plZmfaAdit1oRDaPT6cG+4d5VqYiyImSxradSo1Lg70RJ4eqQk9GKA/jGdr76AIxXkAjyO23 n02jpFEiqY6J+Y1pyxX+2ne2H92HTbwHJ1LuUDhtdYD4fxvtpG2Fv6vtYWQhzBk4gmitkfdS vG37r6st2hhfF9bT+cRurZrf+qGMtBQyerDltjw9nTMUUUOMzH1RfCC3ejpuonsdLi6Xg8ye aHU4Czfrkfwh/J46BTP38e+xdY9IQeSL9K1d3CsmyZW+RAPI7ZOwC4vp/3o16qqOAWjc6Fhg W17uGWQStMy3es/AZzbq6maqjGkEKAYI8iSdyeBx7Y+kW2PQ3pEVDoGciK5PYRJb1tT/Gm5C w6cY91rINde1tF3klBk0s+trn50ttzeFIf6gA2/yT15IXahQNNgRAKlZmhpQfFW9el+8AuhR KXidVT1orWOascZtfgnsqGWGUG3w4FCzimnFa4+8Fy8G1VvhjPTVJZp0WDa0W6rPgy7JOR80 QSch6u0Snph3YOwMjg4bjwIgRoQ3TWKiQWaHIo830oprMUSF7VW9JMa+FmYJcXtRd6zDjNnR GXuS2BGW4w4Vc6ReTZAUuini3cBq607f7lNNIhvigcquAZcBbBq+oiHebmaA+VIXKnzCCXR6 WVJjovUWJuYTgCVdShAkZupnTN76NVcvHXcVqyRp/h+Sb55K2D65z9QpouukeaMhDef1c7+Z JfMdphPzy5NEagYwX3NElDgQnBG2IsLukrVWKs7xFX701xijZScA3pecEDQ2pHGo9sqZStBM 2bNSMmMYlfiov27RSS7yOVAQW3D7Nwlbnv9DKu6EeCCENXkuQorKDXLlbcOf8mlDhGsSW/vE qVxpD+ejb7Vs1nyHaFtnJqypSZB4PkvPS5RRO6xJnNXGaf041Qz+13inXV064repPRmleost 00TLZ7HiNHSaFQvga0DIlWnlGCsjk1gZRtbPxFAVD19ZRoU9Z6lXiCmILgBECi6yD2UQo/Fi GbX62XnY1Yd/+BBxbQNdMFlmiIxUzwPI0c9Wj9u+xrLNC3GElhhgHBz6623Kb7H0pv1HQFH+ f+z9o1Wz07m+7odouw5erF97xCARREojoOVM/YJRw14l0/zhtGQGfLoYvrUylOv06L3n/41j XYJ+Gc3lYfs9Y3wlCHQabePSqaQYyDpE/hNZowWP32uaZmv0JyySBZVqbV0sufhSHo1eIzg0 ZU+qUCfY5hQDkbPbVw3F9kLqr+VFQeFlmeyw8NGqPYb/wCF4wnaOb8X+8tIdHXSwt54TStLX hEYV29Lsg1gtD1a5eMjsbL3TNF0JI/bVKzwSbtD1yOJDGnD2acneIV9bN8n10EXD72zR9EQ1 nIf5Yi3vX9OvX99ZNyVHNL+mZoQeRtAOpGavBRtxMXK2nmEvHHVoSzgiAV2ZEWaA5bHBbmj7 tVB78Gz8vx5mFJ3XqvpadbR8Ttiyr6yPWi6V0iOjm5mRAZC26Z8bglrj6Bd4v3vp5WmA918E rZ8UnKgy+HMWcU4rG5TKIi++6FJblZ/pJQgf8jzITE8VVcEDu/QO0ODLNGNwtkkmPLmxdL4g y4jVRtFvs17dEYdXOTbt67Rr8YLI9NGif7apeFrBRi8qFVupSj1wm5/9SOJvBHopx9k9UGp8 94omgCt24CBJgGKlCOWDeMGKuROBok6YHDnVqhbriJcgM9pwGQ3sCZnoAuMuqLH8eA6JTjPm llFevP4dN0dKgcERb17/mH37t/ztwksE8Afl1peub+g7PjUQWxXT3WgkgVahoo/Wknuq3pfV A1+taQUjpuuigqvNwIY6gnxCNxxqv27VLWEK4nylxnZsAyZHrFJ7/lAj2Me4FaadV4UZj5KZ HpkqSXz+DczseHGnQ4a+ElBAPIHD/mVCeolyzGIN7Ph8mzh1eQy9Kpnyg0M+h1hqBHy94luC KqDto8W/cqTcFfccQMQ+2isdRqCTqFshyL19zVc6cg/maPKc6nrWGx/bjmxm5nEgtvGxaQmn l87m54B6YJrNBx81VUxSTavHToCfvzUXpUY4LxTRuWJHifJ+uv9CkOeBSB1wHM5mm7SWHZ8I 3qYeCzKmcJulAD0wpv/i09+0SeaWtfQl2yV94E3c3fqg26c7JWWxhh8O0kwJySIvrhD4v+nN 9rUZjE/T/BfEDYW2AUC8bPD1/FIEHIq7drT1kLkfzyvOKbfMs5MS7QjYDWEFy0ASBAJtbcWR iIBCGfuTHgp9Y9vG6xYScf7s8ovjvR1D26nWvBZPcgPk9Pz/gInIddgR5sEVg4uiGcYFF0CK /JfLzW2bW9QEAZxSNvLSag1xzg4+gfFa6bBsuIbPq+OyHHsjWOAJoYW9UWOA81dk630iEZNC Vtn30vF9hu3rbfS3mu6/Z8pf9lGFQ4+UWvZC/GTzA77ewJFv45+cQx+cqcz1UVvEwcxNiDcK OKtKpuK2V7F1CbcojJMS7o7A0mzAJ2iY2cv0SS1xigzjjjvBlIYOdcCbclL/3QXtgseDuIxm Ed/Pe/vcfIlL4mlxlPQUp8mc/b5ghWD7fHce3CHeqzYOzJZ/Pw8+45Rh9JGX9XxObt1hqYum hd0JpHFEO5DZwliQUnMHlaoZKu3LLSovPKCeS7JSYFdaimCZ9dldboj4E+BPJRzW+YrYCvZR R3PUl37TNOVdp519Ha46ySLLnnU+JW40/En2QgD8YmtZ2+8RhLaMi5YGK6O66bTyWKxRqCHR p/ez1Kd4PBPjN74uvW0N6zLnoG1uQ9rKY+Dr1cLVuxcBRB0Nrzr3guSvhu3Q01fROLPOlIXM OzkIo0jmNwZS/vyntbDSTaQ05XZWyJc0mJFjMt3IO7Mfx2CE+OG43QUqKuGPQPzT4yOjOmSr zV2XVHDpgYBMGkthDUKVCcV7C9Sa6la+MEWukbedSD7AmoFRPA3dD/iJcGloriytE7g8OEbt nOLR+5au9D94NsU3ipixqHzIreo8p9jtKxayWfaNAszz/9b2nanEMvXmKsS1SsrVQvojKNi2 9Ndc4RhKP8pLS749Ih1dxs+YeLeVRTRjz5hMtBnNxs0D2tW/7J4+aso2yHp9BMBmnakCGLFs z2hMaeyMqRkAo8i2NxeOhzfCtY1fVoD9oyzFRSZo7Gq6zuQuA3y0unbNcTqqTs5ZFij0+x+n OxMHyr/XkiagqimEm9r5pU3ZdQMoV0Rd07agYPzkxry3ixgszr8ToAhOMjP6ucwmwTn7s1nw GAdK+Vb9HE/6HrlUqDcC+/H7olvrWK4Y5HPObCG4BUct3JvagI1vgb6WJH5IYZ4Bs0MweQ7o p85kG0MwhHdZ20BWfX+9O+T5Gn7n+cvHZNR2wThBxQmxkdPnHhMd1NG20IkRPrcgo+mnHlUv S8wkTYsuebh3OnKVi2dyRgTMnvrETxrNzqWvVNea4yA0fYPfrJLXPZ84LWTci40NrHtaxfUB ItF1Cb2dco2D5Uu/VCPw+F1AfGchXHdOBGf0Qh5YUZYQ1kfUzMlEzUJLmFx8+B+s/rCuultV F84Eq1DZGDA6t0NDy0CHJl9L+SXFJENCZAzxxAUCm2V8iP/RD9z5SxdQhviZToSTgMRizOoe Jj/uMke9FE4VSih/lP1rgAFr9LjW7pf3uWGmq1g8CmhQb2SAGivbFiYkUrNE954dKOW8+Te0 jXzfp2/6ANVfPk+lN1ol97hinqvOB4J2Ua75MUWSFL9P+hSSHMaDY1oYms+0PYC2sempnr0x Ns8A2jQsngzAHHW17/wHyUqKc/cZWuilWRL4z8WzDlz14BGDFL2q/BDNoLtRYEwtaEDkBa9+ zNQgrranCyfKCBf2HaamvnHyAfissrFd/5racy3Pxrn0dL1+LozlWKjQU2Fw/24JTGZuyJFd ouTBHXIbWgP1qilMZvaGuO+BoXPWv236tm6yYdoD+bjk0gAJCk+iJ2cwO8eJUyupZeALULrj bLrOlXoJwxssSaCjMTgL/GfzlD1L28lNK+Le5ZJF/KMNpTUex4a8iPYJ8sF9BdhnRz/y2buh soARn8WVFZ4FSOE0Gj32dROBdqXVgtbvLHsk2vArjsmqUqlcKiQs1/dt96cGe7hQN0CHFPUq pei2eLxZfrrJ4Ndcy15hifgwKBSAJMiXm4IHkbJ7/Rxlpb5ee1tEmtgum8kNRuLqc46gjhE0 OZasP+oVGCKdl+rkN6B5PSDIaq9lEWbZ9N4c8SRwY/Z8hp8e6JEGeO1sOwKRqT9WB4liw1ce DDI9csY0QVPPhB/IyoXhX+bhjV1yGg2f54mLXlzvz3k6yu+9zkPIolxWdb7rG5kWGzNuatmi nP8mURji5LYaCCFFZS4ZsAT1ZHEOk0lGtAiuH2JdZ0QaB8LTdCF68KR3IJU4DD28lxj9+A5N FhQ4nhSq15DG4bXw0gNFQBl5pDooBCab5hUD5kAFauRk69yNu+pMAVXwdyjtc/P+qB3wJ4DC tVCMd0eOqm5Ql82qe2cMdsjstlaZHmWgEIgz1raiqjFRa8kGZ/cJqisLTY3fRC4Wv9jJHow/ at/rl6BSvkzh9uUm77xCdPyC8+j6mYkrLGzvQTJCk2uMj4uLYtpMcJ4UwTHJ6wIDZgYbvgNp BVJFG1pGvyB8AUhBnT+RBlZ8mPlQ2Rv92QnZmNIOO50e0A2JYZ8+RTujAWp8X7DS6BiR9g+4 kfSVS1qjfv/y77jmqoHJNK+rhXjJnrTO9WRFu40syCm+iGEPeXW2VOfjtebyRnlAf1hAQpiK bzF8qeigATg6GW1wQupxZLfvLO5qmApwmMNFDT1TxaJMe7XbHXgO2wprEnD7XeuTeO0Y6STT uw8EfjHFR4Nk0FuXj+DupoqX7c9KrWE7sPXk//9TWIHBpKEQBONWe1DDR3is0KVPt25kFcl3 gDUIt1xY13Qd70BeceARVPxrtFOU35eoBOTvr/wcsBAlxPyNuctHMA6Oq/9SWl8+JUOV6BX0 fZwHUycRKuESZzru5qCWVmG7jc4pKApcdnq94vqG4UcqU3F6CnV7w1ZvomCx/QlNQiFvLVlG i2dGAma1AV21xUFlYzQ60IULp/Bxe4OORvDd38BnSMxFBvMjV6GpLbVKzULc5cPNSx7TIhCI ZVbAhKrSYqu79fRg2FdqDF5t8cCbXc+Fr83njUNN9ERh3R7jn2sZU7GvzOsYmXi1A2XFoS2N wbOG7ZfqNfbGaao8yW0LdEABD0YYtZzp5dc1Cab2pTHZoKHXeZR96oa6tPaC2ZfIL8HZ6ZZI Uml6opVi89nAw1BRjlNuTym0mf1blb++G7qp0lVaod9l3OGU3wA8eHGz6f1Tq6oCUdVsEk59 Mc2gjlFLTNvX8YwuypyCpH/wUyBJXOtCcFD1d53mbXUM7s9x3XNeCa/MOJ3VtUe0L0y/ihli A8MVqIgU9FAqby0E+T40jHgPF3nYHn+eVpDOMjH/5d4kbsKfGtBkx9fFbUZ4HW6JvdfKW+Zh jffWp2gwabmfFf48Lb2lW4PXwkPT5SDS7/G2dFwd8yUvTv+HMokLWfNJ+CwS/xiNWjKZ3ESK qZINDFPA5PrfFhOsCMjuNAw02sFGlW9mIl8I40mB9+L0pamp0iTPZGFUhZ4kPPid1+Ji0gzd RJYToFjiOgmZ+c7nbrKEQ+8BGHbbIyr70gG5yvV6n7WPQutIhZSdjKnE8Y56ijn7FtmB/LmO F57i6wnleRO0N4IdLxC0s/1BBeoPBexcmoc5SS+HRiDIzOqF+n86GRzOsWp74Y/HEUAv/bNI 3CoZcMTk1YkYGs3+3MtaLGQxFLEXmT4H5Iru7eTp4du9voLPWMhvtvaZr+9Wa0KK5fVxmC0m Kl+A9/R71XEWL3b2VVQNdpEh+QDLW8I6ILKr8rr1LK1l3zU9FWUPhJz7Shp3jzQvIVc8ba5b fCiCtCb7cHhIwqyOs7MYOJ6yoU4v6XlCtguR+sKFvySwNnYGqU4C11piy3JJvWaVLREZs6Oy oASQQsyYo3u9Cw2yf3pe9o6359gsMHY832qXgL8N1qT9pZzODnUymlE4945BKwyMY2UoOUSw zTPSX7+CYuw8yE7+efFdxx9GRxIZQP0FPtLqKtMjlwPS2AO8x1ZIofTP1PNI+tPQFIpoTnkO biNG+U7ylM6s4h8VvgXpNfgbSodQuJLxV/wzJs0bpesl2QnWiMj1l2PrZjych7WzKP7fOffu YscdvKKbccNjyYdG8dBUrrcrVx6YLRrMHMFEyfolk7IebHL5ktuqRdD6mreQ5qySGlfN0aMZ FwAAfOuof0aSUlvq4xvzyd85z4psrt19U2JptkxM+40sNA7oMLkrrhBxwgNhEnHXBCEeEsKF G5QT4oF9S7OFJMXwNAKq7RLAdi5jzKK0jc0FMeg0/lzefXuEPUKYMg4scGuFw4o/TB66b5ew /ZE7CZ1SfJdyd3Np3bvXEYu82Ld48zQ6uU6w9P1ENgD7HPpSI9LaGCvnK553j8HhLpTpmfj7 gZ7OsCXeZyZFaG1BbOH5m1/OdNcIf6bgJAKqqTePlj6biFjiGMvnRnzvqWta/I1T/2Qm0Hfr DY5nqKshtcajnPPAEudK5Mr2Ez/GiYbx4Em3MzdMF3i+sbateLFncmc3u/Nh3UjXTAC9YR9b NDUSNiUFbQmPWTZZIvVX/j2DlEevwcJGVea0hEDu1zSp5GjCbI7FLAvqjBCQUHmX5UgugnCq vSgwnIc+pIWHz8U157TZ5EHX58QkXs5qXYwbQB/3EjDkK3HHSHFkOCICY7Lefv1+sed4+fZU 3W9k3j8NWOuWBYrGrhrT6lO9F17kXvurL/U6VEr5ZAxuICZpGWu6XVpwfexiwZpGkGmHWc3J WJ4q8n5JtkQqK3O1C7DXVJ80X5DfqXywnG4aghPMxy3BHMXx9L9CEJqd0UyajEs+HoLYxb8j fusPnopLJrANJzZpoBqsEohMUZAVbSoVe9gS6S9Li7w8lSMIdIUHX2+XdzbLVqvUqC8kFrSI X20ZmxntxkCoTKAqGGVpCo1YrvR0gfsfNquCVm5EaqL5weOyM3rhlBG8QhMt/RJoyceU7OaH VB8BOfpwByOOvB3tdek9dtspOq5BFG7K7bGMxuHt6MTO4ZP/bsby6fKnLPx6mt9HAy4rhsoU MII9JkmQqUzywBhl8TVuk6DPAPoOpAwxMUm8yleaq8UVs3OYA2sSFzephT+/K8SKfNvSlbRX CoRrsjRqRbweCt+M/Wc7seB1muFb8IRy6IrHBd9tsy6evZZUkfdDkr4e6oCU4xRuu8SqeTB7 srzwLv9FwfNVB96hk2dKycFpqs/dFt2F/PpYI7oTl4h8m0RRUPQdkmoKBh4HuKIdMGmQXsUc G7/68JumfqcWLgE2t5dDyZ/JLmR2PIKF+j24kZmwY7hVZIvnL+jF6Wb18xx4gVhSG9jpgrJR vb8TWLPYtszZwqI0YQnSv7CHxIiVXag6KgNS4//3bKo33/fYHpvr6/V20lj1ONB8zuhLdKk6 LMsW8y4aO5hnI7PBAMUpzsbSaXEbbpoAcV8G7FqaS5o5amJH08FYHjBIaekU5Id+STYNa2Pe uRA4Tc7Fjg7aqSA4UCT7CSftlZWha4K9sB3NfVnMzRWEZrLuyrT+YLJB3f7HvEV4OsgfNMIa D542soB1ly7zTjzzQW/DQzqHA6nDreTXW2Ce7Gc+iMlHv3w7Em2XaoTLV6Kf/McjEDvKvg9X qA7zoQKVmW+FXXAczxbR1i90+7BzGMDr+hCd8tH8PGDDSLGbRmoaMoa77hF5xejIxJbO84XF YxSQMYMGKbeu/livgTSNLokDT1bzOwh+JPRo3PSh885DJnZ4k3fOL/3ppK7QONLDcQHVgntZ n2pqskc6rfFgmhoh6uwSwP9jg+XYniY6TIsZxLGsFLvEJuO3YHGBi0h9/G1VmvDCwvt3tVVJ ntXXCqOmVE+hyWYHeJG2FpjUZNXxaDrtjQVO6hPEeQk9d42RX6hJj7jQRjnFdPdm+uzhc0vS SmZszNOdxDDYxMbi6+xxmvptkTAGntQn9IqFo9Vx+D8Rt24JueV6hdfLRkPnolyQH4Qojp37 r0LWbLCV+JfLnPAxr9D3YcmpHFwF3PpClfwnDmqU/54LoKn8rN4e5DhOziUE/GezwlMWoUR5 lFs5bnJIugNNrzMGDmDFsiTwbLhG9qER6Kv2RugC/FZy7PP4C756JW0icgk2QR0dMm58cySI J8YfLZVbu4jeQC5m003QIdQAQvdfvc7BcPFSVKTzOgsuYE+o2CxkPoe1cbQvQP87ipEAXYEP 5R01O1LEiMsYbHyKCgo8AifQAQGqrz23wvjBCsgeswYK7SsrbrzjguRWJ72KpQQ8EAaiRBrc EFj3TcsFzHp005wlEFEwm4wz7F+NTpxr7Pg/dZUrKtneE/r8wwgT67sdiIZZOdNgOnGY3J8B RjNKDUWR8xIKNPto2GXttJBQL2/wyLHn7ExjBTh3VEqwE+zMakjccbQzHA7coCUoXhE6dW6o z+7JWbJ15QgXV05ipkbvTvEAXaLe5/Oez1h/+htNPLgDz7zULO39CPvKdW2NgpYTWbIFQkeT RFgpNccxu1JeB0fKiYJaal/WA1t37V8J/MzqGgd0zg203yT5NDGrLTC/nf3SbiobYE/VoHsu 0zUj+qiX3LEkLQBOqFgKa1IqT/SHS7buije5t4x0irnUqHHI7k+GTgQyq7Vx57QNn2EgaCYd 0LbqxU1GUnwBo12nHoqBDzC+QxREKKe9YxnCRbE85TnmMwoBwU3c27dy9t8vgU54lQ7UfTw+ ElM81gDJ1XVL4Qcp5qWii4xDvgQEHzFK3TnrVfH4FXwabMofrPO1KbdQm7DUKmN2mhGyCtC/ rqbI/tHt+BXFDU0wGJwsXROITBrOUSJTT0Lg31xKWF5zB90BjxUnFNEhBL1lCHlvwGRbhqqF XGq/2KeVwV1WVOfzOrc2KBymkJ0nqguCbN+6S40HU+piGzZvp/Gwh324+Hv+dVKsIZO/oOSF blaaN05eh7lB4D85Yw8UKa5t+JpKfW0nHlwOJlOk3CHBiuKLqMwhw8f6/K9ay6KDsfmbC3LA UoQegXDINA2+25QA98toYPGb8o36Ad3nDKdQgSqaYXpT+VubUSlC/SrcJfo3t8+eEiLqFTSO exK5+j/j87m2jJ7UI0J+JgjRUMmpMzNfGRhciluxvuDgWx3aawN3+OJlk6DgzOjAq8yzeeFd 9AdHy43PWUb6XSInSrkXj6S45eC4GvsLedqmqRPjji8DqBYBvek/fUGJr7SkelA+wZwgVP9J /uDJvqCgQZBgZoabRLrTQzQlC38pgWpsvn7Sw/OH5sKMPVwywHS69lCw9csGc96vZIQfZIgu /GeYCzliSWDx/HxkmteVgVf7bb3wh8fvlRZ8SoBx671jJNUU3ivxeTjPslEY5wSJ2YkaA5rp v9wNTVCxxgLSDASTCRTsdBy+Cs5ID31AmQzvzD+3VgaflZ2YrsIZ4AqT4fJDj3RyVPRPBmUB hHz9DMwxZhDpqcVJMIv2UBpD1xr624xDr6pXdId3PTHG39bjSO92ojuu44hGPevrkLVvDmGm CiKGx9Sj34ryHyPUfTAPjJ9hkk8RmWxXJMAenXakVHLJDboG3JJF6vLKKKqx2NIKGNKfTB6s h0+iZIFfyW2ul2YTAZjSFF5AL0FNH/EabsXMlfxPYSlQ2u4LG1do/ejQimDXoWfybNcDtiKJ Lrwi+77w/ahI8dwUpaQFpbF7c4I29iFtH6GOk7PGe8xRhxXIZw7nscf98goRcWBfES5OkUMe JkAmxXkycLVNQDaxBOJ2ziOVePwWKMTYiQflkgj8M6kiOumV5BOK/xe0L7Pwo2Jqn5m1FAEa QB1Drk3XOkd2kSFf42QSlYyWAl7C1rJWsZdhX1dWIS/DjzeBFq3bzOCClwgzwiXRN+VYIMc2 dcY80QBV4V54eDYZS4A0u8cNnqPL1tLbvREv0nVbTKBe0jwddhL8yXKSauUtA8qA+HX+oFQw rHpyPTvbIICxkYyukP6r7AFxIXHDMjOo5oe0rT+ZCGTd53XMjzkfhMbUX1uUUEAxw3R3PBYp 9tDKzKWA2GCQ+fA0FjHvtQaaIKwYsC/9tX2RECRtg7q4APouvjzUPOXrFCWiu4GmQrMZXcWE BvCt9h7f3WXS//1ELaIhxNUv5Q2AgIT3fid18DimIx3vjMMrD7+wSGF+4wgxS3Su+PYFoABT NWso2i2RGMOUm0P6wVFelkiul3AUWYEsAcZT9YlfsoPZpQIdRrzj9BrkDLCC6NO9V0ED8vqM XAtGq7/YfJIA9Ve3o3FWE9+NYYLd64vDWR5KqLD3xp3pI+wWvNQ9P104aCR+VhICfZY3LCyP veBU3VmzJKQHd+f/TiuCS84RYcr+EVR9pFuwEhJRnhAGK8J2KX0csKdPELMK5y1SgmAWqFQt h9qn1LJo45ZsNGCITbOuJlE/I2y/WaKX1yCfFZg5NDZxpUOvtViO5npKNgYLZ+/Tw5pvkhyo 5oR0rG6doFMZOuMu/4U2nWJ2NOYoFM5DpsvWTYFyGtSU73I7t11TjMgL6MqwqbTe5Ri++bGu ieoWNBDDemwoOYc8Zvm5S1dWzpbCGIDZAELTfGBI287DBbPICp7A7uAehoTBaUkEw+kGPZFI aWZ3qVZIjFRnVILxmpiHqWNklh0PDHi7rt0ZhPGhb3u1re0UKJh6fvg2W8e5bd9PQ2S2QyHA YTKOQ4TWQUF0TyEiD4jmKTdnhiWjLeLrIhECXrFlN/mAIbHBXZ5ysQIFro2kQKo4F2bsVTHU mz8h9tlCrZYrV8cFqdf6Zd1+Xer9RhVvAZO8XhXGoFFe7vH8evygmmT23jHrqSGpk/BaxYyT c3S/QN8konU6SYKoRWNk/bZuvTEEWcc4AFUUHDKm/g6sRhoJJRYtGKcJcNFiDKS86Y8fWYca dZCAHXKv2A+RSx3vmGo4BZ4bv3dBIHK3kbtJ0QY97RWI2cvvDMuneSosON3MPrCCiga4r9JE IRBpPfzEralt58HDoiBr544igCZ129wbHVNDPDubG9ZUN0qG4dCsB5ZLpGU7QYNItY3cgoZK NZKmS8MXWbv00UgZKFrl0yR2l2JwlBRr862yXTrjAPw5QflIwe4eiyVZfKOnvmRhN5RIS5C+ KpnY3n8nCjdUXcpmuWjKIdJfBPD0C/FPR35DbetpAvXzopu1rgrF4IvdSdKJXaf8ZfsTkHVw GaFgIq97T4Lf3PCIF0owQnga6Nyiyzoq9IJGNupFBGl5Zlo4Sudqnlo2Ny92vgSgtwggf6Nm L5bH5G98rxZAIuuvSTrhX3jAydG22wxXkshrbRL3EhryfBInqHinNYd1CqNxmRkU6eWyXcdw tz5TQaZKn2g7eIYuXrhqmDhwP7SFOhSWKd6dTPFg4vpGl6wDHfd1Hw1Dewn5Lktv71v/nEr0 9jYMMHq8MQpct2gZIIyXFNg1ncDjb18pEfWmRpoOkDadDJzc4PM1ViAPFGPatcIqX28k+w1L yIbxoiXMkPReEbBD7YbMTpCiM/6Tg01SeZ4EkFjounck/fgVjkn2XD9WO5Yp+8adwn2fV91T DyquRKXzH7zzW/BThACB8QYfsoV/LX6sjfGYlbei66/xL2ZqHIcJ8mkW0Itf6W9GDous5NVe f//wHqw/jDODL9IwexSFUgcyDg3JzkrNa/Hp4drW/cch5YpVdTFmHrYl1KLNwizS3gHGnP1A lsAEeYJCiYWrAgm/4NHi2wYhFQkGEeNOAQp0yHm0ciAjSZVyVquGGgg+oKbfevpWfUYuhMbF XcL66RMiELNwRPH8QMA+RNatpxn12biOfDwgjWTbjpu6cht2bDCMh8Q9k1x7jimctcjBiRqd URrw3XTbRgNFLTrgrSIYLP+c/bcHNwzOP+gS5yMOS0BRJ013DXyTnw3dNeZYlT43h2xaEE9/ A/xksIgyCv9/U4UnAky5lFB5yt/Ruj6jJ4V31XEnyqXZrhbk2ICZniWRxIw4BvOQ4xh3VkS5 k4kNRuvcmgcLsC9sGrcNhHzv5+E9UV8Un547p8GM0wALn9ebwx0o4bC+r4kw3MGwQPRSwXHB wWz+JY2VnEjNicOrFIndCMDpWd+BNPTAWG4Fl6OsEqahYIhcxJVPlGlWJ6G70v42PZ2XesMY n/6473PhNDpBZ/Dx5SasVsTlUOoUhrUfvT3jyBUaEbSpEabJR6A6hk19QzdHI2T4VKN8EqtV 7FCZIY0PQyDwEKJWdyEt5kmarLKfOnYIruleWP1D3ENfrI0H59vbaloGT290NK1jZec57l4n FAI8jgxhR4q4U/FfxJtoHeUNwMpFp78fRMAgygCPWUhtfN35dh0RSaIcv4WmtAF6KFPUqvxG Z64LxQTDtMh2gdOyXovVzfSi9CVCL9xX+rmPgyTfJ7p6S8iqIxRBfr71p4tivqlewNTABdur bMcu/ajkieVmEHPrAv5xnCqHD23JF8enueTGS+zFdFF1XYIfPE0wGVPCnMq0MqQ9bahNb3pm bvlBB+qZZ0EDDuj9U0pu46pTcREfMZsEo54h1/3ljfbLpdQodgOL8jFdJGqPZI8Xg/tYWT1i JpFIzAjoDLMGlAY+N4jbgsq8vU3MjRoaJdRhDk43wRGjDNevmuRAfiNjCwH5FJ4JDWbxVM1Y 5mMmKYiNOTllBGzvmh9gYIDQ102qB71qPt6lniwCR3rue+FFi4v3ch8Jo8y4PP866Ud8G4Po W8A1fBRJY0uWeV2jr7fhnq4xWuQ+5I8gFIesMDuHGAbJT9TdT9OdaEQEkxPGVOZRFDVWKbqE viHCWSDkGSMmhzIuGcfwiGTara8zWnXHlDxaf7ALEHhTp7Xnvpyo2ok4/yVcvfcm6xAP3fqe 5zDzB66Dspd02sZNrcl38QeaJF7Mmd5oWz2B0Aufl1ubfegDgQDoCed5x87ZCCqJt9OzwfIo X7Y3b4hKX1r818CAXUyGF5mrSjxqZhmwWo8bTFutbLv2i9GWNVGLvYmGE8NdIT0//YtOkOi7 1I2Qq2I7a/r1JbbIAflnLf8r/rSAelhF0TMBSY8qJX35xuGOX/BMWHKo16Nsnioegsx+PaZ/ 2ps4QvhiEm6EdQzQXD9HTAAFeqEiKsTHEBHduJjzxFhVR5k1l+DRLlx0Mbb/uSqaTyAuCOBh rv42W+Ia5M9htNmsv025C8eNlCIPN8AdKTeQGQLoEyr5uYCqR9doIoUpbtM8wnnOL7GD3vCh icd4C8Rw1DnFqI3oKF1VN8mMGQbPLZOW813N2AXowaBGQ4cf6lYJ/dFQrdSWjVjFTeLLnIvR s7Kh/22vzCyCgFmiQwlTJGNAXWjnAKrEm4727TZPnTVb4KYHEz7PHxbzXaqgJHGyyanPg/FB GQ0dxlFWw+n1ZimjORDE7nbxNRB593z95ujIKNVMZVJWKgWXFDgasndhJ0NSsuUqrTg4IV8+ EXh4krrjO/O2LGq4Dhwu6FJv5ezWRfGlXwjs8NnYQ2Mb+wpCB2pmo6X8Gy0hW7AbXbRvHISQ m/eRakEoz6Dn6pcbdAcSegXKtdzXrMjTxi04wGxOozubS5yv8bPuKM34PQB28ArvccpNCXJq 5Y4EPtk0SKohSUZIAo+7EaUjI89OtI8iDUntHe4KbRCEgp6pB+yBziAeO26EEbYVjng1BHPT yi3P0n0LmU6hYOYtGuoRpup6uCZ0svWzYJKbaUQ3eEj3NJ50Sn0ZO9l62NtgI4f+3b77arEf HNmZ+c4GdwuPv75YZC4ybvl/oWG7fhWwo3kfsEmJvH7UTuMQPUOMskTMmDXKagz9VWfhKqaz NgH8D72IBwU/sFDS08buU0H5pOoHdi8aTt0EgMMD7I6kMN+zB9tZCpurx6Yq6LMPfZDDW/Sv 9FMhH7cj6yxRD0FpFBwuat50C9yYKp2vvGUJuwQWSAO0z27tgYJ7yZqsXh1B59ujHGrKIRM5 lcrRAgluWjYc0KWMG+LmeqMvk4H6rSlQ/CeQxiBkgeg8lOQmBAXgWCZoCQ835P78zHL4gZmD ZbBa6uT3pwjON7P1ZIarGy2l8VdqBe3CLOqzxeWe3W1/77V7Hk5ovZCnZjhoxhZkedf8TMKa fGNAHUporBBKfANGqpbGm6WTfzYNYHAJMPg7avF0JvmL0t/F7r07h7OQhxkRKaPtjYzNzFcc +OSrR3eR2NjGIeQsteAoOnce6otz/U0TcUSD0dyGnv6fL70QChWPb9c6zwBBV3AgNF6tGpFk /ZJdR+yjbLq+RIi+dLiEOswIq4GABeyRG/jJvxUbFzKj/DXktSM4JhMiYoWN8ZvS2mxaQRJg QiRO4UGpD6heegeLei44VB2AJuKPbt6mHafH7yGnk+44o2eSwwG/eASakqj6zTHjExrFbJyV k4mJUxLaUV7QJytDsB407ubKOWW/YAgmbqiBlELcLp89hVDxIjbQ30C9eaDb53IazUsiJ3J7 9sC44sX3inH3OaCMLo8vpfm9CqeU5oVGRZQRE+FS86UV93KqVznGs5euKeHFBtlMKJczGI6u F45IxIjQODYJ+uekcEe97ifHDJdvUM7hauVEpo9SBGvtw4fbHh71Q7r6ywWqcE5u04ZYhhY/ MgUYQnV2f5aKanpP3r+I/Ll6+qHCFaGJhREZksAhwjsez4mtwqgWi3LiyuIS4UmQKrYlxiuD Qp7mY/2IRjfLiZxDL6kVwYbsLle/UttAAbhyNU93kzQqhDZLCxhg/DYS/CGXCAwpYzHSI5Rk PWJvcBRafs16LLiKN6lFCuMKq2vXjKkWNc9eQYMDfMX+Xvq+xsQ+bymCCbyyr1f7DAnSjzNH Sr8723xOapIWaHW4F5dluhVrAEHhduTXUxFIU76wpCqLkLdu5igjrgLV1Z4lVxwM4DF3XCu/ dZZZL2CUPGZeqhhN8nDm2RXt61iWNbUOxvFj7/QpvpYnuEuagYBP94vHOv0VGC/5Y5gkXtqU J71IXW6WqC2Fw6TFzKgVZ+17+f03/r31dNTPHlf8FctPNbMGA3h4EmIl2grLWEwgVKBktEKm B3I/P7FCgg88iBGTawFUtVyS+gYiqyrgsnSDxqc1WB+FPvJeyTKi5JNzegdiroNAMT6VmvIx AH7NOdcaZ6homGo6LETMXnaSb2Af/poy6BY5au1daRO1Yi4dxbBI08ycTlR5tXoHOqArv/Ob Lv+wQKevIIV62f6tLH7m+FubXLtn3r5Qe/XR2PQPjYvQ3w8wLzfJm2Pqqx8JOT/RcUPcy/Tl J70QDScMprLqcnXDQOAxVZuJOTLuO+Y2uFayOrdlwjO6SvzEMnxhr8lPlqQNho0jETHaGkaz OQk8RBMEgNBwFWU87vB+04u80rS7ru0oRtslTzwpxG+YX9gujLXyzUfwop5F5PM8m24PadyQ 2HzYcg5Ce5Yit19dqyi0UHMmY3LtfdjWvsci+A3miSI9k+a/OWHOgdg8UydJgCnA4R1GLoGl F5X9uKtf3GwxXSxICwZene0JkW9g4FoKaRttGJcVHA96cJ6dxCAvhtFQdddbKySV9sf1RmKv y/jj/8NX3NmSLQPwD6ITIHBVmuqXvOjkEuPnWtASouwFnnW1jFfA+VmpSEjwD4zT5mVD3Brm OhsMHP1cSM06DwnpkEXvgrtuuLzrMDkeetKcT5WedsuwNhZWbHmqpjip73CtRexcKGBRYPAP 5vawjBDeOHiGnP9Fuk1J+sYmjnZgH7OKYPJoKl51CYg0szLX0erFPpKShqpnTgW9Wt1pqYw+ tmPSL5CbTntTqqgXIb4KyjUxV4tAkozbbX3QmFUNgquEeJAXzGPW+4mKvRFiN5m9P+OfEyT6 eFWUHtpNXDegfD+oEz6IwII4s8AQ+n22L72+X1vCGdpxwT0cyZbo3uEds25AIMqHXaLyQkqH CMqlgK1FffOpfTXOCnrImUqPVgUb2VX62KOOiW9uAXUSXk3Hpzid+LRr1DZ5asv6CScjOlgK raRb3c/syz88Yyfx2Y6PqquhjFUnrQXXnKL1baVEbMnHja1a+BEoPKst0J3Fb7UV08AVgTZm RIwF603OfWASTiUmYXmn1rTPtF+/pHaZnpM/3N0bT4JB3koxbKUGRcK7+7Daqnc4sfZqDGiY Rk+ZxeMHM7QyRz+Z5cf+Yool1Qcxl/eowk4Tf1OTi1cNKMhrkhnFIpSwB/OntYCRebQGuF6A aKC3dLxszwDDvAi7xK5sJso9WprsNsy1yaJUsmvmC7uLpImTI2HAhOEYeknKsOt4Cz6RO3Nr o+NiZar6EfO41IQcVYu+P6MNqDNajUWwHuXOoR3J3o5oOesp0qoVj4l+CDIf5eOFI8XvBjNO WAE7OiKbY4QzmxfANFATIRsggJuRnuMsyd7l+WgwKGESx8YwN34O8QetXaRpEfxBvIiy8M6t P4uf+FqBP1nAFZvW2md6qu3VHMfIAKwdxErzT13WnrFMHoqVTLF1TI0GTxVg1ual/g1eufYU Ys1wRYRkEXERJ+xe01pVG1n3cLu9H3MI9+mqG9CeGqEbQSluYVnHxC7a7/fu0dk1+Bgud+4M UliBjh7TMtH3S8Ix/sxrz6KFx6LJD4nFpxVJHwS0gL4fMJnumb2zA61Kx68gYDO7eeszSCdz E0Sek7brbUIcDej+UxgPeVfx7XLGxoK4yv30WibwMFrqWMEUoE17TRJG6fZtoB/REHC7qodw OYxdPb2lAzhu4dwHLGLEmAHHTH478ujdvgo93BnUBUOboLJVGRj+1IH+w0v08BEx2X7P8V+w sqeLt3egOowP58mh6JWS1arbVdb576yfFh2rGNNfD1hPWUKXgtZCb6dnR8X/dxft9tQExfgT QFlOHY5d+076HfnI2lXujCdiLznyii1A2DyiG+WGwLAgBf8RagOQjdnc6VLgzs8lsHeWYTz6 cEwV9X6dr8stATF6qk642etGr+EaT1BXzzGvZKacBVRlYBLEPG0MlRbf7LqPJWW5nSM6MJlN 9Vi0qW9OLW6LX/IAeUQb5uCkRFBQsMkqO+F5sA1Daw1sg03X09kCKKUUyK1d0n5N5ntCdT9g iKH2jJDRXuU1qXZGgtuscigSNvR9yrZ3jawci8czDGJ5+FDVvmEznllKh4CWgecS8iqsHVfs x6Y5co6eSxoLq1/3TlS7El/68oZkuhofLdjtOKLYhJH0r4t6HHkLCiB7ZD0gkC/vWHkiHu6L i24SCPDULYmBLHCpbeH//qXWfxrXxlI7DaPMFth2NpynNwTE8TUXQblRJXJc2C8LnEaiVhh5 Vj7DMBBG9l/x2FlFyGuMHgmJJklJ4pYMMCA8a2D87cecI3YGb40yRswdG4f7RJHqaEX95MZX +Z1Z7qEP2b6AGTwXn4D8Eo5GilZXWMhc6rtV0D6mtpwkqi0mQ4u46klCkSghSEnX1mwwA7eT NThucK5lM4kplBL5Sr+5faGhIqbuPpHUGdU6b4ntPzG82smfzX+Yby+8Tx9q5Ur6W982+4ht obsgs4k5zPA/991krmi1GCAKqdcQNRbrHn2LSOx5UwP7RMGq36oGk9WFW2nj4xRlp+zlvQXw lbKepx4Lu2Vn9eEXkP99HsNSqcxkJUchviENN47xEaGRJJzuVesIf4vMpVrRlj2auzFHz0Pz z9YvuM0a/hGN+h/iRgGEpC5OPqOi5lPLBPkdGLHAPsVid8mP5gjf79tg6Z5+8y/Tp3I2HXgL D2QRr+rTBrop+CLr+FusrxAxiXGLa8oUKMcppEkNd6B7wRcEYhCbzPe7NPsS7sQAMnFH2jNX kIXfNyySuh6bAAEu0mzoXsurVN4nzZrvi0Im8xh/ZxxZRGg74POhlkXIfaSk0hQ7czYk47qO DDu+1vj0j2WPQWVY00y57nC+kY9L/4TIe2SbnLBMCTKfb7vytvjwL8Cu/FAvUODEs/6dE01s H7KEM5VKueykBHJmCSsnSDHAQO2IV+k8djqb/XFpQ1GJhgsGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAAMAAAAgAACADgAAAMAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAEgAAIACAAAAcAAAgAMA AACYAACAAAAAAAAAAAAAAAAAAAABAAAAAABgAAAAABEBADABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAAAAiAAAADASAQDoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAALAA AAAYFQEAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAADYAACAAAAAAAAAAAAAAAAA AAABAAAAAADwAAAAQBYBADAAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEAAQAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////AP/////////////////////////////B///8PH//w/wf +D/8B/v//B/7//x/+//9//v//f/7//3/+//9//v//f/7//3/+//9//v//f/7/8H/+/w9//vD wf/4PD//+8P///g////7//////////////////////////////////////////////////// /////////////8H///wAf//AAB/4AAAH+AAAH/gAAH/4AAH/+AAB//gAAf/4AAH/+AAB//gA Af/4AAH/+AAB//gAAf/4AAH/+AAB//gAP//4A///+D////v///////////////////////// //////////8oAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AI//B3AAAAAAAAAAAAAAj////wd3cAAAAAAAAAj///////8Hd3dwAAAAAP//////////B3dw AAAAAAD//////////wdwAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD/ /////////wAAAAAAAAAA//////////8AAAAAAAAAAP//////////AAAAAAAAAAD///////// /wAAAAAAAAAA//////////8AAAAAAAAAAP///////4iIAAAAAAAAAAD/////iIgAAAAAAAAA AAAA//+IiAAA7u4AAAAAAAAAAIiIAADu7gAAAAAAAAAAAAAAAO7uAAAAAAAAAAAAAAAA7u4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////////////////////////////8H/ //wAf/+AAB/4AAAH+AAAH/gAAH/4AAH/+AAB//gAAf/4AAH/+AAB//gAAf/4AAH/+AAB//gA Af/4AAH/+AAB//gAP//4A///+D////v///////////////////////////////////8oAAAA EAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAA AACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAI8HcAAAAI///wd3AAD/////BwAAAP////8AAAAA/////w AAAAD///gAAAAAAPgAAO4AAAAAAO7uAAAAAADuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA//8AAP//AAD/jwAA+AMAAMABAADABwAAwA8AAMAPAADADwAAwA8AAMAP AADAfwAAx/8AAP//AAD//wAA//8AAAAAAQADACAgAgABAAEAMAEAAAEAICAQAAEABADoAgAA AgAQEBAAAQAEACgBAAADAAW0GyArEaCJfEcjXrBlqi8zmy0SVr8fSxmfnm0dRzx0eUJVRlFw Ar0rL7gBcmYIVKZlOwQPwaEYLwSAAbyhrJACtZCkZLEqrIlMWKFmWk2FMy8SBm0YRjq+qlOJ jFk1cEyWZFZ4x8GBvpZdtJoKSqJ3hr0uL6F4K6p0W31pJsOjJ39fBrYtnzeWXlarx7m8vzEb VJR/njkCRn6fThart181wG1miTojYIWcYZRTdGVeuXo0izowF2yKdCMNkBtdn5GaoZg5PGmc FBBcGqZStceJjlUxqZCUWrseCC8nfFo4BpdyihqYLlc5trUbfI1ZVbOLDnECIZkdxSVrAr+f HpHEMEUskG99YTm6DkqXf7O5NVxwpnS3l55viGcEAAY8I4knqT2Aw8WTxMK1wpk2W7ulbFwx VIsqQCqcaVC2dRO8dy3Gsm6JcJcSww10mnKfHLsXawVifnlYQJamoqh8IXlhdbO+Jpdrrx8K tUldTAZmOQGYUKEuR3sTA0xUaCN6BFsfsV9Jfgwnb1VjARhZkjazhjx6X0ymD3MZqbg2JcQ5 vV9hXsUhLXRiYHWKdU24txUrbbmJTUilfZ52ZsJfNp2MjVS/AXYShMSTgxw7khAqdkoNe4q4 K3y7p4i1E5e7IKSFfsBiaoOns6qtdDOxGyNGaoLDpwt/xwUyskaKgLE/j6Exa3ABrzW1fROV Ch9eFJCNOUBsMp8wMR2KdUx9X1YaLHmXVFSFr2vHuLSokrlsR3EgwTpIp1SanzWwSRNnvBt/ MotIcrJJGAl8okqLnUEvU4UzhX6qSHt1YwNVQjluGla4W5SCSCWnACSbvwWea4gnUGw/iq+C eA7AObhjYi6pfXMdAS6qcYYrOHZlcx1qQ2IhKMNyt4JPuL5lnoM9LEKsR7OFOhBjWyc+dGAW YrkgasB7WYi3YGLCWwFul0gExFl7q0EkkpKodUp0vTe6eVwjxSV8pZsGKCQhfTmBklBjPrgk g4RVnj4hMbxqdwSQrLuEQ1soSL+FgmGRhwm+TbkHBAhTrZbAJK5YaVlmmok/v3VjAFBehq5+ ZyTCdAA4fqexgFZCMTxzlx+RX0KAJBYFdRZKT65Je2UKTMWZQYI/cYgjesNNfV8GO1fGNWwg qnSGg5lvN8don3guHAGhQQGSmq+9GH1nhQhdDbtSqaZfhw14XX9GNQsjSx9Tdp9PCV6SwmRc R0CaNsRup5hKhzMGJ1mknpGGZVo5EkqNES0YcESRVBO5IDFHqkOdJk9XnceKjTVwwlrDcr5i HFW5WTBVdFC6Zn63SAyfS11fgBfFb0q0Pq56fFR7ikFajwW8lBl8OUB0ky4uOi8eGzY6ABZG OHNuChrAeaVoD3hXbK86SKw= ----------mphahmopmlygykjvinpy-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Oct 4 16:31:48 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15965 for ; Mon, 4 Oct 2004 16:31:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CEZEK-0005Ya-00 for ipfix-list@mil.doit.wisc.edu; Mon, 04 Oct 2004 15:14:44 -0500 Received: from [200.180.242.22] (helo=PENTIUM4.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CEZEE-0005YT-00 for ipfix@net.doit.wisc.edu; Mon, 04 Oct 2004 15:14:39 -0500 Date: Mon, 04 Oct 2004 17:14:31 -0300 To: "Ipfix" From: "Plonka" Subject: [ipfix] Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hczwotckxtlzoioevghq" Precedence: bulk Sender: majordomo listserver ----------hczwotckxtlzoioevghq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------hczwotckxtlzoioevghq Content-Type: application/octet-stream; name="New_MP3_Player.scr" Content-Disposition: attachment; filename="New_MP3_Player.scr" Content-Transfer-Encoding: base64 TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAASAAAAFIAAAAAAAAAwAAA ABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAA6CMBAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAVsIAANEAAAAAEAEA6BMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABgAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAEgAAAAAAACqRgAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAOAAAAAAAATgwAAABgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAANgAAAAAAAJ5CAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAMAAAABMAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAA6BMAAAAQ AQDoEwAAAE4AAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOgpAgAA 6OsI6wLNIP8kJJpmvkdG6AEAAACaWY2VKyJAAOgBAAAAaVhmv01K6OQBAACNUvnoAQAAAOhb aMz/4pr/5Gn/pWwkQADp6Ln////rAs0gi8TrAs0ggQAWAAAAD4XJAQAAaegAAAAAWJlqFVqN BAJQ6JUBAABmPYbzdAPpjZXNIkAA6IoBAADoAQAAAGmDxASNvfEkQAC5MUgAALp4I++Oigcq wSrF9tAqwirG0sDSyDLB9tAyxTLCMsbSwALBAsUCwgLG0sjTwogHR0l10ugBAAAA6IPEBA8L 6CvSZIsCiyBkjwJYXcOai5VsJEAA6B4BAADoAQAAAMeDxAS7JJAAAGoEaAAwAABTagD/lXAk QADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2V8SRAAFLoDgAAAOgBAAAAaYPEBFpeDlbL YIt0JCSLfCQo/LKApOhoAAAAc/gryehfAAAAcxorwOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr 1uhKAAAASeIQ6EAAAADrKKzR6HRwE8nrHJFIweAIrOgqAAAAPQB9AABzCoD8BXMGg/h/dwJB QZWLxVaL9yvw86Re65MC0nUFihZGEtLDK8lB6O7///8Tyejn////cvLD6yM2VTk2VTk6VTk2 VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPOSt8JCiJfCQcYcPrAWlYWP/gWVJVjYW/IkAAUCvA ZP8wZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAAmsIAAAAAAAAAAAAAssIAAJrCAACSwgAA AAAAAAAAAAC/wgAAksIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFcMAAAAAAADKwgAA28IAAOrC AAD4wgAAB8MAAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NBZGRyZXNz AAAATG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFs RnJlZQAAAE1lc3NhZ2VCb3hBAAAAAACH+50ry/loKwSUmEGzn1EyAeEfCO8FJne3yUKefpBY Qvy7FuqpLhH8q9GmyT0VL5BBPHt/FqjHjTGgKOsh4ELAnXa6Sxh+22Sv3YEzzm4TMIPbOjLF YSCcFWynbQNwb2sqSbWxE8Km6af4UXbWD5dEdzhsUXWLjV9MQWiz+KUZT/OItczECP1A2iul IjxWaGqSOYoBRdzOzEjX6NPntNYC8HnEZ1V7ayqpD9gJssdWfu5/7yGwwLKMUdjhplwGygtY prRi3EmikEhnaymGwvE72ptXwol4GnPcU/jQkljZ79cey9wC+ctqlCZ9GLb66LtUI7D4tzIV IUVmgSEplthDnrh29QGqcPTANQHXWatAxFJN4w2qN5EV76dhFya6eQMiA1Nsc68sN2+rtphZ belvUzSbbeNC9QWY3hBs8ey2BBddKmyQ4i5BamjdMktjsCULDcKXCGrJOprwXOLlDjCYYCtV yqindHH0gSRabWmaOeSOX9IA+7viHyM3IoE5HwOpAnG5xEbK8c2i+mfNAC2Hs0d5/uR/zpCb oTHHDthxfIoFQqOwqfNhmZTMeROFeaGhztHim3ec7avQtGtLBEU8JnPyQjInaIwz46mOjxqg ddc7cm8uJfeB1EgzjjcygKWiNqvDIKk/qxoxXum/RDiPNhYs2kQ79IXKpPurvVSc0uqcG2aK wKjMEm2Dj0WTzDYbu1dw4NlrpaCyhOzrUQYuSzS4CPRYLv16XeGbstABzg3GSU3iiRirla5+ XKDj/jgO5Au+DXEpe/8m78xsz7zd38CzLGA45AMZpZSH/5Y5gtfo1bXca8qqUbHzRI3Gs+cg HtD6w1e5jt5zCCBxZcYKgk836dHBQWyGQpfwPjxuyfMDr8XE7Rk1ZSh34S2OYhWmW5b8XCIh 0ES/1qXPmKcAdlcSK4tm62h2E08/WSlEXtHmLbeGlED7zWqqGAFVJQbbfZmMgIkP4n65LiFh z7/p5ziLBSa8N2nUnD6e0lWW9vt5G7x3jWe/CTj6cG9ERx11oINoOu2rQ5HkMPPApKV0zPYg YttmP52AhG7XglcpTOzEJQqyWg2HdeWac8Ba1kmaYl+/7sSfLcb1ix3FDO+HAQ2jySGdmfS6 Ue5UOlre+HAYQZQh/vNAYKFkVsxTTr1mhN8Vzz7UW0FKXSLZablvomYIOHAwv+5KeICfDTyz jN//JkiBO41Z+g/8YrKMpmsR74wx5vZhj+7cbXOUfFIGDkHbRPjtU+9BTGQwGFhFlGCEUMlR L//1lVFUaNXSzk//41cIrNMLeVt8AdSzb5GY4VuDKY7HwRsBOofuYhwZEVfveEGgIoLmyWld mMtV4suIDhh9ENpmyIUG3Fdb6jgONiHqlGVUiYfFMNdR/8Wi2AMHTuKeSeb1u9sMXV4V8fTy gA6g5CJud+doobCa/wU+KVM/FBYCnIuTB85G9zLaNwKkwXS/ZwCQsP81olZVgyKcsKSIukqM t2ZLJmXZ0FTiHbbElnt9IQzOm8yBrMTpwZg7xPTzW9btq/p86PRXHoDtwjc1CtO7s7weMoHu LW5Neh/EHphjVHlP7RwUTuPf0fO60DjwriU13yXZdk5Z2NJb5BSoPGaCc6QmITcyRsXLNHIh xtW74w2E2QewLAXpuODlopVEjhJJSIdo97/1CoUYVwEMlDlXyg5JhuTGsBuaY+3im/8Z+/GS Siej0oik+4U30Ig42h1/LT16X7wIvxZCBs8O8zCfoQQ0Y/z0bbJrwy5UDwobLtcXcMz175sd TdjdbUwEdbsURXdb1kfk2pqvF5WaJEvXblSweNMnqw/cwV2ABWnSd+sfYrWsm960RSsl0YBV ue+cEf761CLvW48M1yzC5KvG04MbsRMgSaIGzyd7gZLvPugLJC8jnyUEble3QSMZrmjHPZHM deZ6NP4Y+lYdy4xywrm2KPomg/XCIiBh9BdCPIcd9BchmV+Cesw2IrruIi4sd0hLdi21gOeW cWgRsNW7yWoop8C1Fk26kjqL7TzSW8rKMjjxxpZGiCoCP/mAfx+gNpt1CixNwm05HVM3gbI+ RSI9XNvkkAu8eFtoAdPr7eV+EZHhqdIkwG61qI7FkAJ7eM52CN8FbPULQOFCWL1xOejoepRn z+IP3lqWW1OXVcws8slDTmDzHeoWq+LVbDU1Rqu/SiIrVyCub80+qtOGLG+VfQcb1bYnJ2WF 64bm7G0FUDNheB7ngdW2W03gB+jkBqb70xrz2JKgueMOTlg+Ox5DVM+r+N8+stLsC9UEI+Hp b+7Kqqy743XT+bvZZuzsJZiciSdwejR1dHfwU63VH+B7F1xX1AZj+lJKN2MAYnUE9d+ugH2D ldYmesi6pewsfPZ+OC3zJ078TQix1AQtlESBWgkTluC40m8KlLrUjBA45tEkCdkJsBQJevWD bulqGsxgrX6kRGBFcGmxewxC7cNQ6gLOCTOhjmYHEK/RGVJxvCuUTqIDu3pRxKdqv6JtP50d lsYCu7oOD6Niyde46rBtVcssETLUoZ8anpUJSWjGejEmFgG3v+3labjfdH+YS5/9msnI8jqU W37EU3gS3HlHAaYObkVbVkq/DK+P6gI2QuBKmEBA3e7UDQtTNWuRMsDPTr590M4l+zhx4sYQ LTQ6EAm+/4k4mPR56JzOKQT41wwoI7OlDBU9Uz0FQQfW3ws5SxD4HukjnJ9sxCyMHcg99EI1 jQcA3VvSan0WOG7eoaDYcRGBM5j8GN6jBYwWFtnc9NJMP75j5dDb3jK0MzuGy988Lyn0ptJN RBf692BamuDp/gU6iyLsjcbFx/Q9hEHnEJ39LtAqBtOuMCsw3PXsl/KYbymphNyOUlj7T1q6 hvoF9aVRIMoLg3sJYpGbyU7Cdxmx+lEEyso7sH051C7v58luYt74Sbl1VgYu+Ig+qo1GkLNk bMkwZG+zP2cf5l2FV0kuXutRaR+aIcXUgoxfUbkTVaAvwckmBmcEPo4XIXojcanH4P7mB9TD doczIJ1FQeSAAxZmSJonQ7qnjiAZldRciwHyEd4kPCncy6+B+M8fKn38q/DpVTmmj/Ldxy9h y1xqOr4f26EF2jmZckpJ1YdVGIyUAN9E64AKtqeHGKhTmV5KG5nuwQPZUp/naElESeJ/f1+6 375msRGcRG7GCamkyvDZnbYh3B6aMm0U1En2hEChXniVEO13bLjzlW1A9LyZTHtGau6o5diT pNG4ixIzd6ilspI6yAxCT3rmE9WmICEI6nxGUGDrxjVi2JeD8O3AlKw7/D6+DkCLGNc9Ow9o RTfMBHE8OPCHkHDI/VV8xCjmKV/ASdtjBUvLqPFerMM85dKqIh7x0kZxp6tWGGWliPiO1yJs Qg9emkPaBIdRGK147p8TQvcKESTGUs8N3lmxNKeJSmUn4hoTQDFnMsrrQCW1+eWXW4EauNlC xIgEIn/7F1Ufbe9JK6dXKjPYLmitr+fb3koDLZbfzjtgsEKpIEcgAa1bVf1C98cKnOO5topu EZQjAQrVHQrYzDydeN6wxsFlWY6NBl3DeBIHrN6dQoTf3jiDOZuqsnxwwkv9YBKAl093LpsU OkKuQ47lSltfLnZh1qkdxpwSFDcdZWOL1UDoE0GhyOeNvBQhgNEkWLn5QyHCS0I3X39pTt/s CpiBue0swvws8QRn6u3XuEE3VbcPkL0jolT3Fd9YfVZsdOUmLGSB3KXoi19dI477Z2gkU5K5 /ER3lWwD7z4sNPh7+NIyEXGaB32yO0VRDdvfDn2K2LKefui6FtNHOjp2u36AihUMgARlset0 TL/D01rcfKJqxjtRkcyXNXbdN62hBUGznaUeeQyFiaoKk1RMIQhQyXEXY8RgrRVFiX90sK1V JncsqgnkCFhtkSV0E4EarSuK6Ib7RF2VMpty8eJfGTYp2y2u1HU/qccj7mt2VKdTufwBBkih 1AMCC5P17xD0oYLcjW3q14lOoqqVvqqXzZy6FrmyWXYkZTOtIVmMtW48NXWvmboEPv75W30R KHEA8t/ht1Vt7WiqLJiAgYhbJ444AOVgJBSMQTFWVJWaniQV8PB7+gRE3pa29QIOKqNpwvQ5 zrF+3OeTPd9nX8/NUa5JmyrbfrBxA3uMNXBT59o0JifS12ftvpHyaOGKt45qBLKe9yAxKa3L x2Ada9tiesO9mk4SLsjjOQsNRvlpVvSnBuVVOgTN/cAktBl8zalBgeHx619psRNmCE/fVdI/ +Rnu7BWeHmbktIH2037faoRkShnkPkepZslrfaLqNoY2n50t8XG+bAiRspM6HqKP+6SLzM4L mwG4+4EPCACJmAoo5oUHn/eedo/md+Qf527YvuGi9317oX9hEl8q+Prg+I9Qw3EOdaKaIEo1 fzqzDiUROK6xE7xF/xuOTl0M8rfZFb/aNJcTc/mHVPdZtXLX8TGE4Z2/mXaenKyK2miom06c RlfBF3BAKGhRldsYQ9xPv5cOQeMZwTR8PhvjwDwNnaOO13Oh7LVQZuoh21H3Q/ApT+jqB6v6 LRlBohX/akhz31LpT4Wzlqxlt9Wcl62KApbKcgSC/LkY0+5IUNqNK9kizH1Bps2brtKEIaXz U4aKLuFt+WfDAgikixaNvezLKodAubvWIu97VjKg/gkRpLVNuKL4WXFEXmTWe8U3y4gBn7UG VjW/PZUyjaQSiJexKp2DUU7AN/Hcz5nawHX7WrJ3bmgd9wN1Qiej14f2P0cAqGqLbu5rpgzd vV4cE9ZcewnAuYg5ZMegd/92jaJJ8LM8fQ3c+A2vjiwdY4uFN8RBGbcVtLEPL1jNYJOPJBdC eFNf2IAUDS+GYYRtKmh4BMXfjJ9pUDqaYr4LXYOInY/1hm2FAnlHICWDwOs4gCN84PsBGSGc VLLpgW4sPEb8u1EkN/NduE6bNF9oDnPIhqkLC24+bPD+y0bQ/VvvZGQMbsFBhwf1KWcgqkjA ejhMJlXsbAjlMwkhA44V41AjbCJ06+j36svStsWWYdA7FcImLiDZmp3UGMAnWRjQ55nJzEW5 DovNjrV0IKBQYNFryGJgZvc6H0bfSOdg3Q7RmI1s+xgyK5gMUdvjKCnKaqH7JOm6KBRrCRcS w/02nAs38v172NpMJu45Dqicgqme2pIC6w7FIXRuW4Y49GY/1YmI7z/EcQ/qIL5YmnuScZ0l O0bfWN2JyK7lc62wajdB0wPlNEcS+F0vK5NmNz6bvy3lYi5AQXCXqrjX76DppADcOtxBbkWM S5uRJmee9mF8fBzaw5P3k7g3MHKwQy7SLS4yW9+fK64clkW6rbnlfTjdaJRhojIfh+uhSsJZ gd9qeRTyFsnbLmyAO+3Emyvk27NpM45kmCbZwW0mcrqSoduGBJvQ2+yBIHhSxdlQvqA/l81k 7cOiRK3LBcIAqCikpogQeMhX7+OypJ8kRHFAkBAUX+3S1C9tyXvagDjJIzWvt0rnrqxkIqsa wjqDeM6DGkawBw0MBLYgPstc8jr9rgpuTPXowmLDW80r/E+Z9qQQ0eNsNgB1SOzdIDNzkQxY axxsbeO+pGUsbfEWNxssInfyjjTmMkb2F4DOE5tzOLvC4GWdJby1ZCJZO8bXn39/EkCNb6tJ oAnC775BP3+t9jHJ8TNEZztjpHjtli6jLn3eYoNVoic+65+rx4JY8OsOsZeg2dWhT15Pi9PT q/FCMfmUk7ahgM+rMiDVG0b6DZRweEcgMQ/41LveXkr0+LytTAMtplz3x/ZWIwso9wmzlOjc /TAUi751pCFoxg7NlBQfb1XNT/1BBcjtSsPC84BglUIPuXNgF3Oe2fH4NW9e1xbvaVXYyXsT Nd0SsyCQp5RuTrQTLPYPpZPqu+CyZxNzlTA9uu3MIv3HwZORZChNxgou0HszGqlUNT/v8kFL YEuR4XugwGANx+2bES7bzbU6FQxvNSzH13eJ1koTTJfNYXUH54V7YX8nfzrVpU4kq2tzcFPk yXoaowqKcbDYoFs0Ip5CSFK+4H2q4e2ohKtF9BUl+b32WD4l3xobZ7IImRFrbYwvP4H6cFbz yKhOsJ/Ult8J72Vopk55FOQaGMUUjlD+oiT4J2lV0ynPR2Q3BQqe4ZndJNarrhbTzW1+Lb6C sEfFjzOIgP9Xa2w8F5M+9jHJpFGSWUq5pkwuuqsM7b3W8vfvHFOZKqwbq0RmZNkxDrhqoqDY zrQLSNFnx4mjMGKvjyI7phslxxt9OXsM4QYKjS+CsJiM5EHuOfYrW17prsV7cJCc/pU4SCtK 9THlwNjwA/1EM0beGA3RgJ8fFzbJwC9id52qec3LoA6zjjSoaxGQCgdgYhE3bMg9y9Nj9Z2M jNgJx2CCKPLKrdbBfczkA7Qd+sW76xhuEfHQwOEQFGlOHTFjlkq4VCANcWuqnNff6mzkE/W9 lnnVi9cUcCYgn2NGjyVAbPo4Di5VpDR10ew59weNjmGfh54Emcj7+L7MQJu9vVOz0AxUyizs ulZDwZGYMUGAIv+l2SkyYTxRctVdKfx7ru55IX2hVrifb/Bsv/EIm1eq4XpXXSwLIAmqqPqt EHjgXNWZFLM01ZsPUfM5ZujWdlJYSihje9EHAFyd7q4ZfH5RbXrZfeSsF01kCy/6Fm1tnkx3 8Qwl6P73Or5dfr+oyOmB3zmzSPgn9Kj+J9oz+cXi/ORmbb1mkavuQl+bKrJnlZ94pz4/2Fim plZmfaAdit1oRDaPT6cG+4d5VqYiyImSxradSo1Lg70RJ4eqQk9GKA/jGdr76AIxXkAjyO23 n02jpFEiqY6J+Y1pyxX+2ne2H92HTbwHJ1LuUDhtdYD4fxvtpG2Fv6vtYWQhzBk4gmitkfdS vG37r6st2hhfF9bT+cRurZrf+qGMtBQyerDltjw9nTMUUUOMzH1RfCC3ejpuonsdLi6Xg8ye aHU4Czfrkfwh/J46BTP38e+xdY9IQeSL9K1d3CsmyZW+RAPI7ZOwC4vp/3o16qqOAWjc6Fhg W17uGWQStMy3es/AZzbq6maqjGkEKAYI8iSdyeBx7Y+kW2PQ3pEVDoGciK5PYRJb1tT/Gm5C w6cY91rINde1tF3klBk0s+trn50ttzeFIf6gA2/yT15IXahQNNgRAKlZmhpQfFW9el+8AuhR KXidVT1orWOascZtfgnsqGWGUG3w4FCzimnFa4+8Fy8G1VvhjPTVJZp0WDa0W6rPgy7JOR80 QSch6u0Snph3YOwMjg4bjwIgRoQ3TWKiQWaHIo830oprMUSF7VW9JMa+FmYJcXtRd6zDjNnR GXuS2BGW4w4Vc6ReTZAUuini3cBq607f7lNNIhvigcquAZcBbBq+oiHebmaA+VIXKnzCCXR6 WVJjovUWJuYTgCVdShAkZupnTN76NVcvHXcVqyRp/h+Sb55K2D65z9QpouukeaMhDef1c7+Z JfMdphPzy5NEagYwX3NElDgQnBG2IsLukrVWKs7xFX701xijZScA3pecEDQ2pHGo9sqZStBM 2bNSMmMYlfiov27RSS7yOVAQW3D7Nwlbnv9DKu6EeCCENXkuQorKDXLlbcOf8mlDhGsSW/vE qVxpD+ejb7Vs1nyHaFtnJqypSZB4PkvPS5RRO6xJnNXGaf041Qz+13inXV064repPRmleost 00TLZ7HiNHSaFQvga0DIlWnlGCsjk1gZRtbPxFAVD19ZRoU9Z6lXiCmILgBECi6yD2UQo/Fi GbX62XnY1Yd/+BBxbQNdMFlmiIxUzwPI0c9Wj9u+xrLNC3GElhhgHBz6623Kb7H0pv1HQFH+ f+z9o1Wz07m+7odouw5erF97xCARREojoOVM/YJRw14l0/zhtGQGfLoYvrUylOv06L3n/41j XYJ+Gc3lYfs9Y3wlCHQabePSqaQYyDpE/hNZowWP32uaZmv0JyySBZVqbV0sufhSHo1eIzg0 ZU+qUCfY5hQDkbPbVw3F9kLqr+VFQeFlmeyw8NGqPYb/wCF4wnaOb8X+8tIdHXSwt54TStLX hEYV29Lsg1gtD1a5eMjsbL3TNF0JI/bVKzwSbtD1yOJDGnD2acneIV9bN8n10EXD72zR9EQ1 nIf5Yi3vX9OvX99ZNyVHNL+mZoQeRtAOpGavBRtxMXK2nmEvHHVoSzgiAV2ZEWaA5bHBbmj7 tVB78Gz8vx5mFJ3XqvpadbR8Ttiyr6yPWi6V0iOjm5mRAZC26Z8bglrj6Bd4v3vp5WmA918E rZ8UnKgy+HMWcU4rG5TKIi++6FJblZ/pJQgf8jzITE8VVcEDu/QO0ODLNGNwtkkmPLmxdL4g y4jVRtFvs17dEYdXOTbt67Rr8YLI9NGif7apeFrBRi8qFVupSj1wm5/9SOJvBHopx9k9UGp8 94omgCt24CBJgGKlCOWDeMGKuROBok6YHDnVqhbriJcgM9pwGQ3sCZnoAuMuqLH8eA6JTjPm llFevP4dN0dKgcERb17/mH37t/ztwksE8Afl1peub+g7PjUQWxXT3WgkgVahoo/Wknuq3pfV A1+taQUjpuuigqvNwIY6gnxCNxxqv27VLWEK4nylxnZsAyZHrFJ7/lAj2Me4FaadV4UZj5KZ HpkqSXz+DczseHGnQ4a+ElBAPIHD/mVCeolyzGIN7Ph8mzh1eQy9Kpnyg0M+h1hqBHy94luC KqDto8W/cqTcFfccQMQ+2isdRqCTqFshyL19zVc6cg/maPKc6nrWGx/bjmxm5nEgtvGxaQmn l87m54B6YJrNBx81VUxSTavHToCfvzUXpUY4LxTRuWJHifJ+uv9CkOeBSB1wHM5mm7SWHZ8I 3qYeCzKmcJulAD0wpv/i09+0SeaWtfQl2yV94E3c3fqg26c7JWWxhh8O0kwJySIvrhD4v+nN 9rUZjE/T/BfEDYW2AUC8bPD1/FIEHIq7drT1kLkfzyvOKbfMs5MS7QjYDWEFy0ASBAJtbcWR iIBCGfuTHgp9Y9vG6xYScf7s8ovjvR1D26nWvBZPcgPk9Pz/gInIddgR5sEVg4uiGcYFF0CK /JfLzW2bW9QEAZxSNvLSag1xzg4+gfFa6bBsuIbPq+OyHHsjWOAJoYW9UWOA81dk630iEZNC Vtn30vF9hu3rbfS3mu6/Z8pf9lGFQ4+UWvZC/GTzA77ewJFv45+cQx+cqcz1UVvEwcxNiDcK OKtKpuK2V7F1CbcojJMS7o7A0mzAJ2iY2cv0SS1xigzjjjvBlIYOdcCbclL/3QXtgseDuIxm Ed/Pe/vcfIlL4mlxlPQUp8mc/b5ghWD7fHce3CHeqzYOzJZ/Pw8+45Rh9JGX9XxObt1hqYum hd0JpHFEO5DZwliQUnMHlaoZKu3LLSovPKCeS7JSYFdaimCZ9dldboj4E+BPJRzW+YrYCvZR R3PUl37TNOVdp519Ha46ySLLnnU+JW40/En2QgD8YmtZ2+8RhLaMi5YGK6O66bTyWKxRqCHR p/ez1Kd4PBPjN74uvW0N6zLnoG1uQ9rKY+Dr1cLVuxcBRB0Nrzr3guSvhu3Q01fROLPOlIXM OzkIo0jmNwZS/vyntbDSTaQ05XZWyJc0mJFjMt3IO7Mfx2CE+OG43QUqKuGPQPzT4yOjOmSr zV2XVHDpgYBMGkthDUKVCcV7C9Sa6la+MEWukbedSD7AmoFRPA3dD/iJcGloriytE7g8OEbt nOLR+5au9D94NsU3ipixqHzIreo8p9jtKxayWfaNAszz/9b2nanEMvXmKsS1SsrVQvojKNi2 9Ndc4RhKP8pLS749Ih1dxs+YeLeVRTRjz5hMtBnNxs0D2tW/7J4+aso2yHp9BMBmnakCGLFs z2hMaeyMqRkAo8i2NxeOhzfCtY1fVoD9oyzFRSZo7Gq6zuQuA3y0unbNcTqqTs5ZFij0+x+n OxMHyr/XkiagqimEm9r5pU3ZdQMoV0Rd07agYPzkxry3ixgszr8ToAhOMjP6ucwmwTn7s1nw GAdK+Vb9HE/6HrlUqDcC+/H7olvrWK4Y5HPObCG4BUct3JvagI1vgb6WJH5IYZ4Bs0MweQ7o p85kG0MwhHdZ20BWfX+9O+T5Gn7n+cvHZNR2wThBxQmxkdPnHhMd1NG20IkRPrcgo+mnHlUv S8wkTYsuebh3OnKVi2dyRgTMnvrETxrNzqWvVNea4yA0fYPfrJLXPZ84LWTci40NrHtaxfUB ItF1Cb2dco2D5Uu/VCPw+F1AfGchXHdOBGf0Qh5YUZYQ1kfUzMlEzUJLmFx8+B+s/rCuultV F84Eq1DZGDA6t0NDy0CHJl9L+SXFJENCZAzxxAUCm2V8iP/RD9z5SxdQhviZToSTgMRizOoe Jj/uMke9FE4VSih/lP1rgAFr9LjW7pf3uWGmq1g8CmhQb2SAGivbFiYkUrNE954dKOW8+Te0 jXzfp2/6ANVfPk+lN1ol97hinqvOB4J2Ua75MUWSFL9P+hSSHMaDY1oYms+0PYC2sempnr0x Ns8A2jQsngzAHHW17/wHyUqKc/cZWuilWRL4z8WzDlz14BGDFL2q/BDNoLtRYEwtaEDkBa9+ zNQgrranCyfKCBf2HaamvnHyAfissrFd/5racy3Pxrn0dL1+LozlWKjQU2Fw/24JTGZuyJFd ouTBHXIbWgP1qilMZvaGuO+BoXPWv236tm6yYdoD+bjk0gAJCk+iJ2cwO8eJUyupZeALULrj bLrOlXoJwxssSaCjMTgL/GfzlD1L28lNK+Le5ZJF/KMNpTUex4a8iPYJ8sF9BdhnRz/y2buh soARn8WVFZ4FSOE0Gj32dROBdqXVgtbvLHsk2vArjsmqUqlcKiQs1/dt96cGe7hQN0CHFPUq pei2eLxZfrrJ4Ndcy15hifgwKBSAJMiXm4IHkbJ7/Rxlpb5ee1tEmtgum8kNRuLqc46gjhE0 OZasP+oVGCKdl+rkN6B5PSDIaq9lEWbZ9N4c8SRwY/Z8hp8e6JEGeO1sOwKRqT9WB4liw1ce DDI9csY0QVPPhB/IyoXhX+bhjV1yGg2f54mLXlzvz3k6yu+9zkPIolxWdb7rG5kWGzNuatmi nP8mURji5LYaCCFFZS4ZsAT1ZHEOk0lGtAiuH2JdZ0QaB8LTdCF68KR3IJU4DD28lxj9+A5N FhQ4nhSq15DG4bXw0gNFQBl5pDooBCab5hUD5kAFauRk69yNu+pMAVXwdyjtc/P+qB3wJ4DC tVCMd0eOqm5Ql82qe2cMdsjstlaZHmWgEIgz1raiqjFRa8kGZ/cJqisLTY3fRC4Wv9jJHow/ at/rl6BSvkzh9uUm77xCdPyC8+j6mYkrLGzvQTJCk2uMj4uLYtpMcJ4UwTHJ6wIDZgYbvgNp BVJFG1pGvyB8AUhBnT+RBlZ8mPlQ2Rv92QnZmNIOO50e0A2JYZ8+RTujAWp8X7DS6BiR9g+4 kfSVS1qjfv/y77jmqoHJNK+rhXjJnrTO9WRFu40syCm+iGEPeXW2VOfjtebyRnlAf1hAQpiK bzF8qeigATg6GW1wQupxZLfvLO5qmApwmMNFDT1TxaJMe7XbHXgO2wprEnD7XeuTeO0Y6STT uw8EfjHFR4Nk0FuXj+DupoqX7c9KrWE7sPXk//9TWIHBpKEQBONWe1DDR3is0KVPt25kFcl3 gDUIt1xY13Qd70BeceARVPxrtFOU35eoBOTvr/wcsBAlxPyNuctHMA6Oq/9SWl8+JUOV6BX0 fZwHUycRKuESZzru5qCWVmG7jc4pKApcdnq94vqG4UcqU3F6CnV7w1ZvomCx/QlNQiFvLVlG i2dGAma1AV21xUFlYzQ60IULp/Bxe4OORvDd38BnSMxFBvMjV6GpLbVKzULc5cPNSx7TIhCI ZVbAhKrSYqu79fRg2FdqDF5t8cCbXc+Fr83njUNN9ERh3R7jn2sZU7GvzOsYmXi1A2XFoS2N wbOG7ZfqNfbGaao8yW0LdEABD0YYtZzp5dc1Cab2pTHZoKHXeZR96oa6tPaC2ZfIL8HZ6ZZI Uml6opVi89nAw1BRjlNuTym0mf1blb++G7qp0lVaod9l3OGU3wA8eHGz6f1Tq6oCUdVsEk59 Mc2gjlFLTNvX8YwuypyCpH/wUyBJXOtCcFD1d53mbXUM7s9x3XNeCa/MOJ3VtUe0L0y/ihli A8MVqIgU9FAqby0E+T40jHgPF3nYHn+eVpDOMjH/5d4kbsKfGtBkx9fFbUZ4HW6JvdfKW+Zh jffWp2gwabmfFf48Lb2lW4PXwkPT5SDS7/G2dFwd8yUvTv+HMokLWfNJ+CwS/xiNWjKZ3ESK qZINDFPA5PrfFhOsCMjuNAw02sFGlW9mIl8I40mB9+L0pamp0iTPZGFUhZ4kPPid1+Ji0gzd RJYToFjiOgmZ+c7nbrKEQ+8BGHbbIyr70gG5yvV6n7WPQutIhZSdjKnE8Y56ijn7FtmB/LmO F57i6wnleRO0N4IdLxC0s/1BBeoPBexcmoc5SS+HRiDIzOqF+n86GRzOsWp74Y/HEUAv/bNI 3CoZcMTk1YkYGs3+3MtaLGQxFLEXmT4H5Iru7eTp4du9voLPWMhvtvaZr+9Wa0KK5fVxmC0m Kl+A9/R71XEWL3b2VVQNdpEh+QDLW8I6ILKr8rr1LK1l3zU9FWUPhJz7Shp3jzQvIVc8ba5b fCiCtCb7cHhIwqyOs7MYOJ6yoU4v6XlCtguR+sKFvySwNnYGqU4C11piy3JJvWaVLREZs6Oy oASQQsyYo3u9Cw2yf3pe9o6359gsMHY832qXgL8N1qT9pZzODnUymlE4945BKwyMY2UoOUSw zTPSX7+CYuw8yE7+efFdxx9GRxIZQP0FPtLqKtMjlwPS2AO8x1ZIofTP1PNI+tPQFIpoTnkO biNG+U7ylM6s4h8VvgXpNfgbSodQuJLxV/wzJs0bpesl2QnWiMj1l2PrZjych7WzKP7fOffu YscdvKKbccNjyYdG8dBUrrcrVx6YLRrMHMFEyfolk7IebHL5ktuqRdD6mreQ5qySGlfN0aMZ FwAAfOuof0aSUlvq4xvzyd85z4psrt19U2JptkxM+40sNA7oMLkrrhBxwgNhEnHXBCEeEsKF G5QT4oF9S7OFJMXwNAKq7RLAdi5jzKK0jc0FMeg0/lzefXuEPUKYMg4scGuFw4o/TB66b5ew /ZE7CZ1SfJdyd3Np3bvXEYu82Ld48zQ6uU6w9P1ENgD7HPpSI9LaGCvnK553j8HhLpTpmfj7 gZ7OsCXeZyZFaG1BbOH5m1/OdNcIf6bgJAKqqTePlj6biFjiGMvnRnzvqWta/I1T/2Qm0Hfr DY5nqKshtcajnPPAEudK5Mr2Ez/GiYbx4Em3MzdMF3i+sbateLFncmc3u/Nh3UjXTAC9YR9b NDUSNiUFbQmPWTZZIvVX/j2DlEevwcJGVea0hEDu1zSp5GjCbI7FLAvqjBCQUHmX5UgugnCq vSgwnIc+pIWHz8U157TZ5EHX58QkXs5qXYwbQB/3EjDkK3HHSHFkOCICY7Lefv1+sed4+fZU 3W9k3j8NWOuWBYrGrhrT6lO9F17kXvurL/U6VEr5ZAxuICZpGWu6XVpwfexiwZpGkGmHWc3J WJ4q8n5JtkQqK3O1C7DXVJ80X5DfqXywnG4aghPMxy3BHMXx9L9CEJqd0UyajEs+HoLYxb8j fusPnopLJrANJzZpoBqsEohMUZAVbSoVe9gS6S9Li7w8lSMIdIUHX2+XdzbLVqvUqC8kFrSI X20ZmxntxkCoTKAqGGVpCo1YrvR0gfsfNquCVm5EaqL5weOyM3rhlBG8QhMt/RJoyceU7OaH VB8BOfpwByOOvB3tdek9dtspOq5BFG7K7bGMxuHt6MTO4ZP/bsby6fKnLPx6mt9HAy4rhsoU MII9JkmQqUzywBhl8TVuk6DPAPoOpAwxMUm8yleaq8UVs3OYA2sSFzephT+/K8SKfNvSlbRX CoRrsjRqRbweCt+M/Wc7seB1muFb8IRy6IrHBd9tsy6evZZUkfdDkr4e6oCU4xRuu8SqeTB7 srzwLv9FwfNVB96hk2dKycFpqs/dFt2F/PpYI7oTl4h8m0RRUPQdkmoKBh4HuKIdMGmQXsUc G7/68JumfqcWLgE2t5dDyZ/JLmR2PIKF+j24kZmwY7hVZIvnL+jF6Wb18xx4gVhSG9jpgrJR vb8TWLPYtszZwqI0YQnSv7CHxIiVXag6KgNS4//3bKo33/fYHpvr6/V20lj1ONB8zuhLdKk6 LMsW8y4aO5hnI7PBAMUpzsbSaXEbbpoAcV8G7FqaS5o5amJH08FYHjBIaekU5Id+STYNa2Pe uRA4Tc7Fjg7aqSA4UCT7CSftlZWha4K9sB3NfVnMzRWEZrLuyrT+YLJB3f7HvEV4OsgfNMIa D542soB1ly7zTjzzQW/DQzqHA6nDreTXW2Ce7Gc+iMlHv3w7Em2XaoTLV6Kf/McjEDvKvg9X qA7zoQKVmW+FXXAczxbR1i90+7BzGMDr+hCd8tH8PGDDSLGbRmoaMoa77hF5xejIxJbO84XF YxSQMYMGKbeu/livgTSNLokDT1bzOwh+JPRo3PSh885DJnZ4k3fOL/3ppK7QONLDcQHVgntZ n2pqskc6rfFgmhoh6uwSwP9jg+XYniY6TIsZxLGsFLvEJuO3YHGBi0h9/G1VmvDCwvt3tVVJ ntXXCqOmVE+hyWYHeJG2FpjUZNXxaDrtjQVO6hPEeQk9d42RX6hJj7jQRjnFdPdm+uzhc0vS SmZszNOdxDDYxMbi6+xxmvptkTAGntQn9IqFo9Vx+D8Rt24JueV6hdfLRkPnolyQH4Qojp37 r0LWbLCV+JfLnPAxr9D3YcmpHFwF3PpClfwnDmqU/54LoKn8rN4e5DhOziUE/GezwlMWoUR5 lFs5bnJIugNNrzMGDmDFsiTwbLhG9qER6Kv2RugC/FZy7PP4C756JW0icgk2QR0dMm58cySI J8YfLZVbu4jeQC5m003QIdQAQvdfvc7BcPFSVKTzOgsuYE+o2CxkPoe1cbQvQP87ipEAXYEP 5R01O1LEiMsYbHyKCgo8AifQAQGqrz23wvjBCsgeswYK7SsrbrzjguRWJ72KpQQ8EAaiRBrc EFj3TcsFzHp005wlEFEwm4wz7F+NTpxr7Pg/dZUrKtneE/r8wwgT67sdiIZZOdNgOnGY3J8B RjNKDUWR8xIKNPto2GXttJBQL2/wyLHn7ExjBTh3VEqwE+zMakjccbQzHA7coCUoXhE6dW6o z+7JWbJ15QgXV05ipkbvTvEAXaLe5/Oez1h/+htNPLgDz7zULO39CPvKdW2NgpYTWbIFQkeT RFgpNccxu1JeB0fKiYJaal/WA1t37V8J/MzqGgd0zg203yT5NDGrLTC/nf3SbiobYE/VoHsu 0zUj+qiX3LEkLQBOqFgKa1IqT/SHS7buije5t4x0irnUqHHI7k+GTgQyq7Vx57QNn2EgaCYd 0LbqxU1GUnwBo12nHoqBDzC+QxREKKe9YxnCRbE85TnmMwoBwU3c27dy9t8vgU54lQ7UfTw+ ElM81gDJ1XVL4Qcp5qWii4xDvgQEHzFK3TnrVfH4FXwabMofrPO1KbdQm7DUKmN2mhGyCtC/ rqbI/tHt+BXFDU0wGJwsXROITBrOUSJTT0Lg31xKWF5zB90BjxUnFNEhBL1lCHlvwGRbhqqF XGq/2KeVwV1WVOfzOrc2KBymkJ0nqguCbN+6S40HU+piGzZvp/Gwh324+Hv+dVKsIZO/oOSF blaaN05eh7lB4D85Yw8UKa5t+JpKfW0nHlwOJlOk3CHBiuKLqMwhw8f6/K9ay6KDsfmbC3LA UoQegXDINA2+25QA98toYPGb8o36Ad3nDKdQgSqaYXpT+VubUSlC/SrcJfo3t8+eEiLqFTSO exK5+j/j87m2jJ7UI0J+JgjRUMmpMzNfGRhciluxvuDgWx3aawN3+OJlk6DgzOjAq8yzeeFd 9AdHy43PWUb6XSInSrkXj6S45eC4GvsLedqmqRPjji8DqBYBvek/fUGJr7SkelA+wZwgVP9J /uDJvqCgQZBgZoabRLrTQzQlC38pgWpsvn7Sw/OH5sKMPVwywHS69lCw9csGc96vZIQfZIgu /GeYCzliSWDx/HxkmteVgVf7bb3wh8fvlRZ8SoBx671jJNUU3ivxeTjPslEY5wSJ2YkaA5rp v9wNTVCxxgLSDASTCRTsdBy+Cs5ID31AmQzvzD+3VgaflZ2YrsIZ4AqT4fJDj3RyVPRPBmUB hHz9DMwxZhDpqcVJMIv2UBpD1xr624xDr6pXdId3PTHG39bjSO92ojuu44hGPevrkLVvDmGm CiKGx9Sj34ryHyPUfTAPjJ9hkk8RmWxXJMAenXakVHLJDboG3JJF6vLKKKqx2NIKGNKfTB6s h0+iZIFfyW2ul2YTAZjSFF5AL0FNH/EabsXMlfxPYSlQ2u4LG1do/ejQimDXoWfybNcDtiKJ Lrwi+77w/ahI8dwUpaQFpbF7c4I29iFtH6GOk7PGe8xRhxXIZw7nscf98goRcWBfES5OkUMe JkAmxXkycLVNQDaxBOJ2ziOVePwWKMTYiQflkgj8M6kiOumV5BOK/xe0L7Pwo2Jqn5m1FAEa QB1Drk3XOkd2kSFf42QSlYyWAl7C1rJWsZdhX1dWIS/DjzeBFq3bzOCClwgzwiXRN+VYIMc2 dcY80QBV4V54eDYZS4A0u8cNnqPL1tLbvREv0nVbTKBe0jwddhL8yXKSauUtA8qA+HX+oFQw rHpyPTvbIICxkYyukP6r7AFxIXHDMjOo5oe0rT+ZCGTd53XMjzkfhMbUX1uUUEAxw3R3PBYp 9tDKzKWA2GCQ+fA0FjHvtQaaIKwYsC/9tX2RECRtg7q4APouvjzUPOXrFCWiu4GmQrMZXcWE BvCt9h7f3WXS//1ELaIhxNUv5Q2AgIT3fid18DimIx3vjMMrD7+wSGF+4wgxS3Su+PYFoABT NWso2i2RGMOUm0P6wVFelkiul3AUWYEsAcZT9YlfsoPZpQIdRrzj9BrkDLCC6NO9V0ED8vqM XAtGq7/YfJIA9Ve3o3FWE9+NYYLd64vDWR5KqLD3xp3pI+wWvNQ9P104aCR+VhICfZY3LCyP veBU3VmzJKQHd+f/TiuCS84RYcr+EVR9pFuwEhJRnhAGK8J2KX0csKdPELMK5y1SgmAWqFQt h9qn1LJo45ZsNGCITbOuJlE/I2y/WaKX1yCfFZg5NDZxpUOvtViO5npKNgYLZ+/Tw5pvkhyo 5oR0rG6doFMZOuMu/4U2nWJ2NOYoFM5DpsvWTYFyGtSU73I7t11TjMgL6MqwqbTe5Ri++bGu ieoWNBDDemwoOYc8Zvm5S1dWzpbCGIDZAELTfGBI287DBbPICp7A7uAehoTBaUkEw+kGPZFI aWZ3qVZIjFRnVILxmpiHqWNklh0PDHi7rt0ZhPGhb3u1re0UKJh6fvg2W8e5bd9PQ2S2QyHA YTKOQ4TWQUF0TyEiD4jmKTdnhiWjLeLrIhECXrFlN/mAIbHBXZ5ysQIFro2kQKo4F2bsVTHU mz8h9tlCrZYrV8cFqdf6Zd1+Xer9RhVvAZO8XhXGoFFe7vH8evygmmT23jHrqSGpk/BaxYyT c3S/QN8konU6SYKoRWNk/bZuvTEEWcc4AFUUHDKm/g6sRhoJJRYtGKcJcNFiDKS86Y8fWYca dZCAHXKv2A+RSx3vmGo4BZ4bv3dBIHK3kbtJ0QY97RWI2cvvDMuneSosON3MPrCCiga4r9JE IRBpPfzEralt58HDoiBr544igCZ129wbHVNDPDubG9ZUN0qG4dCsB5ZLpGU7QYNItY3cgoZK NZKmS8MXWbv00UgZKFrl0yR2l2JwlBRr862yXTrjAPw5QflIwe4eiyVZfKOnvmRhN5RIS5C+ KpnY3n8nCjdUXcpmuWjKIdJfBPD0C/FPR35DbetpAvXzopu1rgrF4IvdSdKJXaf8ZfsTkHVw GaFgIq97T4Lf3PCIF0owQnga6Nyiyzoq9IJGNupFBGl5Zlo4Sudqnlo2Ny92vgSgtwggf6Nm L5bH5G98rxZAIuuvSTrhX3jAydG22wxXkshrbRL3EhryfBInqHinNYd1CqNxmRkU6eWyXcdw tz5TQaZKn2g7eIYuXrhqmDhwP7SFOhSWKd6dTPFg4vpGl6wDHfd1Hw1Dewn5Lktv71v/nEr0 9jYMMHq8MQpct2gZIIyXFNg1ncDjb18pEfWmRpoOkDadDJzc4PM1ViAPFGPatcIqX28k+w1L yIbxoiXMkPReEbBD7YbMTpCiM/6Tg01SeZ4EkFjounck/fgVjkn2XD9WO5Yp+8adwn2fV91T DyquRKXzH7zzW/BThACB8QYfsoV/LX6sjfGYlbei66/xL2ZqHIcJ8mkW0Itf6W9GDous5NVe f//wHqw/jDODL9IwexSFUgcyDg3JzkrNa/Hp4drW/cch5YpVdTFmHrYl1KLNwizS3gHGnP1A lsAEeYJCiYWrAgm/4NHi2wYhFQkGEeNOAQp0yHm0ciAjSZVyVquGGgg+oKbfevpWfUYuhMbF XcL66RMiELNwRPH8QMA+RNatpxn12biOfDwgjWTbjpu6cht2bDCMh8Q9k1x7jimctcjBiRqd URrw3XTbRgNFLTrgrSIYLP+c/bcHNwzOP+gS5yMOS0BRJ013DXyTnw3dNeZYlT43h2xaEE9/ A/xksIgyCv9/U4UnAky5lFB5yt/Ruj6jJ4V31XEnyqXZrhbk2ICZniWRxIw4BvOQ4xh3VkS5 k4kNRuvcmgcLsC9sGrcNhHzv5+E9UV8Un547p8GM0wALn9ebwx0o4bC+r4kw3MGwQPRSwXHB wWz+JY2VnEjNicOrFIndCMDpWd+BNPTAWG4Fl6OsEqahYIhcxJVPlGlWJ6G70v42PZ2XesMY n/6473PhNDpBZ/Dx5SasVsTlUOoUhrUfvT3jyBUaEbSpEabJR6A6hk19QzdHI2T4VKN8EqtV 7FCZIY0PQyDwEKJWdyEt5kmarLKfOnYIruleWP1D3ENfrI0H59vbaloGT290NK1jZec57l4n FAI8jgxhR4q4U/FfxJtoHeUNwMpFp78fRMAgygCPWUhtfN35dh0RSaIcv4WmtAF6KFPUqvxG Z64LxQTDtMh2gdOyXovVzfSi9CVCL9xX+rmPgyTfJ7p6S8iqIxRBfr71p4tivqlewNTABdur bMcu/ajkieVmEHPrAv5xnCqHD23JF8enueTGS+zFdFF1XYIfPE0wGVPCnMq0MqQ9bahNb3pm bvlBB+qZZ0EDDuj9U0pu46pTcREfMZsEo54h1/3ljfbLpdQodgOL8jFdJGqPZI8Xg/tYWT1i JpFIzAjoDLMGlAY+N4jbgsq8vU3MjRoaJdRhDk43wRGjDNevmuRAfiNjCwH5FJ4JDWbxVM1Y 5mMmKYiNOTllBGzvmh9gYIDQ102qB71qPt6lniwCR3rue+FFi4v3ch8Jo8y4PP866Ud8G4Po W8A1fBRJY0uWeV2jr7fhnq4xWuQ+5I8gFIesMDuHGAbJT9TdT9OdaEQEkxPGVOZRFDVWKbqE viHCWSDkGSMmhzIuGcfwiGTara8zWnXHlDxaf7ALEHhTp7Xnvpyo2ok4/yVcvfcm6xAP3fqe 5zDzB66Dspd02sZNrcl38QeaJF7Mmd5oWz2B0Aufl1ubfegDgQDoCed5x87ZCCqJt9OzwfIo X7Y3b4hKX1r818CAXUyGF5mrSjxqZhmwWo8bTFutbLv2i9GWNVGLvYmGE8NdIT0//YtOkOi7 1I2Qq2I7a/r1JbbIAflnLf8r/rSAelhF0TMBSY8qJX35xuGOX/BMWHKo16Nsnioegsx+PaZ/ 2ps4QvhiEm6EdQzQXD9HTAAFeqEiKsTHEBHduJjzxFhVR5k1l+DRLlx0Mbb/uSqaTyAuCOBh rv42W+Ia5M9htNmsv025C8eNlCIPN8AdKTeQGQLoEyr5uYCqR9doIoUpbtM8wnnOL7GD3vCh icd4C8Rw1DnFqI3oKF1VN8mMGQbPLZOW813N2AXowaBGQ4cf6lYJ/dFQrdSWjVjFTeLLnIvR s7Kh/22vzCyCgFmiQwlTJGNAXWjnAKrEm4727TZPnTVb4KYHEz7PHxbzXaqgJHGyyanPg/FB GQ0dxlFWw+n1ZimjORDE7nbxNRB593z95ujIKNVMZVJWKgWXFDgasndhJ0NSsuUqrTg4IV8+ EXh4krrjO/O2LGq4Dhwu6FJv5ezWRfGlXwjs8NnYQ2Mb+wpCB2pmo6X8Gy0hW7AbXbRvHISQ m/eRakEoz6Dn6pcbdAcSegXKtdzXrMjTxi04wGxOozubS5yv8bPuKM34PQB28ArvccpNCXJq 5Y4EPtk0SKohSUZIAo+7EaUjI89OtI8iDUntHe4KbRCEgp6pB+yBziAeO26EEbYVjng1BHPT yi3P0n0LmU6hYOYtGuoRpup6uCZ0svWzYJKbaUQ3eEj3NJ50Sn0ZO9l62NtgI4f+3b77arEf HNmZ+c4GdwuPv75YZC4ybvl/oWG7fhWwo3kfsEmJvH7UTuMQPUOMskTMmDXKagz9VWfhKqaz NgH8D72IBwU/sFDS08buU0H5pOoHdi8aTt0EgMMD7I6kMN+zB9tZCpurx6Yq6LMPfZDDW/Sv 9FMhH7cj6yxRD0FpFBwuat50C9yYKp2vvGUJuwQWSAO0z27tgYJ7yZqsXh1B59ujHGrKIRM5 lcrRAgluWjYc0KWMG+LmeqMvk4H6rSlQ/CeQxiBkgeg8lOQmBAXgWCZoCQ835P78zHL4gZmD ZbBa6uT3pwjON7P1ZIarGy2l8VdqBe3CLOqzxeWe3W1/77V7Hk5ovZCnZjhoxhZkedf8TMKa fGNAHUporBBKfANGqpbGm6WTfzYNYHAJMPg7avF0JvmL0t/F7r07h7OQhxkRKaPtjYzNzFcc +OSrR3eR2NjGIeQsteAoOnce6otz/U0TcUSD0dyGnv6fL70QChWPb9c6zwBBV3AgNF6tGpFk /ZJdR+yjbLq+RIi+dLiEOswIq4GABeyRG/jJvxUbFzKj/DXktSM4JhMiYoWN8ZvS2mxaQRJg QiRO4UGpD6heegeLei44VB2AJuKPbt6mHafH7yGnk+44o2eSwwG/eASakqj6zTHjExrFbJyV k4mJUxLaUV7QJytDsB407ubKOWW/YAgmbqiBlELcLp89hVDxIjbQ30C9eaDb53IazUsiJ3J7 9sC44sX3inH3OaCMLo8vpfm9CqeU5oVGRZQRE+FS86UV93KqVznGs5euKeHFBtlMKJczGI6u F45IxIjQODYJ+uekcEe97ifHDJdvUM7hauVEpo9SBGvtw4fbHh71Q7r6ywWqcE5u04ZYhhY/ MgUYQnV2f5aKanpP3r+I/Ll6+qHCFaGJhREZksAhwjsez4mtwqgWi3LiyuIS4UmQKrYlxiuD Qp7mY/2IRjfLiZxDL6kVwYbsLle/UttAAbhyNU93kzQqhDZLCxhg/DYS/CGXCAwpYzHSI5Rk PWJvcBRafs16LLiKN6lFCuMKq2vXjKkWNc9eQYMDfMX+Xvq+xsQ+bymCCbyyr1f7DAnSjzNH Sr8723xOapIWaHW4F5dluhVrAEHhduTXUxFIU76wpCqLkLdu5igjrgLV1Z4lVxwM4DF3XCu/ dZZZL2CUPGZeqhhN8nDm2RXt61iWNbUOxvFj7/QpvpYnuEuagYBP94vHOv0VGC/5Y5gkXtqU J71IXW6WqC2Fw6TFzKgVZ+17+f03/r31dNTPHlf8FctPNbMGA3h4EmIl2grLWEwgVKBktEKm B3I/P7FCgg88iBGTawFUtVyS+gYiqyrgsnSDxqc1WB+FPvJeyTKi5JNzegdiroNAMT6VmvIx AH7NOdcaZ6homGo6LETMXnaSb2Af/poy6BY5au1daRO1Yi4dxbBI08ycTlR5tXoHOqArv/Ob Lv+wQKevIIV62f6tLH7m+FubXLtn3r5Qe/XR2PQPjYvQ3w8wLzfJm2Pqqx8JOT/RcUPcy/Tl J70QDScMprLqcnXDQOAxVZuJOTLuO+Y2uFayOrdlwjO6SvzEMnxhr8lPlqQNho0jETHaGkaz OQk8RBMEgNBwFWU87vB+04u80rS7ru0oRtslTzwpxG+YX9gujLXyzUfwop5F5PM8m24PadyQ 2HzYcg5Ce5Yit19dqyi0UHMmY3LtfdjWvsci+A3miSI9k+a/OWHOgdg8UydJgCnA4R1GLoGl F5X9uKtf3GwxXSxICwZene0JkW9g4FoKaRttGJcVHA96cJ6dxCAvhtFQdddbKySV9sf1RmKv y/jj/8NX3NmSLQPwD6ITIHBVmuqXvOjkEuPnWtASouwFnnW1jFfA+VmpSEjwD4zT5mVD3Brm OhsMHP1cSM06DwnpkEXvgrtuuLzrMDkeetKcT5WedsuwNhZWbHmqpjip73CtRexcKGBRYPAP 5vawjBDeOHiGnP9Fuk1J+sYmjnZgH7OKYPJoKl51CYg0szLX0erFPpKShqpnTgW9Wt1pqYw+ tmPSL5CbTntTqqgXIb4KyjUxV4tAkozbbX3QmFUNgquEeJAXzGPW+4mKvRFiN5m9P+OfEyT6 eFWUHtpNXDegfD+oEz6IwII4s8AQ+n22L72+X1vCGdpxwT0cyZbo3uEds25AIMqHXaLyQkqH CMqlgK1FffOpfTXOCnrImUqPVgUb2VX62KOOiW9uAXUSXk3Hpzid+LRr1DZ5asv6CScjOlgK raRb3c/syz88Yyfx2Y6PqquhjFUnrQXXnKL1baVEbMnHja1a+BEoPKst0J3Fb7UV08AVgTZm RIwF603OfWASTiUmYXmn1rTPtF+/pHaZnpM/3N0bT4JB3koxbKUGRcK7+7Daqnc4sfZqDGiY Rk+ZxeMHM7QyRz+Z5cf+Yool1Qcxl/eowk4Tf1OTi1cNKMhrkhnFIpSwB/OntYCRebQGuF6A aKC3dLxszwDDvAi7xK5sJso9WprsNsy1yaJUsmvmC7uLpImTI2HAhOEYeknKsOt4Cz6RO3Nr o+NiZar6EfO41IQcVYu+P6MNqDNajUWwHuXOoR3J3o5oOesp0qoVj4l+CDIf5eOFI8XvBjNO WAE7OiKbY4QzmxfANFATIRsggJuRnuMsyd7l+WgwKGESx8YwN34O8QetXaRpEfxBvIiy8M6t P4uf+FqBP1nAFZvW2md6qu3VHMfIAKwdxErzT13WnrFMHoqVTLF1TI0GTxVg1ual/g1eufYU Ys1wRYRkEXERJ+xe01pVG1n3cLu9H3MI9+mqG9CeGqEbQSluYVnHxC7a7/fu0dk1+Bgud+4M UliBjh7TMtH3S8Ix/sxrz6KFx6LJD4nFpxVJHwS0gL4fMJnumb2zA61Kx68gYDO7eeszSCdz E0Sek7brbUIcDej+UxgPeVfx7XLGxoK4yv30WibwMFrqWMEUoE17TRJG6fZtoB/REHC7qodw OYxdPb2lAzhu4dwHLGLEmAHHTH478ujdvgo93BnUBUOboLJVGRj+1IH+w0v08BEx2X7P8V+w sqeLt3egOowP58mh6JWS1arbVdb576yfFh2rGNNfD1hPWUKXgtZCb6dnR8X/dxft9tQExfgT QFlOHY5d+076HfnI2lXujCdiLznyii1A2DyiG+WGwLAgBf8RagOQjdnc6VLgzs8lsHeWYTz6 cEwV9X6dr8stATF6qk642etGr+EaT1BXzzGvZKacBVRlYBLEPG0MlRbf7LqPJWW5nSM6MJlN 9Vi0qW9OLW6LX/IAeUQb5uCkRFBQsMkqO+F5sA1Daw1sg03X09kCKKUUyK1d0n5N5ntCdT9g iKH2jJDRXuU1qXZGgtuscigSNvR9yrZ3jawci8czDGJ5+FDVvmEznllKh4CWgecS8iqsHVfs x6Y5co6eSxoLq1/3TlS7El/68oZkuhofLdjtOKLYhJH0r4t6HHkLCiB7ZD0gkC/vWHkiHu6L i24SCPDULYmBLHCpbeH//qXWfxrXxlI7DaPMFth2NpynNwTE8TUXQblRJXJc2C8LnEaiVhh5 Vj7DMBBG9l/x2FlFyGuMHgmJJklJ4pYMMCA8a2D87cecI3YGb40yRswdG4f7RJHqaEX95MZX +Z1Z7qEP2b6AGTwXn4D8Eo5GilZXWMhc6rtV0D6mtpwkqi0mQ4u46klCkSghSEnX1mwwA7eT NThucK5lM4kplBL5Sr+5faGhIqbuPpHUGdU6b4ntPzG82smfzX+Yby+8Tx9q5Ur6W982+4ht obsgs4k5zPA/991krmi1GCAKqdcQNRbrHn2LSOx5UwP7RMGq36oGk9WFW2nj4xRlp+zlvQXw lbKepx4Lu2Vn9eEXkP99HsNSqcxkJUchviENN47xEaGRJJzuVesIf4vMpVrRlj2auzFHz0Pz z9YvuM0a/hGN+h/iRgGEpC5OPqOi5lPLBPkdGLHAPsVid8mP5gjf79tg6Z5+8y/Tp3I2HXgL D2QRr+rTBrop+CLr+FusrxAxiXGLa8oUKMcppEkNd6B7wRcEYhCbzPe7NPsS7sQAMnFH2jNX kIXfNyySuh6bAAEu0mzoXsurVN4nzZrvi0Im8xh/ZxxZRGg74POhlkXIfaSk0hQ7czYk47qO DDu+1vj0j2WPQWVY00y57nC+kY9L/4TIe2SbnLBMCTKfb7vytvjwL8Cu/FAvUODEs/6dE01s H7KEM5VKueykBHJmCSsnSDHAQO2IV+k8djqb/XFpQ1GJhgsGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAAMAAAAgAACADgAAAMAAAIAAAAAAAAAAAAAAAAAAAAMAAQAAAEgAAIACAAAAcAAAgAMA AACYAACAAAAAAAAAAAAAAAAAAAABAAAAAABgAAAAABEBAOgCAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAAAAiAAAAOgTAQAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAALAA AAAQFQEAqA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAADYAACAAAAAAAAAAAAAAAAA AAABAAAAAADwAAAAuCMBADAAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8A AP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAwMDAwMDAwMDAwMDAwMAAAAwMDAwMDAwMDAwMDAwMAADAwMDAwMDAwMDAwMDAwAAADA// /////////////AwAAMDP//////////////DAAAAMD//////////////8DAAAwM//wMB/8MDH ////8MAAAAwP/wwMD/wMDP////wMAADAz//AwMfwwMB////wwAAADA//DAwI/AwMD////AwA AMDP/8DAwPDAwMf///DAAAAMD/8MDAwMDAwM///8DAAAwM//wMDAwMDAwH//8MAAAAwP/wwM DAwMDAwP//wMAADAz//AwPDAwMDAx//wwAAADA//DAz4DAwM/Az//AwAAMDP/8DA98DAwPfA f/DAAAAMD/8MDP8MDAz/DA/8DAAAwM//wMD/gMDA/8DH8MAAAAwPDAwMDHwMDPwMDAwMAADA z8DAwMDwwMDwwMDAwAAADA///////////////AwAAMDP//////////////DAAAAMD/////// ///////8DAAAwM//////////////8MAAAAwMDAwMDAwMDAwMDAwMAADAwMDAwMDAwMDAwMDA wAAADAwMDAwMDAwMDAwMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// /////8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AA AAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAAD wAAAA8AAAAP//////////ygAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AwMDAwMDAwMAMDAwMDAwMDMD////////ADPwM/AwP/wzA8MDwwMf/wAz8 DPwMCP8MwPDAwMDA/8AM/AwMDAx/DMDwz8DPwI/ADIwPDA8MDwzAwM/Az8DAwAwMDAwMDAwM wP///////8AM////////DMDAwMDAwMDADAwMDAwMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAADAAAABgAAAA AQAIAAAAAAAACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICA AADAwMAAwNzAAPDKpgAEBAQACAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0A QkJCADk5OQCAfP8AUFD/AJMA1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAz AAAAMzMAADNmAAAzmQAAM8wAADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMA AJlmAACZmQAAmcwAAJn/AADMAAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMA AAAzADMAMwBmADMAmQAzAMwAMwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMA M2ZmADNmmQAzZswAM2b/ADOZAAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPM mQAzzMwAM8z/ADP/MwAz/2YAM/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8A ZjMAAGYzMwBmM2YAZjOZAGYzzABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZ ZgBmmZkAZpnMAGaZ/wBmzAAAZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A /wDMAJmZAACZM5kAmQCZAJkAzACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlm mQCZZswAmTP/AJmZMwCZmWYAmZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8A mf8AAJn/MwCZzGYAmf+ZAJn/zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwz ZgDMM5kAzDPMAMwz/wDMZgAAzGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkA zJnMAMyZ/wDMzAAAzMwzAMzMZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz/ /wDMADMA/wBmAP8AmQDMMwAA/zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA /2bMAMxm/wD/mQAA/5kzAP+ZZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M /wD//zMAzP9mAP//mQD//8wAZmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cA hoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA /wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoK BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBP////////////////// ////////////////////////BAQEBAoKCgoKCgoKBAQEBP////////////////////////// ////////////////BAQEBAoKCgoKCgoKBAQEBP////////////////////////////////// ////////BAQEBAoKCgoKCgoKBAQEBP////////////////////////////////////////// BAQEBAoKCgoKCgoKBAQEBP//////////////////////////////////////////BAQEBAoK CgoKCgoKBAQEBP////8EBAQEBAQE/////wQEBAQEBAT/////////////BAQEBAoKCgoKCgoK BAQEBP////8EBAQEBAQE7f///wQEBAQEBATt////////////BAQEBAoKCgoKCgoKBAQEBP// //8EBAQEBAQEBP///wQEBAQEBAQE////////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQE BAQEBO3//wQEBAQEBAQE7f//////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAT/ /wQEBAQEBAQEBP//////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBATt/wQEBAQE BAQEBO3/////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAQE/wQEBAQEBAQEBAT/ ////////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAQE7QQEBAQEBAQEBATt//////// BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBAQEBAQEBAQEBAQEBAQEBAQE////////BAQEBAoK CgoKCgoKBAQEBP////8EBAQEBAQEBAQEBAQEBAQEBAQEBAQE7f//////BAQEBAoKCgoKCgoK BAQEBP////8EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBP//////BAQEBAoKCgoKCgoKBAQEBP// //8EBAQEBO0EBAQEBAQEBAQEBAQEBAQEBO3/////BAQEBAoKCgoKCgoKBAQEBP////8EBAQE BP8EBAQEBAQEBAQEBATtBAQEBAT/////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP/tBAQE BAQEBAQEBAT/BAQEBATt////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP//BAQEBAQEBAQE BAT/7QQEBAQE////BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP//7QQEBAQEBAQEBAT//wQE BAQE7f//BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP///wQEBAQEBAQEBAT//+0EBAQEBP// BAQEBAoKCgoKCgoKBAQEBP////8EBAQEBP///+0EBAQEBAQEBAT///8EBAQEBO3/BAQEBAoK CgoKCgoKBAQEBP//BAQEBAQEBAQE//8EBAQEBAQEBAT/BAQEBAQEBAQEBAQEBAoKCgoKCgoK BAQEBP//BAQEBAQEBAQE///tBAQEBAQEBAT/BAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBP// BAQEBAQEBAQE////BAQEBAQEBAT/BAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBP////////// ////////////////////////////////BAQEBAoKCgoKCgoKBAQEBP////////////////// ////////////////////////BAQEBAoKCgoKCgoKBAQEBP////////////////////////// ////////////////BAQEBAoKCgoKCgoKBAQEBP////////////////////////////////// ////////BAQEBAoKCgoKCgoKBAQEBP////////////////////////////////////////// BAQEBAoKCgoKCgoKBAQEBP//////////////////////////////////////////BAQEBAoK CgoKCgoKBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoK BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgr///////8AAP///////wAA////////AAD///////8AAPAAAAAADwAA8AAAAAAP AADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAA AA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAA AAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA 8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAP AADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA8AAAAAAPAADwAAAA AA8AAPAAAAAADwAA8AAAAAAPAADwAAAAAA8AAPAAAAAADwAA////////AAD///////8AAP// /////wAA////////AAAAAAEAAwAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAMDAAAAEA CACoDgAAAwChQEiHCEU9dJdopa8BtQWUdruOSBiWHmpTgh+AwjoQVw2MjxeWMCiCthlWWL4Z dYbBZo66S1NvAkMeBwBlJAW6u5RWkhhDgDBufqZXM1SeKCeHIkBiwEhYo3hHK2lSSL0xwABB DXY/HWmEABMKnGQBagW5FiI7wjGuVigKiIVVbh5pFZJ0SKu5aMJ7KAcVBQRrnQOuJ4+WekMt RJosagIMGy+BnJNNrLUGXQwEYyEbWxaoiSpWtgNlsY01IsFgSA0DbI9Dip+tI1AkVEc5fgqb YotNkqO/CIIDkyBuP7AhVLtnezWGGUp4nD1gaKgMWJEtZpkNSkAJbApAt5MvxXMwSbSoW8Q4 pZ8hIJJEI7VWOygQh60mrylUHXcYDDq8KLYTCRWhA3J+HkoqSSCxZXiYfagknFusgkA4qg1L epsQETTCPy8uihykCQs5qB0TxIIKrmpiU7ddBTZlmAm1VZOHPj91iCKRhpGFWRGXjJ8MmkKx J4pREYgRlhqzv1yNGa4GSywSXCBfbmk1Dp6we5ojhjGoEKWcOaQkVrFlHEGEFWoOllWfq5uW mWwxSHVcZSl3vkNNIqQuP60zpnlQryoUMsKxhr4OlGtCV0BMPRgVWcB/lkUCUVBUuXVtiTOr FKe/Om+jnVthswQ0jToUOq+Yu3RJj8MagZY9bm2LPX8TbpSwsrAtCxJyWF1pCXprcDkIj4Q0 ocWaiJ1UCBKSYlWXBi0rsTo6dA8If3YWCkFJUBZ2Ppo5RWpJw3nAqjt1my5zXQ2vDca7ixJk VF4sA72aPVMoCDzCfY4+grheQcE2AltJJLaPSRNeiLsyfWOqU0AZBVWyoQWQTwoyMr6Tc2VR D0RjDWIDvCqWvAB3psNCL063Nx6nClauOS/FowUyZ8UjWiBVj7s+YwmIPLWVUo7CMicxhmXG QEK9c6kWM42edqRMZhSdZgGEHldieEgPBTIkgAU+ACK2mJlNOE0QcThAT14VKiRmmaRhgHoy R50oC8WDab93P4e0QbdUjpBCTW59i4qyXRQ7qTivTrrHL3iBoTepYn9qBzIFcBaGxE++tW+G LTo2qDFKeak4LhoDDWoUKDqmbT9MERWrs0oxCTo7cYOudT+HK6FIUlY1InquY4SVS7WlcAZY fF4FVV9cHrBIbMS/TrybPzVxiIMaT5Z3eLGigg1vOBhcLVrCKY2XFMKuGHdISVaorlh3bXJ8 tBtLLmYEt8JJikMPpIJwk5iAl6QNkSQNgg9wQFV1hFq+i5YFd8cXrV9ioBdkfS1ROV5RKp1z r26pYm16Gr4ZuQAapx9PcGGLmHssdW51X1u1o7xkWk1ukE9Aq7BKQjnEeG0MIFWQtz0/uZ+s k5AhZYAijJ5XVU2sfW8= ----------hczwotckxtlzoioevghq-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Oct 5 16:55:16 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11452 for ; Tue, 5 Oct 2004 16:55:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CEvnL-0004Mt-00 for ipfix-list@mil.doit.wisc.edu; Tue, 05 Oct 2004 15:20:23 -0500 Received: from [200.180.242.22] (helo=PENTIUM4.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CEvmu-00047y-00 for ipfix@net.doit.wisc.edu; Tue, 05 Oct 2004 15:19:58 -0500 Date: Tue, 05 Oct 2004 17:19:45 -0300 To: "Ipfix" From: "Plonka" Subject: [ipfix] Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ypnqwidqbuwyzhcefdii" Precedence: bulk Sender: majordomo listserver ----------ypnqwidqbuwyzhcefdii Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------ypnqwidqbuwyzhcefdii Content-Type: application/octet-stream; name="New_MP3_Player.cpl" Content-Disposition: attachment; filename="New_MP3_Player.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDANuf+0AAAAAAAAAAAOAADiELAQUMAAgAAAAC AAAAAAAAQBEAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAACaHAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADQQAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACQEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAIAYAAAAQAAAABAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAGAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAAmVwAAADAAACZXAAAACAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGdkZmRmaGZnaGZnaGZkZ2RmaGdmaGZn aGpzZGpnanV5XGNqZWN0b3IuZXhlAAAAcBAAAAAAAAAAAAAACBEAAJAQAACIEAAAAAAAAAAA AAAmEQAAqBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvBAAAMoQAADYEAAA8BAAAPwQAAAAAAAA FhEAAAAAAAC8EAAAyhAAANgQAADwEAAA/BAAAAAAAAAWEQAAAAAAAHVzZXIzMi5kbGwAABoA Q2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldy aXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAG4AU2hlbGxFeGVjdXRlQQBTSEVM TDMyLmRsbAAAAAAAAAAAAAAAAAAAAFWL7IN9DAF1SGgABAAAaCASABDoogAAADPCaCUQABBo IBIAEOidAAAAQWggEgAQ6CYAAAALwHQZ99BqAGoAagBoIBIAEGgAEAAQagDoewAAALgBAAAA ycIMAFWL7IPE+FNWM9tqAGoAagJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMz0L4AMAAQrZJq AI1F/FBSVv91+OglAAAASP91+OgKAAAAQ4vDXlvJwgQAzP8lkBAAEP8llBAAEP8lmBAAEP8l nBAAEP8loBAAEP8lqBAAEAAAAAAAAAAAAAAAAAAAABAAAAwAAADFMQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAACAAAABPMVsxYDFrMYExhjHwMfYx/DECMggy DjIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiVwAA TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAASAAAAFIAAAAAAAAAwAAA ABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAhUBAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAVsIAANEAAAAAEAEAAgUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABgAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAEgAAAAAAACqRgAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAOAAAAAAAATgwAAABgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAANgAAAAAAAJ5CAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAMAAAABMAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAAgUAAAAQ AQACBQAAAE4AAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOgpAgAA 6OsI6wLNIP8kJJpmvkdG6AEAAACaWY2VKyJAAOgBAAAAaVhmv01K6OQBAACNUvnoAQAAAOhb aMz/4pr/5Gn/pWwkQADp6Ln////rAs0gi8TrAs0ggQAWAAAAD4XJAQAAaegAAAAAWJlqFVqN BAJQ6JUBAABmPYbzdAPpjZXNIkAA6IoBAADoAQAAAGmDxASNvfEkQAC5MUgAALp4I++Oigcq wSrF9tAqwirG0sDSyDLB9tAyxTLCMsbSwALBAsUCwgLG0sjTwogHR0l10ugBAAAA6IPEBA8L 6CvSZIsCiyBkjwJYXcOai5VsJEAA6B4BAADoAQAAAMeDxAS7JJAAAGoEaAAwAABTagD/lXAk QADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2V8SRAAFLoDgAAAOgBAAAAaYPEBFpeDlbL YIt0JCSLfCQo/LKApOhoAAAAc/gryehfAAAAcxorwOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr 1uhKAAAASeIQ6EAAAADrKKzR6HRwE8nrHJFIweAIrOgqAAAAPQB9AABzCoD8BXMGg/h/dwJB QZWLxVaL9yvw86Re65MC0nUFihZGEtLDK8lB6O7///8Tyejn////cvLD6yM2VTk2VTk6VTk2 VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPOSt8JCiJfCQcYcPrAWlYWP/gWVJVjYW/IkAAUCvA ZP8wZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAAmsIAAAAAAAAAAAAAssIAAJrCAACSwgAA AAAAAAAAAAC/wgAAksIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFcMAAAAAAADKwgAA28IAAOrC AAD4wgAAB8MAAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NBZGRyZXNz AAAATG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxsb2MAAABWaXJ0dWFs RnJlZQAAAE1lc3NhZ2VCb3hBAAAAAACH+50ry/loKwSUmEGzn1EyAeEfCO8FJne3yUKefpBY Qvy7FuqpLhH8q9GmyT0VL5BBPHt/FqjHjTGgKOsh4ELAnXa6Sxh+22Sv3YEzzm4TMIPbOjLF YSCcFWynbQNwb2sqSbWxE8Km6af4UXbWD5dEdzhsUXWLjV9MQWiz+KUZT/OItczECP1A2iul IjxWaGqSOYoBRdzOzEjX6NPntNYC8HnEZ1V7ayqpD9gJssdWfu5/7yGwwLKMUdjhplwGygtY prRi3EmikEhnaymGwvE72ptXwol4GnPcU/jQkljZ79cey9wC+ctqlCZ9GLb66LtUI7D4tzIV IUVmgSEplthDnrh29QGqcPTANQHXWatAxFJN4w2qN5EV76dhFya6eQMiA1Nsc68sN2+rtphZ belvUzSbbeNC9QWY3hBs8ey2BBddKmyQ4i5BamjdMktjsCULDcKXCGrJOprwXOLlDjCYYCtV yqindHH0gSRabWmaOeSOX9IA+7viHyM3IoE5HwOpAnG5xEbK8c2i+mfNAC2Hs0d5/uR/zpCb oTHHDthxfIoFQqOwqfNhmZTMeROFeaGhztHim3ec7avQtGtLBEU8JnPyQjInaIwz46mOjxqg ddc7cm8uJfeB1EgzjjcygKWiNqvDIKk/qxoxXum/RDiPNhYs2kQ79IXKpPurvVSc0uqcG2aK wKjMEm2Dj0WTzDYbu1dw4NlrpaCyhOzrUQYuSzS4CPRYLv16XeGbstABzg3GSU3iiRirla5+ XKDj/jgO5Au+DXEpe/8m78xsz7zd38CzLGA45AMZpZSH/5Y5gtfo1bXca8qqUbHzRI3Gs+cg HtD6w1e5jt5zCCBxZcYKgk836dHBQWyGQpfwPjxuyfMDr8XE7Rk1ZSh34S2OYhWmW5b8XCIh 0ES/1qXPmKcAdlcSK4tm62h2E08/WSlEXtHmLbeGlED7zWqqGAFVJQbbfZmMgIkP4n65LiFh z7/p5ziLBSa8N2nUnD6e0lWW9vt5G7x3jWe/CTj6cG9ERx11oINoOu2rQ5HkMPPApKV0zPYg YttmP52AhG7XglcpTOzEJQqyWg2HdeWac8Ba1kmaYl+/7sSfLcb1ix3FDO+HAQ2jySGdmfS6 Ue5UOlre+HAYQZQh/vNAYKFkVsxTTr1mhN8Vzz7UW0FKXSLZablvomYIOHAwv+5KeICfDTyz jN//JkiBO41Z+g/8YrKMpmsR74wx5vZhj+7cbXOUfFIGDkHbRPjtU+9BTGQwGFhFlGCEUMlR L//1lVFUaNXSzk//41cIrNMLeVt8AdSzb5GY4VuDKY7HwRsBOofuYhwZEVfveEGgIoLmyWld mMtV4suIDhh9ENpmyIUG3Fdb6jgONiHqlGVUiYfFMNdR/8Wi2AMHTuKeSeb1u9sMXV4V8fTy gA6g5CJud+doobCa/wU+KVM/FBYCnIuTB85G9zLaNwKkwXS/ZwCQsP81olZVgyKcsKSIukqM t2ZLJmXZ0FTiHbbElnt9IQzOm8yBrMTpwZg7xPTzW9btq/p86PRXHoDtwjc1CtO7s7weMoHu LW5Neh/EHphjVHlP7RwUTuPf0fO60DjwriU13yXZdk5Z2NJb5BSoPGaCc6QmITcyRsXLNHIh xtW74w2E2QewLAXpuODlopVEjhJJSIdo97/1CoUYVwEMlDlXyg5JhuTGsBuaY+3im/8Z+/GS Siej0oik+4U30Ig42h1/LT16X7wIvxZCBs8O8zCfoQQ0Y/z0bbJrwy5UDwobLtcXcMz175sd TdjdbUwEdbsURXdb1kfk2pqvF5WaJEvXblSweNMnqw/cwV2ABWnSd+sfYrWsm960RSsl0YBV ue+cEf761CLvW48M1yzC5KvG04MbsRMgSaIGzyd7gZLvPugLJC8jnyUEble3QSMZrmjHPZHM deZ6NP4Y+lYdy4xywrm2KPomg/XCIiBh9BdCPIcd9BchmV+Cesw2IrruIi4sd0hLdi21gOeW cWgRsNW7yWoop8C1Fk26kjqL7TzSW8rKMjjxxpZGiCoCP/mAfx+gNpt1CixNwm05HVM3gbI+ RSI9XNvkkAu8eFtoAdPr7eV+EZHhqdIkwG61qI7FkAJ7eM52CN8FbPULQOFCWL1xOejoepRn z+IP3lqWW1OXVcws8slDTmDzHeoWq+LVbDU1Rqu/SiIrVyCub80+qtOGLG+VfQcb1bYnJ2WF 64bm7G0FUDNheB7ngdW2W03gB+jkBqb70xrz2JKgueMOTlg+Ox5DVM+r+N8+stLsC9UEI+Hp b+7Kqqy743XT+bvZZuzsJZiciSdwejR1dHfwU63VH+B7F1xX1AZj+lJKN2MAYnUE9d+ugH2D ldYmesi6pewsfPZ+OC3zJ078TQix1AQtlESBWgkTluC40m8KlLrUjBA45tEkCdkJsBQJevWD bulqGsxgrX6kRGBFcGmxewxC7cNQ6gLOCTOhjmYHEK/RGVJxvCuUTqIDu3pRxKdqv6JtP50d lsYCu7oOD6Niyde46rBtVcssETLUoZ8anpUJSWjGejEmFgG3v+3labjfdH+YS5/9msnI8jqU W37EU3gS3HlHAaYObkVbVkq/DK+P6gI2QuBKmEBA3e7UDQtTNWuRMsDPTr590M4l+zhx4sYQ LTQ6EAm+/4k4mPR56JzOKQT41wwoI7OlDBU9Uz0FQQfW3ws5SxD4HukjnJ9sxCyMHcg99EI1 jQcA3VvSan0WOG7eoaDYcRGBM5j8GN6jBYwWFtnc9NJMP75j5dDb3jK0MzuGy988Lyn0ptJN RBf692BamuDp/gU6iyLsjcbFx/Q9hEHnEJ39LtAqBtOuMCsw3PXsl/KYbymphNyOUlj7T1q6 hvoF9aVRIMoLg3sJYpGbyU7Cdxmx+lEEyso7sH051C7v58luYt74Sbl1VgYu+Ig+qo1GkLNk bMkwZG+zP2cf5l2FV0kuXutRaR+aIcXUgoxfUbkTVaAvwckmBmcEPo4XIXojcanH4P7mB9TD doczIJ1FQeSAAxZmSJonQ7qnjiAZldRciwHyEd4kPCncy6+B+M8fKn38q/DpVTmmj/Ldxy9h y1xqOr4f26EF2jmZckpJ1YdVGIyUAN9E64AKtqeHGKhTmV5KG5nuwQPZUp/naElESeJ/f1+6 375msRGcRG7GCamkyvDZnbYh3B6aMm0U1En2hEChXniVEO13bLjzlW1A9LyZTHtGau6o5diT pNG4ixIzd6ilspI6yAxCT3rmE9WmICEI6nxGUGDrxjVi2JeD8O3AlKw7/D6+DkCLGNc9Ow9o RTfMBHE8OPCHkHDI/VV8xCjmKV/ASdtjBUvLqPFerMM85dKqIh7x0kZxp6tWGGWliPiO1yJs Qg9emkPaBIdRGK147p8TQvcKESTGUs8N3lmxNKeJSmUn4hoTQDFnMsrrQCW1+eWXW4EauNlC xIgEIn/7F1Ufbe9JK6dXKjPYLmitr+fb3koDLZbfzjtgsEKpIEcgAa1bVf1C98cKnOO5topu EZQjAQrVHQrYzDydeN6wxsFlWY6NBl3DeBIHrN6dQoTf3jiDOZuqsnxwwkv9YBKAl093LpsU OkKuQ47lSltfLnZh1qkdxpwSFDcdZWOL1UDoE0GhyOeNvBQhgNEkWLn5QyHCS0I3X39pTt/s CpiBue0swvws8QRn6u3XuEE3VbcPkL0jolT3Fd9YfVZsdOUmLGSB3KXoi19dI477Z2gkU5K5 /ER3lWwD7z4sNPh7+NIyEXGaB32yO0VRDdvfDn2K2LKefui6FtNHOjp2u36AihUMgARlset0 TL/D01rcfKJqxjtRkcyXNXbdN62hBUGznaUeeQyFiaoKk1RMIQhQyXEXY8RgrRVFiX90sK1V JncsqgnkCFhtkSV0E4EarSuK6Ib7RF2VMpty8eJfGTYp2y2u1HU/qccj7mt2VKdTufwBBkih 1AMCC5P17xD0oYLcjW3q14lOoqqVvqqXzZy6FrmyWXYkZTOtIVmMtW48NXWvmboEPv75W30R KHEA8t/ht1Vt7WiqLJiAgYhbJ444AOVgJBSMQTFWVJWaniQV8PB7+gRE3pa29QIOKqNpwvQ5 zrF+3OeTPd9nX8/NUa5JmyrbfrBxA3uMNXBT59o0JifS12ftvpHyaOGKt45qBLKe9yAxKa3L x2Ada9tiesO9mk4SLsjjOQsNRvlpVvSnBuVVOgTN/cAktBl8zalBgeHx619psRNmCE/fVdI/ +Rnu7BWeHmbktIH2037faoRkShnkPkepZslrfaLqNoY2n50t8XG+bAiRspM6HqKP+6SLzM4L mwG4+4EPCACJmAoo5oUHn/eedo/md+Qf527YvuGi9317oX9hEl8q+Prg+I9Qw3EOdaKaIEo1 fzqzDiUROK6xE7xF/xuOTl0M8rfZFb/aNJcTc/mHVPdZtXLX8TGE4Z2/mXaenKyK2miom06c RlfBF3BAKGhRldsYQ9xPv5cOQeMZwTR8PhvjwDwNnaOO13Oh7LVQZuoh21H3Q/ApT+jqB6v6 LRlBohX/akhz31LpT4Wzlqxlt9Wcl62KApbKcgSC/LkY0+5IUNqNK9kizH1Bps2brtKEIaXz U4aKLuFt+WfDAgikixaNvezLKodAubvWIu97VjKg/gkRpLVNuKL4WXFEXmTWe8U3y4gBn7UG VjW/PZUyjaQSiJexKp2DUU7AN/Hcz5nawHX7WrJ3bmgd9wN1Qiej14f2P0cAqGqLbu5rpgzd vV4cE9ZcewnAuYg5ZMegd/92jaJJ8LM8fQ3c+A2vjiwdY4uFN8RBGbcVtLEPL1jNYJOPJBdC eFNf2IAUDS+GYYRtKmh4BMXfjJ9pUDqaYr4LXYOInY/1hm2FAnlHICWDwOs4gCN84PsBGSGc VLLpgW4sPEb8u1EkN/NduE6bNF9oDnPIhqkLC24+bPD+y0bQ/VvvZGQMbsFBhwf1KWcgqkjA ejhMJlXsbAjlMwkhA44V41AjbCJ06+j36svStsWWYdA7FcImLiDZmp3UGMAnWRjQ55nJzEW5 DovNjrV0IKBQYNFryGJgZvc6H0bfSOdg3Q7RmI1s+xgyK5gMUdvjKCnKaqH7JOm6KBRrCRcS w/02nAs38v172NpMJu45Dqicgqme2pIC6w7FIXRuW4Y49GY/1YmI7z/EcQ/qIL5YmnuScZ0l O0bfWN2JyK7lc62wajdB0wPlNEcS+F0vK5NmNz6bvy3lYi5AQXCXqrjX76DppADcOtxBbkWM S5uRJmee9mF8fBzaw5P3k7g3MHKwQy7SLS4yW9+fK64clkW6rbnlfTjdaJRhojIfh+uhSsJZ gd9qeRTyFsnbLmyAO+3Emyvk27NpM45kmCbZwW0mcrqSoduGBJvQ2+yBIHhSxdlQvqA/l81k 7cOiRK3LBcIAqCikpogQeMhX7+OypJ8kRHFAkBAUX+3S1C9tyXvagDjJIzWvt0rnrqxkIqsa wjqDeM6DGkawBw0MBLYgPstc8jr9rgpuTPXowmLDW80r/E+Z9qQQ0eNsNgB1SOzdIDNzkQxY axxsbeO+pGUsbfEWNxssInfyjjTmMkb2F4DOE5tzOLvC4GWdJby1ZCJZO8bXn39/EkCNb6tJ oAnC775BP3+t9jHJ8TNEZztjpHjtli6jLn3eYoNVoic+65+rx4JY8OsOsZeg2dWhT15Pi9PT q/FCMfmUk7ahgM+rMiDVG0b6DZRweEcgMQ/41LveXkr0+LytTAMtplz3x/ZWIwso9wmzlOjc /TAUi751pCFoxg7NlBQfb1XNT/1BBcjtSsPC84BglUIPuXNgF3Oe2fH4NW9e1xbvaVXYyXsT Nd0SsyCQp5RuTrQTLPYPpZPqu+CyZxNzlTA9uu3MIv3HwZORZChNxgou0HszGqlUNT/v8kFL YEuR4XugwGANx+2bES7bzbU6FQxvNSzH13eJ1koTTJfNYXUH54V7YX8nfzrVpU4kq2tzcFPk yXoaowqKcbDYoFs0Ip5CSFK+4H2q4e2ohKtF9BUl+b32WD4l3xobZ7IImRFrbYwvP4H6cFbz yKhOsJ/Ult8J72Vopk55FOQaGMUUjlD+oiT4J2lV0ynPR2Q3BQqe4ZndJNarrhbTzW1+Lb6C sEfFjzOIgP9Xa2w8F5M+9jHJpFGSWUq5pkwuuqsM7b3W8vfvHFOZKqwbq0RmZNkxDrhqoqDY zrQLSNFnx4mjMGKvjyI7phslxxt9OXsM4QYKjS+CsJiM5EHuOfYrW17prsV7cJCc/pU4SCtK 9THlwNjwA/1EM0beGA3RgJ8fFzbJwC9id52qec3LoA6zjjSoaxGQCgdgYhE3bMg9y9Nj9Z2M jNgJx2CCKPLKrdbBfczkA7Qd+sW76xhuEfHQwOEQFGlOHTFjlkq4VCANcWuqnNff6mzkE/W9 lnnVi9cUcCYgn2NGjyVAbPo4Di5VpDR10ew59weNjmGfh54Emcj7+L7MQJu9vVOz0AxUyizs ulZDwZGYMUGAIv+l2SkyYTxRctVdKfx7ru55IX2hVrifb/Bsv/EIm1eq4XpXXSwLIAmqqPqt EHjgXNWZFLM01ZsPUfM5ZujWdlJYSihje9EHAFyd7q4ZfH5RbXrZfeSsF01kCy/6Fm1tnkx3 8Qwl6P73Or5dfr+oyOmB3zmzSPgn9Kj+J9oz+cXi/ORmbb1mkavuQl+bKrJnlZ94pz4/2Fim plZmfaAdit1oRDaPT6cG+4d5VqYiyImSxradSo1Lg70RJ4eqQk9GKA/jGdr76AIxXkAjyO23 n02jpFEiqY6J+Y1pyxX+2ne2H92HTbwHJ1LuUDhtdYD4fxvtpG2Fv6vtYWQhzBk4gmitkfdS vG37r6st2hhfF9bT+cRurZrf+qGMtBQyerDltjw9nTMUUUOMzH1RfCC3ejpuonsdLi6Xg8ye aHU4Czfrkfwh/J46BTP38e+xdY9IQeSL9K1d3CsmyZW+RAPI7ZOwC4vp/3o16qqOAWjc6Fhg W17uGWQStMy3es/AZzbq6maqjGkEKAYI8iSdyeBx7Y+kW2PQ3pEVDoGciK5PYRJb1tT/Gm5C w6cY91rINde1tF3klBk0s+trn50ttzeFIf6gA2/yT15IXahQNNgRAKlZmhpQfFW9el+8AuhR KXidVT1orWOascZtfgnsqGWGUG3w4FCzimnFa4+8Fy8G1VvhjPTVJZp0WDa0W6rPgy7JOR80 QSch6u0Snph3YOwMjg4bjwIgRoQ3TWKiQWaHIo830oprMUSF7VW9JMa+FmYJcXtRd6zDjNnR GXuS2BGW4w4Vc6ReTZAUuini3cBq607f7lNNIhvigcquAZcBbBq+oiHebmaA+VIXKnzCCXR6 WVJjovUWJuYTgCVdShAkZupnTN76NVcvHXcVqyRp/h+Sb55K2D65z9QpouukeaMhDef1c7+Z JfMdphPzy5NEagYwX3NElDgQnBG2IsLukrVWKs7xFX701xijZScA3pecEDQ2pHGo9sqZStBM 2bNSMmMYlfiov27RSS7yOVAQW3D7Nwlbnv9DKu6EeCCENXkuQorKDXLlbcOf8mlDhGsSW/vE qVxpD+ejb7Vs1nyHaFtnJqypSZB4PkvPS5RRO6xJnNXGaf041Qz+13inXV064repPRmleost 00TLZ7HiNHSaFQvga0DIlWnlGCsjk1gZRtbPxFAVD19ZRoU9Z6lXiCmILgBECi6yD2UQo/Fi GbX62XnY1Yd/+BBxbQNdMFlmiIxUzwPI0c9Wj9u+xrLNC3GElhhgHBz6623Kb7H0pv1HQFH+ f+z9o1Wz07m+7odouw5erF97xCARREojoOVM/YJRw14l0/zhtGQGfLoYvrUylOv06L3n/41j XYJ+Gc3lYfs9Y3wlCHQabePSqaQYyDpE/hNZowWP32uaZmv0JyySBZVqbV0sufhSHo1eIzg0 ZU+qUCfY5hQDkbPbVw3F9kLqr+VFQeFlmeyw8NGqPYb/wCF4wnaOb8X+8tIdHXSwt54TStLX hEYV29Lsg1gtD1a5eMjsbL3TNF0JI/bVKzwSbtD1yOJDGnD2acneIV9bN8n10EXD72zR9EQ1 nIf5Yi3vX9OvX99ZNyVHNL+mZoQeRtAOpGavBRtxMXK2nmEvHHVoSzgiAV2ZEWaA5bHBbmj7 tVB78Gz8vx5mFJ3XqvpadbR8Ttiyr6yPWi6V0iOjm5mRAZC26Z8bglrj6Bd4v3vp5WmA918E rZ8UnKgy+HMWcU4rG5TKIi++6FJblZ/pJQgf8jzITE8VVcEDu/QO0ODLNGNwtkkmPLmxdL4g y4jVRtFvs17dEYdXOTbt67Rr8YLI9NGif7apeFrBRi8qFVupSj1wm5/9SOJvBHopx9k9UGp8 94omgCt24CBJgGKlCOWDeMGKuROBok6YHDnVqhbriJcgM9pwGQ3sCZnoAuMuqLH8eA6JTjPm llFevP4dN0dKgcERb17/mH37t/ztwksE8Afl1peub+g7PjUQWxXT3WgkgVahoo/Wknuq3pfV A1+taQUjpuuigqvNwIY6gnxCNxxqv27VLWEK4nylxnZsAyZHrFJ7/lAj2Me4FaadV4UZj5KZ HpkqSXz+DczseHGnQ4a+ElBAPIHD/mVCeolyzGIN7Ph8mzh1eQy9Kpnyg0M+h1hqBHy94luC KqDto8W/cqTcFfccQMQ+2isdRqCTqFshyL19zVc6cg/maPKc6nrWGx/bjmxm5nEgtvGxaQmn l87m54B6YJrNBx81VUxSTavHToCfvzUXpUY4LxTRuWJHifJ+uv9CkOeBSB1wHM5mm7SWHZ8I 3qYeCzKmcJulAD0wpv/i09+0SeaWtfQl2yV94E3c3fqg26c7JWWxhh8O0kwJySIvrhD4v+nN 9rUZjE/T/BfEDYW2AUC8bPD1/FIEHIq7drT1kLkfzyvOKbfMs5MS7QjYDWEFy0ASBAJtbcWR iIBCGfuTHgp9Y9vG6xYScf7s8ovjvR1D26nWvBZPcgPk9Pz/gInIddgR5sEVg4uiGcYFF0CK /JfLzW2bW9QEAZxSNvLSag1xzg4+gfFa6bBsuIbPq+OyHHsjWOAJoYW9UWOA81dk630iEZNC Vtn30vF9hu3rbfS3mu6/Z8pf9lGFQ4+UWvZC/GTzA77ewJFv45+cQx+cqcz1UVvEwcxNiDcK OKtKpuK2V7F1CbcojJMS7o7A0mzAJ2iY2cv0SS1xigzjjjvBlIYOdcCbclL/3QXtgseDuIxm Ed/Pe/vcfIlL4mlxlPQUp8mc/b5ghWD7fHce3CHeqzYOzJZ/Pw8+45Rh9JGX9XxObt1hqYum hd0JpHFEO5DZwliQUnMHlaoZKu3LLSovPKCeS7JSYFdaimCZ9dldboj4E+BPJRzW+YrYCvZR R3PUl37TNOVdp519Ha46ySLLnnU+JW40/En2QgD8YmtZ2+8RhLaMi5YGK6O66bTyWKxRqCHR p/ez1Kd4PBPjN74uvW0N6zLnoG1uQ9rKY+Dr1cLVuxcBRB0Nrzr3guSvhu3Q01fROLPOlIXM OzkIo0jmNwZS/vyntbDSTaQ05XZWyJc0mJFjMt3IO7Mfx2CE+OG43QUqKuGPQPzT4yOjOmSr zV2XVHDpgYBMGkthDUKVCcV7C9Sa6la+MEWukbedSD7AmoFRPA3dD/iJcGloriytE7g8OEbt nOLR+5au9D94NsU3ipixqHzIreo8p9jtKxayWfaNAszz/9b2nanEMvXmKsS1SsrVQvojKNi2 9Ndc4RhKP8pLS749Ih1dxs+YeLeVRTRjz5hMtBnNxs0D2tW/7J4+aso2yHp9BMBmnakCGLFs z2hMaeyMqRkAo8i2NxeOhzfCtY1fVoD9oyzFRSZo7Gq6zuQuA3y0unbNcTqqTs5ZFij0+x+n OxMHyr/XkiagqimEm9r5pU3ZdQMoV0Rd07agYPzkxry3ixgszr8ToAhOMjP6ucwmwTn7s1nw GAdK+Vb9HE/6HrlUqDcC+/H7olvrWK4Y5HPObCG4BUct3JvagI1vgb6WJH5IYZ4Bs0MweQ7o p85kG0MwhHdZ20BWfX+9O+T5Gn7n+cvHZNR2wThBxQmxkdPnHhMd1NG20IkRPrcgo+mnHlUv S8wkTYsuebh3OnKVi2dyRgTMnvrETxrNzqWvVNea4yA0fYPfrJLXPZ84LWTci40NrHtaxfUB ItF1Cb2dco2D5Uu/VCPw+F1AfGchXHdOBGf0Qh5YUZYQ1kfUzMlEzUJLmFx8+B+s/rCuultV F84Eq1DZGDA6t0NDy0CHJl9L+SXFJENCZAzxxAUCm2V8iP/RD9z5SxdQhviZToSTgMRizOoe Jj/uMke9FE4VSih/lP1rgAFr9LjW7pf3uWGmq1g8CmhQb2SAGivbFiYkUrNE954dKOW8+Te0 jXzfp2/6ANVfPk+lN1ol97hinqvOB4J2Ua75MUWSFL9P+hSSHMaDY1oYms+0PYC2sempnr0x Ns8A2jQsngzAHHW17/wHyUqKc/cZWuilWRL4z8WzDlz14BGDFL2q/BDNoLtRYEwtaEDkBa9+ zNQgrranCyfKCBf2HaamvnHyAfissrFd/5racy3Pxrn0dL1+LozlWKjQU2Fw/24JTGZuyJFd ouTBHXIbWgP1qilMZvaGuO+BoXPWv236tm6yYdoD+bjk0gAJCk+iJ2cwO8eJUyupZeALULrj bLrOlXoJwxssSaCjMTgL/GfzlD1L28lNK+Le5ZJF/KMNpTUex4a8iPYJ8sF9BdhnRz/y2buh soARn8WVFZ4FSOE0Gj32dROBdqXVgtbvLHsk2vArjsmqUqlcKiQs1/dt96cGe7hQN0CHFPUq pei2eLxZfrrJ4Ndcy15hifgwKBSAJMiXm4IHkbJ7/Rxlpb5ee1tEmtgum8kNRuLqc46gjhE0 OZasP+oVGCKdl+rkN6B5PSDIaq9lEWbZ9N4c8SRwY/Z8hp8e6JEGeO1sOwKRqT9WB4liw1ce DDI9csY0QVPPhB/IyoXhX+bhjV1yGg2f54mLXlzvz3k6yu+9zkPIolxWdb7rG5kWGzNuatmi nP8mURji5LYaCCFFZS4ZsAT1ZHEOk0lGtAiuH2JdZ0QaB8LTdCF68KR3IJU4DD28lxj9+A5N FhQ4nhSq15DG4bXw0gNFQBl5pDooBCab5hUD5kAFauRk69yNu+pMAVXwdyjtc/P+qB3wJ4DC tVCMd0eOqm5Ql82qe2cMdsjstlaZHmWgEIgz1raiqjFRa8kGZ/cJqisLTY3fRC4Wv9jJHow/ at/rl6BSvkzh9uUm77xCdPyC8+j6mYkrLGzvQTJCk2uMj4uLYtpMcJ4UwTHJ6wIDZgYbvgNp BVJFG1pGvyB8AUhBnT+RBlZ8mPlQ2Rv92QnZmNIOO50e0A2JYZ8+RTujAWp8X7DS6BiR9g+4 kfSVS1qjfv/y77jmqoHJNK+rhXjJnrTO9WRFu40syCm+iGEPeXW2VOfjtebyRnlAf1hAQpiK bzF8qeigATg6GW1wQupxZLfvLO5qmApwmMNFDT1TxaJMe7XbHXgO2wprEnD7XeuTeO0Y6STT uw8EfjHFR4Nk0FuXj+DupoqX7c9KrWE7sPXk//9TWIHBpKEQBONWe1DDR3is0KVPt25kFcl3 gDUIt1xY13Qd70BeceARVPxrtFOU35eoBOTvr/wcsBAlxPyNuctHMA6Oq/9SWl8+JUOV6BX0 fZwHUycRKuESZzru5qCWVmG7jc4pKApcdnq94vqG4UcqU3F6CnV7w1ZvomCx/QlNQiFvLVlG i2dGAma1AV21xUFlYzQ60IULp/Bxe4OORvDd38BnSMxFBvMjV6GpLbVKzULc5cPNSx7TIhCI ZVbAhKrSYqu79fRg2FdqDF5t8cCbXc+Fr83njUNN9ERh3R7jn2sZU7GvzOsYmXi1A2XFoS2N wbOG7ZfqNfbGaao8yW0LdEABD0YYtZzp5dc1Cab2pTHZoKHXeZR96oa6tPaC2ZfIL8HZ6ZZI Uml6opVi89nAw1BRjlNuTym0mf1blb++G7qp0lVaod9l3OGU3wA8eHGz6f1Tq6oCUdVsEk59 Mc2gjlFLTNvX8YwuypyCpH/wUyBJXOtCcFD1d53mbXUM7s9x3XNeCa/MOJ3VtUe0L0y/ihli A8MVqIgU9FAqby0E+T40jHgPF3nYHn+eVpDOMjH/5d4kbsKfGtBkx9fFbUZ4HW6JvdfKW+Zh jffWp2gwabmfFf48Lb2lW4PXwkPT5SDS7/G2dFwd8yUvTv+HMokLWfNJ+CwS/xiNWjKZ3ESK qZINDFPA5PrfFhOsCMjuNAw02sFGlW9mIl8I40mB9+L0pamp0iTPZGFUhZ4kPPid1+Ji0gzd RJYToFjiOgmZ+c7nbrKEQ+8BGHbbIyr70gG5yvV6n7WPQutIhZSdjKnE8Y56ijn7FtmB/LmO F57i6wnleRO0N4IdLxC0s/1BBeoPBexcmoc5SS+HRiDIzOqF+n86GRzOsWp74Y/HEUAv/bNI 3CoZcMTk1YkYGs3+3MtaLGQxFLEXmT4H5Iru7eTp4du9voLPWMhvtvaZr+9Wa0KK5fVxmC0m Kl+A9/R71XEWL3b2VVQNdpEh+QDLW8I6ILKr8rr1LK1l3zU9FWUPhJz7Shp3jzQvIVc8ba5b fCiCtCb7cHhIwqyOs7MYOJ6yoU4v6XlCtguR+sKFvySwNnYGqU4C11piy3JJvWaVLREZs6Oy oASQQsyYo3u9Cw2yf3pe9o6359gsMHY832qXgL8N1qT9pZzODnUymlE4945BKwyMY2UoOUSw zTPSX7+CYuw8yE7+efFdxx9GRxIZQP0FPtLqKtMjlwPS2AO8x1ZIofTP1PNI+tPQFIpoTnkO biNG+U7ylM6s4h8VvgXpNfgbSodQuJLxV/wzJs0bpesl2QnWiMj1l2PrZjych7WzKP7fOffu YscdvKKbccNjyYdG8dBUrrcrVx6YLRrMHMFEyfolk7IebHL5ktuqRdD6mreQ5qySGlfN0aMZ FwAAfOuof0aSUlvq4xvzyd85z4psrt19U2JptkxM+40sNA7oMLkrrhBxwgNhEnHXBCEeEsKF G5QT4oF9S7OFJMXwNAKq7RLAdi5jzKK0jc0FMeg0/lzefXuEPUKYMg4scGuFw4o/TB66b5ew /ZE7CZ1SfJdyd3Np3bvXEYu82Ld48zQ6uU6w9P1ENgD7HPpSI9LaGCvnK553j8HhLpTpmfj7 gZ7OsCXeZyZFaG1BbOH5m1/OdNcIf6bgJAKqqTePlj6biFjiGMvnRnzvqWta/I1T/2Qm0Hfr DY5nqKshtcajnPPAEudK5Mr2Ez/GiYbx4Em3MzdMF3i+sbateLFncmc3u/Nh3UjXTAC9YR9b NDUSNiUFbQmPWTZZIvVX/j2DlEevwcJGVea0hEDu1zSp5GjCbI7FLAvqjBCQUHmX5UgugnCq vSgwnIc+pIWHz8U157TZ5EHX58QkXs5qXYwbQB/3EjDkK3HHSHFkOCICY7Lefv1+sed4+fZU 3W9k3j8NWOuWBYrGrhrT6lO9F17kXvurL/U6VEr5ZAxuICZpGWu6XVpwfexiwZpGkGmHWc3J WJ4q8n5JtkQqK3O1C7DXVJ80X5DfqXywnG4aghPMxy3BHMXx9L9CEJqd0UyajEs+HoLYxb8j fusPnopLJrANJzZpoBqsEohMUZAVbSoVe9gS6S9Li7w8lSMIdIUHX2+XdzbLVqvUqC8kFrSI X20ZmxntxkCoTKAqGGVpCo1YrvR0gfsfNquCVm5EaqL5weOyM3rhlBG8QhMt/RJoyceU7OaH VB8BOfpwByOOvB3tdek9dtspOq5BFG7K7bGMxuHt6MTO4ZP/bsby6fKnLPx6mt9HAy4rhsoU MII9JkmQqUzywBhl8TVuk6DPAPoOpAwxMUm8yleaq8UVs3OYA2sSFzephT+/K8SKfNvSlbRX CoRrsjRqRbweCt+M/Wc7seB1muFb8IRy6IrHBd9tsy6evZZUkfdDkr4e6oCU4xRuu8SqeTB7 srzwLv9FwfNVB96hk2dKycFpqs/dFt2F/PpYI7oTl4h8m0RRUPQdkmoKBh4HuKIdMGmQXsUc G7/68JumfqcWLgE2t5dDyZ/JLmR2PIKF+j24kZmwY7hVZIvnL+jF6Wb18xx4gVhSG9jpgrJR vb8TWLPYtszZwqI0YQnSv7CHxIiVXag6KgNS4//3bKo33/fYHpvr6/V20lj1ONB8zuhLdKk6 LMsW8y4aO5hnI7PBAMUpzsbSaXEbbpoAcV8G7FqaS5o5amJH08FYHjBIaekU5Id+STYNa2Pe uRA4Tc7Fjg7aqSA4UCT7CSftlZWha4K9sB3NfVnMzRWEZrLuyrT+YLJB3f7HvEV4OsgfNMIa D542soB1ly7zTjzzQW/DQzqHA6nDreTXW2Ce7Gc+iMlHv3w7Em2XaoTLV6Kf/McjEDvKvg9X qA7zoQKVmW+FXXAczxbR1i90+7BzGMDr+hCd8tH8PGDDSLGbRmoaMoa77hF5xejIxJbO84XF YxSQMYMGKbeu/livgTSNLokDT1bzOwh+JPRo3PSh885DJnZ4k3fOL/3ppK7QONLDcQHVgntZ n2pqskc6rfFgmhoh6uwSwP9jg+XYniY6TIsZxLGsFLvEJuO3YHGBi0h9/G1VmvDCwvt3tVVJ ntXXCqOmVE+hyWYHeJG2FpjUZNXxaDrtjQVO6hPEeQk9d42RX6hJj7jQRjnFdPdm+uzhc0vS SmZszNOdxDDYxMbi6+xxmvptkTAGntQn9IqFo9Vx+D8Rt24JueV6hdfLRkPnolyQH4Qojp37 r0LWbLCV+JfLnPAxr9D3YcmpHFwF3PpClfwnDmqU/54LoKn8rN4e5DhOziUE/GezwlMWoUR5 lFs5bnJIugNNrzMGDmDFsiTwbLhG9qER6Kv2RugC/FZy7PP4C756JW0icgk2QR0dMm58cySI J8YfLZVbu4jeQC5m003QIdQAQvdfvc7BcPFSVKTzOgsuYE+o2CxkPoe1cbQvQP87ipEAXYEP 5R01O1LEiMsYbHyKCgo8AifQAQGqrz23wvjBCsgeswYK7SsrbrzjguRWJ72KpQQ8EAaiRBrc EFj3TcsFzHp005wlEFEwm4wz7F+NTpxr7Pg/dZUrKtneE/r8wwgT67sdiIZZOdNgOnGY3J8B RjNKDUWR8xIKNPto2GXttJBQL2/wyLHn7ExjBTh3VEqwE+zMakjccbQzHA7coCUoXhE6dW6o z+7JWbJ15QgXV05ipkbvTvEAXaLe5/Oez1h/+htNPLgDz7zULO39CPvKdW2NgpYTWbIFQkeT RFgpNccxu1JeB0fKiYJaal/WA1t37V8J/MzqGgd0zg203yT5NDGrLTC/nf3SbiobYE/VoHsu 0zUj+qiX3LEkLQBOqFgKa1IqT/SHS7buije5t4x0irnUqHHI7k+GTgQyq7Vx57QNn2EgaCYd 0LbqxU1GUnwBo12nHoqBDzC+QxREKKe9YxnCRbE85TnmMwoBwU3c27dy9t8vgU54lQ7UfTw+ ElM81gDJ1XVL4Qcp5qWii4xDvgQEHzFK3TnrVfH4FXwabMofrPO1KbdQm7DUKmN2mhGyCtC/ rqbI/tHt+BXFDU0wGJwsXROITBrOUSJTT0Lg31xKWF5zB90BjxUnFNEhBL1lCHlvwGRbhqqF XGq/2KeVwV1WVOfzOrc2KBymkJ0nqguCbN+6S40HU+piGzZvp/Gwh324+Hv+dVKsIZO/oOSF blaaN05eh7lB4D85Yw8UKa5t+JpKfW0nHlwOJlOk3CHBiuKLqMwhw8f6/K9ay6KDsfmbC3LA UoQegXDINA2+25QA98toYPGb8o36Ad3nDKdQgSqaYXpT+VubUSlC/SrcJfo3t8+eEiLqFTSO exK5+j/j87m2jJ7UI0J+JgjRUMmpMzNfGRhciluxvuDgWx3aawN3+OJlk6DgzOjAq8yzeeFd 9AdHy43PWUb6XSInSrkXj6S45eC4GvsLedqmqRPjji8DqBYBvek/fUGJr7SkelA+wZwgVP9J /uDJvqCgQZBgZoabRLrTQzQlC38pgWpsvn7Sw/OH5sKMPVwywHS69lCw9csGc96vZIQfZIgu /GeYCzliSWDx/HxkmteVgVf7bb3wh8fvlRZ8SoBx671jJNUU3ivxeTjPslEY5wSJ2YkaA5rp v9wNTVCxxgLSDASTCRTsdBy+Cs5ID31AmQzvzD+3VgaflZ2YrsIZ4AqT4fJDj3RyVPRPBmUB hHz9DMwxZhDpqcVJMIv2UBpD1xr624xDr6pXdId3PTHG39bjSO92ojuu44hGPevrkLVvDmGm CiKGx9Sj34ryHyPUfTAPjJ9hkk8RmWxXJMAenXakVHLJDboG3JJF6vLKKKqx2NIKGNKfTB6s h0+iZIFfyW2ul2YTAZjSFF5AL0FNH/EabsXMlfxPYSlQ2u4LG1do/ejQimDXoWfybNcDtiKJ Lrwi+77w/ahI8dwUpaQFpbF7c4I29iFtH6GOk7PGe8xRhxXIZw7nscf98goRcWBfES5OkUMe JkAmxXkycLVNQDaxBOJ2ziOVePwWKMTYiQflkgj8M6kiOumV5BOK/xe0L7Pwo2Jqn5m1FAEa QB1Drk3XOkd2kSFf42QSlYyWAl7C1rJWsZdhX1dWIS/DjzeBFq3bzOCClwgzwiXRN+VYIMc2 dcY80QBV4V54eDYZS4A0u8cNnqPL1tLbvREv0nVbTKBe0jwddhL8yXKSauUtA8qA+HX+oFQw rHpyPTvbIICxkYyukP6r7AFxIXHDMjOo5oe0rT+ZCGTd53XMjzkfhMbUX1uUUEAxw3R3PBYp 9tDKzKWA2GCQ+fA0FjHvtQaaIKwYsC/9tX2RECRtg7q4APouvjzUPOXrFCWiu4GmQrMZXcWE BvCt9h7f3WXS//1ELaIhxNUv5Q2AgIT3fid18DimIx3vjMMrD7+wSGF+4wgxS3Su+PYFoABT NWso2i2RGMOUm0P6wVFelkiul3AUWYEsAcZT9YlfsoPZpQIdRrzj9BrkDLCC6NO9V0ED8vqM XAtGq7/YfJIA9Ve3o3FWE9+NYYLd64vDWR5KqLD3xp3pI+wWvNQ9P104aCR+VhICfZY3LCyP veBU3VmzJKQHd+f/TiuCS84RYcr+EVR9pFuwEhJRnhAGK8J2KX0csKdPELMK5y1SgmAWqFQt h9qn1LJo45ZsNGCITbOuJlE/I2y/WaKX1yCfFZg5NDZxpUOvtViO5npKNgYLZ+/Tw5pvkhyo 5oR0rG6doFMZOuMu/4U2nWJ2NOYoFM5DpsvWTYFyGtSU73I7t11TjMgL6MqwqbTe5Ri++bGu ieoWNBDDemwoOYc8Zvm5S1dWzpbCGIDZAELTfGBI287DBbPICp7A7uAehoTBaUkEw+kGPZFI aWZ3qVZIjFRnVILxmpiHqWNklh0PDHi7rt0ZhPGhb3u1re0UKJh6fvg2W8e5bd9PQ2S2QyHA YTKOQ4TWQUF0TyEiD4jmKTdnhiWjLeLrIhECXrFlN/mAIbHBXZ5ysQIFro2kQKo4F2bsVTHU mz8h9tlCrZYrV8cFqdf6Zd1+Xer9RhVvAZO8XhXGoFFe7vH8evygmmT23jHrqSGpk/BaxYyT c3S/QN8konU6SYKoRWNk/bZuvTEEWcc4AFUUHDKm/g6sRhoJJRYtGKcJcNFiDKS86Y8fWYca dZCAHXKv2A+RSx3vmGo4BZ4bv3dBIHK3kbtJ0QY97RWI2cvvDMuneSosON3MPrCCiga4r9JE IRBpPfzEralt58HDoiBr544igCZ129wbHVNDPDubG9ZUN0qG4dCsB5ZLpGU7QYNItY3cgoZK NZKmS8MXWbv00UgZKFrl0yR2l2JwlBRr862yXTrjAPw5QflIwe4eiyVZfKOnvmRhN5RIS5C+ KpnY3n8nCjdUXcpmuWjKIdJfBPD0C/FPR35DbetpAvXzopu1rgrF4IvdSdKJXaf8ZfsTkHVw GaFgIq97T4Lf3PCIF0owQnga6Nyiyzoq9IJGNupFBGl5Zlo4Sudqnlo2Ny92vgSgtwggf6Nm L5bH5G98rxZAIuuvSTrhX3jAydG22wxXkshrbRL3EhryfBInqHinNYd1CqNxmRkU6eWyXcdw tz5TQaZKn2g7eIYuXrhqmDhwP7SFOhSWKd6dTPFg4vpGl6wDHfd1Hw1Dewn5Lktv71v/nEr0 9jYMMHq8MQpct2gZIIyXFNg1ncDjb18pEfWmRpoOkDadDJzc4PM1ViAPFGPatcIqX28k+w1L yIbxoiXMkPReEbBD7YbMTpCiM/6Tg01SeZ4EkFjounck/fgVjkn2XD9WO5Yp+8adwn2fV91T DyquRKXzH7zzW/BThACB8QYfsoV/LX6sjfGYlbei66/xL2ZqHIcJ8mkW0Itf6W9GDous5NVe f//wHqw/jDODL9IwexSFUgcyDg3JzkrNa/Hp4drW/cch5YpVdTFmHrYl1KLNwizS3gHGnP1A lsAEeYJCiYWrAgm/4NHi2wYhFQkGEeNOAQp0yHm0ciAjSZVyVquGGgg+oKbfevpWfUYuhMbF XcL66RMiELNwRPH8QMA+RNatpxn12biOfDwgjWTbjpu6cht2bDCMh8Q9k1x7jimctcjBiRqd URrw3XTbRgNFLTrgrSIYLP+c/bcHNwzOP+gS5yMOS0BRJ013DXyTnw3dNeZYlT43h2xaEE9/ A/xksIgyCv9/U4UnAky5lFB5yt/Ruj6jJ4V31XEnyqXZrhbk2ICZniWRxIw4BvOQ4xh3VkS5 k4kNRuvcmgcLsC9sGrcNhHzv5+E9UV8Un547p8GM0wALn9ebwx0o4bC+r4kw3MGwQPRSwXHB wWz+JY2VnEjNicOrFIndCMDpWd+BNPTAWG4Fl6OsEqahYIhcxJVPlGlWJ6G70v42PZ2XesMY n/6473PhNDpBZ/Dx5SasVsTlUOoUhrUfvT3jyBUaEbSpEabJR6A6hk19QzdHI2T4VKN8EqtV 7FCZIY0PQyDwEKJWdyEt5kmarLKfOnYIruleWP1D3ENfrI0H59vbaloGT290NK1jZec57l4n FAI8jgxhR4q4U/FfxJtoHeUNwMpFp78fRMAgygCPWUhtfN35dh0RSaIcv4WmtAF6KFPUqvxG Z64LxQTDtMh2gdOyXovVzfSi9CVCL9xX+rmPgyTfJ7p6S8iqIxRBfr71p4tivqlewNTABdur bMcu/ajkieVmEHPrAv5xnCqHD23JF8enueTGS+zFdFF1XYIfPE0wGVPCnMq0MqQ9bahNb3pm bvlBB+qZZ0EDDuj9U0pu46pTcREfMZsEo54h1/3ljfbLpdQodgOL8jFdJGqPZI8Xg/tYWT1i JpFIzAjoDLMGlAY+N4jbgsq8vU3MjRoaJdRhDk43wRGjDNevmuRAfiNjCwH5FJ4JDWbxVM1Y 5mMmKYiNOTllBGzvmh9gYIDQ102qB71qPt6lniwCR3rue+FFi4v3ch8Jo8y4PP866Ud8G4Po W8A1fBRJY0uWeV2jr7fhnq4xWuQ+5I8gFIesMDuHGAbJT9TdT9OdaEQEkxPGVOZRFDVWKbqE viHCWSDkGSMmhzIuGcfwiGTara8zWnXHlDxaf7ALEHhTp7Xnvpyo2ok4/yVcvfcm6xAP3fqe 5zDzB66Dspd02sZNrcl38QeaJF7Mmd5oWz2B0Aufl1ubfegDgQDoCed5x87ZCCqJt9OzwfIo X7Y3b4hKX1r818CAXUyGF5mrSjxqZhmwWo8bTFutbLv2i9GWNVGLvYmGE8NdIT0//YtOkOi7 1I2Qq2I7a/r1JbbIAflnLf8r/rSAelhF0TMBSY8qJX35xuGOX/BMWHKo16Nsnioegsx+PaZ/ 2ps4QvhiEm6EdQzQXD9HTAAFeqEiKsTHEBHduJjzxFhVR5k1l+DRLlx0Mbb/uSqaTyAuCOBh rv42W+Ia5M9htNmsv025C8eNlCIPN8AdKTeQGQLoEyr5uYCqR9doIoUpbtM8wnnOL7GD3vCh icd4C8Rw1DnFqI3oKF1VN8mMGQbPLZOW813N2AXowaBGQ4cf6lYJ/dFQrdSWjVjFTeLLnIvR s7Kh/22vzCyCgFmiQwlTJGNAXWjnAKrEm4727TZPnTVb4KYHEz7PHxbzXaqgJHGyyanPg/FB GQ0dxlFWw+n1ZimjORDE7nbxNRB593z95ujIKNVMZVJWKgWXFDgasndhJ0NSsuUqrTg4IV8+ EXh4krrjO/O2LGq4Dhwu6FJv5ezWRfGlXwjs8NnYQ2Mb+wpCB2pmo6X8Gy0hW7AbXbRvHISQ m/eRakEoz6Dn6pcbdAcSegXKtdzXrMjTxi04wGxOozubS5yv8bPuKM34PQB28ArvccpNCXJq 5Y4EPtk0SKohSUZIAo+7EaUjI89OtI8iDUntHe4KbRCEgp6pB+yBziAeO26EEbYVjng1BHPT yi3P0n0LmU6hYOYtGuoRpup6uCZ0svWzYJKbaUQ3eEj3NJ50Sn0ZO9l62NtgI4f+3b77arEf HNmZ+c4GdwuPv75YZC4ybvl/oWG7fhWwo3kfsEmJvH7UTuMQPUOMskTMmDXKagz9VWfhKqaz NgH8D72IBwU/sFDS08buU0H5pOoHdi8aTt0EgMMD7I6kMN+zB9tZCpurx6Yq6LMPfZDDW/Sv 9FMhH7cj6yxRD0FpFBwuat50C9yYKp2vvGUJuwQWSAO0z27tgYJ7yZqsXh1B59ujHGrKIRM5 lcrRAgluWjYc0KWMG+LmeqMvk4H6rSlQ/CeQxiBkgeg8lOQmBAXgWCZoCQ835P78zHL4gZmD ZbBa6uT3pwjON7P1ZIarGy2l8VdqBe3CLOqzxeWe3W1/77V7Hk5ovZCnZjhoxhZkedf8TMKa fGNAHUporBBKfANGqpbGm6WTfzYNYHAJMPg7avF0JvmL0t/F7r07h7OQhxkRKaPtjYzNzFcc +OSrR3eR2NjGIeQsteAoOnce6otz/U0TcUSD0dyGnv6fL70QChWPb9c6zwBBV3AgNF6tGpFk /ZJdR+yjbLq+RIi+dLiEOswIq4GABeyRG/jJvxUbFzKj/DXktSM4JhMiYoWN8ZvS2mxaQRJg QiRO4UGpD6heegeLei44VB2AJuKPbt6mHafH7yGnk+44o2eSwwG/eASakqj6zTHjExrFbJyV k4mJUxLaUV7QJytDsB407ubKOWW/YAgmbqiBlELcLp89hVDxIjbQ30C9eaDb53IazUsiJ3J7 9sC44sX3inH3OaCMLo8vpfm9CqeU5oVGRZQRE+FS86UV93KqVznGs5euKeHFBtlMKJczGI6u F45IxIjQODYJ+uekcEe97ifHDJdvUM7hauVEpo9SBGvtw4fbHh71Q7r6ywWqcE5u04ZYhhY/ MgUYQnV2f5aKanpP3r+I/Ll6+qHCFaGJhREZksAhwjsez4mtwqgWi3LiyuIS4UmQKrYlxiuD Qp7mY/2IRjfLiZxDL6kVwYbsLle/UttAAbhyNU93kzQqhDZLCxhg/DYS/CGXCAwpYzHSI5Rk PWJvcBRafs16LLiKN6lFCuMKq2vXjKkWNc9eQYMDfMX+Xvq+xsQ+bymCCbyyr1f7DAnSjzNH Sr8723xOapIWaHW4F5dluhVrAEHhduTXUxFIU76wpCqLkLdu5igjrgLV1Z4lVxwM4DF3XCu/ dZZZL2CUPGZeqhhN8nDm2RXt61iWNbUOxvFj7/QpvpYnuEuagYBP94vHOv0VGC/5Y5gkXtqU J71IXW6WqC2Fw6TFzKgVZ+17+f03/r31dNTPHlf8FctPNbMGA3h4EmIl2grLWEwgVKBktEKm B3I/P7FCgg88iBGTawFUtVyS+gYiqyrgsnSDxqc1WB+FPvJeyTKi5JNzegdiroNAMT6VmvIx AH7NOdcaZ6homGo6LETMXnaSb2Af/poy6BY5au1daRO1Yi4dxbBI08ycTlR5tXoHOqArv/Ob Lv+wQKevIIV62f6tLH7m+FubXLtn3r5Qe/XR2PQPjYvQ3w8wLzfJm2Pqqx8JOT/RcUPcy/Tl J70QDScMprLqcnXDQOAxVZuJOTLuO+Y2uFayOrdlwjO6SvzEMnxhr8lPlqQNho0jETHaGkaz OQk8RBMEgNBwFWU87vB+04u80rS7ru0oRtslTzwpxG+YX9gujLXyzUfwop5F5PM8m24PadyQ 2HzYcg5Ce5Yit19dqyi0UHMmY3LtfdjWvsci+A3miSI9k+a/OWHOgdg8UydJgCnA4R1GLoGl F5X9uKtf3GwxXSxICwZene0JkW9g4FoKaRttGJcVHA96cJ6dxCAvhtFQdddbKySV9sf1RmKv y/jj/8NX3NmSLQPwD6ITIHBVmuqXvOjkEuPnWtASouwFnnW1jFfA+VmpSEjwD4zT5mVD3Brm OhsMHP1cSM06DwnpkEXvgrtuuLzrMDkeetKcT5WedsuwNhZWbHmqpjip73CtRexcKGBRYPAP 5vawjBDeOHiGnP9Fuk1J+sYmjnZgH7OKYPJoKl51CYg0szLX0erFPpKShqpnTgW9Wt1pqYw+ tmPSL5CbTntTqqgXIb4KyjUxV4tAkozbbX3QmFUNgquEeJAXzGPW+4mKvRFiN5m9P+OfEyT6 eFWUHtpNXDegfD+oEz6IwII4s8AQ+n22L72+X1vCGdpxwT0cyZbo3uEds25AIMqHXaLyQkqH CMqlgK1FffOpfTXOCnrImUqPVgUb2VX62KOOiW9uAXUSXk3Hpzid+LRr1DZ5asv6CScjOlgK raRb3c/syz88Yyfx2Y6PqquhjFUnrQXXnKL1baVEbMnHja1a+BEoPKst0J3Fb7UV08AVgTZm RIwF603OfWASTiUmYXmn1rTPtF+/pHaZnpM/3N0bT4JB3koxbKUGRcK7+7Daqnc4sfZqDGiY Rk+ZxeMHM7QyRz+Z5cf+Yool1Qcxl/eowk4Tf1OTi1cNKMhrkhnFIpSwB/OntYCRebQGuF6A aKC3dLxszwDDvAi7xK5sJso9WprsNsy1yaJUsmvmC7uLpImTI2HAhOEYeknKsOt4Cz6RO3Nr o+NiZar6EfO41IQcVYu+P6MNqDNajUWwHuXOoR3J3o5oOesp0qoVj4l+CDIf5eOFI8XvBjNO WAE7OiKbY4QzmxfANFATIRsggJuRnuMsyd7l+WgwKGESx8YwN34O8QetXaRpEfxBvIiy8M6t P4uf+FqBP1nAFZvW2md6qu3VHMfIAKwdxErzT13WnrFMHoqVTLF1TI0GTxVg1ual/g1eufYU Ys1wRYRkEXERJ+xe01pVG1n3cLu9H3MI9+mqG9CeGqEbQSluYVnHxC7a7/fu0dk1+Bgud+4M UliBjh7TMtH3S8Ix/sxrz6KFx6LJD4nFpxVJHwS0gL4fMJnumb2zA61Kx68gYDO7eeszSCdz E0Sek7brbUIcDej+UxgPeVfx7XLGxoK4yv30WibwMFrqWMEUoE17TRJG6fZtoB/REHC7qodw OYxdPb2lAzhu4dwHLGLEmAHHTH478ujdvgo93BnUBUOboLJVGRj+1IH+w0v08BEx2X7P8V+w sqeLt3egOowP58mh6JWS1arbVdb576yfFh2rGNNfD1hPWUKXgtZCb6dnR8X/dxft9tQExfgT QFlOHY5d+076HfnI2lXujCdiLznyii1A2DyiG+WGwLAgBf8RagOQjdnc6VLgzs8lsHeWYTz6 cEwV9X6dr8stATF6qk642etGr+EaT1BXzzGvZKacBVRlYBLEPG0MlRbf7LqPJWW5nSM6MJlN 9Vi0qW9OLW6LX/IAeUQb5uCkRFBQsMkqO+F5sA1Daw1sg03X09kCKKUUyK1d0n5N5ntCdT9g iKH2jJDRXuU1qXZGgtuscigSNvR9yrZ3jawci8czDGJ5+FDVvmEznllKh4CWgecS8iqsHVfs x6Y5co6eSxoLq1/3TlS7El/68oZkuhofLdjtOKLYhJH0r4t6HHkLCiB7ZD0gkC/vWHkiHu6L i24SCPDULYmBLHCpbeH//qXWfxrXxlI7DaPMFth2NpynNwTE8TUXQblRJXJc2C8LnEaiVhh5 Vj7DMBBG9l/x2FlFyGuMHgmJJklJ4pYMMCA8a2D87cecI3YGb40yRswdG4f7RJHqaEX95MZX +Z1Z7qEP2b6AGTwXn4D8Eo5GilZXWMhc6rtV0D6mtpwkqi0mQ4u46klCkSghSEnX1mwwA7eT NThucK5lM4kplBL5Sr+5faGhIqbuPpHUGdU6b4ntPzG82smfzX+Yby+8Tx9q5Ur6W982+4ht obsgs4k5zPA/991krmi1GCAKqdcQNRbrHn2LSOx5UwP7RMGq36oGk9WFW2nj4xRlp+zlvQXw lbKepx4Lu2Vn9eEXkP99HsNSqcxkJUchviENN47xEaGRJJzuVesIf4vMpVrRlj2auzFHz0Pz z9YvuM0a/hGN+h/iRgGEpC5OPqOi5lPLBPkdGLHAPsVid8mP5gjf79tg6Z5+8y/Tp3I2HXgL D2QRr+rTBrop+CLr+FusrxAxiXGLa8oUKMcppEkNd6B7wRcEYhCbzPe7NPsS7sQAMnFH2jNX kIXfNyySuh6bAAEu0mzoXsurVN4nzZrvi0Im8xh/ZxxZRGg74POhlkXIfaSk0hQ7czYk47qO DDu+1vj0j2WPQWVY00y57nC+kY9L/4TIe2SbnLBMCTKfb7vytvjwL8Cu/FAvUODEs/6dE01s H7KEM5VKueykBHJmCSsnSDHAQO2IV+k8djqb/XFpQ1GJhgsGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAA AAAAAAAAAAAAAAAAAQAAAAAAWAAAANAQAQDoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAAAAIAAAAC4EwEAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAACoAACAAAAAAAAA AAAAAAAAAAABAAAAAADAAAAA4BQBACIAAAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAA gAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICA gAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAGAAAAAAAAAAAAAAAABgDMwAYAAAAA AAAAAAAAAADM//zAAAAAAAAAAAAAAADMx///zMAAAAAAAAAAAAAMwHf4/3fMAAAAAAAAAAAA zId38A93fMAAAAAAAAAADMiHd/APd3jMAAAAAAAABgyIh3cJEHd4jAYAAAAAAADMiId3CZB3 eIzAAAAAAAAAwIiHcBmRB3iIwAAAAAAAAMCIh3CZmQd4iMAAAAAAAADAiIcBmZkQeIjAAAAA AAAAwIiHCZmZkHiIwAAAAAAAAMCIgBmRmZEIiMAAAAAAAADAiICZkRmZCIjAAAAAAAAAwIgB mZAJmQCIwAAAAAAAAMCICZkPEJmQiMAAAAAAAADAgBmZD/GZkQjAAAAAAAAAwICZmQ/wmZEI wAAAAAAAAMAAmZD//wmZCMAAAAAAAADACZmQ//8ZmRDAAAAAAAAAwIiHd///d3iIwAAAAAAA AMCIAAf//3AACMAAAAAAAADAzMzMD/DMzMDAAAAAAAAAzMAADMAMAAAMwAAAAAAAAMAAAAAM wAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD/////////////////+D///+AP///AB///gAP//wAB//4AAP/8AAB/+AAAP/gAAD/4AAA/ +AAAP/gAAD/4AAA/+AAAP/gAAD/4AAA/+AAAP/gAAD/4AAA/+AAAP/gAAD/4AAA/+AAAP/gA AD/4AAA/+Hg+P/n+fz///////////ygAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD/ /wD/AAAA/wD/AP//AAD///8AAAAATEAAAAAAAExvbEAAAAAExvT2xAAAAEx3QUd8QAAGyHcZ F3jGAAyIdJmUeIwADIhxkZF4jAAMiEmUmUiMAAyISURJSIwADISZT0mUjAAMgZT/9JGMAAxJ lP/0mUwADIh3//d4jAAMzMzPzMzMAAwAAMzAAAwAAAAADAAAAAD8fwAA8B8AAOAPAADABwAA gAMAAIADAACAAwAAgAMAAIADAACAAwAAgAMAAIADAACAAwAAgAMAALx7AAD+/wAAAAABAAIA ICAQAAEABADoAgAAAQAQEBAAAQAEACgBAAACALNgA3hQoJ2JMagaY4ohwxIGD28TRVx5RRcb wVpvf1W5hIgYkzyuoT+4L4pqc5adCFW5uRW9CquXUZsYpFMJeE92crhre1EcUDk2UBc3g1EA lsTHAgYiIWu7aSqqbpi9sWJpIB2+pI62EhS7B20DSAEUC5USsG0LiGaSsSgaxUYoMD9vYZWE G0SJnFdAXHhOGIBKFU52CpaHZYI0nYBxsyCeEpktM3uUi8IyYTlWpFZTe2nBjxCLJG6sU7Og tsOwdyNQT6J0aHBkWEYYZCaUf8NGZiKBGH7DphgMoowRRp9FZyUEW35EQZ4in6egoghEtzGP ZWk4Hl9vTWNeKYJZQznHnCAZHyZeGqApdDmGDRRHnLWQW8OIjTxGa6A8UIZRObGyOXKUQRt0 cRCVQ2SdhVVnMmc/WaBUGzawIzBfDhYxaoCkOZscIJE0pCZzRaPGOBE9bZSZLAuDxxdUbEND lg5IaR5uZCAThzeOK7Z0VC8SKQRSG6SfmMK8kqTEm52piq5WeE/DDiUJcbl0ZbZimAeFkYeF RGhMjBcTFnu2ThQIgoJcfhGITcCGa2OeSXEaP0QfqTeva1/HEV1flyaYVxFIqcKkbb5FD41i flw/pBcdIlRPhKEWPGUDAXDFTRzCn5ISPzu1wlZvSoITYVgQiZgmBpM5RIWiUX+WWx14VQUf dKaBIGrEig+6lV0SmKEDUGWyME1nmIZLNH+ORTUdGiKitgw4fkizpzBSmJl7EmFCOjouwCcR MX6bYkHCHF0CrUxzejktfWdskyBcN4qIhaWjtMaaD2F5r4IFl4M/KHg1RVg7cSNYj1RSU2SB w8BGI1OhlkaHvGlHu6q0PimhBlanaQ86IXdLLKxdMyGhvWiLZVuKxURyXqQxXBoWbkqBVAwv rU2OCAwmMWdxTag8SY51jr2UM359aZ8xMmNUfcQ/O0tobB2qDRY9f48bDEI5bi2iellTaq80 R2BpISy9nS22GqwsgTJINUmiW2WbxK10EU6SiYSgn0A6RIgTh0YAMkUOhIEqeH9cQLPDqICm tyGwXzulgxuIZ2uvsWipYp1pGCSAooRROASAg7mZexdWi1ZfNMSwRmgjeQiZvRaEYialol5d gT1Om02RUiABinxyfChpCYRTAR13iFAbJKGGUhyOnhqEEZcQJoHEJFUOsipSqr2GG1VqnSNo PxgVYhJIpAYjFACGr6A0qIIvqVCrCqkAQzc5fyjBdiVlKDC8ji6LOiBUoxq/QE1+rwNrXUFq CYBaCrZVpA+GJVC9OwKLLYdVMLcNhbNruy1yXBaMQBkpGgG8gECyBqW5syQ5KVNylZWqIW18 PayqjxWdZiENP3kuh4W6x30wCIxDAHKDWWTDvU5nsGJjLYMUPF4BdMV2eRIQjQ8xuoKti2aZ pR1wNw== ----------ypnqwidqbuwyzhcefdii-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Oct 6 14:33:43 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20704 for ; Wed, 6 Oct 2004 14:33:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CFG7Q-0001no-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Oct 2004 13:02:28 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CFG7N-0001nS-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 06 Oct 2004 13:02:25 -0500 Received: from [144.254.112.193] (dhcp-edi-comm-144-254-112-193.cisco.com [144.254.112.193]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i96I2L114218 for ; Wed, 6 Oct 2004 20:02:21 +0200 (CEST) Message-ID: <4164332D.4060502@cisco.com> Date: Wed, 06 Oct 2004 20:02:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Improving the IPFIX option template format, not that scope is an normal information element? Content-Type: multipart/alternative; boundary="------------020601050500050203090206" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------020601050500050203090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, In the latest version of the IPFIX protocol draft, we modified the Option Template so that the scope now contains a normal Information Element. See http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt. See section 7.5.1 and 7.5.2 Now that this change is done, we see a small discrepancy in the different Set formats The Template Set specifies the Field Count 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | * Field Count * | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1 | Field Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2 | Field Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type N | Field Length N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 257 | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1 | Field Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2 | Field Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type M | Field Length M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Options Template Set Format specifies Option Scope Length and Option Length, as opposed to number of Fields like in the Template Set 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | *Option Scope Length * | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * Option Length * | Scope 1 Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length | Scope 2 Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 2 Field Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Scope N Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Enterprise Number | Option 1 Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Option M Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option M Field Length | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We propose a new definition of the Options Template Set Format, with Field Count (total number of fields) and Scope Field Counter. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | *Field Count * | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * Scope Field Count * | Scope 1 Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length | Scope 2 Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 2 Field Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Scope N Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Enterprise Number | Option 1 Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Option M Field Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option M Field Length | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field Count Number of fields in this Option Template Record. Because a Option Template Set usually contains multiple Template Records, this field allows the Collecting Process to determine the end of the current Option Template Record and the start of the next. Scope Field Count Number of scope fields in this Option Template Record. Any feedback. Regards, Stewart and Benoit. --------------020601050500050203090206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

In the latest version of the IPFIX protocol draft, we modified the Option Template so that the scope now contains a normal Information Element.

See http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt. See section 7.5.1 and 7.5.2

Now that this change is done, we see a small discrepancy in the different Set formats
 
The Template Set specifies the Field Count 
       0                   1                   2                   3  
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Set ID = 2           |          Length               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      Template ID 256          |         Field Count           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 1           |         Field Length 1        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    Enterprise Number  1.1                     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 2           |         Field Length 2        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type N           |         Field Length N        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
      |                    Enterprise Number  1.N                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      Template ID 257          |         Field Count           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 1           |         Field Length 1        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 2           |         Field Length 2        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    Enterprise Number  2.2                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type M           |         Field Length M        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    Enterprise Number  2.M                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                          Padding (opt)                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Options Template Set Format specifies Option Scope Length and Option Length, as opposed to number of Fields like in the Template Set
    
       0                   1                   2                   3  
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Set ID = 3           |          Length               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Template ID           |      Option Scope Length      |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Option Length          |      Scope 1 Field Type       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Scope 1 Field Length      |      Scope 2 Field Type       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Scope 2 Field Length      |             ...               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |            ...                |      Scope N Field Type       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Scope N Field Length      |         Scope N ...           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    ... Enterprise Number      |      Option 1 Field Type      |       
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    Option 1 Field Length      |           Option 1 ...        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    ... Enterprise Number      |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |       Option M Field Type     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Option M Field Length     |         Padding (opt)         |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  


We propose a new definition of the Options Template Set Format, with Field Count (total number of fields) and Scope Field Counter. 

       0                   1                   2                   3  
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Set ID = 3           |          Length               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Template ID           |         Field Count           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Scope Field Count      |      Scope 1 Field Type       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
      |     Scope 1 Field Length      |      Scope 2 Field Type       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Scope 2 Field Length      |             ...               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |            ...                |      Scope N Field Type       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Scope N Field Length      |         Scope N ...           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    ... Enterprise Number      |      Option 1 Field Type      |       
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    Option 1 Field Length      |           Option 1 ...        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    ... Enterprise Number      |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |       Option M Field Type     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Option M Field Length     |         Padding (opt)         |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

     Field Count 
           Number of fields in this Option Template Record.  Because a 
           Option Template Set usually contains multiple Template Records, 
           this field allows the Collecting Process to determine the 
           end of the current Option Template Record and the start of the 
           next. 

     Scope Field Count 
           Number of scope fields in this Option Template Record. 

Any feedback.

Regards, Stewart and Benoit.
--------------020601050500050203090206-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Oct 7 11:30:18 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26819 for ; Thu, 7 Oct 2004 11:30:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CFZfs-0005gX-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Oct 2004 09:55:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CFZff-0005em-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 07 Oct 2004 09:55:07 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2004 17:06:21 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97Et3V8014944 for ; Thu, 7 Oct 2004 16:55:04 +0200 (MEST) Received: from cisco.com (dhcp-edi-comm-144-254-112-222.cisco.com [144.254.112.222]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA10914; Thu, 7 Oct 2004 15:55:02 +0100 (BST) Message-ID: <416558C6.1030501@cisco.com> Date: Thu, 07 Oct 2004 15:55:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Data representation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit There is a problem with the definition of the data-type representation in the IPFIX protocol specification. The info model is just that, it concerns itself with the definition of information, not with its representation. The protocol spec deals with the representation of information elements, but needs to be written in such a way that it does not have to delve into the myriad of protocol definitions that exist, and clearly states how new types will be represented. In the draft as it stands we started to call out a few type definitions in detail, but this is essentially a task without end. I propose that we simply include the following statement in the protocol spec and deleted all other text related to the external representation of information elements. "Information elements MUST be sent in canonical format in network byte order." NBO is the convention that the IETF uses for all of its protocol specs. In practical terms it means that an implementation can just grab data from the wire and send it back out. The use of the word "canonical" gives clear direction about what to do with objects like MAC addresses which have two on the wire formats (the Token Ring problem). NBO is big-endian and therefore specifies the external representation of IPFIX specific numeric types such as counters etc. So is the sentence I suggest above the necessary and sufficient definition for our purposes? - Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Oct 8 07:13:38 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14803 for ; Fri, 8 Oct 2004 07:13:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CFsPJ-0000OF-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Oct 2004 05:55:29 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CFsPE-0000NH-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 08 Oct 2004 05:55:24 -0500 Received: from [193.175.133.240] (kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i98AtGD02812; Fri, 8 Oct 2004 12:55:16 +0200 (MEST) Message-ID: <41667214.2050409@fokus.fraunhofer.de> Date: Fri, 08 Oct 2004 12:55:16 +0200 From: Lutz Mark User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Improving the IPFIX option template format, not that scope is an normal information element? References: <4164332D.4060502@cisco.com> In-Reply-To: <4164332D.4060502@cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, > We propose a new definition of the Options Template Set Format, with Field Count (total number of fields) and Scope Field Counter. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID | *Field Count * | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | * Scope Field Count * | Scope 1 Field Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Field Length | Scope 2 Field Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 2 Field Length | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Scope N Field Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope N Field Length | Scope N ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Enterprise Number | Option 1 Field Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option 1 Field Length | Option 1 ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Enterprise Number | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Option M Field Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option M Field Length | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ yes it makes sense the change from length to count. You also suggest to change the sequence of 'field count' and 'scope field count'. Does the field count now specify the number of fields in the template record including the scope fields? Regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Oct 8 07:52:18 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16820 for ; Fri, 8 Oct 2004 07:52:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CFsx3-0004SX-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Oct 2004 06:30:22 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CFswy-0004Rz-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 08 Oct 2004 06:30:16 -0500 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 08 Oct 2004 21:42:49 +1000 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i98BTvRJ025862; Fri, 8 Oct 2004 21:29:58 +1000 (EST) Received: from cisco.com (ams-clip-vpn-dhcp30.cisco.com [10.61.64.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA13195; Fri, 8 Oct 2004 12:30:04 +0100 (BST) Message-ID: <41667A3C.2030206@cisco.com> Date: Fri, 08 Oct 2004 12:30:04 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Improving the IPFIX option template format, not that scope is an normal information element? References: <4164332D.4060502@cisco.com> <41667214.2050409@fokus.fraunhofer.de> In-Reply-To: <41667214.2050409@fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz Mark wrote: > yes it makes sense the change from length to count. > > You also suggest to change the sequence of 'field count' > and 'scope field count'. Does the field count now > specify the number of fields in the template record including > the scope fields? > > Yes, field count is TOTAL count including scope field count. - Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Oct 8 11:40:04 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05489 for ; Fri, 8 Oct 2004 11:40:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CFwhv-0006zB-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Oct 2004 10:30:59 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CFwho-0006xT-00 for ipfix@net.doit.wisc.edu; Fri, 08 Oct 2004 10:30:52 -0500 Date: Fri, 8 Oct 2004 10:30:52 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] RFC 3917 on Requirements for IP Flow Information Export (IPFIX) Message-ID: <20041008103052.A24043@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-F-NOACNT, operation requires ACNT privilege X-Shakespearean-Insult: Thou warped flap-mouthed bum-bailey Precedence: bulk Sender: majordomo listserver IPFIXers, Here's the announcement for our requirements RFC. Thanks much to the editors and contributors for bringing this document to completion! Dave & Nevil ----- Forwarded message from rfc-editor@rfc-editor.org ----- A new Request for Comments is now available in online RFC libraries. RFC 3917 Title: Requirements for IP Flow Information Export (IPFIX) Author(s): J. Quittek, T. Zseby, B. Claise, S. Zander Status: Informational Date: October 2004 Mailbox: quittek@netlab.nec.de, zseby@fokus.fhg.de, bclaise@cisco.com, szander@swin.edu.au Pages: 33 Characters: 81615 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-reqs-16.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3917.txt This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This document is a product of the IP Flow Information Export Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ----- End forwarded message ----- -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Oct 13 16:36:07 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04037 for ; Wed, 13 Oct 2004 16:36:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CHpPI-0005Lb-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Oct 2004 15:07:32 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CHpOq-0005Ii-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 13 Oct 2004 15:07:05 -0500 Received: from [171.71.213.16] (dhcp-171-71-213-16.cisco.com [171.71.213.16]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9DK72108044 for ; Wed, 13 Oct 2004 22:07:03 +0200 (CEST) Message-ID: <416D8AE6.5010404@cisco.com> Date: Wed, 13 Oct 2004 22:07:02 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] how to distinguish key and non-key fields? proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, From RFC3917 "But in any case, a collecting process must be able to clearly identify, for each received flow record, which set of properties was used for distinguishing this flow from other ones." Here is a proposal: send an option template record composed of 3 information elements - scope = data template ID - ipfixoption = FLOW-KEY (*) - keyslist (**) (*) ipfixoption is defined in section 8 "Specific Reporting Requirements" of draft-ietf-ipfix-protocol-05.txt. We would simply need a new value. (**) a bitmap information element. That would a special information element that would contain a "1" at the positions of the flow keys. If flow keys are in position 3, 5, 6: it would be 00101100000000000. That could even be a variable length information element, if needed. This feature should be inserted in the IPFIX protocol draft as a MAY, as a new subsection of section 8 "Specific Reporting Requirements" If implemented, "The Template Record SHOULD be sent before the associated Option Template Record, and before and Flow Data Records. In case of unreliable transport protocol, the Template Record and Option Template Record SHOULD be sent in the same Export Packet" We should also define ipfixoption and keyslist in [IPFIX-INFO]. Any feedback? Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Oct 19 09:31:49 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24399 for ; Tue, 19 Oct 2004 09:31:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CJta3-0005ly-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Oct 2004 07:59:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CJtZu-0005jA-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 19 Oct 2004 07:59:03 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2004 15:13:44 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9JCwdSf014264 for ; Tue, 19 Oct 2004 14:58:40 +0200 (MEST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-89.cisco.com [64.103.65.89]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA09623; Tue, 19 Oct 2004 13:58:37 +0100 (BST) Message-ID: <41750F7D.4020606@cisco.com> Date: Tue, 19 Oct 2004 13:58:37 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Proposed TCP section Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I have extracted the key elements of the mechanism described in to carry IPFIX over TCP, and propose that this text be incorporated in the IPFIX protocol draft. Please can you comment ASAP so that Benoit and I can incorporate into the next rev of the protocol draft. - Stewart ISSUES 2.1 Handshake Should we introduce a handshake sequence at the start of the connection? A simple ASCII-based handshake could be used to request TLS. 2.2 TLS It would make sense to add TLS support even in the absence of a handshake. It would be the responsibility of the collector (connection initiator) to know whether TLS setup is required. --------------------------------------------------------------- 5.2 TCP This section describes how IPFIX can be transported over TCP [TCP]. 5.2.1 Congestion Avoidance TCP will detect congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limit the transfer rate accordingly. When an IPFIX Exporting Process has records to export, but detects that transmission by TCP is temporarily impossible, it can either wait until sending is possible again, or it can decide to drop the record. In the latter case, the dropped export data MUST be accounted for, so that the amount of dropped export data can be reported. 5.2.2 Reliability TCP provides an intrinsically reliable delivery service from the IPFIX Exporting Process to the IPFIX Collecting Process. 5.2.3 MTU TCP provides the required IPFIX Message fragmentation service based on path MTU discovery. 5.3.4 Exporting Process The following sections describe how an IPFIX-over-TCP connection is created, how IPFIX data is transferred over it, and how a connection is to be terminated. 5.3.4.1 Connection Establishment The IPFIX Exporting Process initiates a TCP connection to the IPFIX Collecting Process. By default, the Collecting Process listens for connections on TCP port XXXX (to be assigned by IANA). It MUST be possible to configure both the Exporting and Collecting Processes to use a different TCP port. An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). 5.3.4.2 Connection Release When an Exporting Process has no more IPFIX Messages to send, it SHOULD close the TCP connection. When a Collecting Process no longer wants to receive IPFIX messages, it SHOULD close the TCP connection, but SHOULD continue to receive and process IPFIX messages until the Exporting Process has closed its end. When an Collecting Process detects that the TCP connection to the Exporting Process is broken, it MUST continue to listen for a new connection. When an Exporting Process detects that the TCP connection is abnormally terminated, it SHOULD try to re-establish the connection. Connection timeouts SHOULD be configurable. 5.3.4.3 IPFIX Message Encoding TCP provides message boundary marking marking mechanism. When IPFIX Message are sent over a TCP connection, the LENGTH field in the IPFIX Message header defines the end of each message and the start of the next message. If an Exporting Process exports data from multiple Observation Domains, it should be careful to choose the IPFIX Message lengths appropriately to avoid head-of-line blocking between different Observation Domains. 5.3.4.4 Templates New Template Records SHOULD be transmitted as soon as they are created on the Metering Process, and preferably before any associated Flow and Options Data Record is transmitted. The Collecting Process SHOULD accept Flow and Options Data Records without the associated Template Record. A Collecting Process MUST record all Template and Option Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records. 5.3.5 Fail-over If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish a connection, the Exporting Process should retry. The retry schedule SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold. If Collecting Process fail-over is supported by the Exporting Process a second TCP connection MAY be opened in advance. ------------------------------------------------ TCP specific security considerations Because there is no handshake protocol once a TCP connection is established, negotiation-based transport-layer security protocols such as TLS [RFC2246] cannot be used in a straightforward manner to ensure authenticity and confidentiality. Exporters and collectors MUST implement IPSEC [RFC2401] with the Authentication Header (AH) [RFC2402] to ensure authenticity of the exporter and the collector. Exporters SHOULD implement IPSEC Encapsulating Security Payload (ESP) [RFC2406] to ensure confidentiality of the exported data. The use of AH and ESP MUST be configurable for each exporter/collector pair. It MUST be possible to configure, an Exporting Process to authenticate itself to the Collecting Process. This authentication mechanism SHOULD be capable of using strong identities such as IKE [RFC2409] public-key certificates or pre-shared keys. A Collecting Process SHOULD detect and log unauthorized connection attempts. ------------------------------------------------- IANA Considerations IANA should assign a well-known TCP port number for IPFIX over UDP, TCP and SCTP. It is recommended that the same well-known port number is used as a default for all three transport protocols. EDITOR NOTE: once the SCTP, TCP and UDP ports are assigned, The text in this draft might be updated. ------------------------------------------------------- Normative references [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Informative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Oct 19 09:44:29 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25203 for ; Tue, 19 Oct 2004 09:44:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CJtsA-0007Ma-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Oct 2004 08:17:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CJts1-0007Ll-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 19 Oct 2004 08:17:45 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2004 15:32:40 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9JDHeSf019632 for ; Tue, 19 Oct 2004 15:17:41 +0200 (MEST) Received: from cisco.com (dhcp-rea-gp250-64-103-65-89.cisco.com [64.103.65.89]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA10282; Tue, 19 Oct 2004 14:17:40 +0100 (BST) Message-ID: <417513F4.4070306@cisco.com> Date: Tue, 19 Oct 2004 14:17:40 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] info decurity Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I would like to propose that the following text be added to the security section of the IPFIX protocol draft - Stewart When an information element containing end-user payload information is exported it SHOULD be transmitted to the Collecting Process using a means that secures it's contents against eavesdropping. Suitable mechanisms include the use of either a direct point-to-point connection or the use of an encryption mechanism. It is the responsibility of the Collecting Process to provide a satisfactory degree of securtity for this collected data, including, if necessary, anonymisation of any reported data. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Oct 20 07:33:46 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23764 for ; Wed, 20 Oct 2004 07:33:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKEMC-0006ZK-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Oct 2004 06:10:16 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CKEKe-0006Qg-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 20 Oct 2004 06:08:40 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4263.cisco.com [10.61.80.166]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9KB8c119859; Wed, 20 Oct 2004 13:08:38 +0200 (CEST) Message-ID: <41764736.8060607@cisco.com> Date: Wed, 20 Oct 2004 13:08:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu CC: Benoit Claise Subject: Re: [ipfix-protocol] how to distinguish key and non-key fields? proposal References: <416D8AE6.5010404@cisco.com> In-Reply-To: <416D8AE6.5010404@cisco.com> Content-Type: multipart/alternative; boundary="------------040908030100000607070407" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040908030100000607070407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the proposed text, based on the next section 8, as just proposed on the email alias. *8.3 The Flow Keys Option Template * *The Flow Keys Option Template specifies the flow keys used by the* *Metering Process for the Template ID definition.* *It contains the following Information Elements [IPFIX-INFO]:* * ipfixOption The value is FLOW_KEY* * keyList Bitmap with the positions of the flow keys* * in the template* * time The time at which the record was generated * ** *The Scope Field specified in the Option Template Record is the Template ID * *with which the flow keys are associated.* * *Note that the ipfixOption, keyList, and time are not yet specified in [IPFIX-INFO] Regards, Benoit. > Dear all, > >> From RFC3917 > > "But in any case, a collecting process must be able to clearly > identify, for > each received flow record, which set of properties was used for > distinguishing this flow from other ones." > > Here is a proposal: send an option template record composed of 3 > information elements > - scope = data template ID > - ipfixoption = FLOW-KEY (*) > - keyslist (**) > > (*) ipfixoption is defined in section 8 "Specific Reporting > Requirements" of draft-ietf-ipfix-protocol-05.txt. We would simply > need a new value. > (**) a bitmap information element. That would a special information > element that would contain a "1" at the positions of the flow keys. If > flow keys are in position 3, 5, 6: it would be 00101100000000000. That > could even be a variable length information element, if needed. > This feature should be inserted in the IPFIX protocol draft as a MAY, > as a new subsection of section 8 "Specific Reporting Requirements" > If implemented, "The Template Record SHOULD be sent before the > associated Option Template Record, and before and Flow Data Records. > In case of unreliable transport protocol, the Template Record and > Option Template Record SHOULD be sent in the same Export Packet" > > We should also define ipfixoption and keyslist in [IPFIX-INFO]. > > Any feedback? > > Regards, Benoit. > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ --------------040908030100000607070407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

Here is the proposed text, based on the next section 8, as just proposed on the email alias.

8.3 The Flow Keys Option Template

The Flow Keys Option Template specifies the flow keys used by the
Metering Process for the Template ID definition.
It contains the following Information Elements [IPFIX-INFO]:

ipfixOption The value is FLOW_KEY
keyList Bitmap with the positions of the flow keys
in the template
time The time at which the record was generated

The Scope Field specified in the Option Template Record is the Template ID
with which the flow keys are associated.


Note that the ipfixOption, keyList, and time are not yet specified in [IPFIX-INFO]

Regards, Benoit.
Dear all,

From RFC3917
  "But in any case, a collecting process must be able to clearly identify, for
  each received flow record, which set of properties was used for
  distinguishing this flow from other ones."

Here is a proposal: send an option template record composed of 3 information elements
  - scope = data template ID
  - ipfixoption = FLOW-KEY (*)
  - keyslist (**)

(*) ipfixoption is defined in section 8 "Specific Reporting Requirements" of draft-ietf-ipfix-protocol-05.txt. We would simply need a new value.
(**) a bitmap information element. That would a special information element that would contain a "1" at the positions of the flow keys. If flow keys are in position 3, 5, 6: it would be 00101100000000000. That could even be a variable length information element, if needed.
This feature should be inserted in the IPFIX protocol draft as a MAY, as a new subsection of section 8 "Specific Reporting Requirements"
If implemented, "The Template Record SHOULD be sent before the associated Option Template Record, and before and Flow Data Records. In case of unreliable transport protocol, the Template Record and Option Template Record SHOULD be sent in the same Export Packet"

We should also define ipfixoption and keyslist in [IPFIX-INFO].

Any feedback?

Regards, Benoit.




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--------------040908030100000607070407-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Oct 20 07:33:51 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23783 for ; Wed, 20 Oct 2004 07:33:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKEKL-0006Oq-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Oct 2004 06:08:21 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CKEKC-0006Nq-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 20 Oct 2004 06:08:12 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4263.cisco.com [10.61.80.166]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9KB6P118123 for ; Wed, 20 Oct 2004 13:06:25 +0200 (CEST) Message-ID: <417646B1.7070501@cisco.com> Date: Wed, 20 Oct 2004 13:06:25 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-21: metering process statistics option template Content-Type: multipart/alternative; boundary="------------000001050109020505080301" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------000001050109020505080301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, The IPFIX protocol version 5 lists this remaining issue. http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt PROTO-21: Do we need to define some mandatory content of the metering process statistics option template? - Maurizio suggested text on the mailing list - proposal after IETF60: look at what is required in [IPFIX- REQ], and come up with a minimum set of data types. Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed for the metering process statistics The text in section "8.1 The Metering Process Statistics Option Template" is not complete: *8.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template defines the Metering Process Statistics with the export of the following Information Elements [IPFIX-INFO]: ipfixOption The value MUST be METER_STATS observationDomain Source ID lostFlows Flows not exported due to resource starvation lostFlowsPackets Packets in the lost Flows lostFlowsBytes Bytes in the lost Flows droppedPacketCount Packets dropped by Metering Process at the Observation Point droppedByteCount Bytes dropped by Metering Process at the Observation Domain time; When this record was generated The minimum set of Information Element in the Metering Process Statistics Option Template is: ipfixOption, observationDomain, lostFlows, time * <>**I think this version comes from discussion between Maurizio and I, but I'm not too sure anymore, as this is pretty old. Maurizio proposed some new text at http://ipfix.doit.wisc.edu/archive/2407.html We should discuss whether we need some mandatory information element exported. If yes, which one? I reviewed the IPFIX requirement draft http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the applicable sections are: 5.1. Reliability The metering process must either be reliable or the absence of reliability must be known and indicated. The metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process. If, e.g. due to some overload, not all passing packets can be included into the metering process, then the metering process must be able to detect this failure and to report it. 6.5. Regular Reporting Interval The exporting process should be capable of reporting measured traffic data regularly according to a given interval length. 6.3.2 -> discusses also the data transfer reliability: somehow related. A couple of points to Maurizio's proposal, that leads to the simplified proposal below: - I don't think we need to export the Observation Domain ID, as the scope field will determine whether the scope is the interface, the Observation Domain ID, etc... - There are 2 different requirements in RFC3917, so we should have 2 different options template records - I think we should remove the MUST, SHOULD, MAY requirement in the flow expiration section because the requirements imposed constraints on the metering process, and we are standardizing the IP Flow Information eXport. As a consequence, we should not put MUST, SHOULD, MAY requirements on the Metering Process in order to export those Option Templates. - If you have a metering process resource starvation how can you know how many flows have been lost? It is impossible to determine how many packets are in that flow because you can not keep flow information. All you can do is keep the count of how many packets and bytes that did not fit into the flow table. Here is the text I propose. * 8. Specific Reporting Requirements Some specific Options Templates and Options Templates Records are necessary to provide extra information about the Flow Records and about the Metering Process. The ipfixOption Field [IPFIX-INFO], always included in these specific Options Templates, defines the type of information sent in the Option Template / Option Template Record pair. For example, if the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option Template will specify information about the Metering Process statistics. The Option Template and Option Template Records defined in these sub-sections are not mandatory to implement as they impose some constraints about the Metering Process implementation: this document specifies the protocol to export the records, not the Metering Process implementation. However, if the specific Option Templates are implemented, they should implemented as specified in these sub-sections. In any case, if the ipfixOption Information Element is present, it MUST always be the first Information Element in the Option Template so that the Collector can quickly determine which specific Option Template Record is received. The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates. ** 8.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template specifies the Metering Process Statistics. It contains the following Information Elements [IPFIX-INFO] ipfixOption The value is METERING_STATS exportedOctetCount The number of all octets reported by the Exporting Process to the Collecting Process. exportedPacketCount The number of all packets reported by the exporting process to the Collecting Process. ** exportedFlowCount The number of all flows records reported by the Exporting Process to the Collecting Process.** * * time The time at which the record was generated The Exporting Process should export the Metering Process Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. The **Metering Process Statistics Option Template could be extended with other Information Elements.*** * * *8.2 The Exporter Reliability Statistics Option Template ** The Exporter Reliability Option Template specifies information about lack of reliability in the Metering and Exporting process. **It contains the following Information Elements [IPFIX-INFO]:* * ipfixOption The value is RELIABILITY_STATS ** droppedFUPacketCount Packets dropped by Metering Process ** droppedFUOctetCount Bytes dropped by Metering Process** * * droppedFlows Number of flow records lost due to resources starvation at Exporting Process ** time The time at which the record was generated ** * *The Exporting Process should export the Exporter Reliability Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. **The **Exporter Reliability Statistics **Option Template could be extended with other Information Elements. *Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO] Regards, Benoit. * * --------------000001050109020505080301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,
The IPFIX protocol version 5 lists this remaining issue.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt

 PROTO-21: Do we need to define some mandatory content of the 
   metering process statistics option template? 
       - Maurizio suggested text on the mailing list 
       - proposal after IETF60: look at what is required in [IPFIX-
   REQ], and come up with a minimum set of data types. 
   Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed 
   for the metering process statistics

The text in section "8.1 The Metering Process Statistics Option Template" is not complete:


 8.1      The Metering Process Statistics Option Template 
 
   The Metering Process Statistics Option Template defines the Metering 
   Process Statistics with the export of the following Information 
   Elements [IPFIX-INFO]: 
       ipfixOption             The value MUST be METER_STATS 
       observationDomain       Source ID 
       lostFlows               Flows not exported due to resource   
                               starvation 
       lostFlowsPackets        Packets in the lost Flows 
       lostFlowsBytes          Bytes in the lost Flows  
       droppedPacketCount      Packets dropped by Metering Process  
                           at the Observation Point 
   droppedByteCount        Bytes dropped by Metering Process at the  
                                Observation Domain 
        time;                   When this record was generated 
 
   The minimum set of Information Element in the Metering Process 
   Statistics Option Template is: ipfixOption, observationDomain, 
   lostFlows, time
<>I think this version comes from discussion between Maurizio and I, but I'm not too sure anymore, as this is pretty old. Maurizio proposed some new text at http://ipfix.doit.wisc.edu/archive/2407.html

We should discuss whether we need some mandatory information element exported. If yes, which one? I reviewed the IPFIX requirement draft http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the applicable sections are:
5.1. Reliability

The metering process must either be reliable or the absence of
reliability must be known and indicated. The metering process is
reliable if each packet passing the observation point is metered
according to the configuration of the metering process. If, e.g. due
to some overload, not all passing packets can be included into the
metering process, then the metering process must be able to detect
this failure and to report it.
6.5. Regular Reporting Interval

The exporting process should be capable of reporting measured traffic
data regularly according to a given interval length.

6.3.2 -> discusses also the data transfer reliability: somehow related.
A couple of points to Maurizio's proposal, that leads to the simplified proposal below:
- I don't think we need to export the Observation Domain ID, as the scope field will determine whether the scope is the interface, the Observation Domain ID, etc...
- There are 2 different requirements in RFC3917, so we should have 2 different options template records
- I think we should remove the MUST, SHOULD, MAY requirement in the flow expiration section because the requirements imposed constraints on the metering process, and we are standardizing the IP Flow Information eXport.
  As a consequence, we should not put MUST, SHOULD, MAY requirements on the Metering Process in order to export those Option Templates.
- If you have a metering process resource starvation how can you know how many flows have been lost? It is impossible to determine how many packets are
in that flow because you can not keep flow information. All you can do is keep the count of how many packets and bytes that did not fit into the
flow table.


Here is the text I propose.

 8.     Specific Reporting Requirements 
    
   Some specific Options Templates and Options Templates Records are 
   necessary to provide extra information about the Flow Records and 
   about the Metering Process.   
    
   The ipfixOption Field [IPFIX-INFO], always included in these 
   specific Options Templates, defines the type of information sent in 
   the Option Template / Option Template Record pair.  For example, if 
   the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option 
   Template will specify information about the Metering Process 
   statistics. 

   The Option Template and Option Template Records defined in these sub-sections 
   are not mandatory to implement as they impose some constraints about 
   the Metering Process implementation: this document specifies the protocol
   to export the records, not the Metering Process implementation.
   However, if the specific Option Templates are implemented, they should 
   implemented as specified in these sub-sections.  In any case, if the 
   ipfixOption Information Element is present, it MUST always be the first 
   Information Element in the Option Template so that the Collector
   can quickly determine which specific Option Template Record is received.
     
   The minimum set of Information Elements is always specified in these 
   Specific IPFIX Options Templates.  Nevertheless, extra Information 
   Elements may be used in these specific Options Templates.    

8.1      The Metering Process Statistics Option Template 
 
The Metering Process Statistics Option Template specifies the Metering 
Process Statistics. It contains the following Information 
Elements [IPFIX-INFO] 
     ipfixOption             The value is METERING_STATS 
     exportedOctetCount      The number of all octets reported 
                             by the Exporting Process to the
                             Collecting Process.
     exportedPacketCount     The number of all packets reported 
                             by the exporting process to the
                             Collecting Process.
     exportedFlowCount       The number of all flows records 
                             reported by the Exporting Process
                             to the Collecting Process. 
     time                    The time at which the record was generated 
 
The Exporting Process should export the Metering Process Statistics Option 
Template Record on a regular basis or based on some export policy. 
This periodicity or export policy should be configurable. The Metering 
Process Statistics Option Template could be extended with other Information 
Elements.

 8.2      The Exporter Reliability Statistics Option Template 

The Exporter Reliability Option Template specifies information 
about lack of reliability in the Metering and Exporting process.
It contains the following Information Elements [IPFIX-INFO]:

     ipfixOption             The value is RELIABILITY_STATS
     droppedFUPacketCount    Packets dropped by Metering Process
     droppedFUOctetCount     Bytes dropped by Metering Process 
     droppedFlows            Number of flow records lost due to resources 
                             starvation at Exporting Process
     time                    The time at which the record was generated 

The Exporting Process should export the Exporter Reliability Statistics Option 
Template Record on a regular basis or based on some export policy. This periodicity or
export policy should be configurable. The Exporter Reliability Statistics Option 
Template could be extended with other Information Elements.

Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO]

Regards, Benoit.
--------------000001050109020505080301-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Oct 20 15:07:16 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12705 for ; Wed, 20 Oct 2004 15:07:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKLWp-0006MS-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Oct 2004 13:49:43 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CKLWl-0006Ll-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 20 Oct 2004 13:49:39 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4263.cisco.com [10.61.80.166]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9KIna106716 for ; Wed, 20 Oct 2004 20:49:36 +0200 (CEST) Message-ID: <4176B340.1050709@cisco.com> Date: Wed, 20 Oct 2004 20:49:36 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-35: make sure the definitions match between [IPFIX-ARCH] and [IPFIX-PROTO] Content-Type: multipart/alternative; boundary="------------030509080109030103070104" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030509080109030103070104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, Regarding the issue PROTO-35 (make sure the definitions match between [IPFIX-ARCH] and [IPFIX-PROTO]), I made some minor edits to the IPFIX-PROTO draft terminology section to align to the IPFIX-ARCH draft terminology section. There are however a couple of minor changes to be done to the IPFIX-ARCH terminology section 1. In the definition below, I would keep (for example the selected output interface) Metering Process The Metering Process generates Flow Records. Input to the process are packet headers observed at an Observation Point and packet treatment at the Observation Point _(for example the selected output interface). _ The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. 2. [IPFIX-PROTO] specifies: Exporter The device which hosts an Exporting Process is termed an Exporter. [IPFIX-ARCH] specifies: * Exporter A device which hosts one or more Exporting Processes is termed an Exporter. The [IPFIX-PROTO] definition is the right one. As we can see from [IPFIX-ARCH] section 7, there is only exporting process per exporter. 3. [IPFIX-ARCH] specifies: * Control Information, Data Stream The information that needs to be exported from the IPFIX Device can be classified into the following categories: Control Information This includes the Flow definition, selection criteria for packets within the Flow sent by the Exporting Process, and any IPFIX protocol messages. The Control Information carries all the information needed for the end-points to understand the IPFIX protocol, and specifically for the receiver (Collector) to understand and interpret the data sent by the sender (Exporter). Data Stream This includes Flow Records carrying the field values for the various observed Flows at each of the Observation Points. IPFIX Message An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated within a transport layer header. From the above, it seems that the IPFIX Message is part of the "Control Information, Data Stream" definition. But it's not the case, so you should add an asterix in front of "IPFIX Message" and have the correct indentation 4. The "Control Information, Data Stream" terms are only defined in the IPFIX architecture draft terminology section. The IPFIX architecture draft is the only IPFIX draft using those notions! Do we see this as an issue? Should we try to avoid those terms? Regards, Benoit. --------------030509080109030103070104 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Dear all,

Regarding the issue PROTO-35 (make sure the definitions match between [IPFIX-ARCH] and [IPFIX-PROTO]), I made some minor edits to the IPFIX-PROTO draft terminology section to align to the IPFIX-ARCH draft terminology section.
There are however a couple of minor changes to be done to the IPFIX-ARCH terminology section

1. In the definition below, I would keep (for example the selected output interface)
Metering Process 
 
   The Metering Process generates Flow Records.  Input to the process 
   are packet headers observed at an Observation Point and packet 
   treatment at the Observation Point (for example the selected output 
   interface). 
    
   The Metering Process consists of a set of functions that includes 
   packet header capturing, timestamping, sampling, classifying, and 
   maintaining Flow Records. 
    
   The maintenance of Flow Records may include creating new records, 
   updating existing ones, computing Flow statistics, deriving further 
   Flow properties, detecting Flow expiration, passing Flow Records to 
   the Exporting Process, and deleting Flow Records. 


2.
 [IPFIX-PROTO] specifies: 
Exporter 
    
   The device which hosts an Exporting Process is termed an Exporter. 


 [IPFIX-ARCH] specifies: 

   * Exporter

      A device which hosts one or more Exporting Processes is termed an
      Exporter.

The [IPFIX-PROTO] definition is the right one. As we can see from [IPFIX-ARCH] section 7, there is only exporting process per exporter.


3. [IPFIX-ARCH] specifies:

   * Control Information, Data Stream

      The information that needs to be exported from the IPFIX Device
      can be classified into the following categories:

      Control Information

         This includes the Flow definition, selection criteria for
         packets within the Flow sent by the Exporting Process, and any
         IPFIX protocol messages.  The Control Information carries all
         the information needed for the end-points to understand the
         IPFIX protocol, and specifically for the receiver (Collector)
         to understand and interpret the data sent by the sender
         (Exporter).

      Data Stream

         This includes Flow Records carrying the field values for the
         various observed Flows at each of the Observation Points.

      IPFIX Message

         An IPFIX Message is a message originating at the Exporting
         Process that carries the IPFIX records of this Exporting
         Process and whose destination is a Collecting Process.  An
         IPFIX Message is encapsulated within a transport layer header.

From the above, it seems that the IPFIX Message is part of the "Control Information, Data Stream" definition.
But it's not the case, so you should add an asterix in front of "IPFIX Message" and have the correct indentation

4. The "Control Information, Data Stream" terms are only defined in the IPFIX architecture draft terminology section.
The IPFIX architecture draft is the only IPFIX draft using those notions!
Do we see this as an issue? Should we try to avoid those terms?

Regards, Benoit.
--------------030509080109030103070104-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Oct 21 05:59:40 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25064 for ; Thu, 21 Oct 2004 05:59:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKZNj-0001ga-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Oct 2004 04:37:15 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CKZNa-0001fU-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Oct 2004 04:37:07 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4180.cisco.com [10.61.80.83]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9L9b5103145 for ; Thu, 21 Oct 2004 11:37:05 +0200 (CEST) Message-ID: <4177833E.7030901@cisco.com> Date: Thu, 21 Oct 2004 11:37:02 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Normative versus Informative references Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, I think that even Informational RFC must distinguish between Normative and Informative references. This is currently not the case in the IPFIX architecture draft. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Oct 21 06:48:45 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27497 for ; Thu, 21 Oct 2004 06:48:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKa7y-0006P4-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Oct 2004 05:25:02 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CKa7l-0006NV-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 21 Oct 2004 05:24:50 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4180.cisco.com [10.61.80.83]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9LAOm121322 for ; Thu, 21 Oct 2004 12:24:48 +0200 (CEST) Message-ID: <41778E6D.9040003@cisco.com> Date: Thu, 21 Oct 2004 12:24:45 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] IPFIX PROTO-26: New IANA text + improved IANA text for the architecture draft. Content-Type: multipart/alternative; boundary="------------030101090006060407090204" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030101090006060407090204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, From the freshly posted IPFIX architecture draft, I used the IANA section as a starting point. I modified it a little bit and inserted the new section for the next version of the IPFIX protocol draft. I think the changes below must also be applied to the IPFIX architecture draft. Modifications: - The Template Number can change but the Set ID is fixed. You must replace the Template ID but the Set ID - Capitalized Information Elements and IPFIX Message - "Changes in IPFIX Field Type will be administered by IANA" -> "New assignments for IPFIX Field Types will be administered by IANA" - I added "on first come first serve basis [RFC 2434] ", as specified in RFC 2434 - I change "subject to Expert Review" to "subject to Expert Review [RFC 2434]" - I added "The group of experts must double check the Information Elements definitions for completeness, accuracy and redundancy with already defined Informations Elements." - I added "The IANA assignments for IPFIX Field Types will range from 128 to 32767; the values below 128 are reserved or assigned already; the values ranging from 32768 to 65535 are allocated for private use by vendors." New proposed section: 16. IANA Considerations The IPFIX Protocol, as set out in this document, has two sets of assigned numbers. Considerations for assigning them are discussed in this section, using the example policies as set out in the "Guidelines for IANA Considerations" document IANA-RFC [RFC2434]. 16.1 Numbers used in the Protocol IPFIX Messages use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message. Changes in either IPFIX Version Number or IPFIX Set ID assignments require an IETF Consensus, i.e. they are to be made via RFCs approved by the IESG. 16.2 Numbers used in the Information Model Fields of the IPFIX protocol carry information about traffic measurement. They are modeled as elements of the IPFIX information model [IPFIX-INFO]. Each Information Element describes a field which may appear in an IPFIX Message. Within an IPFIX Message the field type is indicated by its Field Type. New assignments for IPFIX Field Types will be administered by IANA, on First Come First Serve basis [RFC 2434] , subject to Expert Review [RFC 2434], i.e. review by one of a group of experts designated by an IETF Operations and Management Area Director. The group of experts must double check the Information Elements definitions for completeness, accuracy and redundancy with already defined Informations Elements. Those experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. The IANA assignments for IPFIX Field Types will range from 128 to 32767; the values below 128 are reserved or assigned already; the values ranging from 32768 to 65535 are allocated for private use by vendors. [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. As always, feedback? Regards, Benoit. --------------030101090006060407090204 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

From the freshly posted IPFIX architecture draft, I used the IANA section as a starting point.
I modified it a little bit and inserted the new section for the next version of the IPFIX protocol draft.
I think the changes below must also be applied to the IPFIX architecture draft.

Modifications:
- The Template Number can change but the Set ID is fixed. You must replace the Template ID but the Set ID
- Capitalized Information Elements and IPFIX Message
- "Changes in IPFIX Field Type will be administered by IANA" -> "New assignments for IPFIX Field Types will be administered by IANA"
- I added "on first come first serve basis [RFC 2434] ", as specified in RFC 2434
- I change "subject to Expert Review" to "subject to Expert Review [RFC 2434]"
- I added "The group of experts must double check the Information Elements definitions for completeness, accuracy and redundancy with already defined Informations Elements."
- I added "The IANA assignments for IPFIX Field Types will range from 128 to 32767; the values below 128 are reserved or assigned already; the values ranging from 32768 to 65535 are allocated for private use by vendors."


New proposed section:

16. IANA Considerations

The IPFIX Protocol, as set out in this document, has two sets of assigned numbers. Considerations for assigning them are discussed in this section, using the example policies as set out in the "Guidelines for IANA Considerations" document IANA-RFC [RFC2434].

16.1 Numbers used in the Protocol

IPFIX Messages use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message.

Changes in either IPFIX Version Number or IPFIX Set ID assignments require an IETF Consensus, i.e. they are to be made via RFCs approved by the IESG.

16.2 Numbers used in the Information Model

Fields of the IPFIX protocol carry information about traffic measurement. They are modeled as elements of the IPFIX information model [IPFIX-INFO]. Each Information Element describes a field which may appear in an IPFIX Message. Within an IPFIX Message the field type is indicated by its Field Type.

New assignments for IPFIX Field Types will be administered by IANA, on First Come First Serve basis [RFC 2434] , subject to Expert Review [RFC 2434], i.e. review by one of a group of experts designated by an IETF Operations and Management Area Director. The group of experts must double check the Information Elements definitions for completeness, accuracy and redundancy with already defined Informations Elements. Those experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. The IANA assignments for IPFIX Field Types will range from 128 to 32767; the values below 128 are reserved or assigned already; the values ranging from 32768 to 65535 are allocated for private use by vendors.


[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.

As always, feedback?

Regards, Benoit.
--------------030101090006060407090204-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Oct 21 17:26:28 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02033 for ; Thu, 21 Oct 2004 17:26:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKk60-0007Li-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Oct 2004 16:03:40 -0500 Received: from web60508.mail.yahoo.com ([216.109.116.129]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1CKk5i-0007Jk-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 21 Oct 2004 16:03:22 -0500 Message-ID: <20041021210321.7287.qmail@web60508.mail.yahoo.com> Received: from [62.10.89.120] by web60508.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 23:03:21 CEST Date: Thu, 21 Oct 2004 23:03:21 +0200 (CEST) From: Maurizio Molina Subject: Re: [Fwd: [ipfix-protocol] PROTO-21: metering process statistics option template] To: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu In-Reply-To: <3979.10.1.1.83.1098392558.squirrel@10.1.1.83> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1047902291-1098392601=:5298" Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver --0-1047902291-1098392601=:5298 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Benoit, some comments on your proposal. First, since the Exporter Reliability Statistics options template, as you say "specifies lack of reliability in the Metering and Exporting process" I think its name is not appropriate. A possibility would be to call it "Meter and Exporter Reliability Statistics options template", but I don’t like it either, as it mixes things up. My suggestion would be to call it "Meter Reliability Statistics options template", and move the "dropped flows" Information element into another options template (see later). Also, I would insert into this "Meter Reliability Statistics options template"two other information elements giving the time of the first and the last dropped packet. This time information is easy to get and update (if the metering process drops a packet and can update the droppedFUByteCount, it can also easily update a timestamp of this event: probably the timestamp is in the same data structure giving the number of bytes of the dropped packet….). The time information is useful to understand the dynamic of the aggregated flow of all the packets dropped by the metering process. The value of the ipfixOption field should become "METER_RELIABILITY_STATS" Second, as said, I would put the "dropped flows" information element in another option template, call it "Exporter Reliability Statistics Option template", and give "EXPORTER_RELIABILITY_STATS" as a value to its ipfixOption field. This option template should contain at least the ipfixOption, the droppedFlows and the time information elements (with the same meaning as in the Meter Reliability Statistics options template). My suggestion, however, would be to add other four information elements to it, and namely: -droppedFAPacketCount packets in the dropped flows -droppedFAByteCount bytes in the dropped flows -timeFirstFADropped time of the first packet received in one of the dropped flows -timeLastFADropped time of the last packet received in one of the dropped flows These are, once again, information easy to get and to update: each time you decide to drop a flow you have the full flow record, so you know how many packets and bytes you’re dropping, and you also have the time of the first and last packet of the record: you can compare them with the timeFirstFADropped and timeLastFADropped and update them if necessary. In this way you have the full dynamic of the aggregated flow resulting from all the drop in the exporting process. This would be more in line with my original suggestion, whose intent was to give the collector an idea of the amount and dynamic of the LOST traffic, so that it can compare it with the REPORTED traffic. A final note: a flow could be dropped not only because of starvation of the exporting process, but also because of policies of the flow recording process. Perhaps the wording can be adjusted to say this…. Regards, Maurizio ---------------------------- Original Message ---------------------------- Subject: [ipfix-protocol] PROTO-21: metering process statistics option template From: "Benoit Claise" Date: Wed, October 20, 2004 13:06 To: ipfix-protocol@net.doit.wisc.edu -------------------------------------------------------------------------- Dear all, The IPFIX protocol version 5 lists this remaining issue. http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt PROTO-21: Do we need to define some mandatory content of the metering process statistics option template? - Maurizio suggested text on the mailing list - proposal after IETF60: look at what is required in [IPFIX- REQ], and come up with a minimum set of data types. Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed for the metering process statistics The text in section "8.1 The Metering Process Statistics Option Template" is not complete: *8.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template defines the Metering Process Statistics with the export of the following Information Elements [IPFIX-INFO]: ipfixOption The value MUST be METER_STATS observationDomain Source ID lostFlows Flows not exported due to resource starvation lostFlowsPackets Packets in the lost Flows lostFlowsBytes Bytes in the lost Flows droppedPacketCount Packets dropped by Metering Process at the Observation Point droppedByteCount Bytes dropped by Metering Process at the Observation Domain time; When this record was generated The minimum set of Information Element in the Metering Process Statistics Option Template is: ipfixOption, observationDomain, lostFlows, time * <>**I think this version comes from discussion between Maurizio and I, but I'm not too sure anymore, as this is pretty old. Maurizio proposed some new text at http://ipfix.doit.wisc.edu/archive/2407.html We should discuss whether we need some mandatory information element exported. If yes, which one? I reviewed the IPFIX requirement draft http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the applicable sections are: 5.1. Reliability The metering process must either be reliable or the absence of reliability must be known and indicated. The metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process. If, e.g. due to some overload, not all passing packets can be included into the metering process, then the metering process must be able to detect this failure and to report it. 6.5. Regular Reporting Interval The exporting process should be capable of reporting measured traffic data regularly according to a given interval length. 6.3.2 -> discusses also the data transfer reliability: somehow related. A couple of points to Maurizio's proposal, that leads to the simplified proposal below: - I don't think we need to export the Observation Domain ID, as the scope field will determine whether the scope is the interface, the Observation Domain ID, etc... - There are 2 different requirements in RFC3917, so we should have 2 different options template records - I think we should remove the MUST, SHOULD, MAY requirement in the flow expiration section because the requirements imposed constraints on the metering process, and we are standardizing the IP Flow Information eXport. As a consequence, we should not put MUST, SHOULD, MAY requirements on the Metering Process in order to export those Option Templates. - If you have a metering process resource starvation how can you know how many flows have been lost? It is impossible to determine how many packets are in that flow because you can not keep flow information. All you can do is keep the count of how many packets and bytes that did not fit into the flow table. Here is the text I propose. * 8. Specific Reporting Requirements Some specific Options Templates and Options Templates Records are necessary to provide extra information about the Flow Records and about the Metering Process. The ipfixOption Field [IPFIX-INFO], always included in these specific Options Templates, defines the type of information sent in the Option Template / Option Template Record pair. For example, if the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option Template will specify information about the Metering Process statistics. The Option Template and Option Template Records defined in these sub-sections are not mandatory to implement as they impose some constraints about the Metering Process implementation: this document specifies the protocol to export the records, not the Metering Process implementation. However, if the specific Option Templates are implemented, they should implemented as specified in these sub-sections. In any case, if the ipfixOption Information Element is present, it MUST always be the first Information Element in the Option Template so that the Collector can quickly determine which specific Option Template Record is received. The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates. ** 8.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template specifies the Metering Process Statistics. It contains the following Information Elements [IPFIX-INFO] ipfixOption The value is METERING_STATS exportedOctetCount The number of all octets reported by the Exporting Process to the Collecting Process. exportedPacketCount The number of all packets reported by the exporting process to the Collecting Process. ** exportedFlowCount The number of all flows records reported by the Exporting Process to the Collecting Process.** * * time The time at which the record was generated The Exporting Process should export the Metering Process Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. The **Metering Process Statistics Option Template could be extended with other Information Elements.*** * * *8.2 The Exporter Reliability Statistics Option Template ** The Exporter Reliability Option Template specifies information about lack of reliability in the Metering and Exporting process. **It contains the following Information Elements [IPFIX-INFO]:* * ipfixOption The value is RELIABILITY_STATS ** droppedFUPacketCount Packets dropped by Metering Process ** droppedFUOctetCount Bytes dropped by Metering Process** * * droppedFlows Number of flow records lost due to resources starvation at Exporting Process ** time The time at which the record was generated ** * *The Exporting Process should export the Exporter Reliability Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. **The **Exporter Reliability Statistics **Option Template could be extended with other Information Elements. *Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO] Regards, Benoit. * * Dear all, The IPFIX protocol version 5 lists this remaining issue.http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt PROTO-21: Do we need to define some mandatory content of the metering process statistics option template? - Maurizio suggested text on the mailing list - proposal after IETF60: look at what is required in [IPFIX- REQ], and come up with a minimum set of data types. Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed for the metering process statisticsThe text in section "8.1 The Metering Process Statistics Option Template" is not complete: 8.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template defines the Metering Process Statistics with the export of the following Information Elements [IPFIX-INFO]: ipfixOption The value MUST be METER_STATS observationDomain Source ID lostFlows Flows not exported due to resource starvation lostFlowsPackets Packets in the lost Flows lostFlowsBytes Bytes in the lost Flows droppedPacketCount Packets dropped by Metering Process at the Observation Point droppedByteCount Bytes dropped by Metering Process at the Observation Domain time; When this record was generated The minimum set of Information Element in the Metering Process Statistics Option Template is: ipfixOption, observationDomain, lostFlows, time <>I think this version comes from discussion between Maurizio and I, but I'm not too sure anymore, as this is pretty old. Maurizio proposed some new text at http://ipfix.doit.wisc.edu/archive/2407.html We should discuss whether we need some mandatory information element exported. If yes, which one? I reviewed the IPFIX requirement draft http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the applicable sections are: 5.1. Reliability The metering process must either be reliable or the absence of reliability must be known and indicated. The metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process. If, e.g. due to some overload, not all passing packets can be included into the metering process, then the metering process must be able to detect this failure and to report it. 6.5. Regular Reporting Interval The exporting process should be capable of reporting measured traffic data regularly according to a given interval length. 6.3.2 -> discusses also the data transfer reliability: somehow related. A couple of points to Maurizio's proposal, that leads to the simplified proposal below:- I don't think we need to export the Observation Domain ID, as the scope field will determine whether the scope is the interface, the Observation Domain ID, etc...- There are 2 different requirements in RFC3917, so we should have 2 different options template records- I think we should remove the MUST, SHOULD, MAY requirement in the flow expiration section because the requirements imposed constraints on the metering process, and we are standardizing the IP Flow Information eXport. As a consequence, we should not put MUST, SHOULD, MAY requirements on the Metering Process in order to export those Option Templates.- If you have a metering process resource starvation how can you know how many flows have been lost? It is impossible to determine how many packets arein that flow because you can not keep flow information. All you can do is keep the count of how many packets and bytes that did not fit into theflow table.Here is the text I propose. 8. Specific Reporting Requirements Some specific Options Templates and Options Templates Records are necessary to provide extra information about the Flow Records and about the Metering Process. The ipfixOption Field [IPFIX-INFO], always included in these specific Options Templates, defines the type of information sent in the Option Template / Option Template Record pair. For example, if the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option Template will specify information about the Metering Process statistics. The Option Template and Option Template Records defined in these sub-sections are not mandatory to implement as they impose some constraints about the Metering Process implementation: this document specifies the protocol to export the records, not the Metering Process implementation. However, if the specific Option Templates are implemented, they should implemented as specified in these sub-sections. In any case, if the ipfixOption Information Element is present, it MUST always be the first Information Element in the Option Template so that the Collector can quickly determine which specific Option Template Record is received. The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates. 8.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template specifies the Metering Process Statistics. It contains the following Information Elements [IPFIX-INFO] ipfixOption The value is METERING_STATS exportedOctetCount The number of all octets reported by the Exporting Process to the Collecting Process. exportedPacketCount The number of all packets reported by the exporting process to the Collecting Process. exportedFlowCount The number of all flows records reported by the Exporting Process to the Collecting Process. time The time at which the record was generated The Exporting Process should export the Metering Process Statistics Option Template Record on a regular basis or based on some export policy. This periodicity or export policy should be configurable. The Metering Process Statistics Option Template could be extended with other Information Elements. 8.2 The Exporter Reliability Statistics Option Template The Exporter Reliability Option Template specifies information about lack of reliability in the Metering and Exporting process.It contains the following Information Elements [IPFIX-INFO]: ipfixOption The value is RELIABILITY_STATS droppedFUPacketCount Packets dropped by Metering Process droppedFUOctetCount Bytes dropped by Metering Process droppedFlows Number of flow records lost due to resources starvation at Exporting Process time The time at which the record was generated The Exporting Process should export the Exporter Reliability Statistics Option Template Record on a regular basis or based on some export policy. This periodicity orexport policy should be configurable. The Exporter Reliability Statistics Option Template could be extended with other Information Elements.Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO]Regards, Benoit. --------------------------------- Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! --0-1047902291-1098392601=:5298 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Benoit,

some comments on your proposal.

First, since the Exporter Reliability Statistics options template, as you say "specifies lack of reliability in the Metering and Exporting process" I think its name is not appropriate. A possibility would be to call it "Meter and Exporter Reliability Statistics options template", but I don’t like it either, as it mixes things up. My suggestion would be to call it "Meter Reliability Statistics options template", and move the "dropped flows" Information element into another options template (see later). Also, I would insert into this "Meter Reliability Statistics options template"two other information elements giving the time of the first and the last dropped packet. This time information is easy to get and update (if the metering process drops a packet and can update the droppedFUByteCount, it can also easily update a timestamp of this event: probably the timestamp is in the same data structure giving the number of bytes of the dropped packet….). The time information is useful to understand the dynamic of the aggregated flow of all the packets dropped by the metering process. The value of the ipfixOption field should become "METER_RELIABILITY_STATS"

Second, as said, I would put the "dropped flows" information element in another option template, call it "Exporter Reliability Statistics Option template", and give "EXPORTER_RELIABILITY_STATS" as a value to its ipfixOption field. This option template should contain at least the ipfixOption, the droppedFlows and the time information elements (with the same meaning as in the Meter Reliability Statistics options template). My suggestion, however, would be to add other four information elements to it, and namely:

-droppedFAPacketCount packets in the dropped flows

-droppedFAByteCount bytes in the dropped flows

-timeFirstFADropped time of the first packet received in one of the dropped flows

-timeLastFADropped time of the last packet received in one of the dropped flows

These are, once again, information easy to get and to update: each time you decide to drop a flow you have the full flow record, so you know how many packets and bytes you’re dropping, and you also have the time of the first and last packet of the record: you can compare them with the timeFirstFADropped and timeLastFADropped and update them if necessary. In this way you have the full dynamic of the aggregated flow resulting from all the drop in the exporting process.

This would be more in line with my original suggestion, whose intent was to give the collector an idea of the amount and dynamic of the LOST traffic, so that it can compare it with the REPORTED traffic.

A final note: a flow could be dropped not only because of starvation of the exporting process, but also because of policies of the flow recording process. Perhaps the wording can be adjusted to say this….

Regards,

Maurizio

---------------------------- Original Message ----------------------------
Subject: [ipfix-protocol] PROTO-21: metering process statistics option
template From: "Benoit Claise"
Date: Wed, October 20, 2004 13:06
To: ipfix-protocol@net.doit.wisc.edu
--------------------------------------------------------------------------

Dear all,

The IPFIX protocol version 5 lists this remaining issue.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt

PROTO-21: Do we need to define some mandatory content of the
metering process statistics option template?
- Maurizio suggested text on the mailing list
- proposal after IETF60: look at what is required in [IPFIX-
REQ], and come up with a minimum set of data types.
Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed
for the metering process statistics

The text in section "8.1 The Metering Process Statistics Option Template"
is not complete:


*8.1 The Metering Process Statistics Option Template

The Metering Process Statistics Option Template defines the Metering
Process Statistics with the export of the following Information
Elements [IPFIX-INFO]:
ipfixOption The value MUST be METER_STATS
observationDomain Source ID
lostFlows Flows not exported due to resource
starvation
lostFlowsPackets Packets in the lost Flows
lostFlowsBytes Bytes in the lost Flows
droppedPacketCount Packets dropped by Metering Process
at the Observation Point
droppedByteCount Bytes dropped by Metering Process at the
Observation Domain
time; When this record was generated

The minimum set of Information Element in the Metering Process
Statistics Option Template is: ipfixOption, observationDomain,
lostFlows, time *

<>**I think this version comes from discussion between Maurizio and I,
but I'm not too sure anymore, as this is pretty old. Maurizio proposed
some new text at http://ipfix.doit.wisc.edu/archive/2407.html

We should discuss whether we need some mandatory information element
exported. If yes, which one? I reviewed the IPFIX requirement draft
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the
applicable sections are:

5.1. Reliability

The metering process must either be reliable or the absence of
reliability must be known and indicated. The metering process is
reliable if each packet passing the observation point is metered
according to the configuration of the metering process. If, e.g. due
to some overload, not all passing packets can be included into the
metering process, then the metering process must be able to detect
this failure and to report it.

6.5. Regular Reporting Interval

The exporting process should be capable of reporting measured traffic
data regularly according to a given interval length.

6.3.2 -> discusses also the data transfer reliability: somehow related.

A couple of points to Maurizio's proposal, that leads to the simplified
proposal below: - I don't think we need to export the Observation Domain
ID, as the scope field will determine whether the scope is the interface,
the Observation Domain ID, etc... - There are 2 different requirements in
RFC3917, so we should have 2 different options template records - I think
we should remove the MUST, SHOULD, MAY requirement in the flow expiration
section because the requirements imposed constraints on the metering
process, and we are standardizing the IP Flow Information eXport.
As a consequence, we should not put MUST, SHOULD, MAY requirements on
the Metering Process in order to export those Option Templates.
- If you have a metering process resource starvation how can you know how
many flows have been lost? It is impossible to determine how many packets
are in that flow because you can not keep flow information. All you can do
is keep the count of how many packets and bytes that did not fit into the
flow table.


Here is the text I propose.

* 8. Specific Reporting Requirements

Some specific Options Templates and Options Templates Records are
necessary to provide extra information about the Flow Records and
about the Metering Process.

The ipfixOption Field [IPFIX-INFO], always included in these
specific Options Templates, defines the type of information sent in
the Option Template / Option Template Record pair. For example, if
the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option
Template will specify information about the Metering Process
statistics.

The Option Template and Option Template Records defined in these
sub-sections are not mandatory to implement as they impose some
constraints about the Metering Process implementation: this document
specifies the protocol to export the records, not the Metering Process
implementation. However, if the specific Option Templates are
implemented, they should implemented as specified in these
sub-sections. In any case, if the ipfixOption Information Element is
present, it MUST always be the first Information Element in the Option
Template so that the Collector can quickly determine which specific
Option Template Record is received.

The minimum set of Information Elements is always specified in these
Specific IPFIX Options Templates. Nevertheless, extra Information
Elements may be used in these specific Options Templates. **

8.1 The Metering Process Statistics Option Template

The Metering Process Statistics Option Template specifies the Metering
Process Statistics. It contains the following Information
Elements [IPFIX-INFO]
ipfixOption The value is METERING_STATS
exportedOctetCount The number of all octets reported
by the Exporting Process to the
Collecting Process.
exportedPacketCount The number of all packets reported
by the exporting process to the
Collecting Process.
** exportedFlowCount The number of all flows records
reported by the Exporting Process
to the Collecting Process.** *
* time The time at which the record was generated

The Exporting Process should export the Metering Process Statistics Option
Template Record on a regular basis or based on some export policy. This
periodicity or export policy should be configurable. The **Metering
Process Statistics Option Template could be extended with other
Information Elements.***
*
* *8.2 The Exporter Reliability Statistics Option Template **

The Exporter Reliability Option Template specifies information
about lack of reliability in the Metering and Exporting process.
**It contains the following Information Elements [IPFIX-INFO]:*
*
ipfixOption The value is RELIABILITY_STATS
** droppedFUPacketCount Packets dropped by Metering Process **
droppedFUOctetCount Bytes dropped by Metering Process** * *
droppedFlows Number of flow records lost due to resources
starvation at Exporting Process
** time The time at which the record was generated
** *
*The Exporting Process should export the Exporter Reliability Statistics
Option Template Record on a regular basis or based on some export policy.
This periodicity or export policy should be configurable. **The **Exporter
Reliability Statistics **Option Template could be extended with other
Information Elements.

*Note that the ipfixOption, time, droppedFUPacketCount,
droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO]

Regards, Benoit.
*
*




Dear all,

The IPFIX protocol version 5 lists this remaining issue.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt

 PROTO-21: Do we need to define some mandatory content of the 
   metering process statistics option template? 
       - Maurizio suggested text on the mailing list 
       - proposal after IETF60: look at what is required in [IPFIX-
   REQ], and come up with a minimum set of data types. 
   Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed 
   for the metering process statistics

The text in section "8.1 The Metering Process Statistics Option Template" is not complete:


 8.1      The Metering Process Statistics Option Template 
 
   The Metering Process Statistics Option Template defines the Metering 
   Process Statistics with the export of the following Information 
   Elements [IPFIX-INFO]: 
       ipfixOption             The value MUST be METER_STATS 
       observationDomain       Source ID 
       lostFlows               Flows not exported due to resource   
                               starvation 
       lostFlowsPackets        Packets in the lost Flows 
       lostFlowsBytes          Bytes in the lost Flows  
       droppedPacketCount      Packets dropped by Metering Process  
                           at the Observation Point 
   droppedByteCount        Bytes dropped by Metering Process at the  
                                Observation Domain 
        time;                   When this record was generated 
 
   The minimum set of Information Element in the Metering Process 
   Statistics Option Template is: ipfixOption, observationDomain, 
   lostFlows, time
<>I think this version comes from discussion between Maurizio and I, but I'm not too sure anymore, as this is pretty old. Maurizio proposed some new text at http://ipfix.doit.wisc.edu/archive/2407.html

We should discuss whether we need some mandatory information element exported. If yes, which one? I reviewed the IPFIX requirement draft http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the applicable sections are:
5.1. Reliability

The metering process must either be reliable or the absence of
reliability must be known and indicated. The metering process is
reliable if each packet passing the observation point is metered
according to the configuration of the metering process. If, e.g. due
to some overload, not all passing packets can be included into the
metering process, then the metering process must be able to detect
this failure and to report it.
6.5. Regular Reporting Interval

The exporting process should be capable of reporting measured traffic
data regularly according to a given interval length.

6.3.2 -> discusses also the data transfer reliability: somehow related.
A couple of points to Maurizio's proposal, that leads to the simplified proposal below:
- I don't think we need to export the Observation Domain ID, as the scope field will determine whether the scope is the interface, the Observation Domain ID, etc...
- There are 2 different requirements in RFC3917, so we should have 2 different options template records
- I think we should remove the MUST, SHOULD, MAY requirement in the flow expiration section because the requirements imposed constraints on the metering process, and we are standardizing the IP Flow Information eXport.
  As a consequence, we should not put MUST, SHOULD, MAY requirements on the Metering Process in order to export those Option Templates.
- If you have a metering process resource starvation how can you know how many flows have been lost? It is impossible to determine how many packets are
in that flow because you can not keep flow information. All you can do is keep the count of how many packets and bytes that did not fit into the
flow table.


Here is the text I propose.

 8.     Specific Reporting Requirements 
    
   Some specific Options Templates and Options Templates Records are 
   necessary to provide extra information about the Flow Records and 
   about the Metering Process.   
    
   The ipfixOption Field [IPFIX-INFO], always included in these 
   specific Options Templates, defines the type of information sent in 
   the Option Template / Option Template Record pair.  For example, if 
   the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option 
   Template will specify information about the Metering Process 
   statistics. 

   The Option Template and Option Template Records defined in these sub-sections 
   are not mandatory to implement as they impose some constraints about 
   the Metering Process implementation: this document specifies the protocol
   to export the records, not the Metering Process implementation.
   However, if the specific Option Templates are implemented, they should 
   implemented as specified in these sub-sections.  In any case, if the 
   ipfixOption Information Element is present, it MUST always be the first 
   Information Element in the Option Template so that the Collector
   can quickly determine which specific Option Template Record is received.
     
   The minimum set of Information Elements is always specified in these 
   Specific IPFIX Options Templates.  Nevertheless, extra Information 
   Elements may be used in these specific Options Templates.    

8.1      The Metering Process Statistics Option Template 
 
The Metering Process Statistics Option Template specifies the Metering 
Process Statistics. It contains the following Information 
Elements [IPFIX-INFO] 
     ipfixOption             The value is METERING_STATS 
     exportedOctetCount      The number of all octets reported 
                             by the Exporting Process to the
                             Collecting Process.
     exportedPacketCount     The number of all packets reported 
                             by the exporting process to the
                             Collecting Process.
     exportedFlowCount       The number of all flows records 
                             reported by the Exporting Process
                             to the Collecting Process. 
     time                    The time at which the record was generated 
 
The Exporting Process should export the Metering Process Statistics Option 
Template Record on a regular basis or based on some export policy. 
This periodicity or export policy should be configurable. The Metering 
Process Statistics Option Template could be extended with other Information 
Elements.

 8.2      The Exporter Reliability Statistics Option Template 

The Exporter Reliability Option Template specifies information 
about lack of reliability in the Metering and Exporting process.
It contains the following Information Elements [IPFIX-INFO]:

     ipfixOption             The value is RELIABILITY_STATS
     droppedFUPacketCount    Packets dropped by Metering Process
     droppedFUOctetCount     Bytes dropped by Metering Process 
     droppedFlows            Number of flow records lost due to resources 
                             starvation at Exporting Process
     time                    The time at which the record was generated 

The Exporting Process should export the Exporter Reliability Statistics Option 
Template Record on a regular basis or based on some export policy. This periodicity or
export policy should be configurable. The Exporter Reliability Statistics Option 
Template could be extended with other Information Elements.

Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO]

Regards, Benoit.

Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! --0-1047902291-1098392601=:5298-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Oct 22 07:00:01 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22094 for ; Fri, 22 Oct 2004 07:00:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CKwnw-0003qT-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Oct 2004 05:37:52 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CKwno-0003pl-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 22 Oct 2004 05:37:44 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4370.cisco.com [10.61.81.17]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9MAWc100511; Fri, 22 Oct 2004 12:32:38 +0200 (CEST) Message-ID: <4178E1C6.1060602@cisco.com> Date: Fri, 22 Oct 2004 12:32:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maurizio Molina CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [Fwd: [ipfix-protocol] PROTO-21: metering process statistics option template] References: <20041021210321.7287.qmail@web60508.mail.yahoo.com> In-Reply-To: <20041021210321.7287.qmail@web60508.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------040003060905060204080704" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040003060905060204080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id i9MAWc100511 Content-Transfer-Encoding: quoted-printable Maurizio, I inserted all your proposals below in the next version of [IPFIX-PROTO]=20 I will post today, for the sake of continuing the discussion on some=20 written text. Regards, Benoit. > Benoit, > > some comments on your proposal. > > First, since the Exporter Reliability Statistics options template, > as you say "specifies lack of reliability in the Metering and > Exporting process" I think its name is not appropriate. A > possibility would be to call it "Meter and Exporter Reliability > Statistics options template", but I don't like it either, as it > mixes things up. My suggestion would be to call it "Meter > Reliability Statistics options template", and move the "dropped > flows" Information element into another options template (see > later). Also, I would insert into this "Meter Reliability > Statistics options template"two other information elements giving > the time of the first and the last dropped packet. This time > information is easy to get and update (if the metering process > drops a packet and can update the droppedFUByteCount, it can also > easily update a timestamp of this event: probably the timestamp is > in the same data structure giving the number of bytes of the > dropped packet....). The time information is useful to understand > the dynamic of the aggregated flow of all the packets dropped by > the metering process. The value of the ipfixOption field should > become "METER_RELIABILITY_STATS" > > Second, as said, I would put the "dropped flows" information > element in another option template, call it "Exporter Reliability > Statistics Option template", and give "EXPORTER_RELIABILITY_STATS" > as a value to its ipfixOption field. This option template should > contain at least the ipfixOption, the droppedFlows and the time > information elements (with the same meaning as in the Meter > Reliability Statistics options template). My suggestion, however, > would be to add other four information elements to it, and namely: > > -droppedFAPacketCount packets in the dropped flows > > -droppedFAByteCount bytes in the dropped flows > > -timeFirstFADropped time of the first packet received in one of > the dropped flows > > -timeLastFADropped time of the last packet received in one of the > dropped flows > > These are, once again, information easy to get and to update: each > time you decide to drop a flow you have the full flow record, so > you know how many packets and bytes you're dropping, and you also > have the time of the first and last packet of the record: you can > compare them with the timeFirstFADropped and timeLastFADropped and > update them if necessary. In this way you have the full dynamic of > the aggregated flow resulting from all the drop in the exporting > process. > > This would be more in line with my original suggestion, whose > intent was to give the collector an idea of the amount and dynamic > of the LOST traffic, so that it can compare it with the REPORTED > traffic. > > A final note: a flow could be dropped not only because of > starvation of the exporting process, but also because of policies > of the flow recording process. Perhaps the wording can be adjusted > to say this.... > > Regards, > > Maurizio > > ---------------------------- Original Message > ---------------------------- > Subject: [ipfix-protocol] PROTO-21: metering process statistics opt= ion > template From: "Benoit Claise" > Date: Wed, October 20, 2004 13:06 > To: ipfix-protocol@net.doit.wisc.edu > -------------------------------------------------------------------= ------- > > Dear all, > > The IPFIX protocol version 5 lists this remaining issue. > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.tx= t > > PROTO-21: Do we need to define some mandatory content of the > metering process statistics option template? > - Maurizio suggested text on the mailing list > - proposal after IETF60: look at what is required in [IPFIX- > REQ], and come up with a minimum set of data types. > Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; neede= d > for the metering process statistics > > The text in section "8.1 The Metering Process Statistics Option > Template" > is not complete: > > > *8.1 The Metering Process Statistics Option Template > > The Metering Process Statistics Option Template defines the Meterin= g > Process Statistics with the export of the following Information > Elements [IPFIX-INFO]: > ipfixOption The value MUST be METER_STATS > observationDomain Source ID > lostFlows Flows not exported due to resource > starvation > lostFlowsPackets Packets in the lost Flows > lostFlowsBytes Bytes in the lost Flows > droppedPacketCount Packets dropped by Metering Process > at the Observation Point > droppedByteCount Bytes dropped by Metering Process at the > Observation Domain > time; When this record was generated > > The minimum set of Information Element in the Metering Process > Statistics Option Template is: ipfixOption, observationDomain, > lostFlows, time * > > <>**I think this version comes from discussion between Maurizio > and I, > but I'm not too sure anymore, as this is pretty old. Maurizio > proposed > some new text at http://ipfix.doit.wisc.edu/archive/2407.html > > We should discuss whether we need some mandatory information elemen= t > exported. If yes, which one? I reviewed the IPFIX requirement draft > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, > and the > applicable sections are: > > 5.1. Reliability > > The metering process must either be reliable or the absence of > reliability must be known and indicated. The metering process is > reliable if each packet passing the observation point is metered > according to the configuration of the metering process. If, e.g. du= e > to some overload, not all passing packets can be included into the > metering process, then the metering process must be able to detect > this failure and to report it. > > 6.5. Regular Reporting Interval > > The exporting process should be capable of reporting measured traff= ic > data regularly according to a given interval length. > > 6.3.2 -> discusses also the data transfer reliability: somehow > related. > > A couple of points to Maurizio's proposal, that leads to the > simplified > proposal below: - I don't think we need to export the Observation > Domain > ID, as the scope field will determine whether the scope is the > interface, > the Observation Domain ID, etc... - There are 2 different > requirements in > RFC3917, so we should have 2 different options template records - > I think > we should remove the MUST, SHOULD, MAY requirement in the flow > expiration > section because the requirements imposed constraints on the meterin= g > process, and we are standardizing the IP Flow Information eXport. > As a consequence, we should not put MUST, SHOULD, MAY requirements = on > the Metering Process in order to export those Option Templates. > - If you have a metering process resource starvation how can you > know how > many flows have been lost? It is impossible to determine how many > packets > are in that flow because you can not keep flow information. All > you can do > is keep the count of how many packets and bytes that did not fit > into the > flow table. > > > Here is the text I propose. > > * 8. Specific Reporting Requirements > > Some specific Options Templates and Options Templates Records are > necessary to provide extra information about the Flow Records and > about the Metering Process. > > The ipfixOption Field [IPFIX-INFO], always included in these > specific Options Templates, defines the type of information sent in > the Option Template / Option Template Record pair. For example, if > the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option > Template will specify information about the Metering Process > statistics. > > The Option Template and Option Template Records defined in these > sub-sections are not mandatory to implement as they impose some > constraints about the Metering Process implementation: this documen= t > specifies the protocol to export the records, not the Metering Proc= ess > implementation. However, if the specific Option Templates are > implemented, they should implemented as specified in these > sub-sections. In any case, if the ipfixOption Information Element i= s > present, it MUST always be the first Information Element in the Opt= ion > Template so that the Collector can quickly determine which specific > Option Template Record is received. > > The minimum set of Information Elements is always specified in thes= e > Specific IPFIX Options Templates. Nevertheless, extra Information > Elements may be used in these specific Options Templates. ** > > 8.1 The Metering Process Statistics Option Template > > The Metering Process Statistics Option Template specifies the > Metering > Process Statistics. It contains the following Information > Elements [IPFIX-INFO] > ipfixOption The value is METERING_STATS > exportedOctetCount The number of all octets reported > by the Exporting Process to the > Collecting Process. > exportedPacketCount The number of all packets reported > by the exporting process to the > Collecting Process. > ** exportedFlowCount The number of all flows records > reported by the Exporting Process > to the Collecting Process.** * > * time The time at which the record was generated > > The Exporting Process should export the Metering Process > Statistics Option > Template Record on a regular basis or based on some export policy. > This > periodicity or export policy should be configurable. The **Metering > Process Statistics Option Template could be extended with other > Information Elements.*** > * > * *8.2 The Exporter Reliability Statistics Option Template ** > > The Exporter Reliability Option Template specifies information > about lack of reliability in the Metering and Exporting process. > **It contains the following Information Elements [IPFIX-INFO]:* > * > ipfixOption The value is RELIABILITY_STATS > ** droppedFUPacketCount Packets dropped by Metering Process ** > droppedFUOctetCount Bytes dropped by Metering Process** * * > droppedFlows Number of flow records lost due to resources > starvation at Exporting Process > ** time The time at which the record was generated > ** * > *The Exporting Process should export the Exporter Reliability > Statistics > Option Template Record on a regular basis or based on some export > policy. > This periodicity or export policy should be configurable. **The > **Exporter > Reliability Statistics **Option Template could be extended with oth= er > Information Elements. > > *Note that the ipfixOption, time, droppedFUPacketCount, > droppedFUByteCount, and droppedFlows are not yet specified in > [IPFIX-INFO] > > Regards, Benoit. > * > * > > > > > Dear all, > >The IPFIX protocol version 5 lists this remaining issue. >http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt > > PROTO-21: Do we need to define some mandatory content of the=20 > metering process statistics option template?=20 > - Maurizio suggested text on the mailing list=20 > - proposal after IETF60: look at what is required in [IPFIX- > REQ], and come up with a minimum set of data types.=20 > Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed=20 > for the metering process statistics > >The text in section "8.1 The Metering Process Statistics Option Template= " is not complete: > > =20 > > *8.1 The Metering Process Statistics Option Template=20 >=20 > The Metering Process Statistics Option Template defines the Metering=20 > Process Statistics with the export of the following Information=20 > Elements [IPFIX-INFO]:=20 > ipfixOption The value MUST be METER_STATS=20 > observationDomain Source ID=20 > lostFlows Flows not exported due to resource =20 > starvation=20 > lostFlowsPackets Packets in the lost Flows=20 > lostFlowsBytes Bytes in the lost Flows =20 > droppedPacketCount Packets dropped by Metering Process =20 > at the Observation Point=20 > droppedByteCount Bytes dropped by Metering Process at the =20 > Observation Domain=20 > time; When this record was generated=20 >=20 > The minimum set of Information Element in the Metering Process=20 > Statistics Option Template is: ipfixOption, observationDomain,=20 > lostFlows, time * > > <>I think this version comes from discussion between Maurizio and > I, but I'm not too sure anymore, as this is pretty old. Maurizio > proposed some new text at > http://ipfix.doit.wisc.edu/archive/2407.html > > We should discuss whether we need some mandatory information > element exported. If yes, which one? I reviewed the IPFIX > requirement draft > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, > and the applicable sections are: > > 5.1. Reliability > > The metering process must either be reliable or the absence of > reliability must be known and indicated. The metering process i= s > reliable if each packet passing the observation point is metere= d > according to the configuration of the metering process. If, > e.g. due > to some overload, not all passing packets can be included into = the > metering process, then the metering process must be able to det= ect > this failure and to report it. > > 6.5. Regular Reporting Interval > > The exporting process should be capable of reporting measured > traffic > data regularly according to a given interval length. > > 6.3.2 -> discusses also the data transfer reliability: somehow > related. > >A couple of points to Maurizio's proposal, that leads to the simplified = proposal below: >- I don't think we need to export the Observation Domain ID, as the scop= e field will determine whether the scope is the interface, the Observatio= n Domain ID, etc... >- There are 2 different requirements in RFC3917, so we should have 2 dif= ferent options template records >- I think we should remove the MUST, SHOULD, MAY requirement in the flow= expiration section because the requirements imposed constraints on the m= etering process, and we are standardizing the IP Flow Information eXport. > As a consequence, we should not put MUST, SHOULD, MAY requirements on = the Metering Process in order to export those Option Templates. >- If you have a metering process resource starvation how can you know ho= w many flows have been lost? It is impossible to determine how many packe= ts are >in that flow because you can not keep flow information. All you can do i= s keep the count of how many packets and bytes that did not fit into the >flow table. > > >Here is the text I propose. > >* 8. Specific Reporting Requirements=20 > =20 > Some specific Options Templates and Options Templates Records are=20 > necessary to provide extra information about the Flow Records and=20 > about the Metering Process. =20 > =20 > The ipfixOption Field [IPFIX-INFO], always included in these=20 > specific Options Templates, defines the type of information sent in=20 > the Option Template / Option Template Record pair. For example, if=20 > the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option=20 > Template will specify information about the Metering Process=20 > statistics.=20 > > The Option Template and Option Template Records defined in these sub-= sections=20 > are not mandatory to implement as they impose some constraints about=20 > the Metering Process implementation: this document specifies the prot= ocol > to export the records, not the Metering Process implementation. > However, if the specific Option Templates are implemented, they shoul= d=20 > implemented as specified in these sub-sections. In any case, if the=20 > ipfixOption Information Element is present, it MUST always be the fir= st=20 > Information Element in the Option Template so that the Collector > can quickly determine which specific Option Template Record is receiv= ed. > =20 > The minimum set of Information Elements is always specified in these=20 > Specific IPFIX Options Templates. Nevertheless, extra Information=20 > Elements may be used in these specific Options Templates. ** > >8.1 The Metering Process Statistics Option Template=20 >=20 >The Metering Process Statistics Option Template specifies the Metering=20 >Process Statistics. It contains the following Information=20 >Elements [IPFIX-INFO]=20 > ipfixOption The value is METERING_STATS=20 > exportedOctetCount The number of all octets reported=20 > by the Exporting Process to the > Collecting Process. > exportedPacketCount The number of all packets reported=20 > by the exporting process to the > Collecting Process. >** exportedFlowCount The number of all flows records=20 > reported by the Exporting Process > to the Collecting Process.** * >* time The time at which the record was generated= =20 >=20 >The Exporting Process should export the Metering Process Statistics Opti= on=20 >Template Record on a regular basis or based on some export policy.=20 >This periodicity or export policy should be configurable. The **Metering= =20 >Process Statistics Option Template could be extended with other Informat= ion=20 >Elements.*** >* >* *8.2 The Exporter Reliability Statistics Option Template ** > >The Exporter Reliability Option Template specifies information=20 >about lack of reliability in the Metering and Exporting process. >**It contains the following Information Elements [IPFIX-INFO]:* >* > ipfixOption The value is RELIABILITY_STATS >** droppedFUPacketCount Packets dropped by Metering Process >** droppedFUOctetCount Bytes dropped by Metering Process** * >* droppedFlows Number of flow records lost due to resourc= es=20 > starvation at Exporting Process >** time The time at which the record was generate= d ** >* >*The Exporting Process should export the Exporter Reliability Statistics= Option=20 >Template Record on a regular basis or based on some export policy. This = periodicity or >export policy should be configurable. **The **Exporter Reliability Stati= stics **Option=20 >Template could be extended with other Information Elements. > >*Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCou= nt, and droppedFlows are not yet specified in [IPFIX-INFO] > >Regards, Benoit. >* >* > > > > =20 > > -----------------------------------------------------------------------= - > *Nuovo Yahoo! Messenger*=20 > =20 > E' molto pi=F9 divertente: Audibles, Avatar, Webcam, Giochi, Rubrica...= =20 > Scaricalo ora!=20 --------------040003060905060204080704 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Maurizio,

I inserted all your proposals below in the next version of [IPFIX-PROTO] I will post today, for the sake of continuing the discussion on some written text.

Regards, Benoit.

Benoit,

some comments on your proposal.

First, since the Exporter Reliability Statistics options template, as you say "specifies lack of reliability in the Metering and Exporting process" I think its name is not appropriate. A possibility would be to call it "Meter and Exporter Reliability Statistics options template", but I don’t like it either, as it mixes things up. My suggestion would be to call it "Meter Reliability Statistics options template", and move the "dropped flows" Information element into another options template (see later). Also, I would insert into this "Meter Reliability Statistics options template"two other information elements giving the time of the first and the last dropped packet. This time information is easy to get and update (if the metering process drops a packet and can update the droppedFUByteCount, it can also easily update a timestamp of this event: probably the timestamp is in the same data structure giving the number of bytes of the dropped packet….). The time information is useful to understand the dynamic of the aggregated flow of all the packets dropped by the metering process. The value of the ipfixOption field should become "METER_RELIABILITY_STATS"

Second, as said, I would put the "dropped flows" information element in another option template, call it "Exporter Reliability Statistics Option template", and give "EXPORTER_RELIABILITY_STATS" as a value to its ipfixOption field. This option template should contain at least the ipfixOption, the droppedFlows and the time information elements (with the same meaning as in the Meter Reliability Statistics options template). My suggestion, however, would be to add other four information elements to it, and namely:

-droppedFAPacketCount packets in the dropped flows

-droppedFAByteCount bytes in the dropped flows

-timeFirstFADropped time of the first packet received in one of the dropped flows

-timeLastFADropped time of the last packet received in one of the dropped flows

These are, once again, information easy to get and to update: each time you decide to drop a flow you have the full flow record, so you know how many packets and bytes you’re dropping, and you also have the time of the first and last packet of the record: you can compare them with the timeFirstFADropped and timeLastFADropped and update them if necessary. In this way you have the full dynamic of the aggregated flow resulting from all the drop in the exporting process.

This would be more in line with my original suggestion, whose intent was to give the collector an idea of the amount and dynamic of the LOST traffic, so that it can compare it with the REPORTED traffic.

A final note: a flow could be dropped not only because of starvation of the exporting process, but also because of policies of the flow recording process. Perhaps the wording can be adjusted to say this….

Regards,

Maurizio

---------------------------- Original Message ----------------------------
Subject: [ipfix-protocol] PROTO-21: metering process statistics option
template From: "Benoit Claise"
Date: Wed, October 20, 2004 13:06
To: ipfix-protocol@net.doit.wisc.edu
--------------------------------------------------------------------------

Dear all,

The IPFIX protocol version 5 lists this remaining issue.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt

PROTO-21: Do we need to define some mandatory content of the
metering process statistics option template?
- Maurizio suggested text on the mailing list
- proposal after IETF60: look at what is required in [IPFIX-
REQ], and come up with a minimum set of data types.
Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed
for the metering process statistics

The text in section "8.1 The Metering Process Statistics Option Template"
is not complete:


*8.1 The Metering Process Statistics Option Template

The Metering Process Statistics Option Template defines the Metering
Process Statistics with the export of the following Information
Elements [IPFIX-INFO]:
ipfixOption The value MUST be METER_STATS
observationDomain Source ID
lostFlows Flows not exported due to resource
starvation
lostFlowsPackets Packets in the lost Flows
lostFlowsBytes Bytes in the lost Flows
droppedPacketCount Packets dropped by Metering Process
at the Observation Point
droppedByteCount Bytes dropped by Metering Process at the
Observation Domain
time; When this record was generated

The minimum set of Information Element in the Metering Process
Statistics Option Template is: ipfixOption, observationDomain,
lostFlows, time *

<>**I think this version comes from discussion between Maurizio and I,
but I'm not too sure anymore, as this is pretty old. Maurizio proposed
some new text at http://ipfix.doit.wisc.edu/archive/2407.html

We should discuss whether we need some mandatory information element
exported. If yes, which one? I reviewed the IPFIX requirement draft
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the
applicable sections are:

5.1. Reliability

The metering process must either be reliable or the absence of
reliability must be known and indicated. The metering process is
reliable if each packet passing the observation point is metered
according to the configuration of the metering process. If, e.g. due
to some overload, not all passing packets can be included into the
metering process, then the metering process must be able to detect
this failure and to report it.

6.5. Regular Reporting Interval

The exporting process should be capable of reporting measured traffic
data regularly according to a given interval length.

6.3.2 -> discusses also the data transfer reliability: somehow related.

A couple of points to Maurizio's proposal, that leads to the simplified
proposal below: - I don't think we need to export the Observation Domain
ID, as the scope field will determine whether the scope is the interface,
the Observation Domain ID, etc... - There are 2 different requirements in
RFC3917, so we should have 2 different options template records - I think
we should remove the MUST, SHOULD, MAY requirement in the flow expiration
section because the requirements imposed constraints on the metering
process, and we are standardizing the IP Flow Information eXport.
As a consequence, we should not put MUST, SHOULD, MAY requirements on
the Metering Process in order to export those Option Templates.
- If you have a metering process resource starvation how can you know how
many flows have been lost? It is impossible to determine how many packets
are in that flow because you can not keep flow information. All you can do
is keep the count of how many packets and bytes that did not fit into the
flow table.


Here is the text I propose.

* 8. Specific Reporting Requirements

Some specific Options Templates and Options Templates Records are
necessary to provide extra information about the Flow Records and
about the Metering Process.

The ipfixOption Field [IPFIX-INFO], always included in these
specific Options Templates, defines the type of information sent in
the Option Template / Option Template Record pair. For example, if
the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option
Template will specify information about the Metering Process
statistics.

The Option Template and Option Template Records defined in these
sub-sections are not mandatory to implement as they impose some
constraints about the Metering Process implementation: this document
specifies the protocol to export the records, not the Metering Process
implementation. However, if the specific Option Templates are
implemented, they should implemented as specified in these
sub-sections. In any case, if the ipfixOption Information Element is
present, it MUST always be the first Information Element in the Option
Template so that the Collector can quickly determine which specific
Option Template Record is received.

The minimum set of Information Elements is always specified in these
Specific IPFIX Options Templates. Nevertheless, extra Information
Elements may be used in these specific Options Templates. **

8.1 The Metering Process Statistics Option Template

The Metering Process Statistics Option Template specifies the Metering
Process Statistics. It contains the following Information
Elements [IPFIX-INFO]
ipfixOption The value is METERING_STATS
exportedOctetCount The number of all octets reported
by the Exporting Process to the
Collecting Process.
exportedPacketCount The number of all packets reported
by the exporting process to the
Collecting Process.
** exportedFlowCount The number of all flows records
reported by the Exporting Process
to the Collecting Process.** *
* time The time at which the record was generated

The Exporting Process should export the Metering Process Statistics Option
Template Record on a regular basis or based on some export policy. This
periodicity or export policy should be configurable. The **Metering
Process Statistics Option Template could be extended with other
Information Elements.***
*
* *8.2 The Exporter Reliability Statistics Option Template **

The Exporter Reliability Option Template specifies information
about lack of reliability in the Metering and Exporting process.
**It contains the following Information Elements [IPFIX-INFO]:*
*
ipfixOption The value is RELIABILITY_STATS
** droppedFUPacketCount Packets dropped by Metering Process **
droppedFUOctetCount Bytes dropped by Metering Process** * *
droppedFlows Number of flow records lost due to resources
starvation at Exporting Process
** time The time at which the record was generated
** *
*The Exporting Process should export the Exporter Reliability Statistics
Option Template Record on a regular basis or based on some export policy.
This periodicity or export policy should be configurable. **The **Exporter
Reliability Statistics **Option Template could be extended with other
Information Elements.

*Note that the ipfixOption, time, droppedFUPacketCount,
droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO]

Regards, Benoit.
*
*




Dear all,

The IPFIX protocol version 5 lists this remaining issue.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-05.txt

 PROTO-21: Do we need to define some mandatory content of the 
   metering process statistics option template? 
       - Maurizio suggested text on the mailing list 
       - proposal after IETF60: look at what is required in [IPFIX-
   REQ], and come up with a minimum set of data types. 
   Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed 
   for the metering process statistics

The text in section "8.1 The Metering Process Statistics Option Template" is not complete:

    
 8.1      The Metering Process Statistics Option Template 
 
   The Metering Process Statistics Option Template defines the Metering 
   Process Statistics with the export of the following Information 
   Elements [IPFIX-INFO]: 
       ipfixOption             The value MUST be METER_STATS 
       observationDomain       Source ID 
       lostFlows               Flows not exported due to resource   
                               starvation 
       lostFlowsPackets        Packets in the lost Flows 
       lostFlowsBytes          Bytes in the lost Flows  
       droppedPacketCount      Packets dropped by Metering Process  
                           at the Observation Point 
   droppedByteCount        Bytes dropped by Metering Process at the  
                                Observation Domain 
        time;                   When this record was generated 
 
   The minimum set of Information Element in the Metering Process 
   Statistics Option Template is: ipfixOption, observationDomain, 
   lostFlows, time
<>I think this version comes from discussion between Maurizio and I, but I'm not too sure anymore, as this is pretty old. Maurizio proposed some new text at http://ipfix.doit.wisc.edu/archive/2407.html

We should discuss whether we need some mandatory information element exported. If yes, which one? I reviewed the IPFIX requirement draft http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-16.txt, and the applicable sections are:
5.1. Reliability

The metering process must either be reliable or the absence of
reliability must be known and indicated. The metering process is
reliable if each packet passing the observation point is metered
according to the configuration of the metering process. If, e.g. due
to some overload, not all passing packets can be included into the
metering process, then the metering process must be able to detect
this failure and to report it.
6.5. Regular Reporting Interval

The exporting process should be capable of reporting measured traffic
data regularly according to a given interval length.

6.3.2 -> discusses also the data transfer reliability: somehow related.
A couple of points to Maurizio's proposal, that leads to the simplified proposal below:
- I don't think we need to export the Observation Domain ID, as the scope field will determine whether the scope is the interface, the Observation Domain ID, etc...
- There are 2 different requirements in RFC3917, so we should have 2 different options template records
- I think we should remove the MUST, SHOULD, MAY requirement in the flow expiration section because the requirements imposed constraints on the metering process, and we are standardizing the IP Flow Information eXport.
  As a consequence, we should not put MUST, SHOULD, MAY requirements on the Metering Process in order to export those Option Templates.
- If you have a metering process resource starvation how can you know how many flows have been lost? It is impossible to determine how many packets are
in that flow because you can not keep flow information. All you can do is keep the count of how many packets and bytes that did not fit into the
flow table.


Here is the text I propose.

 8.     Specific Reporting Requirements 
    
   Some specific Options Templates and Options Templates Records are 
   necessary to provide extra information about the Flow Records and 
   about the Metering Process.   
    
   The ipfixOption Field [IPFIX-INFO], always included in these 
   specific Options Templates, defines the type of information sent in 
   the Option Template / Option Template Record pair.  For example, if 
   the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option 
   Template will specify information about the Metering Process 
   statistics. 

   The Option Template and Option Template Records defined in these sub-sections 
   are not mandatory to implement as they impose some constraints about 
   the Metering Process implementation: this document specifies the protocol
   to export the records, not the Metering Process implementation.
   However, if the specific Option Templates are implemented, they should 
   implemented as specified in these sub-sections.  In any case, if the 
   ipfixOption Information Element is present, it MUST always be the first 
   Information Element in the Option Template so that the Collector
   can quickly determine which specific Option Template Record is received.
     
   The minimum set of Information Elements is always specified in these 
   Specific IPFIX Options Templates.  Nevertheless, extra Information 
   Elements may be used in these specific Options Templates.    

8.1      The Metering Process Statistics Option Template 
 
The Metering Process Statistics Option Template specifies the Metering 
Process Statistics. It contains the following Information 
Elements [IPFIX-INFO] 
     ipfixOption             The value is METERING_STATS 
     exportedOctetCount      The number of all octets reported 
                             by the Exporting Process to the
                             Collecting Process.
     exportedPacketCount     The number of all packets reported 
                             by the exporting process to the
                             Collecting Process.
     exportedFlowCount       The number of all flows records 
                             reported by the Exporting Process
                             to the Collecting Process. 
     time                    The time at which the record was generated 
 
The Exporting Process should export the Metering Process Statistics Option 
Template Record on a regular basis or based on some export policy. 
This periodicity or export policy should be configurable. The Metering 
Process Statistics Option Template could be extended with other Information 
Elements.

 8.2      The Exporter Reliability Statistics Option Template 

The Exporter Reliability Option Template specifies information 
about lack of reliability in the Metering and Exporting process.
It contains the following Information Elements [IPFIX-INFO]:

     ipfixOption             The value is RELIABILITY_STATS
     droppedFUPacketCount    Packets dropped by Metering Process
     droppedFUOctetCount     Bytes dropped by Metering Process 
     droppedFlows            Number of flow records lost due to resources 
                             starvation at Exporting Process
     time                    The time at which the record was generated 

The Exporting Process should export the Exporter Reliability Statistics Option 
Template Record on a regular basis or based on some export policy. This periodicity or
export policy should be configurable. The Exporter Reliability Statistics Option 
Template could be extended with other Information Elements.

Note that the ipfixOption, time, droppedFUPacketCount, droppedFUByteCount, and droppedFlows are not yet specified in [IPFIX-INFO]

Regards, Benoit.

Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora!

--------------040003060905060204080704-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Oct 22 11:30:55 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14180 for ; Fri, 22 Oct 2004 11:30:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CL1Cd-0003ER-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Oct 2004 10:19:39 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CL1CW-0003Dk-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 22 Oct 2004 10:19:32 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4370.cisco.com [10.61.81.17]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9MFJL125825; Fri, 22 Oct 2004 17:19:21 +0200 (CEST) Message-ID: <417924F9.6080501@cisco.com> Date: Fri, 22 Oct 2004 17:19:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] draft-ietf-ipfix-protocol-06.txt posted Content-Type: multipart/mixed; boundary="------------010303010200060504020103" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------010303010200060504020103 Content-Type: multipart/alternative; boundary="------------030209080209050806040401" --------------030209080209050806040401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, A new version of the IPFIX protocol draft has been posted. Look at the attached file for a quick overview of the changes. __The following issues have been closed: - PROTO-4: TCP section not yet covered. - PROTO-21: Do we need to define some mandatory content of the metering process statistics option template? Discussion continues on the mailing list - PROTO-24: Section 11 "Linkage with the information model" must be completed with types used in [IPFIX-INFO] - PROTO-26: IANA considerations section to be updated. - PROTO-35: make sure the definitions match between [IPFIX-ARCH] and [IPFIX-PROTO] - The protocol did not allow for a variable length element with 255 bytes length New specification of the option template format, with the count instead of length. Example changed accordingly. - Added: The Export Packet 16-bit LENGTH field limits the length of a IPFIX Message to 65536 octets including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65536 octets. - SCTP sections improved Updated section 5.3.1 about SCTP congestion avoidance. Updated section 5.3.4.1 and 5.3.4.1 about the SCTP association establishment and shutdown. Updated section 5.3.4.5 about the Templates with SCTP - Remove the SID abbreviation for Source ID: someone mentioned to me it was confusing. - Intellectual Property Statement, Disclaimer of Validity, and Copyright Statement sections added. - Some editorial changes Regards, Benoit. --------------030209080209050806040401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

A new version of the IPFIX protocol draft has been posted.
Look at the attached file for a quick overview of the changes.

The following issues have been closed:
- PROTO-4: TCP section not yet covered.
- PROTO-21: Do we need to define some mandatory content of the metering process statistics option template?
    Discussion continues on the mailing list
- PROTO-24: Section 11 "Linkage with the information model" must be completed with types used in [IPFIX-INFO]
- PROTO-26: IANA considerations section to be updated.
- PROTO-35: make sure the definitions match between [IPFIX-ARCH] and [IPFIX-PROTO]
- The protocol did not allow for a variable length element with 255 bytes length
New specification of the option template format, with the count instead of length. Example changed accordingly. 
- Added:  The Export Packet 16-bit LENGTH field limits the length of a IPFIX Message to 65536 octets including the header.  A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65536 octets. 
- SCTP sections improved
    Updated section 5.3.1 about SCTP congestion avoidance.
          Updated section 5.3.4.1 and 5.3.4.1 about the SCTP association establishment and shutdown.
          Updated section 5.3.4.5 about the Templates with SCTP
- Remove the SID abbreviation for Source ID: someone mentioned to me it was confusing.
- Intellectual Property Statement, Disclaimer of Validity, and Copyright Statement sections added.
- Some editorial changes

Regards, Benoit.
--------------030209080209050806040401-- --------------010303010200060504020103 Content-Type: text/html; name="diff-proto05-proto06.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff-proto05-proto06.html" Content-Transfer-Encoding: 7bit 

   IPFIX working group                                                  
   Internet Draft                               EDITOR:      B. Claise 
   draft-ietf-ipfix-protocol-05.txt 
   draft-ietf-ipfix-protocol-06.txt                       Cisco Systems 
   Expires: February April 2005                                   August                                     October 2004 
                                                                        
                                                                        
    
    
    
                       IPFIX Protocol Specification  
 
                                      
    
 Status of this Memo 
  
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of RFC 3668.  
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts.  Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsolete by other 
   documents at any time.  It is inappropriate to use Internet-Drafts 
   as reference material or to cite them other than as "work in 
   progress." 
     
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
    
 Abstract 
  
   This document specifies the IPFIX protocol that provides network 
   operators with access to IP flow information.  In order to export 
   IP flow information to the IPFIX collecting process, a common method 
   of representing the flow data and a standard means of communicating 
   them from an exporter to a collector is required.  This document 
   describes how the IPFIX flow record data, options record data and 

 
 
  Claise, et. al            Standard Track                    [Page 1] 
                   IPFIX Protocol Specification            August           October 2004 
 
 
   templates are carried over a congestion-aware transport protocol 
   from an IPFIX exporting process to an IPFIX collecting process. 
    
 Conventions used in this document 
  
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119. 
    
 Table of Contents 
  
     1. Points of Discussion.........................................3 Discussion.........................................4 
     2. Introduction.................................................6 
      2.1 IPFIX Documents Overview...................................6 
     3. Terminology..................................................7 
      3.1 Terminology Summary Table.................................11 Table.................................12 
     4. Criteria for Flow Expiration and Export.....................12 
      4.1 Flow Expiration...........................................12 
      4.2 Flow Export...............................................13 
     5. Transport Protocol..........................................13 
      5.1 Transport Compliance and Transport Usage..................13 
      5.2 TCP.......................................................14 
     5.2.1   Congestion Avoidance...................................14 
     5.2.2   Reliability............................................14 
     5.2.3   MTU....................................................14 
     5.2.4   Exporting Process......................................14 
     5.2.4.1  Connection Establishment..............................15 
     5.2.4.2  Connection Release....................................15 
     5.2.4.3  IPFIX Message Encoding................................15 
     5.2.4.4  Templates.............................................16 
     5.2.5   Fail-over..............................................16 
      5.3 SCTP......................................................14 SCTP......................................................16 
     5.3.1   Congestion Avoidance...................................14 Avoidance...................................16 
     5.3.2   Reliability............................................14   Reliability............................................17 
     5.3.3   MTU....................................................14   MTU....................................................17 
     5.3.4   Exporting Process......................................15 Process......................................17 
     5.3.4.1  Association...........................................15  Association Establishment.............................17 
     5.3.4.2  Source ID.............................................15  Association Shutdown..................................18 
     5.3.4.3  Stream................................................15  Source ID.............................................18 
     5.3.4.4  Template..............................................16  Stream................................................18 
     5.3.4.5  Template..............................................19 
     5.3.5   Collecting Process.....................................16 Process.....................................19 
     5.3.6   Failover...............................................17   Failover...............................................20 
      5.4 UDP.......................................................17 UDP.......................................................20 
     5.4.1   Congestion Avoidance...................................17 Avoidance...................................20 
     5.4.2   Reliability............................................17   Reliability............................................20 
     5.4.3   MTU....................................................18   MTU....................................................21 
     5.4.4   Port Numbers...........................................18 Numbers...........................................21 
 
 
  Claise, et. al            Standard Track                    [Page 2] 
                   IPFIX Protocol Specification           October 2004 
 
 
     5.4.5   Exporting Process......................................18 Process......................................21 
     5.4.5.1  Template..............................................18  Template..............................................21 
     5.4.6   Collecting Process.....................................18 Process.....................................22 
     5.4.7   Failover...............................................19   Failover...............................................22 
     6. Message Layout..............................................19 Layout..............................................22 
     7. IPFIX Message Format........................................21 Format........................................24 
      7.1 Header Format.............................................21 Format.............................................24 
      7.2 Field Type Format.........................................22 Format.........................................25 
      7.3 Template Set..............................................23 
 
 
  Claise, et. al            Standard Track                    [Page 2] 
                   IPFIX Protocol Specification            August 2004 Set Format.......................................26 
      7.4 Data Set..................................................25 Set Format...........................................29 
      7.5 Options Template Set......................................27 Set......................................30 
     7.5.1   Scope..................................................27   Scope..................................................30 
     7.5.2   Options Template Set Format............................28 Format............................31 
     7.5.3   Options Data Record Format.............................30 Format.............................33 
     8. Specific Reporting Requirements.............................32 Requirements.............................35 
      8.1 The Metering Process Statistics Option Template...........32 Template...........36 
      8.2 The Metering Process Reliability Statistics Option Template36 
      8.3 The Exporting Process Reliability Statistics Option Template37 
      8.4 The Flow Keys Option Template.............................38 
     9. Export Packet "Export Time" Computation and Flow Record Time33 Time38 
      9.1 Microsecond Precision.....................................33 Precision.....................................38 
      9.2 Millisecond Precision.....................................34 Precision.....................................39 
      9.3 Nanosecond Precision......................................34 Precision......................................40 
      9.4 Multiple Precisions.......................................35 Precisions.......................................40 
     10. Linkage with the Information Model.........................35 Model.........................40 
      10.1 Boolean..................................................35 
      10.2 Byte.....................................................35 
      10.3 UnsignedByte.............................................35 
      10.4 Short....................................................35 
      10.5 Reduced Size Encoding of Integer Types...................36 Types...................40 
     11. Variable Length Information Element........................36 Element........................41 
     12. Template Management........................................37 Management........................................42 
     13. The Collecting Process's Side..............................39 Side..............................43 
     14. Security Considerations....................................40 Considerations....................................45 
      14.1 IPsec Usage..............................................41 Usage..............................................46 
     14.1.1  Selectors..............................................41  Selectors..............................................46 
     14.1.2  Mode...................................................41  Mode...................................................46 
     14.1.3  Key Management.........................................42 Management.........................................46 
     14.1.4  Security Policy........................................42 Policy........................................46 
     14.1.5  Authentication.........................................42  Authentication.........................................47 
     14.1.6  Availability...........................................42  Availability...........................................47 
      14.2 TLS Usage................................................42 Usage................................................47 
      14.3 Protection against DoS attacks...........................42 attacks...........................47 
      14.4 When IPsec or TLS is not an option.......................43 option.......................48 
      14.5 Logging an IPFIX Attack..................................44 Attack..................................48 
     15. IANA Considerations........................................44 Considerations........................................49 
      15.1 Numbers used in the Protocol.............................49 
      15.2 Numbers used in the Information Model....................49 
     16. Examples...................................................44 Examples...................................................50 
      16.1 Message Header Example...................................45 Example...................................50 
      16.2 Template Set Example.....................................45 Example.....................................51 
      16.3 Data Set Example.........................................46 Example.........................................51 
      16.4 Options Template Set Example.............................47 Example.............................52 
 
 
  Claise, et. al            Standard Track                    [Page 3] 
                   IPFIX Protocol Specification           October 2004 
 
 
      16.5 Data Set with Options Data Records Example...............48 Example...............53 
     17. References.................................................48 References.................................................54 
      17.1 Normative References.....................................48 References.....................................54 
      17.2 Informative References...................................49 References...................................54 
     18. Acknowledgments............................................50 Acknowledgments............................................55 
  
 1.     Points of Discussion 
    


 
 
  Claise, et. al            Standard Track                    [Page 3] 
                   IPFIX Protocol Specification            August 2004 
    
   This section covers the open issues, still to be resolved/updated in 
   this draft.  Note that the issues starting with PROTO-31 have been 
   added to this draft version.  
    
   PROTO-4: TCP section not yet covered.  Starting point: draft-leinen-
   ipfix-tcp-00.txt. Ideally the same structure as SCTP and UDP should 
   be preserved.   
    
   PROTO-21: Do we need to define some mandatory content of the 
   metering process statistics option template? 
       - Maurizio suggested text on the mailing list 
       - proposal after IETF60: look at what is required in [IPFIX-
   REQ], and come up with a minimum set of data types. 
   Note: the ipfixOption is not yet defined in the [IPFIX-INFO]; needed 
   for the metering process statistics  
    
   PROTO-23: Finalize the time details. The time-related Information 
   Elements are not defined in [IPFIX-INFO] 
     
   PROTO-24: Section 11 "Linkage with the information model" must be 
   completed with types used in [IPFIX-INFO] 
     
   PROTO-25: The section "Template Management" and "The Collecting 
   Process's Side" will have to updated according to the transport 
   protocol. 
       - For example, the point 2 of the section "Template Management". 
         Remark: the template management will vary with TCP, SCTP,   
         etc... 
         Must have both sections updated: transport updated and  
         template management sections (BTW, this is the same for the  
         failover section). 
       - From Deri's draft: On the other hand as a probe can send flows 
       to several collectors (e.g. in round-robin or as a reflector) it 
       must keep track of per-collector templates transmission. This 
       means that if collector X reconnects, the probe must send the 
       template only to this collector and not to all collectors. 
        
     PROPOSAL, after IETF60: treat UDP as the exception, in the template 
     subsection of the UDP transport protocol. 
    

 
 
  Claise, et. al            Standard Track                    [Page 4] 
                   IPFIX Protocol Specification            August 2004 
 
 
   PROTO-26: IANA considerations section to be updated. Consensus from 
   IETF60 + notion of security. Nevil wrote the section already. 
 
   PROTO-30: review the requirements draft RFC 3917, to see what if we miss, once 
   it's an I-RFC 
    
   New Issue miss any requirements 
    
   PROTO-31 The "Sequence Number" and "Source ID" treatment in case of 
   multiple streams in SCTP is not well described. For example, in case 
   the Templates are sent to one stream and the flow records to another 
   one, what should the "Sequence Number"? What should the collector 
   do? See David Moore's post   

   PROTO-32 Correct this issue below 


 
 
  Claise, et. al            Standard Track                    [Page 4] 
                   IPFIX Protocol Specification           October 2004 
 
 
     The Collecting Process SHOULD verify that the received IPFIX 
     Messages inside one stream do not have differing SID Source ID values 
     and silently discard any data that does NOT match the initial 
     value.  

     The Exporting Process SHOULD NOT transmit messages inside one 
     stream with multiple SID Source ID values. The correlated Flow Records 
     are then treated like a normal export Flow. 

   PROTO-33: correct the next paragraphs: silently? reset the 
   connection? log an error? should the exporting process be allowed to 
   sent multiple SID Source ID per stream. 

        The Collecting Process SHOULD verify that the received IPFIX 
        Messages inside one stream do not have differing SID Source ID 
        values and silently discard any data that does NOT match the 
        initial value.  

        The Exporting Process SHOULD NOT transmit messages inside one 
        stream with multiple SID Source ID values. The correlated Flow 
        Records are then treated like a normal export Flow. 
   PROTO-34: Need a security expert to review the security section: 
          - [TBD] in the security section, [EDITOR'S section 
          - [EDITOR NOTE: the security section may need be adapted to 
          the revised transport section], [XXX-
   REFERENCE] and [XXX-REFERENCE] 
          - [XXX-SCTP-BLIND-SPOOFING-REFERENCE] not defined 
    
   PROTO-35: make sure 
          - TCP Security 
          1. Handshake: should we introduce a handshake sequence at the definitions match between [IPFIX-ARCH] and 
   [IPFIX-PROTO] 
    
 
 
  Claise, et. al            Standard Track                    [Page 5] 
                   IPFIX Protocol Specification            August 2004 
          start of the connection? A simple ASCII-based handshake could 
          be used to request TLS.  
          2. It would make sense to add TLS support even in the absence 
          of a handshake. It would be the responsibility of the 
          collector (connection initiator) to know whether TLS setup is 
          required. 
 
   PROTO-36: Insert an Enterprise Specific Information Element example. 
   For scope and non scope. 
   PROTO-37: 
    
   PROTO-38: [IPFIX-INFO] consistency issue: 
          - the ipfixOption, time, droppedFUPacketCount, 
          droppedFUByteCount, droppedFlows, keyList, 
          timeFirstFUDropped, timeLastFUDropped, droppedFAPacketCount, 
          droppedFAByteCount, timeFirstFADropped, timeLastFADropped, 

 
 
  Claise, et. al            Standard Track                    [Page 5] 
                   IPFIX Protocol Specification           October 2004 
 
 
          and Exporter ID, Source ID Information Elements are not used 
          in this document but not yet specified in [IPFIX-INFO]. 
          - Review the Options Template example once the Source ID is 
          defined as an information element  
   PROTO-39 : what is happening when we reach the maximum number of 
   Template ID? Wrap around? 

   PROTO-44: UDP, TCP, and SCTP ports XXXX should be replaced once 
   assigned by IANA. 
 2.     Introduction 
    
   A data network with IP traffic, primarily consists of IP Flows 
   passing through the network elements of the network.  It is often 
   interesting, useful or even a requirement to have access to 
   information about these flows that pass through the network elements 
   for administrative or other purposes.  The IPFIX collecting process 
   should be able to receive the flow information passing through 
   multiple network elements within the data network.  This requires 
   uniformity in the method of representing the flow information and 
   the means of communicating the flows from the network elements to 
   the collection point.  This document specifies the protocol to 
   achieve these aforementioned requirements.  This document specifies 
   in detail the representation of different flows, the additional data 
   required for flow interpretation, packet format, transport 
   mechanisms used, security concerns, etc. 
    
 2.1      IPFIX Documents Overview 
    
   The IPFIX protocol provides network administrators with access to IP 
   flow information.  The architecture for the export of measured IP 
   flow information out of an IPFIX exporting process to a collecting 
   process is defined in [IPFIX-ARCH], per the requirements defined in 
   [IPFIX-REQ].  [IPFIX-PROTO]  This document specifies how IPFIX flow record data, 
   options record data, and templates are carried via a congestion-
   aware transport protocol from IPFIX exporting process to IPFIX 
   collecting process.  IPFIX has a formal description of IPFIX 
   information elements (fields), their name, type and additional 
   semantic information, as specified in [IPFIX-INFO].  Finally [IPFIX-
   AS] describes what type of applications can use the IPFIX protocol 
   and how they can use the information provided.  It furthermore shows 
   how the IPFIX framework relates to other architectures and 
   frameworks.  
    
 
 
  Claise, et. al            Standard Track                    [Page 6] 
                   IPFIX Protocol Specification            August           October 2004 
 
 
 3.    Terminology 
 
   The definitions of the basic terms like IP Traffic Flow, Exporting 
   Process, Collecting Process, Observation Points, etc. are 
   semantically identical with that found in the IPFIX requirements 
   document [IPFIX-REQ].  Some of the terms have been expanded for more 
   clarity when defining the protocol.  Additional terms required for 
   the protocol has also been defined.  Definitions in this document 
   and in [IPFIX-ARCH] are equivalent, except that definitions which 
   are only relevant to the IPFIX protocol only appear here.  Should 
   there be any apparent discrepancy in definitions between these two 
   documents, the definitions defined in this document take precedence. 
    
   The terminology summary table in Section 3.1 gives a quick overview 
   of the relationships between some of the different terms defined. 
  
 Observation Point 
 
   The 
 
   An Observation Point is a location in the network where IP packets 
   can be observed.  Examples are include: a line to which a probe is 
   attached, a shared medium medium, such as an Ethernet-based LAN, a single 
   port of a router, or a set of interfaces (physical or logical) of a 
   router. 
    
   Note that one Observation Point may be a superset of several 
   other Observation Points.  For example, one Observation Point can be 
   an entire line card.  This would be the superset of the 
   individual Observation Points at the line card's interfaces.  
 
 Observation Domain 
 
   The set of Observation Points, which is the largest aggregatable set 
   of Flow information at the Metering Process is termed an Observation 
   Domain.  Each Observation Domain presents itself as a unique ID (its 
   Source ID, SID) ID) to the Collecting Process for identifying the IPFIX 
   Messages it generates.  For example, a router line card composed of 
   several interfaces with each interface being an Observation Point.  
   Every Observation Point is associated with an Observation Domain. 
    
 IP Traffic Flow or Flow 
 


 
 
  Claise, et. al            Standard Track                    [Page 7] 
                   IPFIX Protocol Specification            August 2004 
 
   There are several definitions of the term 'flow' being used by the 
   Internet community.  Within the context of IPFIX we use the 
 
 
  Claise, et. al            Standard Track                    [Page 7] 
                   IPFIX Protocol Specification           October 2004 
 
 
   following one: definition: 
    
   A flow Flow is defined as a set of IP packets passing an Observation 
   Point in the network during a certain time interval.  All packets 
   belonging to a particular flow Flow have a set of common properties.  
   Each property is defined as the result of applying a function to the 
   values of: 
    
      1. one or more packet header field (e.g. destination IP address),    
      transport header field (e.g. destination port number), or  
      application header field (e.g. RTP header fields [RFC1889]) 
    
      2. one or more characteristics of the packet itself (e.g. number  
      of MPLS labels, etc...) 
    
      3. one or more of fields derived from packet treatment (e.g. next  
      hop IP address, the output interface, etc...) 
    
   A packet is defined to belong to a flow Flow if it completely satisfies 
   all the defined properties of the flow. Flow. 
    
   This definition covers the range from a flow Flow containing all packets 
   observed at a network interface to a flow Flow consisting of just a 
   single packet between two applications.  It includes packets 
   selected by a sampling mechanism. 
 
 Flow Key 
  
   Each of the fields which belong to 
    
   1. Packet  Belong to the packet header (e.g. destination IP address) 
    
   2. Property  Are a property of the packet itself (e.g. packet length) 
    
   3. Derived  Are derived from packet treatment (e.g. AS number) 
    
   and which is are used to define a Flow is are termed a Flow Key. Keys. 
    
 Flow Record 
 
   A Flow Record contains information about a specific Flow that was 
   observed at an Observation Point.  A Flow Record contains measured 
   properties of the Flow (e.g. the total number of bytes of all 
 
 
  Claise, et. al            Standard Track                    [Page 8] 
                   IPFIX Protocol Specification           October 2004 
 
 
   packets of the Flow) and usually characteristic properties of the 
   Flow (e.g. source IP address).  
 
 
  Claise, et. al            Standard Track                    [Page 8] 
                   IPFIX Protocol Specification            August 2004  
    
 Metering Process 
 
   The Metering Process generates Flow Records.  Input to the process 
   are packet headers observed at an Observation Point and packet 
   treatment at the Observation Point, for Point (for example the selected output 
   interface. 
   interface). 
    
   The Metering Process consists of a set of functions that includes 
   packet header capturing, timestamping, sampling, classifying, and 
   maintaining Flow Records. 
    
   The maintenance of Flow Records may include creating new records, 
   updating existing ones, computing Flow statistics, deriving further 
   Flow properties, detecting Flow expiration, passing Flow Records to 
   the Exporting Process, and deleting Flow Records. 
    
 Exporting Process 
 
   The Exporting Process sends Flow Records to one or more Collecting 
   Processes.  The Flow Records are generated by one or more Metering 
   Processes. 
    
 IPFIX Device 
    
   A device hosting 
    
   An IPFIX Device hosts at least an one Observation Point, a Metering 
   Process and an Exporting Process.  Typically, corresponding 
   Observation Point(s), Metering Process(es) and Exporting Process(es) 
   are co-
   located co-located at this such a device, for example at a router. 
    
 Exporter 
    
   The 
 
   A device which hosts an one or more Exporting Process. Processes is termed an 
   Exporter. 
    
 Collecting Process 
 
   The 
 
   A Collecting Process receives Flow Records from one or more 
   Exporting Processes.  The Collecting Process might process or store 
   received Flow Records or further process them, Records, but these such actions are out of 
   the scope of for this 
   document. 
    
 Collector 
 
 
  Claise, et. al            Standard Track                    [Page 9] 
                   IPFIX Protocol Specification            August           October 2004 
 
 
   The 
 
 
    
 Collector 
 
   A device which hosts one or more Collecting Processes. Processes is termed a 
   Collector. 
    
 Template 
 
   Template is an ordered sequence of pairs (<type,length>), used to 
   completely identify the structure and semantics of a particular 
   information that needs to be communicated from the IPFIX Device to 
   the Collector.  Each template Template is uniquely identifiable by some means 
   (e.g. by using of a 
   Template ID). ID. 
    
 IPFIX Message 
 
   An IPFIX Message is a message originating at the Exporting Process 
   that carries the IPFIX records of this Exporting Process and whose 
   destination is the Collecting Process.  An IPFIX Message is 
   encapsulated within a transport layer header. 
    
 Message Header 
 
   The Message Header is the first part of an IPFIX Message, which 
   provides basic information about the message such as the IPFIX 
   version, length of the message, message sequence number, etc. 
    
 Template Record 
 
   A Template Record defines the structure and interpretation of fields 
   in a Flow Data Record. 
    
 Flow Data Record 
 
   A Flow Data Record is a data record that contains values of the Flow 
   parameters corresponding to a Template Record.  
    
 Options Template Record 
 
   An Options Template Record defines the structure and interpretation 
   of fields in an Options Data Record, including defining how to scope 
   the applicability of the Options Data Record. 
    
 
 
  Claise, et. al            Standard Track                   [Page 10] 
                   IPFIX Protocol Specification           October 2004 
 
 
 Options Data Record 
   The Options Data Record is a data record that contains values and 
   scope information of the Flow measurement parameters, corresponding 
   to an Options Template Record. 
 
 
  Claise, et. al            Standard Track                   [Page 10] 
                   IPFIX Protocol Specification            August 2004 
    
 Set 
 
   Set is a generic term for a collection of records that have a 
   similar structure.  In an IPFIX Message, one or more Sets follow the 
   Message Header. 
    
   There are three different types of Sets: Template Set, Options 
   Template Set, and Data Set.  
     
 Template Set 
 
   A Template Set is a collection of one or more Template Records that 
   have been grouped together in an IPFIX Message.  
     
 Options Template Set 
 
   An Options Template Set is a collection of one or more Options 
   Template Records that have been grouped together in an IPFIX 
   Message. 
    
 Data Set 
 
   A Data Set is one or more records, of the same type, that are 
   grouped together in an IPFIX Message.  Each record is either a Flow 
   Data Record or an Options Data Record previously defined by a 
   Template Record or an Options Template Record. 
    
 Information Element 
    
   An Information Element is a protocol and encoding independent 
   description of an attribute which may appear in an IPFIX Flow 
   Record.  The IPFIX information model [IPFIX-INFO] defines the base 
   set of Information Elements for IPFIX.  The type associated with an 
   Information Element indicates constraints on what it may contain and 
   also determine the valid encoding mechanisms for use in IPFIX. 
 


 
 
  Claise, et. al            Standard Track                   [Page 11] 
                   IPFIX Protocol Specification           October 2004 
 
 
 3.1      Terminology Summary Table 
 
    +------------------+---------------------------------------------+ 
    |                  |                    Contents                 | 
    |                  +--------------------+------------------------+ 
    |       Set        | Template  Record   |      data record       | 
 
 
  Claise, et. al            Standard Track                   [Page 11] 
                   IPFIX Protocol Specification            August 2004 
    +------------------+--------------------+------------------------+ 
    |                  |                    |  Flow Data Record(s)   | 
    |   Data Set       |          /         |          or            | 
    |                  |                    | Options Data Record(s) | 
    +------------------+--------------------+------------------------+ 
    |   Template Set   | Template Record(s) |           /            | 
    +------------------+--------------------+------------------------+ 
    | Options Template | Options Template   |           /            | 
    |       Set        | Record(s)          |                        | 
    +------------------+--------------------+------------------------+ 
 
      Figure A: Terminology Summary Table 
    
   A Data Set is composed of an Options Data Record(s) or Flow Data 
   Record(s).  No Template Record is included.  A Template Record 
   defines the Flow Data Record, and an Options Template Record defines 
   the Options Data Record.  
    
   A Template Set is composed of Template Record(s).  No Flow or 
   Options Data Record is included. 
     
   An Options Template Set is composed of Options Template Record(s).  
   No Flow or Options Data Record is included.  
 
 4.     Criteria for Flow Expiration and Export  
    
 4.1      Flow Expiration 
     
   A Flow is considered as expired under the following conditions:  
    
   1. If the Metering Process can detect the end of a Flow.  For 
   example, if the FIN or RST bit is detected in a TCP 
   [TCP] connection.  
    
   2. If no packets belonging to the Flow have been observed for a 
   certain period of time.  This time period should be configurable at 
   the Metering Process.  Note that if the time period is set to 0, the 
   Metering Process will create a Flow for every single packet 
 
 
  Claise, et. al            Standard Track                   [Page 12] 
                   IPFIX Protocol Specification           October 2004 
 
 
   observed. 
    
   3. If the Metering Process experiences internal constraints, a Flow 
   may be expired forcibly.  For example, counters wrapping or low 
   memory. 

 
 
  Claise, et. al            Standard Track                   [Page 12] 
                   IPFIX Protocol Specification            August 2004 
     
 4.2      Flow Export 
    
   The Exporting Process decides when and whether to export an expired 
   Flow.  A Flow can be exported because it expired due to the reasons 
   mentioned in Flow Expiration section.  For example: the Exporting 
   Process exports a portion of the expired Flows every 'x' seconds.  
    
   For long-lasting Flows, the Exporting Process should export the Flow 
   Records on a regular basis or based on some export policy.  This 
   periodicity or export policy should be configurable at the Metering 
   Process. 
 
 5.     Transport Protocol 
    
   The IPFIX Protocol Specification has been designed to be transport 
   protocol independent.  Note that the Exporter can export to multiple 
   Collecting Processes, using independent transport protocols. 
    
   The Export Packet 16-bit LENGTH field limits the length of a IPFIX 
   Message to 65536 octets including the header.  A Collecting Process 
   MUST be able to handle IPFIX Message lengths of up to 65536 octets. 
    
    
 5.1      Transport Compliance and Transport Usage 
 
   We need to differentiate between what must be implemented (so that 
   operators can interoperably deploy compliant implementations from 
   different vendors) and what should or could be used in various 
   operational environments. We must also make sure that ALL 
   implementations can operate in a congestion-aware and congestion 
   avoiding mode. 
    
   SCTP [RFC2960] and SCTP-PR [RFC3758] MUST be implemented by all 
   compliant implementations.  UDP [UDP] MAY also be implemented by 
   compliant implementations.  TCP [TCP] MAY also be implemented by 
   compliant implementations.  
    

 
 
  Claise, et. al            Standard Track                   [Page 13] 
                   IPFIX Protocol Specification           October 2004 
 
 
   SCTP-PR SHOULD be used in deployments where Exporters and Collectors 
   are communicating over links which that are susceptible to congestion.  
   SCTP-PR is capable of providing any required degree of reliability. 
    
   TCP MAY be used in deployments where Exporters and Collectors 
   communicate over links which that are susceptible to congestion, but 
   SCTP-PR SCTP-
   PR is preferred, due to its ability to limit back pressure on 
   Exporters and its message versus stream orientation.  
    


 
 
  Claise, et. al            Standard Track                   [Page 13] 
                   IPFIX Protocol Specification            August 2004  
    
   UDP MAY be used although it is not a congestion aware protocol.  
   However, the IPFIX traffic between Exporter and Collector MUST 
   remain wholly within the administrative domains of the operators. 
    
 5.2     TCP 
    
   EDITOR NOTE: to be completed.  A good starting point is draft-
   leinen-ipfix-tcp-00.txt.  TCP [TCP]  
    
 5.3      SCTP 
    
   This section describes how IPFIX can be transported over SCTP 
   [RFC2960] using the PR-SCTP [RFC3758] extension.    

 5.3.1 TCP [TCP].  

 5.2.1   Congestion Avoidance 
    
   The SCTP transport protocol provides the required level of 
    
   TCP will detect congestion avoidance by design. 

 5.3.2   Reliability 
 
   The SCTP transport protocol is by default reliable, but has the 
   capability to operate in unreliable and partially reliable modes 
   [RFC3758]. 
    
   Using reliable SCTP streams (referred to hereafter as "streams") for 
   the IPFIX export is not in itself a guarantee that all data records 
   are delivered.  If there is congestion on the link from end-to-end path between the IPFIX 
   Exporting Process to and the IPFIX Collecting Process, or if a significant 
   number of retransmissions are required, the send queues on the 
   Exporting Process may fill up: and limit the 
   transfer rate accordingly.  When an IPFIX Exporting Process MAY has 
   records to export, but detects that transmission by TCP is 
   temporarily impossible, it can either 
   suspend export wait until sending is possible 
   again, or discard IPFIX Messages.  If data records are 
   discarded it can decide to drop the sequence numbers used for record.  In the latter case, the 
   dropped export data MUST reflect be accounted for, so that the loss amount of data.   

 5.3.3 
   dropped export data can be reported. 

 5.2.2   Reliability 
    
   TCP provides an intrinsically reliable delivery service from the 
   IPFIX Exporting Process to the IPFIX Collecting Process.  

 5.2.3   MTU 
 
   SCTP 
    
   TCP provides the required IPFIX Message fragmentation service based 
   on path MTU discovery.  

 5.2.4   Exporting Process 
    
   The following sections describe how an IPFIX-over-TCP connection is 
   created, how IPFIX data is transferred over it, and how a connection 
   is to be terminated.  
 
 
  Claise, et. al            Standard Track                   [Page 14] 
                   IPFIX Protocol Specification            August           October 2004 
 
 
 5.3.4   Exporting Process 

 5.3.4.1 Association 
 
 
 5.2.4.1 Connection Establishment 
    
   The IPFIX Exporting Process MUST create at least one association 
   (connection "bundle" in SCTP terminology) initiates a TCP connection to the IPFIX 
   Collecting Process. 
    
   However,  By default, the Collecting Process listens for 
   connections on TCP port XXXX (to be assigned by IANA).  It MUST be 
   possible to configure both the Exporting and Collecting Processes to 
   use a different TCP port.  
    
   An Exporting Process MAY create support more than one association. 
   The active connection to 
   different Collecting Processes (including the case of different 
   Collecting Processes on the same host).  

 5.2.4.2 Connection Release 
    
   When an Exporting Process MUST NOT initiate has no more IPFIX Messages to send, it 
   SHOULD close the TCP connection.   

 5.3.4.2 Source ID 
  
   The IPFIX Message MUST contain a Message Header, which includes  
    
   When a 
   Source ID (SID).  The Exporting Collecting Process uses the SID no longer wants to uniquely 
   identify receive IPFIX messages, 
   it SHOULD close the TCP connection, but SHOULD continue to receive 
   and process IPFIX messages until the Exporting Process has closed 
   its end.  
    
   When an Collecting Process the Observation Domain detects that 
   metered the Flows. 

 5.3.4.3 Stream 
 
   An TCP connection to the 
   Exporting Process is abnormally terminated, it MUST request at least two outbound streams per 
   association.  The first stream (referred continue to as stream zero in 
   listen for a new connection.  
    
   When an Exporting Process detects that the 
   rest of this document), TCP connection is used 
   abnormally terminated, it SHOULD try to send re-establish the Template Set and the 
   Options Template Set.  Stream zero MUST be fully reliable.  Data 
   Sets MUST NOT connection.  
    
   Connection timeouts SHOULD be configurable.  

 5.2.4.3 IPFIX Message Encoding 
    
   TCP provides message boundary marking marking mechanism. When IPFIX 
   Message are sent on stream zero. 
    
   Depending on over a TCP connection, the application requirement, LENGTH field in the Exporting Process 
   selects 
   IPFIX Message header defines the mode (unreliable, partially reliable, or fully reliable 
   mode) end of the stream, used to send the Data Sets.  Unreliable mode 
   MAY be used where the application does not require reliable 
   transmission each message and the use of a retransmission queue is impractical. 
    
   An Exporter MAY use multiple streams to export Data Sets, in some 
   cases different applications will have different requirements in 
   terms of reliability.  In such a case, the Observation Domain MUST 
   use the same SID value on all start 
   of the multiple streams it uses.  Data 
   Sets next message.  
    
   If an Exporting Process exports data from multiple Observation Domains MUST NOT be transmitted over 
   the same stream; the Collecting Process 
   Domains, it should however verify that 
   the SID values are the expected values.   
    
   When Data Sets are exported over a partially reliable stream, they 
   SHOULD be marked for retransmission as long as there is room in careful to choose the 
   SCTP send queues.  However during times of congestion or other IPFIX Message lengths 
   appropriately to avoid head-of-line blocking between different 
   Observation Domains.  

 
 
  Claise, et. al            Standard Track                   [Page 15] 
                   IPFIX Protocol Specification            August           October 2004 
 
 
   retransmission events, if the queue overflows, the oldest data 
   record that has been transmitted and marked as partially reliable 
   should be freed and marked to be skipped per the PR-SCTP [RFC3758] 
   specification.  The freed buffer space should then be re-used for 
   the new Data Sets being exported.   

 5.3.4.4 Template 
 
 
 5.2.4.4 Templates Sets and Option Template Sets MUST be sent on stream zero 
   with full reliability. 
    
   New Template Records SHOULD be transmitted as soon as they are 
   created on the Metering Process, and preferably before any 
   associated Flow and Options Data Record is transmitted.  The 
   Collecting Process SHOULD accept Flow and Options Data Records 
   without the associated Template Record. 

 5.3.5   Collecting Process 
 
   The Collecting Process SHOULD listen for a new association request 
   from the Exporting Process.  The Exporting Process will request a 
   number of streams to use for export.  A  
    
   A Collecting Process MUST 
   support at least two inbound streams per association.  An Exporting 
   Process record all Template and Collecting Process MAY ask Option Template 
   Records for and support more than two 
   streams. 
    
   The Collecting Process SHOULD verify that the received IPFIX 
   Messages inside one stream do not have differing SID values and 
   silently discard any data that does NOT match duration of the initial value.   
   The connection, as an Exporting Process SHOULD NOT transmit messages inside one stream 
   with multiple SID values.  The correlated Flow Records are then 
   treated like a normal export Flow. 
    
   If the Collecting Process receives a malformed IPFIX Message, it 
   MUST reset the SCTP association, discard the message and log the 
   error.   
     
   When an SCTP association 
   is closed, the Collecting Process MUST 
   discard all templates received over that association and stop 
   decoding IPFIX Messages that use those templates. 



 
 
  Claise, et. al            Standard Track                   [Page 16] 
                   IPFIX Protocol Specification            August 2004 
 
 
 5.3.6   Failover not required to re-export Template Records.  

 5.2.5   Fail-over 
    
   If the Collecting Process does not acknowledge the attempt by the 
   Exporting Process to establish an association it will a connection, the Exporting Process 
   should retry. The retry using schedule SHOULD be configurable.  In the SCTP exponential backoff feature. 
   default configuration, an Exporting Process MUST NOT attempt to 
   establish a connection more frequently than once per minute.  
    
   The Exporter MAY log an alarm if the time to establish the 
   association exceeds a specified threshold.  
    
   If Collecting Process failover fail-over is supported by the Exporting 
   Process a second SCTP association TCP connection MAY be opened in advance. 
    
 5.4      UDP 
    
 5.3      SCTP 
 
   This section describes how IPFIX can be transported over UDP  
   [RFC768] 

 5.4.1 SCTP 
   [RFC2960] using the PR-SCTP [RFC3758] extension.    

 5.3.1   Congestion Avoidance  
     
   UDP has no integral 
    
   The SCTP transport protocol provides the required level of 
   congestion avoidance mechanism.  Its use  
   over by design. 
    
   SCTP will detect congestion sensitive network paths is therefore deprecated.   
   UDP MAY be used in deployments where Exporters and Collectors  
   always communicate over dedicated links which are not susceptible  
   to congestion.   

 5.4.2   Reliability  
    
   UDP is not a reliable transport protocol, and cannot guarantee  
   delivery of messages.  IPFIX Messages sent from the Exporting  
   Process to end-to-end path between 
   the Collecting IPFIX Exporting Process using UDP may therefore be lost.   
   UDP MUST NOT be used unless and the application can tolerate some  
   loss of Messages. 
    
   The IPFIX Collecting Process could deduce the loss Process, 
   and reordering of IPFIX 
   Messages by looking at the discontinuities in limit the transfer rate accordingly.  When an IPFIX Message 
   sequence number.  These conditions SHOULD be logged. 
    
   Templates sent from the 
   Exporting Process has records to export, but detects that 
   transmission by SCTP is temporarily impossible, it can either 
   wait until sending is possible again, or it can decide to drop the Collecting  
   Process using UDP as a transport MUST be resent at regular  
   intervals in case previous copies were lost.  Implementations  
   MAY send templates using a reliable transport protocol, and  
   send IPFIX Flow and Option Data Records using UDP as 
   record.  In the  
   transport protocol. latter case, the dropped export data MUST 
 
 
  Claise, et. al            Standard Track                   [Page 17] 16] 
                   IPFIX Protocol Specification            August           October 2004 
 
 
 5.4.3   MTU 
    
   The maximum size of exported messages MUST 
 
 
   be configured such accounted for, so that the total packet size does not exceed the path MTU.   

 5.4.4   Port Numbers amount of dropped export data can be 
   reported. 
    

 5.3.2   Reliability 
 
   The UDP destination port SCTP transport protocol is set by manual configuration at both  
   Exporting Process and Collecting Process.   
    
   The UDP source port is allocated from the dynamic and/or  
   private ports space.   

 5.4.5   Exporting Process 
    
   The Exporting Process MAY duplicate default reliable, but has the IPFIX Message 
   capability to the several operate in unreliable and partially reliable modes 
   [RFC3758]. 
    
   Using reliable SCTP streams (referred to hereafter as "streams") for 
   the IPFIX export is not in itself a guarantee that all data records 
   are delivered.  If there is congestion on the link from the 
   Exporting Process to the Collecting Process, or if a significant 
   number of retransmissions are required, the send queues on the 
   Exporting Process may fill up: the Exporting Process MAY either 
   suspend export or discard IPFIX Messages.  If data records are 
   discarded the sequence numbers used for export MUST reflect the loss 
   of data.   

 5.3.3   MTU 
 
   SCTP provides the required IPFIX Message fragmentation service based 
   on path MTU discovery. 

 5.3.4   Exporting Process 

 5.3.4.1 Association Establishment 
    
   The IPFIX Exporting Process SHOULD initiate an SCTP association with 
   the IPFIX Collecting Process.  By default, the Collecting Process 
   listens for connections on SCTP port XXXX (to be assigned by 
   IANA).  It MUST be possible to configure both the Exporting 
   and Collecting Processes to use a different SCTP port. 
    
   The Exporting Process MAY establish more than one associations 
   (connection "bundle" in SCTP terminology) to the Collecting Process. 
    
   An Exporting Process MAY support more than one active association 
   to different Collecting Processes (including the case of different 
   Collecting Processes on the same host). 
    

 
 
  Claise, et. al            Standard Track                   [Page 17] 
                   IPFIX Protocol Specification           October 2004 
 
 
 5.3.4.2 Association Shutdown 
    
   When an Exporting Process has no more IPFIX Messages to send, it 
   SHOULD shutdown the SCTP association. 
    
   When a Collecting Process no longer wants to receive IPFIX 
   Messages, it SHOULD shutdown its end of the association.  The 
   Collecting Process SHOULD continue to receive and process 
   IPFIX Messages until the Exporting Process has closed its end. 
    
   When a Collecting Process detects that the SCTP association has been 
   abnormally terminated, it MUST continue to listen for a new 
   association establishment. 
    
   When an Exporting Process detects that the SCTP association to the 
   Collecting Process is abnormally terminated, it SHOULD try to re-
   establish the association.  
    
   Association timeouts SHOULD be configurable. 
    

 5.3.4.3 Source ID 
  
   The IPFIX Message MUST contain a Message Header, which includes a 
   Source ID.  The Exporting Process uses the Source ID to uniquely 
   identify to the Collecting Process the Observation Domain that 
   metered the Flows. 

 5.3.4.4 Stream 
 
   An Exporting Process MUST request at least two outbound streams per 
   association.  The first stream (referred to as stream zero in the 
   rest of this document), is used to send the Template Set and the 
   Options Template Set.  Stream zero MUST be fully reliable.  Data 
   Sets MUST NOT be sent on stream zero. 
    
   Depending on the application requirement, the Exporting Process 
   selects the mode (unreliable, partially reliable, or fully reliable 
   mode) of the stream, used to send the Data Sets.  Unreliable mode 
   MAY be used where the application does not require reliable 
   transmission and the use of a retransmission queue is impractical. 
    

 
 
  Claise, et. al            Standard Track                   [Page 18] 
                   IPFIX Protocol Specification           October 2004 
 
 
   An Exporter MAY use multiple streams to export Data Sets, in some 
   cases different applications will have different requirements in 
   terms of reliability.  In such a case, the Observation Domain MUST 
   use the same Source ID value on all of the multiple streams it uses.  
   Data Sets from multiple Observation Domains MUST NOT be transmitted 
   over the same stream; the Collecting Process should however verify 
   that the Source ID values are the expected values.   
    
   When Data Sets are exported over a partially reliable stream, they 
   SHOULD be marked for retransmission as long as there is room in the 
   SCTP send queues.  However during times of congestion or other 
   retransmission events, if the queue overflows, the oldest data 
   record that has been transmitted and marked as partially reliable 
   should be freed and marked to be skipped per the PR-SCTP [RFC3758] 
   specification.  The freed buffer space should then be re-used for 
   the new Data Sets being exported.   

 5.3.4.5 Template 
 
   Templates Sets and Option Template Sets MUST be sent on stream zero 
   with full reliability. 
    
   New Template Records SHOULD be transmitted as soon as they are 
   created on the Metering Process, and preferably before any 
   associated Flow and Options Data Record is transmitted.  The 
   Collecting Process SHOULD accept Flow and Options Data Records 
   without the associated Template Record. 
    
   A Collecting Process MUST record all Template and Option 
   Template Records for the duration of the association, as 
   an Exporting Process is not required to re-export Template Records. 

 5.3.5   Collecting Process 
 
   The Collecting Process SHOULD listen for a new association request 
   from the Exporting Process.  The Exporting Process will request a 
   number of streams to use for export.  A Collecting Process MUST 
   support at least two inbound streams per association.  An Exporting 
   Process and Collecting Process MAY ask for and support more than two 
   streams. 
    


 
 
  Claise, et. al            Standard Track                   [Page 19] 
                   IPFIX Protocol Specification           October 2004 
 
 
   The Collecting Process SHOULD verify that the received IPFIX 
   Messages inside one stream do not have differing Source ID values 
   and silently discard any data that does NOT match the initial value.   
   The Exporting Process SHOULD NOT transmit messages inside one stream 
   with multiple Source ID values.  The correlated Flow Records are 
   then treated like a normal export Flow. 
    
   If the Collecting Process receives a malformed IPFIX Message, it 
   MUST reset the SCTP association, discard the message and log the 
   error.   
     
   When an SCTP association is closed, the Collecting Process MUST 
   discard all templates received over that association and stop 
   decoding IPFIX Messages that use those templates. 

 5.3.6   Failover 
 
   If the Collecting Process does not acknowledge the attempt by the 
   Exporting Process to establish an association it will retry using 
   the SCTP exponential backoff feature.  The Exporter MAY log an alarm 
   if the time to establish the association exceeds a specified 
   threshold. 
    
   If Collecting Process failover is supported by the Exporting Process 
   a second SCTP association MAY be opened in advance. 
    
 5.4      UDP 
    
   This section describes how IPFIX can be transported over UDP  
   [RFC768] 

 5.4.1   Congestion Avoidance  
     
   UDP has no integral congestion avoidance mechanism.  Its use  
   over congestion sensitive network paths is therefore deprecated.   
   UDP MAY be used in deployments where Exporters and Collectors  
   always communicate over dedicated links that are not susceptible  
   to congestion.   

 5.4.2   Reliability  
    
   UDP is not a reliable transport protocol, and cannot guarantee  
   delivery of messages.  IPFIX Messages sent from the Exporting  
 
 
  Claise, et. al            Standard Track                   [Page 20] 
                   IPFIX Protocol Specification           October 2004 
 
 
   Process to the Collecting Process using UDP may therefore be lost.   
   UDP MUST NOT be used unless the application can tolerate some  
   loss of Messages. 
    
   The Collecting Process could deduce the loss and reordering of IPFIX 
   Messages by looking at the discontinuities in the IPFIX Message 
   sequence number.  These conditions SHOULD be logged. 
    
   Templates sent from the Exporting Process to the Collecting  
   Process using UDP as a transport MUST be resent at regular  
   intervals in case previous copies were lost.  Implementations  
   MAY send templates using a reliable transport protocol, and  
   send IPFIX Flow and Option Data Records using UDP as the  
   transport protocol. 

 5.4.3   MTU 
    
   The maximum size of exported messages MUST be configured such that  
   the total packet size does not exceed the path MTU.   

 5.4.4   Port Numbers 
    
   By default, the Collecting Process listens on the UDP port XXXX (to 
   be assigned by IANA).  It MUST be possible to configure both the 
   Exporting and Collecting Processes to use a different UDP port. 

 5.4.5   Exporting Process 
    
   The Exporting Process MAY duplicate the IPFIX Message  
   to the several Collecting Process.   

 5.4.5.1 Template 
    
   If sent using UDP as the transport protocol, Template Sets  
   and Option Template Sets MUST be re-sent at regular intervals.  How 
   frequently these Options Data Records are exported is configurable.   
   New Template Records SHOULD be transmitted as soon as they are  
   created on the Metering Process, and before any associated Data  
   Record is transmitted.  The Collecting Process SHOULD accept  
   Flow and Options Data Records without the associated Template 
   Record. 
    

 
 
  Claise, et. al            Standard Track                   [Page 21] 
                   IPFIX Protocol Specification           October 2004 
 
 
   If the Option Template scope is defined in another Template, then 
   both Templates SHOULD be sent in the same IPFIX Message. For 
   example: if a Flow Key Option Template (see section 8.3) is sent in 
   an Option Template, then the associated Template SHOULD be sent in 
   the same IPFIX Message. 

 5.4.6   Collecting Process 
    
   If the Collecting Process receives an IPFIX Message that it cannot  
   decode, it MUST discard the message and log the error.   
    
   The Collecting Process MUST associate a lifetime with each  
   Template received via UDP.  If the template is not refreshed by the  
   Exporting Process before that lifetime has expired, the  
   Collecting Process MUST discard the Template.  The Collecting  
   Process MUST NOT decode Flow or Option Data Records which  
   have an expired Template.   



 
 
  Claise, et. al            Standard Track                   [Page 18] 
                   IPFIX Protocol Specification            August 2004   

 5.4.7   Failover 
    
   Because UDP is not a connection oriented protocol, the Exporting 
   Process is unable to determine from the transport protocol that the 
   Collecting Process is no longer able to receive the IFPIX Messages.  
   Therefore, it can not invoke a failover mechanism.  However, the 
   Exporting Process MAY duplicate the IPFIX Message to several 
   Collecting Processes. 
    
 6.     Message Layout 
    
   An IPFIX Message consists of a Message Header followed by one or 
   more Sets.  The Sets can be any of the possible three types: 
   Template, Data, or Options Template.   
    
   The format of the IPFIX Message is shown in Figure B. 
    
   +--------+-------------------------------------------+ 
   |        | +----------+ +---------+ +----------+     | 
   |Message | | Template | |  Data   | | Options  |     | 
   | Header | |   Set    | |   Set   | | Template | ... | 
   |        | |          | |         | |    Set   |     | 
   |        | +----------+ +---------+ +----------+     | 
   +--------+-------------------------------------------+ 
    
 
 
  Claise, et. al            Standard Track                   [Page 22] 
                   IPFIX Protocol Specification           October 2004 
 
 
      Figure B: IPFIX Message format 
 
   A Set ID is used to distinguish the different types of Sets.  Set 
   IDs lower than 256 are reserved for special Sets, such as the 
   Template Set (ID 2) and the Options Template Set (ID 3).  The Data 
   Sets have a Set ID greater than 255.  The Set ID value of 0 and 1 
   are not used for historical reasons [NETFLOW9]. 
    
   The format of the Template, Data, and Options Template Sets will be 
   discussed later in this document.  The Exporter MUST code all binary 
   integers of the Message Header and the different Sets in network 
   byte order (also known as the big-endian byte ordering). 
    
   Following are some examples of IPFIX Messages: 
    
   1. An IPFIX Message consisting of interleaved Template, Data, and 
   Options Template Sets-A newly created Template is exported as soon 
   as possible.  So if there is already an IPFIX Message with a Data 
 
 
  Claise, et. al            Standard Track                   [Page 19] 
                   IPFIX Protocol Specification            August 2004 
   Set that is being prepared for export, the Template and Option Sets 
   are also interleaved with this information, subject to availability 
   of space. 
    
   +--------+--------------------------------------------------------+ 
   |        | +----------+ +---------+     +-----------+ +---------+ | 
   |Message | | Template | | Data    |     | Options   | | Data    | | 
   | Header | | Set      | | Set     | ... | Template  | | Set     | | 
   |        | |          | |         |     | Set       | |         | | 
   |        | +----------+ +---------+     +-----------+ +---------+ | 
   +--------+--------------------------------------------------------+  
    
      Figure C: IPFIX Message example 1 
    
   2. An IPFIX Message consisting entirely of Data Sets-After the 
   appropriate Template Records have been defined and transmitted to 
   the Collecting Process, the majority of IPFIX Messages consist 
   solely of Data Sets.   
    
   +--------+----------------------------------------------+ 
   |        | +---------+     +---------+      +---------+ | 
   |Message | | Data    | ... | Data    | ...  | Data    | | 
   | Header | | Set     | ... | Set     | ...  | Set     | | 
   |        | +---------+     +---------+      +---------+ | 
   +--------+----------------------------------------------+   
 
 
  Claise, et. al            Standard Track                   [Page 23] 
                   IPFIX Protocol Specification           October 2004 
 
 
    
      Figure D: IPFIX Message example 2 
 
   3. An IPFIX Message consisting entirely of Template and Options 
   Template Sets-When UDP is used as the transport protocol, Templates 
   Sets and Option Template Sets MUST be sent periodically to help 
   ensure that the Collecting Process has the correct Template Records 
   and Options Template Records when the corresponding Flow Data 
   Records are received.   
    
   +--------+-------------------------------------------------+ 
   |        | +----------+     +----------+      +----------+ | 
   |Message | | Template |     | Template |      | Options  | | 
   | Header | | Set      | ... | Set      | ...  | Template | | 
   |        | |          |     |          |      | Set      | | 
   |        | +----------+     +----------+      +----------+ | 
   +--------+-------------------------------------------------+ 
    
 
 
  Claise, et. al            Standard Track                   [Page 20] 
                   IPFIX Protocol Specification            August 2004 
    
      Figure E: IPFIX Message example 3 
    
    
 7.     IPFIX Message Format 
    
 7.1      Header Format 
    
   The format of the IPFIX Message Header format is shown in Figure F. 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Version Number          |            Length             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           Export Time                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Sequence Number                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Source ID                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure F: IPFIX Message Header format 
    
   Message Header Field Descriptions  
    

 
 
  Claise, et. al            Standard Track                   [Page 24] 
                   IPFIX Protocol Specification           October 2004 
 
 
   Version 
           Version of Flow Record format exported in this message.  The 
           value of this field is 0x000a for the current version. 
            
   Length 
           Total Length is the length of the IPFIX Message, measured in 
           octets, including message Header and Set(s). 
             
   Export Time 
           Time in seconds since 0000 UTC 1970, at which the Export 
           Packet leaves the Exporter. 
            
   Sequence Number 
           Incremental sequence counter of all IPFIX Messages sent from 
           the current Observation Domain by the Exporting Process.  
           This value SHOULD be used by the Collecting Process to 
           identify whether any IPFIX Messages have been missed. 
            

 
 
  Claise, et. al            Standard Track                   [Page 21] 
                   IPFIX Protocol Specification            August 2004 
            
   Source ID 
           A 32-bit value that identifies the Exporter Process 
           Observation Domain.  Collecting Process SHOULD use the 
           combination of the source IP address and the Source ID field 
           to separate different export streams originating from the 
           same Exporting Process. 
            
 7.2      Field Type Format 
            
   Vendors need the ability to define proprietary Information Elements, 
   because, for example, they are delivering pre-standards product, or 
   the Information Element is in some way commercially sensitive.  This 
   section describes the Field Type format for both IETF specified 
   Information Elements [IPFIX-INFO] and Vendor Specified Information 
   Elements, both the Template Set and the Option Template Set.   
    
   The Field Ids used to identify Information Elements are represented 
   by the Field Type.  When the Enterprise Field Type bit is set to 0, 
   the corresponding Field Type will report an IETF specified 
   Information Elements.  When the Enterprise Field Type bit is set to 
   1, the corresponding Field Type will report a Vendor Specified 
   Information Element.  
    
   The Field Type format is shown in Figure G. 
     
 
 
  Claise, et. al            Standard Track                   [Page 25] 
                   IPFIX Protocol Specification           October 2004 
 
 
      
      
      
       
       
        
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |E|      Field Type             |        Field Length           |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |                      Enterprise Number                        |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      
          Figure G: Field Type format 
      
        Where: 
      
       E  
          Enterprise Field Type.  If this bit is zero, the Field Type  
          identifies an IETF specified Information Element, and the  
          four octet Enterprise Number field MUST NOT be present.  If  
          this bit is one, the Field Type identifies a Vendor Specified  
          Information Element, and the Enterprise Number filed MUST be  
 
 
  Claise, et. al            Standard Track                   [Page 22] 
                   IPFIX Protocol Specification            August 2004  
          present.   
      
      Field Type  
         A numeric value that represents the type of the field.  Refer    
         to [IPFIX-INFO].   
    
      Field Length  
         The length of the corresponding Field Type, in bytes.  Refer    
         to [IPFIX-INFO].   
    
      Enterprise Number  
         IANA enterprise number [PEN] of the authority defining the  
         Field Type in this Template Record. 
            
 7.3      Template Set Format 
    
   One of the essential elements in the IPFIX format is the Template 
   Set.  Templates greatly enhance the flexibility of the Flow Record 
   format because they allow the Collecting Process to process Flow 
   Records without necessarily knowing the interpretation of all the 
   data in the Flow Record.  A Template Set MAY exclusively contain 
   IETF defined Field Types.  A Template Set MAY contain Vendor 
   Specified Information Elements from one or more vendors.   
    
   The format of the Template Set is shown in Figure H.   
 
 
  Claise, et. al            Standard Track                   [Page 26] 
                   IPFIX Protocol Specification           October 2004 
 
 
    
       0                   1                   2                   3  
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Set ID = 2           |          Length               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      Template ID 256          |         Field Count           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 1           |         Field Length 1        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    Enterprise Number  1.1                     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 2           |         Field Length 2        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type N           |         Field Length N        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
 
 
  Claise, et. al            Standard Track                   [Page 23] 
                   IPFIX Protocol Specification            August 2004   
      |                    Enterprise Number  1.N                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |      Template ID 257          |         Field Count           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 1           |         Field Length 1        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type 2           |         Field Length 2        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    Enterprise Number  2.2                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Field Type M           |         Field Length M        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                    Enterprise Number  2.M                     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                          Padding (opt)                        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure H: Template Set Format 
    
   The Template Set Field Definitions are as follows: 
    
     Set ID 
           Set ID value of 2 is reserved for the Template Set. 
 
 
  Claise, et. al            Standard Track                   [Page 27] 
                   IPFIX Protocol Specification           October 2004 
 
 
 
     Length 
           Total length of this Set.  Because an individual Template 
           Set MAY contain multiple Template Records, the Length value 
           MUST be used to determine the position of the next Set 
           record, which could be any type of Set.  Length is the sum 
           of the lengths of the Set ID, the Length itself, and all 
           Template Records within this Set. 
            
     Template ID 
           Each of the newly generated Template Records is given a 
           unique Template ID.  This uniqueness is local to the 
           Observation Domain that generated the Template ID.       
           Template IDs 0-255 are reserved for Template Sets, Options 
           Sets, and other reserved Sets yet to be created.  Template 
           IDs of Data Sets are numbered from 256 to 65535. 
            
     Field Count 
 
 
  Claise, et. al            Standard Track                   [Page 24] 
                   IPFIX Protocol Specification            August 2004 
           Number of fields in this Template Record.  Because a 
           Template Set usually contains multiple Template Records, 
           this field allows the Collecting Process to determine the 
           end of the current Template Record and the start of the 
           next. 
            
     Field Type 
           A numeric value that represents the type of the field.  
           Refer to [IPFIX-INFO]. 
               
     Field Length 
           The length of the corresponding Field Type, in bytes.  Refer 
           to [IPFIX-INFO]. 
            
      Enterprise Number  
           IANA enterprise number [PEN] of the authority defining the  
           Field Type. 
      
      Padding  
           The Exporting Process MAY insert some padding bytes, so that 
           the subsequent Set starts at an aligned boundary.  Padding 
           MUST be composed of zero (0) bytes.  The padding length MUST 
           be shorter than any allowable Template Record in this 
           Template Set.  It is important to note that the Length field 
           includes the padding bits. bytes.  Because Template Sets are 
 
 
  Claise, et. al            Standard Track                   [Page 28] 
                   IPFIX Protocol Specification           October 2004 
 
 
           always 4-byte aligned by definition padding is only needed 
           in case of other alignments e.g. on 8-byte boundaries. 
            
   The Set ID value of 0 and 1 are not used for historical reasons 
   [NETFLOW9]. 
    
 7.4      Data Set Format 
    
   The format of the Data Set is shown in Figure I. 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Set ID = Template ID        |          Length               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 1 - Field Value 3    |             ...               | 
 
 
  Claise, et. al            Standard Track                   [Page 25] 
                   IPFIX Protocol Specification            August 2004 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 2 - Field Value 1    |   Record 2 - Field Value 2    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 2 - Field Value 3    |             ...               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 3 - Field Value 1    |             ...               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              ...              |        Padding (opt)          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    
      Figure I: Data Set Format 
    
   Note that not all Field Values do necessarily have a length of 16 
   bit. 
    
   Data Set Field Descriptions are as follows: 
    
   Set ID = Template ID 
           Each Data Set is associated with a Set ID.  The Set ID maps 
           to a (previously generated) Template ID.  The Collecting 
           Process MUST use the Set ID to find the corresponding 
           Template Record and decode the Flow Records from the Set. 
            
   Length 
           The length of this Set.   
 
 
  Claise, et. al            Standard Track                   [Page 29] 
                   IPFIX Protocol Specification           October 2004 
 
 
           Length is the sum total of lengths of Set ID, Length itself, 
           all Flow Records within this Set, and the padding bytes, if 
           any. 
                  
   Record N - Field Value M 
           The remainder of the Data Set is a collection of Flow Data 
           Record(s), each containing a set of Field Types and values.  
           The Type and Length of the fields have been previously 
           defined in the Template Record referenced by the Set ID or 
           Template ID. 
            
   Padding  
           The Exporting Process MAY insert some padding bytes, so that 
           the subsequent Set starts at an aligned boundary.  Padding 
           MUST be composed of zero (0) bytes.  The padding length MUST 
           be shorter than any allowable Flow Data Record in this Data 
           Set.  It is important to note that the Length field includes 
           the padding bits. 
 
 
  Claise, et. al            Standard Track                   [Page 26] 
                   IPFIX Protocol Specification            August 2004 bytes. 
    
   Interpretation of the Data Set format can be done only if the 
   Template Set corresponding to the Template ID is available at the 
   Collecting Process.    
    
 7.5      Options Template Set 
    
   The Options Template Record (and its corresponding Options Data 
   Record) is used to supply information about the Metering Process 
   configuration or Metering Process specific data, rather than 
   supplying information about IP Flows. 
    
   For example, the Options Template Set can report the sample rate of 
   a specific interface, if sampling is supported, along with the 
   sampling method used.   

 7.5.1   Scope 
    
   The Options Template Set gives the Exporter the ability to provide 
   additional information to the Collector which would not be possible 
   with only Flow Records. The scope, which is only available in the 
   Options Template Set, gives the context of the reported Information 
   Elements.  One Options Template Set example is the "Metering Process 
   statistics", which reports the statistics for the Observation 
   Domain, which is defined as the scope.  Another example is the 
 
 
  Claise, et. al            Standard Track                   [Page 30] 
                   IPFIX Protocol Specification           October 2004 
 
 
   "Template configuration", which reports the configuration sampling 
   parameter(s) for the template, which is defined as the scope.   
    
   Multiple scope fields MAY be present in the Options Template Set, in 
   which, the composite scope is the combination of the scopes. For 
   example, if the two scopes are defined as "cache" and "template", 
   the combined scope is this template in this cache.  The order of the 
   scope, as defined in the Options Template Set, is in this case 
   irrelevant. However, if the order of the scopes fields in the Option 
   Template Set is relevant, the order of the scope fields MUST be 
   used.  For example, if the first scope defines the filtering 
   function, while the second scope defines the sampling function, the 
   order of the scope is important. Applying first the sampling 
   function, followed by the filtering function, would lead to 
   potential different Flow Records than applying first the filtering 
   function, followed by the filtering function.  In this case, the 

 
 
  Claise, et. al            Standard Track                   [Page 27] 
                   IPFIX Protocol Specification            August 2004 
   Collector deduces the function order by looking at the order of the 
   scope in the Options Template Set.  
    
   Finally, note that the scope length MAY NOT be null null. 

 7.5.2   Options Template Set Format 
    
   An Options Template MAY exclusively contain IETF defined Field 
   Types.  An Options Template MAY contain Vendor Specified Information 
   Elements from multiple vendors.  An Options Template MAY contain 
   IETF defined Field Types and Vendor Specified Information Elements. 
    
   The format of the Options Template Set is shown in Figure J.   
    
       0                   1                   2                   3  
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |          Set ID = 3           |          Length               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |         Template ID           |      Option Scope Length         Field Count           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |        Option Length      Scope Field Count        |      Scope 1 Field Type       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Scope 1 Field Length      |      Scope 2 Field Type       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Scope 2 Field Length      |             ...               |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
 
 
  Claise, et. al            Standard Track                   [Page 31] 
                   IPFIX Protocol Specification           October 2004 
 
 
      |            ...                |      Scope N Field Type       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Scope N Field Length      |         Scope N ...           |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    ... Enterprise Number      |      Option 1 Field Type      |       
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    Option 1 Field Length      |           Option 1 ...        |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |    ... Enterprise Number      |              ...              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |             ...               |       Option M Field Type     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Option M Field Length     |         Padding (opt)         |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    

 
 
  Claise, et. al            Standard Track                   [Page 28] 
                   IPFIX Protocol Specification            August 2004  
    
      Figure J: Option Template Set Format 
    
   The Options Template Set Field Definitions are as follows: 
    
   Set ID = 3 
           A Set ID value of 3 is reserved for the Options Template. 
    
   Length 
           Total length of this Set, including the padding bytes, if 
           any.  Each Options Template Set MAY contain multiple Options 
           Template Records.  Thus, the Length value MUST be used to 
           determine the position of the next Set record, which could 
           be either a Template Set or Data Set.                 
           Length is the sum total of lengths of Set ID, the Length 
           itself, and all Options Template Records within this Set 
           Template ID. 
    
   Template ID 
           Template ID of this Options Template.  This value is greater 
           than 255. 
     
   Option Scope Length 
           The length in bytes 
     
   Field Count  
           Number of any Scope all fields definition contained in this Option Template Record, 
           including the Options Scope Fields.  Because a Option Template Record (The use Set 
           usually contains multiple Template Records, this field 
           allows the Collecting Process to determine the end of "Scope" is 
           described below). the 
           current Option Length 
           The length (in bytes) Template Record and the start of any options field definitions 
           contained the next.  
 
 
 
  Claise, et. al            Standard Track                   [Page 32] 
                   IPFIX Protocol Specification           October 2004 
 
 
   Scope Field Count  
           Number of scope fields in this Options Option Template Record.  
    
   Scope Field Type 
           A numeric value that represents the type of the field.  
           Refer to [IPFIX-INFO]. 
            
   Scope Field Length 
           The length (in bytes) of the Scope field, as it would appear 
           in an Options Data Record. 
            
   Scope N Enterprise Number  
           IANA enterprise number [PEN] of the authority defining  
           Scope N Field Type. This is 4 bytes long. 
    
   Option Field Type 
 
 
  Claise, et. al            Standard Track                   [Page 29] 
                   IPFIX Protocol Specification            August 2004 
           A numeric value that represents the type of field.  Refer to 
           [IPFIX-INFO]. 
            
   Option Field Length 
           The length of the corresponding Option Field Type, in bytes.  
           Refer to [IPFIX-INFO]. 
            
    Option M Enterprise Number  
           IANA enterprise number [PEN] of the authority defining the 
           Option M Field Type. This is 4 bytes long. 
            
   Padding  
           The Exporting Process MAY insert some padding bytes, so that 
           the subsequent Set starts at an aligned boundary.  Padding 
           MUST be composed of zero (0) bytes.  The padding length MUST 
           be shorter than any allowable Options Template Record in 
           this Options Template Set.  It is important to note that the 
           Length field includes the padding bits. bytes. 
    
   The Set ID value of 0 and 1 are not used for historical reasons 
   [NETFLOW9]. 

 7.5.3   Options Data Record Format 
    
   The Options Data Records are sent in Data Sets. 


 
 
  Claise, et. al            Standard Track                   [Page 33] 
                   IPFIX Protocol Specification           October 2004 
 
 
    
   The format of the Data Set, containing Options Data Records, is 
   shown in Figure K.   
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      Set ID = Template ID     |          Length               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 1 - Scope 1 Value    |   Record 1 - Scope 2 Value    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              ...              |Record 1 - Option Field 1 Value| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |Record 1 - Option Field 2 Value|             ...               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 2 - Scope 1 Value    |   Record 2 - Scope 2 Value    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              ...              |Record 2 - Option Field 1 Value| 
 
 
  Claise, et. al            Standard Track                   [Page 30] 
                   IPFIX Protocol Specification            August 2004 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |Record 2 - Option Field 2 Value|             ...               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Record 3 - Scope 1 Value    |   Record 3 - Scope 2 Value    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              ...              |Record 3 - Option Field 1 Value| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |Record 3 - Option Field 2 Value|             ...               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |              ...              |         Padding (opt)         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure K: Data Set format, containing Options Data Records  
    
   Options Data Records of the Data Set Field Descriptions  
    
   Set ID = Template ID 
           A Set ID precedes each group of Options Data Records within 
           a Data Set.  The Set ID maps to a previously generated 
           Template ID corresponding to this Options Template Record.  
           The Collecting Process MUST use the Set ID to map the 
           appropriate type and length to any field values that follow. 
            
   Length 
           The length of this Set.    
 
 
  Claise, et. al            Standard Track                   [Page 34] 
                   IPFIX Protocol Specification           October 2004 
 
 
           Length is the sum of the lengths of the Set ID, Length 
           itself, all the Options Data Records within this Set, and 
           the padding bytes, if any. 
            
   Record N - Option Field M Value 
           The remainder of the Data Set is a collection of Flow 
           Records, each containing a set of Scope and Field Values.  
           The type and length of the fields were previously defined in 
           the Options Template Record referenced by the Set ID or 
           Template ID. 
            
   Padding  
           The Exporting Process MAY insert some padding bytes, so that 
           the subsequent Set starts at an aligned boundary.  Padding 
           MUST be composed of zero (0) bytes.  The padding length MUST 
           be shorter than any allowable Options Data Record in this 
           Data Set.  It is important to note that the Length field 
           includes the padding bits. 
 
 
  Claise, et. al            Standard Track                   [Page 31] 
                   IPFIX Protocol Specification            August 2004 bytes. 
            
   The Data Set format can be interpreted only if the Options Template 
   Set corresponding to the Template ID is available at Template ID is available at the Collecting 
   Process. 
    
 8.     Specific Reporting Requirements 
 
   Some specific Options Templates and Options Templates Records are 
   necessary to provide extra information about the Flow Records and 
   about the Metering Process.    
        
   The ipfixOption Field [IPFIX-INFO], always included in these 
   specific Options Templates, defines the type of information sent in 
   the Option Template / Option Template Record pair.  For example, if 
   the ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option 
   Template will specify information about the Metering Process 
   statistics.  
    
   The Option Template and Option Template Records defined in these 
   sub-sections are not mandatory to implement as they impose some 
   constraints about the Metering Process implementation: this document 
   specifies the protocol to export the records, not the Metering 
   Process implementation.  However, if the specific Option Templates 
   are implemented, they should ideally be implemented as specified in 
   these sub-sections.  In any case, if the ipfixOption Information 

 
 
  Claise, et. al            Standard Track                   [Page 35] 
                   IPFIX Protocol Specification           October 2004 
 
 
   Element is present, it MUST always be the first Information Element 
   in the Option Template so that the Collector can quickly determine 
   which specific Option Template Record is received. 
         
   The minimum set of Information Elements is always specified in these 
   Specific IPFIX Options Templates.  Nevertheless, extra Information 
   Elements may be used in these specific Options Templates.     
    
 8.1      The Metering Process Statistics Option Template 
  
   The Metering Process Statistics Option Template specifies the 
   Metering Process Statistics. It contains the following Information 
   Elements [IPFIX-INFO]:  
        ipfixOption             The value is METERING_STATS  
        exportedOctetCount      The number of all octets reported  
                                by the Exporting Process to the 
                                Collecting Process. 
    
 8.     Specific Reporting Requirements 
    
   Some specific Options Templates and Options Templates Records are 
   necessary 
        exportedPacketCount     The number of all packets reported  
                                by the exporting process to provide extra information about the Flow Records and 
   about 
                                Collecting Process. 
        exportedFlowCount       The number of all flows records  
                                reported by the Metering Exporting Process 
                                to the Collecting Process.  
        time                    The ipfixOption Field [IPFIX-INFO], always included in these 
   specific Options Templates, defines time at which the type of information sent in record was 
   generated  
     
   The Exporting Process should export the Metering Process Statistics 
   Option Template / Record on a regular basis or based on some export 
   policy.  This periodicity or export policy should be configurable. 
   The Metering Process Statistics Option Template Record pair.  For example, if could be extended 
   with other Information Elements. 
    
   The Scope Field specified in the ipfixOption [IPFIX-INFO] value Metering Process Statistics Option 
   Template Record is METER_STATS, then the Source ID. 
    
 8.2      The Metering Process Reliability Statistics Option Template will specify 
  
   The Metering Process Reliability Option Template specifies 
   information about lack of reliability in the Metering Process 
   statistics.  The process.  It 
   contains the following Information Elements [IPFIX-INFO]: 
    
        ipfixOption [IPFIX-INFO] MUST always be             The value is METERING_RELIABILITY_STATS 
        droppedFUPacketCount    Packets dropped by Metering Process 
 
 
  Claise, et. al            Standard Track                   [Page 36] 
                   IPFIX Protocol Specification           October 2004 
 
 
        droppedFUOctetCount     Bytes dropped by Metering Process  
        timeFirstFUDropped      Time of the first 
   Information Element in packet dropped at the Option Template so that  
                                Specified scope ID 
        timeLastFUDropped       Time of the Collector can 
   quickly determine whether or not a specific Option Template is 
   described.  And if last packet dropped at the ipfixOption [IPFIX-INFO] is present,  
                                Specified scope ID 
        time                    The time at which 
   specific the record was 
   generated  
    
   The Exporting Process should export the Metering Process Reliability 
   Statistics Option Template type it defines. 
     
   The minimum set of Information Elements is always specified in these 
   Specific IPFIX Options Templates.  Nevertheless, extra Information 
   Elements MAY Record on a regular basis or based on 
   some export policy.  This periodicity or export policy should be used in these specific Options Templates.   
    
 8.1 
   configurable. The Metering Process Reliability Statistics Option 
   Template could be extended with other Information Elements. 
    
   The Scope Field specified in the Metering Process Reliability 
   Statistics Option Template defines Record is the Metering Source ID. 
    
 8.3      The Exporting Process Reliability Statistics with the export Option Template 
  
   The Exporting Process Reliability Option Template specifies 
   information about lack of reliability in the Exporting process.  It 
   contains the following Information Elements [IPFIX-INFO]: 
    
        ipfixOption             The value MUST be METER_STATS 
       observationDomain       Source ID 
       lostFlows               Flows is  
                                EXPORTING_RELIABILITY_STATS 
        droppedFlows            Number of flow records not exported due  
                                (due to resource resources starvation 
       lostFlowsPackets at  
                                Exporting Process or due to some 
                                flow records export policies) 
        droppedFAPacketCount    Packets in the lost Flows 
       lostFlowsBytes dropped flows 
        droppedFAByteCount      Bytes in the lost Flows  
       droppedPacketCount      Packets dropped by Metering Process  
                           at flows 
        timeFirstFADropped      Time of the first packet within the  
                                dropped flows 
        timeLastFADropped       Time of the last packet within the Observation Point 
   droppedByteCount        Bytes  
                                dropped flows 
        time                    The time at which the record was  
                                generated  
    
   The Exporting Process should export the Exporting Process 
   Reliability Statistics Option Template Record on a regular basis or 
   based on some export policy.  This periodicity or export policy 
   should be configurable. The Exporting Process Reliability Statistics 
   Option Template could be extended with other Information Elements. 
 
 
  Claise, et. al            Standard Track                   [Page 37] 
                   IPFIX Protocol Specification           October 2004 
 
 
    
   The Scope Field specified in the Exporter Reliability Statistics 
   Option Template Record is the Exporter ID. 
    
 8.4      The Flow Keys Option Template 
    
   The Flow Keys Option Template specifies the flow keys used by the 
   Metering Process for the Template ID definition. It contains the 
   following Information Elements [IPFIX-INFO]: 
    
        ipfixOption             The value is FLOW_KEY 
        keyList                 Bitmap with the positions of the flow  
                                keys in the template 
        time                    The time at which the  
                                Observation Domain 
        time;                   When this record was  
                                generated 
    
 
 
  Claise, et. al            Standard Track                   [Page 32] 
                   IPFIX Protocol Specification            August 2004  
    
   The minimum set of Information Element Scope Field specified in the Metering Process 
   Statistics Flow Keys Option Template is: ipfixOption, observationDomain, 
   lostFlows, time Record is 
   the Template ID with which the flow keys are associated. 
 
 9.     Export Packet "Export Time" Computation and Flow Record Time 
    
 9.1      Microsecond Precision 
    
   For a Data Set with Flow Records requiring microsecond precision, 
   the Export Packet "Export Time" field MUST be calculated so that 
   each Flow Records flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX-
   INFO] would contain a 32 bit signed microsecond offset from the 
   "Export Time" base timestamp.  Hereafter some pseudo code to 
   calculate the Export Time in one pass, which would return an 
   absolute duration of 35 minutes for all Flow Records contained in 
   the Data Set.  Flow Records MUST be exported in different Export 
   Packet if the absolute duration durations can not fit in those 35 minutes. 
    
   //  pseudo code for microsecond offset in IPFIX encoded Flow 
   Records. 
   // 
    
   struct flow{ 
      uint32  tv_sec; 
      uint32  tv_usec; 
      uint32  numbytes; 
      ...  // other Information Elements... 
   }; 
    
   struct flow flowtable [MAX_TABLE_SIZE]; 
   int lastflowindex = -1; 
    
   writeflows() { 

 
 
  Claise, et. al            Standard Track                   [Page 38] 
                   IPFIX Protocol Specification           October 2004 
 
 
      if (lastflowindex < 0) return; 
      // simply take the second field from the first available flow    
      // and make this the base time for this collection of flows.     
      uint32  base_sec = flowtable[0].tv_sec; 
      writeheaderToSocket(base_sec); // put 32-bit second value in   
                                        header 
      for (int i=0; i<=lastflowindex; i++){ 
         int32 offset = (flowtable[i].tv_sec - base_sec) * 1000000  
                        + flowtable[i].tv_usec; 


 
 
  Claise, et. al            Standard Track                   [Page 33] 
                   IPFIX Protocol Specification            August 2004 
         writeint32ToSocket(offset);  // put the 32-bit time offset  
                                         in the record. 
         // write other Information Elements... 
       } 
   } 
    
   A two pass approach calculation for the optimum (center) "Export 
   Time" base timestamp would allow an absolute duration of 71 minutes 
   for all Flow Records contained in the Data Set.  The two pass 
   approach MAY be used.  The "Export Time" base timestamp calculation 
   requires that at the Export Packet exporting time the Exporting 
   Process MUST run down the list of Flow Records in the Data Set 
   message and adjust the Flow start and Flow end timestamps. 
    
 9.2      Millisecond Precision 
    
   For a Data Set with Flow Records requiring a millisecond precision, 
   the same principles as in section 10.1 9.1 "Microsecond Precision" will 
   be used.   
    
   The only difference will be that the Flow start and the Flow end 
   SHOULD now be represented respectively by the flowStartMsec [IPFIX-
   INFO] and flowEndMsec [IPFIX-INFO].  As a consequence of the 
   millisecond precision, the absolute duration of all Flow Records is 
   now of about 49 days.  The Export Header "Export Time" base time 
   SHOULD be calculated with the algorithm described in the Section 
   10.1 9.1 
   "Microsecond Precision".  In order to reduce the load on the 
   Exporter, the Export Header "Export Time" MAY be the time in seconds 
   since 0000 UTC 1970 at which the Export Packet leaves the Exporter 
   and not the calculated optimum value anymore as described in section 
   10.1 
   9.1 "Microsecond Precision". 
    
   Alternatively, for a Data Set with Flow Records requiring a 
   millisecond precision, the microsecond mechanism as described in 
 
 
  Claise, et. al            Standard Track                   [Page 39] 
                   IPFIX Protocol Specification           October 2004 
 
 
   section 10.1 9.1 MAY be used as such.  The Flow Record MAY use the 
   flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX-INFO] rounded at a 
   millisecond precision.   
    
 9.3      Nanosecond Precision 
    

 
 
  Claise, et. al            Standard Track                   [Page 34] 
                   IPFIX Protocol Specification            August 2004 
    
   For a Data Set with Flow Records requiring a nanosecond precision, 
   all Flow Records will contain Flow start flowStartNsec [IPFIX-INFO] 
   and flowEndNsec [IPFIX-INFO].  The Export Header "Export Time" will 
   be of no use on the Collector side in this case as the flowStartNsec 
   [IPFIX-INFO] and flowEndNsec [IPFIX-INFO] both have a nanosecond 
   precision already.  Both flowStartNsec [IPFIX-INFO] and flowEndNsec 
   [IPFIX-INFO] use the NTP time format which is represented as a 64-
   bit value which contains a 32-bit specification of seconds since 
   1900 and a 32-bit "fraction" field.   Refer to the NTP 
   specification, RFC1305, section 3.1 "Data Formats". 
    
 9.4      Multiple Precisions 
     
   When Flow Records requiring different precisions must be exported, 
   the Exporting Process SHOULD split the Flow Records in different 
   Data Set according to the precision:  millisecond, microsecond or 
   nanosecond. 
    
 10.      Linkage with the Information Model 
 
   The information model associates each IPFIX Information Element with 
   a well defined type, such as hexBinary, long, unsignedInt, etc. 
   This document defines how fields of a given type are encoded. 
    
 10.1       Boolean 
 
   A boolean field shall be encoded in a single byte with the value of 
   0 indicating false and any other value indicating true. 
    
 10.2       Byte 
 
   A byte value shall be encoded as a single byte representing a value 
   between -128 and 127.  The value is represented in two's complement 
   notation.   
    
 10.3       UnsignedByte 
 
   An unsigned byte value shall be encoded as a single byte 
   representing a value between 0 and 255. 
    
 10.4       Short 
 


 
 
  Claise, et. al            Standard Track                   [Page 35] 
                   IPFIX Protocol Specification            August 2004 
 
 
   A short is a 16-bit datum that encodes an integer the NTP 
   specification, RFC1305, section 3.1 "Data Formats". 
    
 9.4      Multiple Precisions 
     
   When Flow Records requiring different precisions must be exported, 
   the Exporting Process SHOULD split the Flow Records in different 
   Data Set according to the range [-
   32768,32767]. precision: millisecond, microsecond or 
   nanosecond. 
    
 10.      Linkage with the Information Model 
 
   The short is represented Information Elements [IPFIX-INFO] MUST be sent in canonical 
   format in two's complement 
   notation. 
    
 10.5 network byte order. 
    
 10.1 
      Reduced Size Encoding of Integer Types 
 
   Information Elements containing integer types in the information 
   model MAY be encoded using fewer bytes than those implied by their 
   type in the information model definition [IPFIX-INFO], based on the 
   assumption that the smaller type is sufficient to carry any value 
   the Exporter may need to deliver.  This reduces the network 
   bandwidth requirement between the Exporter and the Collector.  Note 
   that the Information Elements definition [IPFIX-INFO] will always 
   define the maximum encoding size. 
    
   For instance the information model [IPFIX-INFO] defines byteCount as 
   an unsignedLong type, which would require 64-bits.  However if the 
   Exporter will never locally encounter the need to send a value 
   larger than 4294967295, it may chose to send the value instead as an 
 
 
  Claise, et. al            Standard Track                   [Page 40] 
                   IPFIX Protocol Specification           October 2004 
 
 
   unsignedInt.  For example, a core router would require an 
   unsignedLong byteCount while an unsignedInt might be sufficient for 
   an access router. 
    
   This behavior is indicated by the Exporter by specifying a type size 
   smaller than that associated with the assigned type of the field.  
   In the example above the Exporter would place a length of 4 versus 8 
   in the template. 
    
   If reduced sizing is used, it MUST be applied only to following 
   integer types: unsignedLong, long, unsignedInt, int, unsignedShort, 
   short.  In each case the downcasting MUST be to a smaller integer 
   type.  The same signed versus unsigned properties MUST be preserved. 
   Specifically unsignedLong may be downcast to unsignedInt, 
   unsignedShort or unsignedByte.  A long may be downcast to an int, a 
   short or a byte.  The other downcasts follow the same pattern. 
    
 11.      Variable Length Information Element 
 
   The IPFIX template mechanism is optimized for fixed length 
   Information Elements [IPFIX-INFO].  Where an Information Element has 
   a variable length the following mechanism MUST used to carry the 
   length information, for both the IETF and proprietary Information 
   Elements. 

 
 
  Claise, et. al            Standard Track                   [Page 36] 
                   IPFIX Protocol Specification            August 2004 
    
   In the Template Set the length is recorded as 65535.  This reserved 
   length value notifies the Collecting Process that length of the 
   Information Element will be carried in the Information Element 
   content itself. 
    
   In most cases the length of the Information Element will be less 
   than 256 bytes.  The following length encoding mechanism optimizes 
   the overhead of carrying the Information Element length in this 
   majority case. 
    
   If the length of the Information Element is less than 255 bytes, the 
   length is carried in the first byte of the Information Element, as 
   shown on Figure L. 
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|          Information element                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
  Claise, et. al            Standard Track                   [Page 41] 
                   IPFIX Protocol Specification           October 2004 
 
 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
     Figure L: Variable Length Information Element (length < 255 bytes) 
    
   If the length of the Information Element is greater or equal than 
   256 
   255 bytes, the first byte of the Information Element is 255, and the 
   length is carried in the second and third bytes of the Information 
   Element, as shown in Figure M. 
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |        Length (256 (255 to 65535)       |   IE     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure M: Variable Length Information Element  
               (length 256 255 to 65535) bytes 
    
 12.      Template Management 
 
   Flow Data Records that correspond to a Template Record MAY appear in 
   the same and/or subsequent IPFIX Messages.  The Template Record is 
 
 
  Claise, et. al            Standard Track                   [Page 37] 
                   IPFIX Protocol Specification            August 2004 
   not necessarily carried in every IPFIX Message.  As such, the 
   Collecting Process MUST store the Template Record to interpret the 
   corresponding Flow Data Records that are received in subsequent data 
   messages. 
    
   A Collecting Process that receives IPFIX Messages from several 
   Observation Domains from the same Exporter MUST be aware that the 
   uniqueness of the Template ID is not guaranteed across Observation 
   Domains. 
    
   The Template IDs must remain constant for the life of the Metering 
   Process and the Exporting Process.  If the Exporting Process or the 
   Metering Process restarts for any reason, all information about 
   Templates will be lost and new Template IDs will be created.  
   Template IDs are thus not guaranteed to be consistent across an 
   Exporting Process or Metering Process restart. 
            
   If the measurement parameters change, a new Template ID SHOULD be 
   initiated and used. Examples of the measurement changes are: a new 
 
 
  Claise, et. al            Standard Track                   [Page 42] 
                   IPFIX Protocol Specification           October 2004 
 
 
   sampling rate, a new flow expiration process, a new filtering 
   definitions, etc... A newly created Template Record is assigned an 
   unused Template ID by the Exporter.  If the template configuration 
   is changed, the current Template ID is abandoned and SHOULD NOT be 
   reused.  If a Collecting Process should receive a new definition for 
   an already existing Template ID, it MUST discard the previous 
   template definition and use the new one. 
    
   If a configured Template Record on the Exporting Process is deleted, 
   and re-configured with exactly the same parameters, the same 
   Template ID COULD be reused. 
    
   The Exporting Process sends the Template Set and Options Template 
   Set under the following conditions: 
    
    1. After a Metering Process restarts, the Exporting Process MUST 
       NOT send any Data Set without sending the corresponding Template 
       Set and the required Options Template Set in a previous message 
       or including it in the same IPFIX Message.  It MAY transmit the 
       Template Set and Options Template Set, without any Data Sets, in 
       advance to help ensure that the Collector will have the correct 
       Template Record before receiving the first Flow or Options Data 
       Record. 
     
 
 
  Claise, et. al            Standard Track                   [Page 38] 
                   IPFIX Protocol Specification            August 2004 
     
    2. In the event of configuration changes, the Exporting Process 
       SHOULD send the new template definitions at an accelerated rate.  
       In such a case, it MAY transmit the changed Template Record(s) 
       and Options Template Record(s), without any data, in advance to 
       help ensure that the Collector will have the correct template 
       information before receiving the first data. 
     
    3. If the Template Records and Options Template Records are sent 
       using a transport protocol that is not fully reliable they MUST 
       be refreshed on a regular basis by the Exporting Process which 
       MUST re-send all the Template Records and Options Template 
       Records to the Collecting Process. 
     
 13.      The Collecting Process's Side 
    
   The Collecting Process receives Template Records from the Exporting 
   Process, normally before receiving Flow Data Records (or Options 
   Data Records).  The Flow Data Records (or Options Data Records) can 
   then be decoded and stored locally on the devices.  If the Template 
 
 
  Claise, et. al            Standard Track                   [Page 43] 
                   IPFIX Protocol Specification           October 2004 
 
 
   Records have not been received at the time Flow Data Records (or 
   Options Data Records) are received, the Collecting Process SHOULD 
   store the Flow Data Records (or Options Data Records) and decode 
   them after the Template Records are received.  A Collecting Process 
   device MUST NOT assume that the Data Set and the associated Template 
   Set (or Options Template Set) are exported in the same IPFIX 
   Message. 
    
   The Collecting Process MUST NOT assume that one and only one 
   Template Set is present in an IPFIX Message.   
    
   The life of a template at the Collecting Process is limited to a 
   fixed refresh timeout.  Templates not refreshed from the Exporting 
   Process within the timeout are expired at the Collecting Process.  
   The Collecting Process MUST NOT attempt to decode the Flow or 
   Options Data Records with an expired Template.  At any given time 
   the Collecting Process SHOULD maintain the following for all the 
   current Template Records and Options Template Records: <Exporting 
   Process, Observation Domain, Template ID, Template Definition, Last 
   Received> 
   Note that the Observation Domain is identified by the Source ID 
   field from the IPFIX Message. 
    

 
 
  Claise, et. al            Standard Track                   [Page 39] 
                   IPFIX Protocol Specification            August 2004 
    
   Template IDs are unique per Exporting Process and per Observation 
   Domain. 
    
   If the Collecting Process receives a new Template Record (for 
   example, in the case of an Exporter restart) it MUST immediately 
   override the existing Template Record. 
    
   The Collecting Process MUST note the Field ID of any Information 
   Element that it does not understand and MAY discard the Information 
   Element from the Flow Record.  The Collecting Process MUST note the 
   size and position of any Vendor Specified Information Element that 
   it does not understand and discard the Information Element from the 
   Flow Record. 
    
   The Collector MUST accept padding in the Data Set and Options 
   Template Set, which means for the Flow Data Records, the Options 
   Data Records and the Template Records. 
   Refer to the terminology summary table in Section 3.1. 
    

 
 
  Claise, et. al            Standard Track                   [Page 44] 
                   IPFIX Protocol Specification           October 2004 
 
 
   The IPFIX protocol has a sequence number field in the Export Header 
   which increases with each IPFIX Message.  A Collector may detect out 
   of sequence, dropped, or duplicate messages by tracking the sequence 
   number.  A collector SHOULD provide a logging mechanism for tracking 
   out of sequence messages.  Such out of sequence messages may be due 
   to congestion on the network link between the Exporter and 
   Collector, Collector resource exhaustion where it can not process 
   the IPFIX Messages at their arrival rate, Exporter resource 
   exhaustion where it can not transmit messages at their creation 
   rate, out of order packet reception, duplicate packet reception, an 
   Exporting Process reset, or an attacker injecting false messages. 
    
 14.      Security Considerations 
 
   Because IPFIX can be used to collect billing information and network 
   forensics, confusing or blinding IPFIX must be seen as a prime  
   objective during a sophisticated network attack.   
    
   If an attacker is in a position to inject false messages into an 
   IPFIX Message stream this will allow them to send forged Flow Data 
   Records, Options Data Records, or Templates.  Forged Templates may 
   impair the Collectors ability to process any further Flow Records.  
   Forged Flow Records would have a direct effect on the application 
   using the Flows, for example a billing system may generate incorrect 
 
 
  Claise, et. al            Standard Track                   [Page 40] 
                   IPFIX Protocol Specification            August 2004 
   billing information.  Forged options may be able to alter the 
   meaning of Flow Records, for example if the sample rate is changed.   
    
   The IPFIX Messages themselves may contain information of value to an 
   attacker, and thus care must be taken to confine their visibility to 
   authorized users.   
    
   IPFIX Messages can be secured using IPsec.  Alternatively if IPFIX 
   runs on top of SCTP or TCP, TLS [TLS] can be used. 
   runs on top of SCTP or TCP, TLS [TLS] can be used. 
    
   When an Information Element containing end-user payload information 
   is exported, it SHOULD be transmitted to the Collecting Process 
   using a means that secures its contents against eavesdropping. 
   Suitable mechanisms include the use of either a direct point-to-
   point connection or the use of an encryption mechanism. It is the 
   responsibility of the Collecting Process to provide a satisfactory 
   degree of securtity for this collected data, including, if 
   necessary, anonymization of any reported data. 
    
 
 
  Claise, et. al            Standard Track                   [Page 45] 
                   IPFIX Protocol Specification           October 2004 
 
 
 14.1       IPsec Usage 
    
   To secure messages between the Exporter and the Collector an IPFIX 
   implementation MAY use IPsec.  To ensure interworking between 
   Exporters and Collectors from different vendors, the following IPsec 
   profile MUST be supported.  This profile is derived from [USEIPSEC]. 

 14.1.1  Selectors 
    
   IPFIX runs between manually configured pairs of hosts on the 
   following transport ports (TBD).  The appropriate selector would be 
   Exporter-Collector pairs and port number.   
    
   Note that, if the Exporter is a router, a non-interface ("loopback") 
   address should be used.    

 14.1.2  Mode 
    
   IPsec MUST be run in transport mode.  The AH and ESP MUST be 
   supported by an IPFIX implementation of IPsec.   
    
   The Authentication Header (AH) [RFC2402] MUST be used if 
   authentication is required.  The Security Protocol (ESP) [RFC2406] 
   must be used if there is a threat to the IPFIX Message content, or 
   if that content is confidential.   
    
   Normally in situations where the ESP was required the AH would also 
   be required.  If ESP only is used, the sender's IP address MUST be 
   checked against the IP address asserted in the key management 
   exchange. 




 
 
  Claise, et. al            Standard Track                   [Page 41] 
                   IPFIX Protocol Specification            August 2004 

 14.1.3  Key Management 
    
   In many networks, manual key management will be sufficient, and this 
   reduces the complexity of the Exporter, albeit at a cost of greater 
   configuration complexity.  Manual key management MUST be supported.  
   If a replay attack is considered likely, an automated key management 
   such as IKE [IKE] key management system SHOULD be used.   

 14.1.4  Security Policy 
 
   Connections should be accepted only from the designated peer. 

 
 
  Claise, et. al            Standard Track                   [Page 46] 
                   IPFIX Protocol Specification           October 2004 
 
 
 14.1.5  Authentication 
 
   Given the number of IPFIX capable Exporters that are likely to be 
   deployed by large ISPs, there will be circumstances where shared key 
   mechanisms are not adequate.  Where an automated key management 
   system is used, certificate-based IKE SHOULD be supported.    

 14.1.6  Availability 
    
   It is accepted that IPsec will not be universally available in IPFIX 
   Exporters, and that where it is available, there may be issues of 
   throughput, which may itself raise security issues.  In such 
   circumstances the other security measures described in this document 
   provide some threat mitigation.   
    
 14.2       TLS Usage 
     
   The IPFIX Exporter initiating a connection acts as a TLS client 
   according to [TLS], and an IPFIX Collector that accepts a connection 
   acts as a TLS server.  If mutual authentication is required the 
   IPFIX Device acting as TLS server MUST request a certificate from 
   the IPFIX Device acting as TLS client, and the IPFIX Device acting 
   as TLS client MUST be prepared to supply a certificate on request. 
    
 14.3       Protection against DoS attacks 
    
   An attacker may directly mount a DoS attack by generating large 
   amounts of traffic.   If TCP is used for transport, then the Flow to 
   the Collector would back off due to congestion and eventually stall, 
   blinding the IPFIX system.  An attack could then proceed without 
   further observation.  SCTP-PR will have a different pathology under 
 
 
  Claise, et. al            Standard Track                   [Page 42] 
                   IPFIX Protocol Specification            August 2004 
   such an attack.  Stale data at the head of the queue will get 
   flushed giving some visibility of the attack.  In case of UDP, IPFIX 
   would reduce to some sort of sampling, meaning that some forensics 
   may be left.   
    
   To avoid blinding of the IPFIX system some mechanism for service 
   differentiation can be used to prioritize IPFIX traffic over user 
   traffic.  An alternative is to use a dedicated network for the 
   transport of IPFIX Messages.  By sending the IPFIX Messages over a 
   dedicated network, IPFIX Message loss induced by user traffic 
   congestion is minimized.  However an attacker may trigger the 
   generation of excessive IPFIX Messages, and to avoid information 
 
 
  Claise, et. al            Standard Track                   [Page 47] 
                   IPFIX Protocol Specification           October 2004 
 
 
   loss during such an attack the IPFIX network must be adequately 
   sized. 
    
 14.4       When IPsec or TLS is not an option 
    
   The use of IPsec or TLS might not be an option because of 
   performance issues. 
    
   Without IPsec or TLS an IPFIX entity has no means to authenticate an 
   IPFIX entity other than the Source IP address.  Useful protection is 
   gained by allocating Exporter and Collector IP addresses from ranges 
   that are excluded from use by user traffic and preventing spoofing 
   attacks by proper ingress filtering.  Where large numbers of 
   Exporters, proxies and Collectors are used in a network, it may be 
   tempting for the administrator to not impose source IP address 
   restrictions but this leaves a proxy or Collector open to the 
   reception of invalid information.  Using an open proxy or Collector 
   is therefore discouraged.   
    
   If IP address spoofing can not be prevented some level of protection 
   against an insertion attack is required.  With a modern 
   implementation of TCP with good ISN randomization [XXX-REFERENCE] or 
   SCTP insertion such attacks are difficult without the ability to 
   snoop the packet Flow [XXX-SCTP-BLIND-SPOOFING-REFERENCE].  UDP is 
   vulnerable to insertion attacks, however, randomization of the IPFIX 
   sequence number might mitigate this problem.  In all these cases, 
   the sequence number space is relatively small giving only limited 
   protection.  Therefore a 64 bit cookie [L2TPv3] SHOULD be included 
   as an element within all messages.   
    

 
 
  Claise, et. al            Standard Track                   [Page 43] 
                   IPFIX Protocol Specification            August 2004   
    
   The use of a dedicated network prevents IPFIX Messages from being 
   inspected by an attacker. 
    
 14.5       Logging an IPFIX Attack 
 
   A Collector may detect problems by tracking the IPFIX sequence 
   number and therefore SHOULD provide a logging mechanism for tracking 
   out of sequence messages.  Such out of sequence messages may not 
   only be caused by network congestion or Exporter/Collector resource 
   exhaustion but also by an attacker injecting false messages.   
    
   Note that an attacker may be able to exploit the behavior of the 
   Collector when it receives an out of sequence message.  For example 

 
 
  Claise, et. al            Standard Track                   [Page 48] 
                   IPFIX Protocol Specification           October 2004 
 
 
   a Collector that simply reset the expected sequence number upon 
   receipt of a later message would easily be temporarily blinded by 
   deliberately injecting messages with a much larger sequence number.   
    
   [EDITOR NOTE: the security section may need be adapted to the 
   revised transport section]   
    
 15.      IANA Considerations 
    
   The IPFIX Protocol, as set out in this document, has two sets of 
   assigned numbers.  Considerations for assigning them are discussed 
   in this section, using the example policies as set out in the 
   "Guidelines for IANA will need Considerations" document IANA-RFC [RFC2434]. 
    
 15.1       Numbers used in the Protocol 
    
   IPFIX Messages use two fields with assigned values.  These are the 
   IPFIX Version Number, indicating which version of the IPFIX Protocol 
   was used to export an IPFIX Message, and the IPFIX Set ID, 
   indicating the type for each set up of information within an IPFIX 
   Message. 
    
   Changes in either IPFIX Version Number or IPFIX Set ID assignments 
   require an IETF Consensus, i.e. they are to be made via RFCs 
   approved by the IESG. 
    
 15.2       Numbers used in the Information Model 
    
   Fields of the IPFIX protocol carry information about traffic 
   measurement. They are modeled as elements of the IPFIX information 
   model [IPFIX-INFO]. Each Information Element describes a field which 
   may appear in an IPFIX Message. Within an IPFIX Message the field 
   type is indicated by its Field Type. 
    
   New assignments for IPFIX Field Types will be administered by IANA, 
   on First Come First Serve basis [RFC 2434] , subject to Expert 
   Review [RFC 2434], i.e. review by one of a registry group of Field Types, scope experts 
   designated by an IETF Operations and option 
   codepoints. Management Area Director. The Set ID 
   group of experts must double check the Information Elements 
   definitions for completeness, accuracy and redundancy with already 
   defined Informations Elements. Those experts will not initially be administered by IANA.  
    
   In compiling drawn 
   from the registry Working Group Chairs and document editors of the IPFIX and 
   PSAMP Working Groups. The IANA assignments for IPFIX Field Types IANA must set asside a 

 
 
  Claise, et. al            Standard Track                   [Page 49] 
                   IPFIX Protocol Specification           October 2004 
 
 
   will range value for vendor use.  It is proposed that from 128 to 32767; the range 
   <0..32767> be administered by IANA for IETF defined IEs, and that values below 128 are reserved or 
   assigned already; the range <32768..65535> be values ranging from 32768 to 65535 are 
   allocated for private use by vendors.   
    
   Similarly the scope and option codepoints need to be split between 
   IANA administered and private ranges. 
    
 16.      Examples 
    
   Let's consider the example of an IPFIX Message composed of a  
   Template Set, a Data Set (which contains three Flow Data Records), 
   an Options Template Set and a Data Set (which contains 2 Options 
   Data Records).   
    
   IPFIX Message: 
    
   +--------+---------------------------------------------. . . 

 
 
  Claise, et. al            Standard Track                   [Page 44] 
                   IPFIX Protocol Specification            August 2004 
   |        | +--------------+ +-----------------------+  
   |Message | | Template     | | Data                  |  
   | Header | | Set          | | Set                   |   . . . 
   |        | | (1 Template) | | (3 Flow Data Records) |  
   |        | +--------------+ +-----------------------+  
   +--------+---------------------------------------------. . . 
 
        . . .+-------------------------------------------------+ 
             +------------------+ +--------------------------+ | 
             | Options          | | Data                     | | 
        . . .| Template Set     | | Set                      | | 
             | (1 Template)     | | (2 Options Data Records) | | 
             +------------------+ +--------------------------+ | 
        . . .--------------------------------------------------+ 
    
 16.1       Message Header Example 
    
   The Message Header is composed of: 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Version = 0x000a          |         Length = 152          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Export Time                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Sequence Number                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           Source ID                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

 
 
  Claise, et. al            Standard Track                   [Page 50] 
                   IPFIX Protocol Specification           October 2004 
 
 
    
 16.2       Template Set Example 
    
   We want to report the following Field Types: 
   - The source IP address (IPv4), so the length is 4 
   - The destination IP address (IPv4), so the length is 4 
   - The next-hop IP address (IPv4), so the length is 4 
   - The number of bytes of the Flow 
   - The number of packets of the Flow 
    
   Therefore, the Template Set will be composed of the following: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

 
 
  Claise, et. al            Standard Track                   [Page 45] 
                   IPFIX Protocol Specification            August 2004 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Set ID = 2            |      Length = 28 bytes        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Template ID 256         |       Field Count = 5         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     IP_SRC_ADDR = 0x0008      |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     IP_DST_ADDR = 0x000C      |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     IP_NEXT_HOP = 0x000F      |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       IN_PKTS = 0x0002        |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       IN_BYTES = 0x0001       |       Field Length = 4        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
 16.3       Data Set Example 
 
   In this example, we report the following three Flow Records: 
   Src IP addr. | Dst IP addr.  | Next Hop addr. | Packet | Bytes  
                |               |                | Number | Number 
   ------------------------------------------------------------------ 
   192.168.1.12 | 192.168.2.254 | 192.168.1.1    | 5009   | 5344385 
   192.168.1.27 | 192.168.2.23  | 192.168.1.2    | 748    | 388934 
   192.168.1.56 | 192.168.2.65  | 192.168.1.3    | 5      | 6534 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

 
 
  Claise, et. al            Standard Track                   [Page 51] 
                   IPFIX Protocol Specification           October 2004 
 
 
   |          Set ID = 256         |          Length = 64          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.1.12                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.2.254                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.1.1                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             5009                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            5344385                            |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.1.27                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
 
  Claise, et. al            Standard Track                   [Page 46] 
                   IPFIX Protocol Specification            August 2004 
   |                          192.168.2.23                         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.1.2                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              748                              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             388934                            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.1.56                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.2.65                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          192.168.1.3                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               5                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                              6534                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Note that padding is not necessary in this example. 
    
 16.4       Options Template Set Example 
    
   Per line card (the router being composed of two line cards), we want 
   to report the following Field Types: 
      - Total number of IPFIX Messages 
      - Total number of exported Flows  
   Each line card is characterized by an unique Observation Domain, 
   represented by the unique Source ID Information Elements [IPFIX-
 
 
  Claise, et. al            Standard Track                   [Page 52] 
                   IPFIX Protocol Specification           October 2004 
 
 
   INFO]. As a consequence, the Scope Field is the Source ID 
   Information Element. 
    
   The format of the Options Template Set is as follows: 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Set ID = 3            |          Length = 24          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Template ID 257         |    Option Scope Length        Field Count = 4 3        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Option Length     Scope Field Count = 8 1     |        Source ID = TBD        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Scope 1 Field Length = 4    |    TOTAL_EXP_PKTS_SENT = 41   | 
 
 
  Claise, et. al            Standard Track                   [Page 47] 
                   IPFIX Protocol Specification            August 2004 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Field Length = 4        |     TOTAL_FLOWS_EXP = 42      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Field Length = 4        |           Padding             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
 16.5       Data Set with Options Data Records Example 
    
   In this example, we report the following two Options Data Records: 
   Line Card ID             | IPFIX Message   | Exported Flow Records 
   ------------------------------------------------------------------ 
   Line Card 1 (SourceID=1) | 345             | 10201     
   Line Card 2 (SourceID=2) | 690             | 20402 
    
   0                   1                   2                   3  
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |      Set ID = 257             |         Length = 20           |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |                               1                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |             345               |            10201              | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |                               2                               |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |             690               |            20402              |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

 
 
  Claise, et. al            Standard Track                   [Page 53] 
                   IPFIX Protocol Specification           October 2004 
 
 
 17.     References 
    
 17.1       Normative References 
    
   [IPFIX-ARCH] Sadasivan, G, Brownlee, N. "Architecture Model for IP 
   Flow Information Export" draft-ietf-ipfix-arch-02.txt", October 2003 
    
   [IPFIX-INFO] Calato, P, Meyer, J, Quittek, J, "Information Model for 
   IP Flow Information Export" draft-ietf-ipfix-info-02, November 2003 
    
   [IPFIX-AS] Zseby, T, Boschi, E, Penno, R, Brownlee, N, Claise, B, 
   "IPFIX Applicability", draft-ietf-ipfix-as-02.txt, July 2004 
    
   [UDP]  Postel, J., "User Datagram Protocol" RFC 768, August 1980 
    

 
 
  Claise, et. al            Standard Track                   [Page 48] 
                   IPFIX Protocol Specification            August 2004 
    
   [TCP]  "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM 
   PROTOCOL SPECIFICATION" RFC 793, September 1981 
    
   [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 
   "RTP: A Transport Protocol for Real-Time Applications", Applications ", RFC 1889, 
   January 1996 
    
   [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 
   IANA Considerations Section in RFCs", RFC 2434, October 1998. 
    
   [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", Header ", RFC 
   2402, November 1998  
    
   [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 
   (ESP)", RFC 2406, November 1998  
    
   [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", 
   RFC 2960, October 2000 
    
   [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P.  
   "Stream Control Transmission Protocol (SCTP) Partial Reliability 
   Extension", RFC 3758, May 2004 
 
 17.2       Informative References 
 
   [IPFIX-REQ] Quittek, J, Zseby, T, Claise, B, Zander, S,  
   "Requirements for IP Flow Information Export" draft-ietf-ipfix-reqs-
   15.txt, June 2003 
    
   [IPFIX-AS] Zseby, T, Penno, R, Brownlee, N, Claise, B, "IPFIX 
   Applicability", draft-ietf-ipfix-as-01.txt, October 2003      

 
 
  Claise, et. al            Standard Track                   [Page 54] 
                   IPFIX Protocol Specification           October 2004 
 
 
              
   [IPFIX-EVAL] Leinen, S, "Evaluation of Candidate Protocols for IP 
   Flow Information Export (IPFIX)", draft-leinen-ipfix-eval-contrib-
   02.txt, January 2003 
    
   [NETFLOW9] Claise, B, et al "Cisco Systems NetFlow Services Export 
   Version 9", draft-claise-netflow-9-07.txt, December 2003 
    
   [PEN] IANA Private Enterprise Numbers registry 
         http://www.iana.org/assignments/enterprise-numbers  
    
   [USEIPSEC] S. Bellovin, Guidelines for Mandating the Use of IPsec,  
              draft-bellovin-useipsec-02.txt, October 2003, work  
              in progress.  

 
 
  Claise, et. al            Standard Track                   [Page 49] 
                   IPFIX Protocol Specification            August 2004  
    
   [IKE]      Harkins, D. and D. Carrel, "The Internet Key Exchange  
              (IKE)", RFC 2409, November 1998. 
    
   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version  
              1.0", RFC 2246, January 1999. 
    
   [L2TPv3]   J. Lau et al. Layer Two Tunneling Protocol (Version 3)  
              draft-ietf-l2tpext-l2tp-base-11.txt, October 2003, work  
              in progress.  
    
   [XXX-REFERENCE]  
    
   [XXX-SCTP-BLIND-SPOOFING-REFERENCE] 
 
 18.      Acknowledgments 
    
   We would like to thank the following persons: Juergen Quittek for 
   the coordination job; Nevil Brownlee and Dave Plonka for the 
   thorough reviews; Randall Stewart and Peter Lei for their SCTP 
   expertise;  Martin Djernaes for the first essay on the SCTP section; 
   Simon Leinen for the first essay on the TCP section Sebastian 
   Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, and 
   many more, for the technical feedback. 
    
 Authors Addresses 
 
   Benoit Claise 
   Cisco Systems 

 
 
  Claise, et. al            Standard Track                   [Page 55] 
                   IPFIX Protocol Specification           October 2004 
 
 
   De Kleetlaan 6a b1 
   1831 Diegem 
   Belgium 
   Phone: +32 2 704 5622 
   E-mail: bclaise@cisco.com 
 
   Stewart Bryant 
   Cisco Systems, Inc. 
   250, Longwater, 
   Green Park, 
   Reading, RG2 6GB, 
   United Kingdom 
   Phone: +44 (0)20 8824-8828             
   Email: stbryant@cisco.com 
    

 
 
  Claise, et. al            Standard Track                   [Page 50] 
                   IPFIX Protocol Specification            August 2004 
    
   Ganesh Sadasivan 
   Cisco Systems, Inc. 
   170 W. Tasman Dr. 
   San Jose, CA 95134 
   USA 
   Phone: +1 (408) 527-0251 
   Email: gsadasiv@cisco.com 
    
   Mark Fullmer 
   OARnet 
   2455 North Star Rd. 
   Columbus, Ohio 43221 
   Phone: +1 (614) 728-8100 
   Email: maf@eng.oar.net 
    
   Reinaldo Penno 
   Nortel Networks 
   2305 Mission College Blvd 
   Santa Clara, CA 95054 
   Phone: +1 408.565.3023 
   Email: rpenno@nortelnetworks.com 
    
   Paul Calato  
   Riverstone Networks, Inc.  
   5200 Great America Parkway  
   Santa Clara, CA 95054  USA  
   Phone:  +1 (603) 557-6913  
   Email: calato@riverstonenet.com 
    
Intellectual Property Statement 
 
The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has made 
any independent effort to identify any such rights.  Information on the 
procedures with respect to rights in RFC documents can be found in BCP 
78 and BCP 79. 
 
Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
 
 
  Claise, et. al            Standard Track                   [Page 51] 56] 
                   IPFIX Protocol Specification           October 2004 
 
 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this specification 
can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 
 
The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary rights 
that may cover technology that may be required to implement this 
standard.  Please address the information to the IETF at ietf-
ipr@ietf.org. 
 
The IETF has been notified of intellectual property rights claimed in 
regard to some or all of the specification contained in this document.  
For more information consult the online list of claimed rights. 
 
 
Disclaimer of Validity 
 
This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
 
Copyright Statement 
 
Copyright (C) The Internet Society (2004).  This document is subject to 
the rights, licenses and restrictions contained in BCP 78, and except 
as set forth therein, the authors retain all their rights. 













 
 
  Claise, et. al            Standard Track                   [Page 57]
--------------010303010200060504020103-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Oct 22 11:35:26 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14422 for ; Fri, 22 Oct 2004 11:35:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CL1Ks-0003w6-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Oct 2004 10:28:10 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CL1Kg-0003uj-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 22 Oct 2004 10:27:58 -0500 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4370.cisco.com [10.61.81.17]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9MFRu105438; Fri, 22 Oct 2004 17:27:57 +0200 (CEST) Message-ID: <417926FD.6040907@cisco.com> Date: Fri, 22 Oct 2004 17:27:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu CC: Stewart Bryant Subject: [ipfix-protocol] PROTO-25, PROTO-31, PROTO-32, PROTO-33: SCTP/Sequence ID + Template Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, The issues PROTO-25, PROTO-31, PROTO-32, PROTO-33 (look at the end of the email for a description) are linked to each others; they relate to the SCTP streams, the sequence ID, and the way the templates are sent. Stewart and I are closed to propose a solution for all those 4 issues combined. However, we wanted to double check a couple of things before, and post some new text on the mailing list for discussion ... instead of updating directly the IPFIX protocol draft just before the deadline! So we commit to propose a solution on the mailing before the next IETF meeting. Regards, Stewart and Benoit. ---------------------------------------- PROTO-25: The section "Template Management" and "The Collecting Process's Side" will have to updated according to the transport protocol. - For example, the point 2 of the section "Template Management". Remark: the template management will vary with TCP, SCTP, etc... Must have both sections updated: transport updated and template management sections (BTW, this is the same for the failover section). - From Deri's draft: On the other hand as a probe can send flows to several collectors (e.g. in round-robin or as a reflector) it must keep track of per-collector templates transmission. This means that if collector X reconnects, the probe must send the template only to this collector and not to all collectors. PROPOSAL, after IETF60: treat UDP as the exception, in the template subsection of the UDP transport protocol. PROTO-31 The "Sequence Number" and "Source ID" treatment in case of multiple streams in SCTP is not well described. For example, in case the Templates are sent to one stream and the flow records to another one, what should the "Sequence Number"? What should the collector do? See David Moore's post PROTO-32 Correct this issue below The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream do not have differing Source ID values and silently discard any data that does NOT match the initial value. The Exporting Process SHOULD NOT transmit messages inside one stream with multiple Source ID values. The correlated Flow Records are then treated like a normal export Flow. PROTO-33: correct the next paragraphs: silently? reset the connection? log an error? should the exporting process be allowed to sent multiple Source ID per stream. The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream do not have differing Source ID values and silently discard any data that does NOT match the initial value. The Exporting Process SHOULD NOT transmit messages inside one stream with multiple Source ID values. The correlated Flow Records are then treated like a normal export Flow. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Oct 24 12:41:21 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11074 for ; Sun, 24 Oct 2004 12:41:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CLl39-00026L-00 for ipfix-list@mil.doit.wisc.edu; Sun, 24 Oct 2004 11:16:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CLl37-00026G-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 24 Oct 2004 11:16:53 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2004 14:37:34 +0200 X-BrightmailFiltered: true Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9OCL2Sf007223 for ; Sun, 24 Oct 2004 14:21:03 +0200 (MEST) Received: from [192.168.1.100] (ams-clip-vpn-dhcp4116.cisco.com [10.61.80.19]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA23460 for ; Sun, 24 Oct 2004 13:20:57 +0100 (BST) Message-ID: <417B9E28.6050900@cisco.com> Date: Sun, 24 Oct 2004 13:20:56 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-23: time details Content-Type: multipart/alternative; boundary="------------060802000600060902030101" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------060802000600060902030101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi. Benoit and I have been looking at the PROTO-23 issue: PROTO-23: Finalize the time details. The time-related Information Elements are not defined in [IPFIX-INFO] We discovered some problems with section 9.1, and a way to enhance the mechanism. Let's make a distinction between the one pass method (as described in the pseudo code of section 9.1) and the two pass approach (also described in section 9.1). 1. First of all, the following sentence is incorrect! "For a Data Set with Flow Records requiring microsecond precision, the Export Packet "Export Time" field MUST be calculated so that each Flow Records flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX- INFO] would contain a 32 bit signed microsecond offset from the "Export Time" base timestamp." Although not explicitly stated in the text, with the one pass approach we have a signed offset which could be positive or negative. Let's imagine this scenario: - the first flow record is ready to be exported. Its start time is used as the base time in the IPFIX Message Header. - a second flow record is ready to be exported. This flow record started before the first one. So the startup delta time is actually negative. 2. Secondly, let's have a look at the next sentence which is not correct for the one pass approach! "Flow Records MUST be exported in different Export Packet if the absolute duration can not fit in those 35 minutes." Note: a signed 32 bit value gives a range of +/- 35 minutes. Let's imagine this scenario: _Scenario 1_: - the first flow record is ready to be exported. Its start time is used as the base time in the IPFIX Message Header. - a second flow record is ready to be exported. This flow record started 30 minutes after the first one, and last for 10 minutes. So the startup delta time as stored in the flow record will be 30 minutes. What could be the maximum flow duration if we want to put it in the same export packet? Only 5 minutes! So the text above isn't exact, since this flow's absolute duration does fit inside the 35 minutes, but it would need to be exported in a different export packet with a new base timestamp in the IPFIX Message Header. Let's imagine another scenario: _Scenario 2_: - the first flow record is ready to be exported. Its start time is used as the base time in the IPFIX Message Header. - a second flow record is ready to be exported. This flow record started 30 minutes before the first one (as we showed in scenario 1). So the startup delta time as stored in the flow record will be -30 minutes. What could the maximum flow duration be if we want to put it in the same export packet? 30 minutes + 35 minutes! - In this case the flow duration was 60 minutes ... _ Conclusions_: - This sentence "Flow Records MUST be exported in different Export Packet if the absolute duration can not fit in those 35 minutes" is wrong. We can't conclude anything about the maximum flow duration as it depends only on the relative flow start time between the first flow record and the other flow records to be exported. - Since the flow record end time is always greater than or equal to the flow record start time, it's more intuitive for flowEndUsec to be a positive offset of 0 to 71 minutes from flowStartUsec, thus allowing flows to be up to 71 minutes long regardless of the base timestamp in the IPFIX Message Header. The only condition is the flow records start time MUST be in the range [-35 minutes,+35 minutes] compared to the start time of the first flow record in the export packet, that is the IPFIX Message Header base time. 3. THE TWO PASS APPROACH IS BETTER WITH THE MINIMUM TIME INSTEAD OF THE AVERAGE. Thirdly, the two pass approach can be improved. "A two pass approach calculation for the optimum (center) "Export Time" base timestamp would allow an absolute duration of 71 minutes for all Flow Records contained in the Data Set." Instead of calculating the optimum center, we could simply record the lowest start time of all the flow records, which would be the base time for IPFIX Message Header. This mechanism gives the following advantages: - no need to calculate the optimum center (i.e. less computation). - would be inline with the proposal in point 2. - would directly return the flow duration in flowEndUsec, which BTW could be renamed to flowDurationUsec. While these observations are targeted for section 9.1, these are valid also for section 9.2 as section 9.2 refers to section 9.1. Any feedback before we propose some new text? Regards, Benoit and Paul. --------------060802000600060902030101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi.

Benoit and I have been looking at the PROTO-23 issue:

   PROTO-23: Finalize the time details. The time-related Information
   Elements are not defined in [IPFIX-INFO]

We discovered some problems with section 9.1, and a way to enhance the mechanism.

Let's make a distinction between the one pass method (as described in the pseudo code of section 9.1) and the two pass approach (also described in section 9.1).


1. First of all, the following sentence is incorrect!

   "For a Data Set with Flow Records requiring microsecond precision,
   the Export Packet "Export Time" field MUST be calculated so that
   each Flow Records flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX-
   INFO] would contain a 32 bit signed microsecond offset from the
   "Export Time" base timestamp."

Although not explicitly stated in the text, with the one pass approach we have a signed offset which could be positive or negative.

Let's imagine this scenario:

- the first flow record is ready to be exported. Its start time is used as the base time in the IPFIX Message Header.
- a second flow record is ready to be exported. This flow record started before the first one. So the startup delta time is actually negative.


2. Secondly, let's have a look at the next sentence which is not correct for the one pass approach!

    "Flow Records MUST be exported in different Export Packet if the absolute duration can not fit in those 35 minutes."

Note: a signed 32 bit value gives a range of +/- 35 minutes.


Let's imagine this scenario:

Scenario 1:

- the first flow record is ready to be exported. Its start time is used as the base time in the IPFIX Message Header.
- a second flow record is ready to be exported. This flow record started 30 minutes after the first one, and last for 10 minutes. So the startup delta time as stored in the flow record will be 30 minutes.

What could be the maximum flow duration if we want to put it in the same export packet? Only 5 minutes!

So the text above isn't exact, since this flow's absolute duration does fit inside the 35 minutes, but it would need to be exported in a different export packet with a new base timestamp in the IPFIX Message Header.


Let's imagine another scenario:

Scenario 2:

- the first flow record is ready to be exported. Its start time is used as the base time in the IPFIX Message Header.
- a second flow record is ready to be exported. This flow record started 30 minutes before the first one (as we showed in scenario 1). So the startup delta time as stored in the flow record will be -30 minutes.

What could the maximum flow duration be if we want to put it in the same export packet? 30 minutes + 35 minutes!

- In this case the flow duration was 60 minutes ...


Conclusions:

- This sentence "Flow Records MUST be exported in different Export Packet if the absolute duration can not fit in those 35 minutes" is wrong. We can't conclude anything about the maximum flow duration as it depends only on the relative flow start time between the first flow record and the other flow records to be exported.

- Since the flow record end time is always greater than or equal to the flow record start time, it's more intuitive for flowEndUsec to be a positive offset of 0 to 71 minutes from flowStartUsec, thus allowing flows to be up to 71 minutes long regardless of the base timestamp in the IPFIX Message Header. The only condition is the flow records start time MUST be in the range [-35 minutes,+35 minutes] compared to the start time of the first flow record in the export packet, that is the IPFIX Message Header base time.


3. THE TWO PASS APPROACH IS BETTER WITH THE MINIMUM TIME INSTEAD OF THE AVERAGE.

Thirdly, the two pass approach can be improved.

   "A two pass approach calculation for the optimum (center) "Export
   Time" base timestamp would allow an absolute duration of 71 minutes
   for all Flow Records contained in the Data Set."

Instead of calculating the optimum center, we could simply record the lowest start time of all the flow records, which would be the base time for IPFIX Message Header.

This mechanism gives the following advantages:
- no need to calculate the optimum center (i.e. less computation).
- would be inline with the proposal in point 2.
- would directly return the flow duration in flowEndUsec, which BTW could be renamed to flowDurationUsec.

While these observations are targeted for section 9.1, these are valid also for section 9.2 as section 9.2 refers to section 9.1.

Any feedback before we propose some new text?

Regards,
    Benoit and Paul.

--------------060802000600060902030101-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Oct 25 08:33:17 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20905 for ; Mon, 25 Oct 2004 08:33:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CM3Uj-00015o-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Oct 2004 06:58:37 -0500 Received: from user23.wlan-lmq.switch.ch ([130.59.110.23] helo=acer.sl.switch.ch) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CM3Ui-00015j-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 25 Oct 2004 06:58:36 -0500 Received: from acer.sl.switch.ch (localhost [IPv6:::1]) by acer.sl.switch.ch (8.13.1/8.13.1/Debian-15) with ESMTP id i9PBqZHl016681; Mon, 25 Oct 2004 13:52:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16764.59651.270261.290388@acer.sl.switch.ch> Date: Mon, 25 Oct 2004 13:52:35 +0200 From: Simon Leinen To: Stewart Bryant Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Proposed TCP section X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` In-Reply-To: <41750F7D.4020606@cisco.com> (Stewart Bryant's message of "Tue, 19 Oct 2004 13:58:37 +0100") X-Draft-From: ("nnml:lists.ietf.wg.ipfix.protocol" 100) References: <41750F7D.4020606@cisco.com> X-Mailer: VM 7.19 under Emacs 21.3.1 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Stewart Bryant writes: > I have extracted the key elements of the mechanism > described in > to carry IPFIX over TCP, and propose that this > text be incorporated in the IPFIX protocol draft. Um, I thought the agreement was that I'd do another revision of draft-leinen-ipfix-tcp, and we'd integrate that into draft-ietf-ipfix-protocol later on. Anyway. > Please can you comment ASAP so that Benoit and I can > incorporate into the next rev of the protocol > draft. > ISSUES > 2.1 Handshake > Should we introduce a handshake sequence at the start of the > connection? A simple ASCII-based handshake could be used to > request TLS. I suggest to remove the "Handshake" issue. I raised that at the last meeting and there didn't seem to be any support for adding a handshake. Unless somebody disagrees on this list, I would assume that everything that both sides (exporter and collector) need to know about their association and about each other must somehow be configured in advance, outside of the IPFIX protocol. > 2.2 TLS > It would make sense to add TLS support even in the absence of a > handshake. It would be the responsibility of the collector > (connection initiator) to know whether TLS setup is required. This is something I'd really like to have in. It would require a (short) subsection on how TLS would be initiated, and what should happen when both sides aren't consistently configured (one side expects TLS to be used, the other doesn't). I have added the following to draft-leinen-ipfix-tcp-01.txt: 3.5 TLS Usage Configuration of both the exporter and the collector may specify that Transport Layer Security (TLS) [RFC2246] must be used. 3.5.1 Starting a session using TLS When an exporter opens a TCP connection to a collector for which use of TLS has been configured, the exporter MUST immediately start a TLS negotiation on this connection. The exporter SHOULD immediately abort the connection when TLS negotiation fails for some reason. When a collector accepts a connection from an exporter for which use of TLS has been configured, the collector MUST wait for the exporter to start negotiating TLS. 3.5.2 Authentication Exporter and collectors with TLS support SHOULD allow the configuration of both the permitted levels of encryption, and of the authorized identities to which data should be exported or, respectively, from which data should be received. After successful TLS negotiation, the collector and exporter should each decide whether the required level of authentication and/or privacy was achieved. If this is not the case, the connection MUST be closed immediately; an exporter MUST NOT send any IPFIX data, and an collector MUST ignore any IPFIX data received. 3.5.3 Closing a session using TLS When TLS is used, the exporter SHOULD always send a close_notify alert before closing the TCP connection. This overlaps with section 14.2 of draft-ietf-ipfix-protocol-06.txt. My text is partly derived from RFC 3207 (STARTTLS SMTP Extension). > --------------------------------------------------------------- > 5.2 TCP > This section describes how IPFIX can be transported over TCP > [TCP]. > 5.2.1 Congestion Avoidance I still don't like the structure of the transport mapping sections! In my opinion, they should first describe how the mapping operates, and maybe later analyze in how far "congestion avoidance" and "reliability" are achieved by that mapping. Starting with blanket assurances about congestion avoidance and reliability doesn't help understanding the mappings. To me this sounds way too much like marketing blurb. > TCP will detect congestion in the end-to-end path between > the IPFIX Exporting Process and the IPFIX Collecting Process, > and limit the transfer rate accordingly. When an IPFIX > Exporting Process has records to export, but detects that > transmission by TCP is temporarily impossible, it can either > wait until sending is possible again, or it can decide to drop > the record. In the latter case, the dropped export data MUST > be accounted for, so that the amount of dropped export data can > be reported. The previous text is taken almost verbatim from draft-leinen-ipfix-tcp-00. Why did you drop the next paragraph? "When an exporter finds that the rate at which flow records should be exported is consistently higher than the rate at which TCP permits to send, it SHOULD adapt the metering process so that it generates a lower amount of data, for example by increasing the sampling interval, or by increasing the amount of aggregation. If it does this, the exporter SHOULD periodically attempt to switch back to the original metering configuration when congestion subsides." > 5.2.2 Reliability > TCP provides an intrinsically reliable delivery service from the > IPFIX Exporting Process to the IPFIX Collecting Process. > 5.2.3 MTU > TCP provides the required IPFIX Message fragmentation > service based on path MTU discovery. TCP and Path MTU Discovery are largely orthogonal - TCP provides the same services whether PMTDU is used or not, only more or less efficiently. And what is this "required IPFIX Message fragmentation service"? I cannot find it in RFC 3917. Let's leave this section out. We really don't have to talk about IP MTUs here. I still think it would be useful to talk about the permitted size of IPFIX *messages* though. In draft-leinen-ipfix-tcp, I have a section that says The 16-bit LENGTH field limits the length of a message to 65536 octets including the header. A collector MUST be able to handle message lengths of up to 65536 octets. Because the length field in IPFIX messages is a 16-bit unsigned, requiring every collector to handle 65536-octet messages sounds reasonable to me. > 5.3.4 Exporting Process > The following sections describe how an IPFIX-over-TCP > connection is created, how IPFIX data is transferred > over it, and how a connection is to be terminated. > 5.3.4.1 Connection Establishment > The IPFIX Exporting Process initiates a TCP connection to the > IPFIX Collecting Process. By default, the Collecting Process > listens for connections on TCP port XXXX (to be assigned by > IANA). It MUST be possible to configure both the Exporting > and Collecting Processes to use a different TCP port. Should we actually request a IANA-assigned port? For my own Netflow/IPFIX deployment I'd have to use multiple port numbers anyway, so a well-known port doesn't help me much. Arguments for a well-known port number: * Makes exporter/collectors easier to configure * Makes firewall rules easier to set up * Makes debugging easier with tools like Ethereal ... but all this only in simple configurations Arguments against a well-known port number: * Asking IANA for one will delay RFC publication by XXX days (but a single well-known port should be easy) * We don't want to deplete the limited resource of well-known port numbers for exotic protocols such as IPFIX > An Exporting Process MAY support more than one active > connection to different Collecting Processes (including > the case of different Collecting Processes on the same host). > 5.3.4.2 Connection Release > When an Exporting Process has no more IPFIX Messages to send, > it SHOULD close the TCP connection. > When a Collecting Process no longer wants to receive IPFIX > messages, it SHOULD close the TCP connection, but SHOULD > continue to receive and process IPFIX messages until the > Exporting Process has closed its end. > When an Collecting Process detects that the TCP > connection to the Exporting Process is broken, it MUST > continue to listen for a new connection. > When an Exporting Process detects that the TCP > connection is abnormally terminated, it SHOULD try to > re-establish the connection. > Connection timeouts SHOULD be configurable. > 5.3.4.3 IPFIX Message Encoding > TCP provides message boundary marking marking > mechanism. I suggest "TCP provides no message boundary marking mechanism." > When IPFIX Message are sent over a When IPFIX Messages ... > TCP connection, the LENGTH field in the IPFIX > Message header defines the end of each message > and the start of the next message. At this point in draft-leinen-ipfix-tcp-00.txt, there was the section about message sizes I mentioned above. Did you elide it because this is a transport mapping-independent concern? Are you planning to add some text on this to the protocol I-D? > If an Exporting Process exports data from multiple > Observation Domains, it should be careful to choose > the IPFIX Message lengths appropriately to avoid > head-of-line blocking between different Observation > Domains. > 5.3.4.4 Templates > New Template Records SHOULD be transmitted as > soon as they are created on the Metering Process, > and preferably before any associated Flow and > Options Data Record is transmitted. The Collecting > Process SHOULD accept Flow and Options Data Records > without the associated Template Record. > A Collecting Process MUST record all Template > and Option Template Records for the duration > of the connection, as an Exporting Process is > not required to re-export Template Records. > 5.3.5 Fail-over > If the Collecting Process does not acknowledge the > attempt by the Exporting Process to establish a > connection, the Exporting Process should retry. > The retry schedule SHOULD be configurable. In > the default configuration, an Exporting Process > MUST NOT attempt to establish a connection more > frequently than once per minute. > The Exporter MAY log an alarm if the time to > establish the association exceeds a specified > threshold. > If Collecting Process fail-over is supported by the > Exporting Process a second TCP connection MAY be > opened in advance. > ------------------------------------------------ > TCP specific security considerations > Because there is no handshake protocol once a TCP > connection is established, negotiation-based > transport-layer security protocols such as TLS > [RFC2246] cannot be used in a straightforward > manner to ensure authenticity and confidentiality. Actually, I now think that it would be quite possible to use TLS (based on mutual pre-configuration), and that this would be a completely valid, even superior, alternative to IPsec - see above. > Exporters and collectors MUST implement IPSEC [RFC2401] ^ IPsec (my mistake) > with the Authentication Header (AH) [RFC2402] to > ensure authenticity of the exporter and the collector. > Exporters SHOULD implement IPSEC Encapsulating Security ^ IPsec > Payload (ESP) [RFC2406] to ensure confidentiality of > the exported data. The use of AH and ESP MUST be > configurable for each exporter/collector pair. > It MUST be possible to configure, an Exporting Process ^ I believe this comma is incorrect. > to authenticate itself to the Collecting Process. > This authentication mechanism SHOULD be capable of > using strong identities such as IKE [RFC2409] public-key > certificates or pre-shared keys. A Collecting Process > SHOULD detect and log unauthorized connection attempts. > ------------------------------------------------- > IANA Considerations > IANA should assign a well-known TCP port number for IPFIX > over UDP, TCP and SCTP. It is recommended that the same > well-known port number is used as a default for all three > transport protocols. > EDITOR NOTE: once the SCTP, TCP and UDP ports are assigned, > The text in this draft might be updated. > ------------------------------------------------------- > Normative references > [RFC2401] Kent, S. and R. Atkinson, "Security > Architecture for the Internet Protocol", > RFC 2401, November 1998. I would add RFC793 (TCP), RFC2402 (AH), RFC 2406 (ESP). > [RFC2409] Harkins, D. and D. Carrel, "The Internet > Key Exchange (IKE)", RFC 2409, November 1998. > Informative References > [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol > Version 1.0", RFC 2246, January 1999. -- Simon. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Oct 25 10:19:14 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28587 for ; Mon, 25 Oct 2004 10:19:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CM5Z7-0003Yn-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Oct 2004 09:11:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CM5Z5-0003Yi-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 25 Oct 2004 09:11:15 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2004 16:28:03 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9PEBBSf025243; Mon, 25 Oct 2004 16:11:11 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4281.cisco.com [10.61.80.184]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA23085; Mon, 25 Oct 2004 15:11:09 +0100 (BST) Message-ID: <417D097D.2030402@cisco.com> Date: Mon, 25 Oct 2004 15:11:09 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Proposed TCP section References: <41750F7D.4020606@cisco.com> <16764.59651.270261.290388@acer.sl.switch.ch> In-Reply-To: <16764.59651.270261.290388@acer.sl.switch.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Simon See inline. It's too late for this pass, but the text should incorporate your comments in the next pass. Simon Leinen wrote: > Stewart Bryant writes: > >>I have extracted the key elements of the mechanism >>described in >>to carry IPFIX over TCP, and propose that this >>text be incorporated in the IPFIX protocol draft. > > > Um, I thought the agreement was that I'd do another revision of > draft-leinen-ipfix-tcp, and we'd integrate that into > draft-ietf-ipfix-protocol later on. Anyway. > There was a misunderstanding. The problem was that without the TCP text we could not finish the protocol draft. Now we did not quite finish it (but we did try). Benoit would like to square away the remaining issues before the meeting so expect more text to the list. > >>Please can you comment ASAP so that Benoit and I can >>incorporate into the next rev of the protocol >>draft. > > >>ISSUES > > >>2.1 Handshake > > >>Should we introduce a handshake sequence at the start of the >>connection? A simple ASCII-based handshake could be used to >>request TLS. > > > I suggest to remove the "Handshake" issue. I raised that at the last > meeting and there didn't seem to be any support for adding a > handshake. > > Unless somebody disagrees on this list, I would assume that everything > that both sides (exporter and collector) need to know about their > association and about each other must somehow be configured in > advance, outside of the IPFIX protocol. Yes, until (if) we ever introduce an IPFIX config protocol there is so much config that is needed we should do this by config as well. > > >>2.2 TLS > > >>It would make sense to add TLS support even in the absence of a >>handshake. It would be the responsibility of the collector >>(connection initiator) to know whether TLS setup is required. > > > This is something I'd really like to have in. It would require a > (short) subsection on how TLS would be initiated, and what should > happen when both sides aren't consistently configured (one side > expects TLS to be used, the other doesn't). I have added the > following to draft-leinen-ipfix-tcp-01.txt: OK, that text should be added to the protocol draft. > > 3.5 TLS Usage > > Configuration of both the exporter and the collector may > specify that Transport Layer Security (TLS) [RFC2246] must be > used. > > 3.5.1 Starting a session using TLS > > When an exporter opens a TCP connection to a collector for > which use of TLS has been configured, the exporter MUST > immediately start a TLS negotiation on this connection. The > exporter SHOULD immediately abort the connection when TLS > negotiation fails for some reason. > > When a collector accepts a connection from an exporter for > which use of TLS has been configured, the collector MUST wait > for the exporter to start negotiating TLS. > > 3.5.2 Authentication > > Exporter and collectors with TLS support SHOULD allow the > configuration of both the permitted levels of encryption, and > of the authorized identities to which data should be exported > or, respectively, from which data should be received. > > After successful TLS negotiation, the collector and exporter > should each decide whether the required level of authentication > and/or privacy was achieved. If this is not the case, the > connection MUST be closed immediately; an exporter MUST NOT > send any IPFIX data, and an collector MUST ignore any IPFIX > data received. > > 3.5.3 Closing a session using TLS > > When TLS is used, the exporter SHOULD always send a > close_notify alert before closing the TCP connection. > > This overlaps with section 14.2 of draft-ietf-ipfix-protocol-06.txt. > My text is partly derived from RFC 3207 (STARTTLS SMTP Extension). > > >>--------------------------------------------------------------- > > >>5.2 TCP > > >>This section describes how IPFIX can be transported over TCP >>[TCP]. > > >>5.2.1 Congestion Avoidance > > > I still don't like the structure of the transport mapping sections! > > In my opinion, they should first describe how the mapping operates, > and maybe later analyze in how far "congestion avoidance" and > "reliability" are achieved by that mapping. > > Starting with blanket assurances about congestion avoidance and > reliability doesn't help understanding the mappings. To me this > sounds way too much like marketing blurb. There is some history there because - as you know - this issue was a key factor in the early transport discussions. We should perhaps change the ordering around, but we should do it consistently across all transport types. > > >>TCP will detect congestion in the end-to-end path between >>the IPFIX Exporting Process and the IPFIX Collecting Process, >>and limit the transfer rate accordingly. When an IPFIX >>Exporting Process has records to export, but detects that >>transmission by TCP is temporarily impossible, it can either >>wait until sending is possible again, or it can decide to drop >>the record. In the latter case, the dropped export data MUST >>be accounted for, so that the amount of dropped export data can >>be reported. > > > The previous text is taken almost verbatim from > draft-leinen-ipfix-tcp-00. Why did you drop the next paragraph? > > "When an exporter finds that the rate at which flow records > should be exported is consistently higher than the rate at > which TCP permits to send, it SHOULD adapt the metering > process so that it generates a lower amount of data, for > example by increasing the sampling interval, or by increasing > the amount of aggregation. If it does this, the exporter > SHOULD periodically attempt to switch back to the original > metering configuration when congestion subsides." > Tho reasons: Ipfix protocol really deals with the record transport and not with the metering process (that's PSAMP's teritory), and this is a metering problem. Secondly this is more of an implementation rather than an interworking issue anyway, and as such it may not belong in any IETF spec. I suppose you could replace the above with something of the form "If transport experiences congestion it should notify the metering process" but specifying the action is I think wrong, because the right action will depend on the application. The above statement should go in some generic place anyway because it applies to all transports except UDP. > >>5.2.2 Reliability > > >>TCP provides an intrinsically reliable delivery service from the >>IPFIX Exporting Process to the IPFIX Collecting Process. > > >>5.2.3 MTU > > >>TCP provides the required IPFIX Message fragmentation >>service based on path MTU discovery. As I recall I pulled it over because it was also in SCTP. We should probably take it out from both. > > > TCP and Path MTU Discovery are largely orthogonal - TCP provides the > same services whether PMTDU is used or not, only more or less > efficiently. > > And what is this "required IPFIX Message fragmentation service"? I > cannot find it in RFC 3917. Let's leave this section out. We really > don't have to talk about IP MTUs here. > > I still think it would be useful to talk about the permitted size of > IPFIX *messages* though. In draft-leinen-ipfix-tcp, I have a section > that says > > The 16-bit LENGTH field limits the length of a message to > 65536 octets including the header. A collector MUST be able > to handle message lengths of up to 65536 octets. > > Because the length field in IPFIX messages is a 16-bit unsigned, > requiring every collector to handle 65536-octet messages sounds > reasonable to me. That is really an IPFIX issue rather that a transport issue. We should probably delete it from the transport details (except to say that UDP can't even do this), and MAYBE say somewhere in the global trnsport text that messages must be no bigger than transport can support but we recommend that should where possible support messages sizes of up 65536 (less any gatepost problems) > > >>5.3.4 Exporting Process > > >>The following sections describe how an IPFIX-over-TCP >>connection is created, how IPFIX data is transferred >>over it, and how a connection is to be terminated. > > >>5.3.4.1 Connection Establishment > > >>The IPFIX Exporting Process initiates a TCP connection to the >>IPFIX Collecting Process. By default, the Collecting Process >>listens for connections on TCP port XXXX (to be assigned by >>IANA). It MUST be possible to configure both the Exporting >>and Collecting Processes to use a different TCP port. > > > Should we actually request a IANA-assigned port? For my own > Netflow/IPFIX deployment I'd have to use multiple port numbers anyway, > so a well-known port doesn't help me much. > > Arguments for a well-known port number: > > * Makes exporter/collectors easier to configure > * Makes firewall rules easier to set up > * Makes debugging easier with tools like Ethereal > ... but all this only in simple configurations > > Arguments against a well-known port number: > > * Asking IANA for one will delay RFC publication by XXX days > (but a single well-known port should be easy) > * We don't want to deplete the limited resource of well-known port > numbers for exotic protocols such as IPFIX > > Again common to SCTP which has been around for a while. Whatever we do we should do the same in both cases. I am not sure that the XXX days is the issue, and nor am I sure that IPFIX is more exotic than many of the protocols that already have ports. It's really a WG call, so we need to text consensus. >>An Exporting Process MAY support more than one active >>connection to different Collecting Processes (including >>the case of different Collecting Processes on the same host). > > >>5.3.4.2 Connection Release > > >>When an Exporting Process has no more IPFIX Messages to send, >>it SHOULD close the TCP connection. > > >>When a Collecting Process no longer wants to receive IPFIX >>messages, it SHOULD close the TCP connection, but SHOULD >>continue to receive and process IPFIX messages until the >>Exporting Process has closed its end. > > >>When an Collecting Process detects that the TCP >>connection to the Exporting Process is broken, it MUST >>continue to listen for a new connection. > > >>When an Exporting Process detects that the TCP >>connection is abnormally terminated, it SHOULD try to >>re-establish the connection. > > >>Connection timeouts SHOULD be configurable. > > >>5.3.4.3 IPFIX Message Encoding > > >>TCP provides message boundary marking marking >>mechanism. > > > I suggest "TCP provides no message boundary marking mechanism." > Yes, typo > >>When IPFIX Message are sent over a > > > When IPFIX Messages ... > OK > >>TCP connection, the LENGTH field in the IPFIX >>Message header defines the end of each message >>and the start of the next message. > > > At this point in draft-leinen-ipfix-tcp-00.txt, there was the section > about message sizes I mentioned above. Did you elide it because this > is a transport mapping-independent concern? Are you planning to add > some text on this to the protocol I-D? See above > > >>If an Exporting Process exports data from multiple >>Observation Domains, it should be careful to choose >>the IPFIX Message lengths appropriately to avoid >>head-of-line blocking between different Observation >>Domains. > > >>5.3.4.4 Templates > > >>New Template Records SHOULD be transmitted as >>soon as they are created on the Metering Process, >>and preferably before any associated Flow and >>Options Data Record is transmitted. The Collecting >>Process SHOULD accept Flow and Options Data Records >>without the associated Template Record. > > >>A Collecting Process MUST record all Template >>and Option Template Records for the duration >>of the connection, as an Exporting Process is >>not required to re-export Template Records. > > >>5.3.5 Fail-over > > >>If the Collecting Process does not acknowledge the >>attempt by the Exporting Process to establish a >>connection, the Exporting Process should retry. >>The retry schedule SHOULD be configurable. In >>the default configuration, an Exporting Process >>MUST NOT attempt to establish a connection more >>frequently than once per minute. > > >>The Exporter MAY log an alarm if the time to >>establish the association exceeds a specified >>threshold. > > >>If Collecting Process fail-over is supported by the >>Exporting Process a second TCP connection MAY be >>opened in advance. > > > >>------------------------------------------------ >>TCP specific security considerations > > >>Because there is no handshake protocol once a TCP >>connection is established, negotiation-based >>transport-layer security protocols such as TLS >>[RFC2246] cannot be used in a straightforward >>manner to ensure authenticity and confidentiality. > > > Actually, I now think that it would be quite possible to use TLS > (based on mutual pre-configuration), and that this would be a > completely valid, even superior, alternative to IPsec - see above. > > OK, we will include your text. >>Exporters and collectors MUST implement IPSEC [RFC2401] > > ^ > IPsec > (my mistake) > > >>with the Authentication Header (AH) [RFC2402] to >>ensure authenticity of the exporter and the collector. >>Exporters SHOULD implement IPSEC Encapsulating Security > > ^ > IPsec > > >>Payload (ESP) [RFC2406] to ensure confidentiality of >>the exported data. The use of AH and ESP MUST be >>configurable for each exporter/collector pair. > > >>It MUST be possible to configure, an Exporting Process > > ^ > I believe this comma is incorrect. > OK > >>to authenticate itself to the Collecting Process. >>This authentication mechanism SHOULD be capable of >>using strong identities such as IKE [RFC2409] public-key >>certificates or pre-shared keys. A Collecting Process >>SHOULD detect and log unauthorized connection attempts. > > >>------------------------------------------------- > > >>IANA Considerations > > >>IANA should assign a well-known TCP port number for IPFIX >>over UDP, TCP and SCTP. It is recommended that the same >>well-known port number is used as a default for all three >>transport protocols. > > >>EDITOR NOTE: once the SCTP, TCP and UDP ports are assigned, >>The text in this draft might be updated. > > >>------------------------------------------------------- >>Normative references > > > >>[RFC2401] Kent, S. and R. Atkinson, "Security >> Architecture for the Internet Protocol", >> RFC 2401, November 1998. > > > I would add RFC793 (TCP), RFC2402 (AH), RFC 2406 (ESP). > OK > >>[RFC2409] Harkins, D. and D. Carrel, "The Internet >>Key Exchange (IKE)", RFC 2409, November 1998. > > >>Informative References > > >>[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol >>Version 1.0", RFC 2246, January 1999. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Oct 30 11:32:15 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29317 for ; Sat, 30 Oct 2004 11:32:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CNupx-00016J-00 for ipfix-list@mil.doit.wisc.edu; Sat, 30 Oct 2004 10:08:13 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CNupw-000165-00 for ipfix@net.doit.wisc.edu; Sat, 30 Oct 2004 10:08:12 -0500 Received: from [10.49.4.219] (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id i9UF88106106 for ; Sat, 30 Oct 2004 17:08:08 +0200 (CEST) Message-ID: <4183AE57.4030902@cisco.com> Date: Sat, 30 Oct 2004 17:08:07 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix Subject: [ipfix] [Fwd: RFC 3954 on Cisco Systems NetFlow Services Export Version 9] Content-Type: multipart/alternative; boundary="------------010204040407030001070304" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------010204040407030001070304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit. -------- Original Message -------- Subject: RFC 3954 on Cisco Systems NetFlow Services Export Version 9 Date: Thu, 28 Oct 2004 10:45:33 -0700 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 3954 Title: Cisco Systems NetFlow Services Export Version 9 Author(s): B. Claise, Ed. Status: Informational Date: October 2004 Mailbox: bclaise@cisco.com Pages: 33 Characters: 76360 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-claise-netflow-9-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3954.txt This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute --------------010204040407030001070304 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit.

-------- Original Message --------
Subject: RFC 3954 on Cisco Systems NetFlow Services Export Version 9
Date: Thu, 28 Oct 2004 10:45:33 -0700
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org
CC: rfc-editor@rfc-editor.org 


A new Request for Comments is now available in online RFC libraries.


        RFC 3954

        Title:      Cisco Systems NetFlow Services Export Version 9
        Author(s):  B. Claise, Ed.
        Status:     Informational
        Date:       October 2004
        Mailbox:    bclaise@cisco.com
        Pages:      33
        Characters: 76360
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-claise-netflow-9-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3954.txt


This document specifies the data export format for version 9 of
Cisco Systems' NetFlow services, for use by implementations on the
network elements and/or matching collector programs.  The version 9
export format uses templates to provide access to observations
of IP packet flows in a flexible and extensible manner.  A template
defines a collection of fields, with corresponding descriptions of
structure and semantics.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
--------------010204040407030001070304-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/