Xa
A
Cl
Vl
So
Va
Le

nax   (30)
mbien  (30)
AL= lS  (30)
AGRA  (30)
ma    (= 30)
LlUM  (30)
vitra (30)

- $124
- $120
- $= 170
- $135
- $76
- $86
= ;- $166

Where are the mechanisms? The guardhouse. Get in there! yelled Bourne, taking one of the three remaining flares out of his field jacket pocket and handing it to Benjamin. Ive got two more of these and two other grenades. ... When you see one of my flares go over the crowd, lower those gates on this side-only this side, understood? What for? My rules, Ben! Do it! Then ignite this flare and throw it out the window so Ill know its done. Then what? Something you may not want to do, but you have to. ... Take the forty-seven from the colonels body and force the crowd, shoot it = back

------=_NextPart_000_0001_01C600E4.08E09FC0-- From majordomo@mil.doit.wisc.edu Thu Dec 15 13:12:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmxaX-0007bk-2T for ipfix-archive@megatron.ietf.org; Thu, 15 Dec 2005 13:12:21 -0500 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 NAA12413 for ; Thu, 15 Dec 2005 13:11:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EmxC1-0005OV-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Dec 2005 11:47:01 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EmxC0-0005NV-00 for ipfix@net.doit.wisc.edu; Thu, 15 Dec 2005 11:47:00 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2005 18:46:59 +0100 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 jBFHkvFZ004121 for ; Thu, 15 Dec 2005 18:46:58 +0100 (MET) Received: from [144.254.153.68] (dhcp-144-254-153-68.cisco.com [144.254.153.68]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA28915 for ; Thu, 15 Dec 2005 17:46:56 GMT Message-ID: <43A1AC10.2000805@cisco.com> Date: Thu, 15 Dec 2005 17:46:56 +0000 From: Andrew Johnson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] Floating point numbers in IPFIX Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all In the IPFIX protocol draft, section 3.1.5, we have a definition of a floating point number. This definition allows export of floating point numbers using the 32-bit format as specified in IEEE.754. This same standard also allows floating point numbers to be defined in a 64-bit format. I would like to see a float64 type added and the abiltity to send float64 fields using float32 using a variation of the Reduced Size Encoding as used with the integers. I would like to propose that at the next editing phase we add the following type to the information model: 3.1.6. float64 The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985]. In the protocol, section 6.2 could also be expanded to encompase the Reduced Size encoding for the floating point types. i.e. 6.2 Reduced Size Encoding of Integer Types Information Elements containing integer, float, string, and ... ^^^^^^^ octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [IPFIX-INFO], ... ... If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed16. ... @@[NOTE: the signed types above are not in the data model]@@ Reduced sizing can also be used on the float64 and float32. The float32 not only has a reduced number range, but due to the smaller mantissa is also less precise. The reduced size encoding MUST NOT be applied to ... Andrew -- 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 security@eBay.com Thu Dec 15 17:16:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En1OP-00069n-MK for ipfix-archive@megatron.ietf.org; Thu, 15 Dec 2005 17:16:05 -0500 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 RAA23699 for ; Thu, 15 Dec 2005 17:15:06 -0500 (EST) From: security@eBay.com Received: from h134-215-222-110.134-215.unk.tds.net ([134.215.222.110]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1En121-0002Ht-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Dec 2005 15:52:58 -0600 Received: from 134.215.222.110 (unverified [61.157.22.155]) by karbast.halsteadcontractors.com (EMWAC SMTPRS 0.83) with SMTP id Date: Thu, 15 Dec 2005 15:52:58 -0600 From majordomo@mil.doit.wisc.edu Fri Dec 16 03:55:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnBMu-0004Fg-3h for ipfix-archive@megatron.ietf.org; Fri, 16 Dec 2005 03:55:12 -0500 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 DAA19220 for ; Fri, 16 Dec 2005 03:54:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EnAxe-00055f-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Dec 2005 02:29:07 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EnAxd-00055O-00 for ipfix@net.doit.wisc.edu; Fri, 16 Dec 2005 02:29:05 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2005 09:29:05 +0100 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 jBG8T2FZ003739 for ; Fri, 16 Dec 2005 09:29:02 +0100 (MET) Received: from [10.61.66.30] (ams-clip-vpn-dhcp542.cisco.com [10.61.66.30]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA03439; Fri, 16 Dec 2005 08:29:00 GMT Message-ID: <43A27ACC.8040606@cisco.com> Date: Fri, 16 Dec 2005 08:29:00 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Johnson CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <43A1AC10.2000805@cisco.com> In-Reply-To: <43A1AC10.2000805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit These are good suggestions. We need to add signed types to the data model, and I think that we should add float64 with the export compresion to float32. - Stewart Andrew Johnson wrote: > Hi all > > In the IPFIX protocol draft, section 3.1.5, we have a definition > of a floating point number. This definition allows export of > floating point numbers using the 32-bit format as specified in > IEEE.754. This same standard also allows floating point numbers > to be defined in a 64-bit format. > > I would like to see a float64 type added and the abiltity to > send float64 fields using float32 using a variation of the > Reduced Size Encoding as used with the integers. > > I would like to propose that at the next editing phase we add > the following type to the information model: > > 3.1.6. float64 > > The type "float64" corresponds to an IEEE double-precision 64-bit > floating point type as defined in [IEEE.754.1985]. > > > In the protocol, section 6.2 could also be expanded to encompase > the Reduced Size encoding for the floating point types. i.e. > > 6.2 Reduced Size Encoding of Integer Types > Information Elements containing integer, float, string, and ... > ^^^^^^^ > octetarray types in the information model MAY be encoded using fewer > octets than those implied by their type in the information model > definition [IPFIX-INFO], ... > > ... > If reduced sizing is used, it MUST only be applied to the following > integer types: unsigned64, signed64, unsigned32, signed32, > unsigned16, signed16. ... > > @@[NOTE: the signed types above are not in the data model]@@ > > Reduced sizing can also be used on the float64 and float32. The > float32 not only has a reduced number range, but due to the > smaller mantissa is also less precise. > > The reduced size encoding MUST NOT be applied to ... > > > Andrew > > > -- > 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/ > > -- 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 yannicislas@ffg.com Fri Dec 16 04:57:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnCKy-0006YV-IM for ipfix-archive@megatron.ietf.org; Fri, 16 Dec 2005 04:57:16 -0500 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 EAA25247 for ; Fri, 16 Dec 2005 04:56:15 -0500 (EST) Received: from c-66-41-114-54.hsd1.mn.comcast.net ([66.41.114.54] helo=ffg.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1EnCFC-0000CL-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Dec 2005 03:51:18 -0600 From: "Yannic Islas" To: "Nerea Weishaar" Message-ID: <000001c601db$0e172020$b1afa8c0@coconut> Subject: Re: song peaceable Date: Thu, 15 Dec 2005 19:52:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C601B1.25411820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?66.41.114.54 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C601B1.25411820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.vergeeralisin.com =20 CIA Am Xa Pro So VIA Lev VA Me LIS bien nax pecia ma GRA itra LIUM ridia $9 $6 $1 $6 $7 $6 $9 $8 $9 9.95 8.00 23.45 4.95 5.95 9.95 9.95 5.45 9.95 =20 =20 =20 What? Ill explain later. Now hurry up. Ill see you in the lobby. You mean my office, dont you? Ive got the clothes, remember? Theyll come later-roughly a minute later, after I get out of this uniform. Do you have a camera in your office? Three or four of them. Guests are always leaving them behind- Put all of them with the clothes, interrupted Jason. Get going! Bourne shoved the radio into his belt, then changed his mind. He pulled it out and handed it to Fontaine. Here, you take this. Ill get another and stay in contact. ... Whats happening down there? Our alarmed priest looks around as they go to the lobby doors. Hes truly frightened now. Wheres he looking? asked Bourne, grabbing the binoculars. ------=_NextPart_000_0001_01C601B1.25411820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.vergeeralisin.com

CIA
Am
Xa
Pro
So
VIA
Lev
VA
Me

LIS
bien
nax
pecia
ma
GRA
itra
LIUM
= ridia

$9
$6
$1
$6
$7
= $6
$9
$8
$9

9.95
8.00
23.45
4.95
5.95
9.95
9.95
5.4= 5
9.95

What? Ill explain later. Now hurry up. Ill see you in the lobby. You mean my office, dont you? Ive got the clothes, remember? Theyll come later-roughly a minute later, after I get out of this uniform. Do you have a camera in your office? Three or four of them. Guests are always leaving them behind- Put all of them with the clothes, interrupted Jason. Get going! Bourne shoved the radio into his belt, then changed his mind. He pulled it out and handed it to Fontaine. Here, you take this. Ill get another and stay in contact. ... Whats happening down there? Our alarmed priest looks around as they go to the lobby doors. Hes truly frightened now. Wheres he looking? asked Bourne, grabbing the = binoculars.

------=_NextPart_000_0001_01C601B1.25411820-- From majordomo@mil.doit.wisc.edu Fri Dec 16 08:57:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnG5h-0006Nu-9S for ipfix-archive@megatron.ietf.org; Fri, 16 Dec 2005 08:57:45 -0500 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 IAA21149 for ; Fri, 16 Dec 2005 08:56:44 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EnFz0-0007gt-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Dec 2005 07:50:50 -0600 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EnFyz-0007gg-00 for ipfix@net.doit.wisc.edu; Fri, 16 Dec 2005 07:50:49 -0600 Received: from venus.office (venus.office [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id EAAF01C953; Fri, 16 Dec 2005 14:50:47 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix] Floating point numbers in IPFIX Date: Fri, 16 Dec 2005 14:50:32 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0071_01C60250.10B849B0" Message-ID: X-MS-Has-Attach: yes Thread-Topic: [ipfix] Floating point numbers in IPFIX thread-index: AcYBpmpPzTf7TXSqSwa+5RrMTuy7MQAn2QmQ From: "Thomas Dietz" To: "Andrew Johnson" , Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C60250.10B849B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Andrew, Find my comments inline. -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Andrew Johnson > Sent: Thursday, December 15, 2005 6:47 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] Floating point numbers in IPFIX > > Hi all > > In the IPFIX protocol draft, section 3.1.5, we have a definition > of a floating point number. This definition allows export of > floating point numbers using the 32-bit format as specified in > IEEE.754. This same standard also allows floating point numbers > to be defined in a 64-bit format. > > I would like to see a float64 type added and the abiltity to > send float64 fields using float32 using a variation of the > Reduced Size Encoding as used with the integers. Fine with me if all the others agree. > > I would like to propose that at the next editing phase we add > the following type to the information model: > > 3.1.6. float64 > > The type "float64" corresponds to an IEEE double-precision 64-bit > floating point type as defined in [IEEE.754.1985]. > I guess the definition is ok. > > In the protocol, section 6.2 could also be expanded to encompase > the Reduced Size encoding for the floating point types. i.e. > > 6.2 Reduced Size Encoding of Integer Types Note the section says "Integer Types", so I would propose to have a seperate section. This would also make clear that the reduzed size encoding of floats is different than those of integers. > > Information Elements containing integer, float, string, and ... > ^^^^^^^ > octetarray types in the information model MAY be encoded using fewer > octets than those implied by their type in the information model > definition [IPFIX-INFO], ... > > ... > > If reduced sizing is used, it MUST only be applied to the following > integer types: unsigned64, signed64, unsigned32, signed32, > unsigned16, signed16. ... > > @@[NOTE: the signed types above are not in the data model]@@ > > Reduced sizing can also be used on the float64 and float32. The > float32 not only has a reduced number range, but due to the > smaller mantissa is also less precise. > > The reduced size encoding MUST NOT be applied to ... I think we still need to elaborate this a little bit more, because we have to explain how mantissa and exponent can be mapped from float64 to float32. Regards, Thomas > > > Andrew > > > -- > 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/ > ------=_NextPart_000_0071_01C60250.10B849B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIxNjEzNTAzMlowIwYJKoZIhvcNAQkEMRYEFM1msGGm i4DKts/opzuqGCWA3SNeMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAH4VnaKFJhhfbVfw/Y3Q 6DYoSSR9ONLAfnoj78RtjGE1PTybC85zigYpyVCg22ldrUU3S+ytbvJr842YnSDgVautw/Vh+BBV ZLT17b27gcQdwB1XFjScuUQQWGh1UBcqaD41+deSoUpBAnaelS2y48/xJ7Bop22YWW4w8+9r+3TH wIE49rV51LhfOxruPkUhIg+Va/X15aR0wMFlPSYxNx1iQw7HL3WWTdvCTTU0dOJlMIZZFgP6I0Em u8tjLA2criwjPecM+9AlyTaHbvSbahix3MED207BLmOrKw3ZSdSzi1XHieL/FsCwC8J6I6BTU9Oh VERMhgWc3fo1tJ5NDVQAAAAAAAA= ------=_NextPart_000_0071_01C60250.10B849B0-- -- 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 Dec 16 11:14:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnIDl-0004rZ-1Z for ipfix-archive@megatron.ietf.org; Fri, 16 Dec 2005 11:14:13 -0500 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 LAA09974 for ; Fri, 16 Dec 2005 11:13:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EnI7q-0004Wo-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Dec 2005 10:08:06 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EnI7o-0004WZ-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Dec 2005 10:08:04 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Dec 2005 17:08:04 +0100 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 jBGG80FZ012576; Fri, 16 Dec 2005 17:08:01 +0100 (MET) Received: from [10.61.65.73] (ams-clip-vpn-dhcp329.cisco.com [10.61.65.73]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA15854; Fri, 16 Dec 2005 16:07:59 GMT Message-ID: <43A2E65E.5020800@cisco.com> Date: Fri, 16 Dec 2005 16:07:58 +0000 From: Andrew Johnson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sven Anderson CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu, psamp Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements in a template -> proposed IPFIX text References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE> In-Reply-To: <4399B4B2.5060204@CS.Uni-Goettingen.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA09974 Hello Sven Sven Anderson wrote: > Dear Benoit and all, >=20 > Benoit Claise wrote: >=20 >> I would add: >> >> If an Information Element is required more than once in Template, >> the different occurrences of this Information Element SHOULD follow >> the logical order of their treatments by the Metering Process. >> For example, if a selected packet goes through two hash functions, >> and if the two hash values are sent within a single template, the=20 >> first occurrence of the hash value should belong to the first hash >> function in the Metering Process. For example, when exporting the=20 >> two source IP addresses of an IPv4 in IPv4 packets, the first =20 >> sourceIPv4Address Information Element occurrence should be the IPv4 >> address of the outer header, while the second occurrence should be=20 >> the inner header one. >> >> In section 9 "The Collecting Process's Side", at the very end, I would= =20 >> add: >> >> The Collector MUST support the use of Templates containing multip= le occurrences of >> the similar Information Elements. >=20 >=20 > Isn't that quite exactly what I proposed in my mail of 2005/08/04? It=20 > was a long mail I admit, so maybe nobody read it. ;-) That mail is=20 > attached, if somebody now is interested to read it. I would say that the problem your proposal is trying to solve and the pro= blem that this proposal is trying to solve are subtely different. You are trying to solve the issue of building a flow record with element captured from different observation points. The problem with using the same I.E.s for the same field but seen in different places is that you can't tell which entry in the record applies to which field. Even adding an order dependence doesn't solve this issue because there is no requirement to put all versions of the element in the record. This is detailed in your proposal but your solution is quite a complex addition to the protocol. There is a seperate problem when it comes to having the same element be applicable more than once at a single observation point. Actually there are two similar problems: 1. The same element applies more than once but you want to be able to selectively report only some of them. i.e. MPLS labels. In this case we have to use seperate I.E.s 2. The same element applies more than once but you need to report them all. This is the issue Benoit's proposal is an attempt to solve. For example a classification routines may classify a packet as classes 1, 10 and 15 similtaneously because these classes have independent properties. In this example order may not seem important, but if you want to match the classes with some statistics about each class then making it order dependent allows the order of each to be alligned. Andrew > But doesn't make this all the post-/pre- I.E. discussion obsolete?=20 > Wouldn't it be enough just to export two I.E. of the same type? Of=20 > course, with the post-I.E. you have more semantics. But wouldn't it be=20 > better to give this semantics by other means? >=20 > But there are certain amiguities. For instance in your example (IP in=20 > IP), if you also export the packet size (for single packet reports) or=20 > in octet counters in general, is it corresponding to the outer or the=20 > inner packet? That's why I also proposed a kind of separator I.E. with=20 > length 0, which separates different groups of I.E. in the template. An= d=20 > in each group, every I.E. MUST appear only one time. That way you alway= s=20 > know which I.E. belong together. >=20 > Template example: > > > ** (pseudo I.E. with length 0) > >=20 > That way it's clear, that the counter corresponds to the first packet=20 > state size, which in the IP in IP scenario is the outer packet size. >=20 > J=FCrgen stated to my proposal, that you try to avoid more complex=20 > concepts if possible. But as it seems, it's getting more complex anyway. >=20 >=20 > Cheers, >=20 > Sven >=20 >=20 > -----------------------------------------------------------------------= - >=20 > Subject: > [ipfix-info] Proposal for IFPIX observations at middleboxes > From: > Sven Anderson > Date: > Thu, 04 Aug 2005 19:05:42 +0200 > To: > ipfix-info@net.doit.wisc.edu >=20 > To: > ipfix-info@net.doit.wisc.edu >=20 >=20 > Hi all, >=20 > I will try to explain again my idea for reporting flows from middleboxe= s > as clear and short(?) as possible: >=20 > When IP packets travel through a middlebox, their properties may change. > Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or > replication (multicasting). That means, that if an Observation Domain > includes several Observation Points, and the same packet passes more th= an > one of these Observation Points, some properties can be ambiguous in th= is > Observation Domain. >=20 > You could solve this by saying, that every propery of a flow-report > has to derive from the same observation point. But this would be > restrictive. Sometimes it is desirable, that you can classify a single > Flow by properties, that derive from _different_ Observation Points. Fo= r > example a flow-definition that includes the source IP address before an= d > after a NAT, or the DSCP at three different Observation Points (before > ingress linecard, after ingress linecard, after egress linecard). >=20 > To realise this, you need a way to use certain properties more than one > time in a flow-template, to correspond to the different states at the > different Observation Points. One way to do this, is the introduction o= f > additional post- I.E.s, which then correspond to the first and the last > Observation Point in the Observation Domain. But this is a restriction = to > two special Observation Points, and the second example from above is no= t > solvable with this approach. >=20 > A more general solution would be to allow the use of the same I.E. more > than one time in the same template. The order of the multiple I.E.s > corresponds to the different observations as the packet travels through > the middlebox. The problem here is, that you cannot tell then, to which= of > the different observations the _singular_ I.E.s belong to. >=20 > To solve this, you need a possibility to build goups of I.E.s in the > Template: The I.E. values in one "Observation Group" always derive from > the same Observation Point (for each packet!). The Observation Groups a= re > ordered accordingly to the sequence of Observation Points the packet is > passing. Of course there are also fields which don't depend on the > Observation Point and can be reported in any Observation Group, like > ingressInterface (not egress!), as it is always the same, no matter whe= re > in the middlebox the packet is observed. (You may say, that these field= s > _have_ to be reported in the first group then, if this is an advantage.= ) >=20 > Important to note is, that packets of a Flow defined by (for example) t= wo > Observation Groups don't necessarily pass the same sequence of two > Observation Points. They just share the same Flow poperties at the thei= r > first and second Observation Points respectively. To make sure, that al= l > packets passed the same sequence of Observation Points you have to incl= ude > an (yet to be defined) I.E. "observationPointID" as a Flow Key in each > Observation Group. >=20 > BTW.: It's possible that a Flow has the same observationPointID in > different Observation Groups. For example if your Flow contains two > Observation Groups, corresponding to Observation Points at the ingress = and > egress interface, you could have Flows where ingress and egress interfa= ce > and therefore the observationPointID is the same (e.g. after some NAT). >=20 > The next question is: what is a good way to define these groups? Here a= re > just two ideas: >=20 > - my first idea, which I descibed in an former mail, was to define > "Combined Templates", which are a ordered list of other Templates. Each > Template in the Combined Template represents an Observation Group. The > reports for Combined Templates are just normal reports with all the Fie= lds > of all the listed Templates concatenated. The disadvantage is, that a > change of IPFIX-PROTO is necessary. >=20 > - another idea is to define a special separator I.E. with length 0, lik= e > "newObservationGroup". This pseudo-field separates the Fields in the > Template into different Observation Groups. In the reports they don't > appear, but the collector has the template and knows where to split. He= re > no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very simila= r=20 > idea) >=20 > I think this concept is a superset of the proposals of J=FCrgen and Ben= oit. > Instead of using post-I.E.s Benoit could use Templates like this (using > the second grouping-mechanism): >=20 > > [...different Fields...] > > > ** > >=20 > The DSCP field in the second ObservationGroup is the same as his postDS= CP > field. >=20 > J=FCrgen would do it maybe like this: >=20 > > ** > > > [...different Fields...] > >=20 > instead of using an preDestinationIPv4Address Field. >=20 > Why do I like this concept: >=20 > - it includes all the possibilities of the other solutions. >=20 > - you can have as many Observation Groups as you want. (I have an > VPN-Relay here, where I will need 3 Observation Groups, which is not > possible with the pre-/post- solutions.) >=20 > - it is always clear, which fields derive from the same Observation Poi= nts > (same packet state). This is especially true for the counter Fields! Yo= u > can have even the same counter in different Observation Groups, if you > expect the packet size to be changed. >=20 > - you don't need any post-/pre- variants of the I.E.s You just need the > newObservationGroup I.E.. The observationPointID is a good idea anyway,= I > think. >=20 > - you don't need complicated semantics, you just report an ordered > sequence of packet states. (And that's all you know, in fact.) >=20 > I'm not really sure, but I think, that the in- and out- counters also g= et > obsolete then. Wouldn't it be the same as having a counter in the first > and last Observation Group? >=20 > A side note: I think a packet-altering instance - like a NAT process - > which is reporting information to the metering process, should always b= e > seen as _two_ observation points, one before and one after the change. >=20 > Anyway, this is my "work in progress" idea. I hope I could present this > quite complex object in an understandable manner. Now tell me, why it i= s a > bad idea. :-) >=20 >=20 > Cheers, >=20 > Sven >=20 -- 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 Dec 16 12:18:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJDU-0004mI-O2 for ipfix-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:18:00 -0500 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 MAA17597 for ; Fri, 16 Dec 2005 12:17:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EnJ0r-0004NH-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Dec 2005 11:04:57 -0600 Received: from serv-80-156.sernet.de ([193.175.80.156] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EnJ0q-0004Mx-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Dec 2005 11:04:56 -0600 Received: from dslc-082-082-065-229.pools.arcor-ip.net ([82.82.65.229] helo=[192.168.0.3]) by mail.anderson.de with esmtpa (Exim 4.51) id 1EnJ0o-0003PB-HN; Fri, 16 Dec 2005 18:04:54 +0100 Message-ID: <43A2F3BD.9070804@CS.Uni-Goettingen.DE> Date: Fri, 16 Dec 2005 18:05:01 +0100 From: Sven Anderson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Andrew Johnson CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements in a template -> proposed IPFIX text References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE> <43A2E65E.5020800@cisco.com> In-Reply-To: <43A2E65E.5020800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Andrew, Andrew Johnson schrieb: > You are trying to solve the issue of building a flow record with element > captured from different observation points. The problem with using the > same I.E.s for the same field but seen in different places is that you > can't tell which entry in the record applies to which field. Even adding > an order dependence doesn't solve this issue because there is no > requirement to put all versions of the element in the record. This is > detailed in your proposal but your solution is quite a complex addition > to the protocol. As long as an observation point can be an superset of other observation points, as it is defined at the moment, all fields are amiguous, also if you use the I.E. only once. > This is the issue Benoit's proposal is an attempt to solve. For example > a classification routines may classify a packet as classes 1, 10 and 15 > similtaneously because these classes have independent properties. In > this example order may not seem important, but if you want to match the > classes with some statistics about each class then making it order > dependent allows the order of each to be alligned. I agree in the case of you example. This is another situation, as these special fields can have different values even in an atomic observation point. But Benoits example of IPv4 in IPv4 is an case, where I would say, it's an case of two observation points, before and after unwrapping. That's why I think it matches to my proposal. Don't get me wrong, I support Benoits proposal, i just would go a little bit further. If there are multiple I.E.s allowed, is it so much more complexity to include an 0-length I.E. for separation? Maybe I don't have enough experience to overview the implications. As I'm quite new to the IETF-community: is this a typical situation, where I should initiate an draft for an IPFIX extension? Or should I just shut up? ;-) Cheers, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- 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 giga_b@hotmail.com Sun Dec 18 01:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ens3i-0006qT-8S for ipfix-archive@megatron.ietf.org; Sun, 18 Dec 2005 01:30:14 -0500 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 BAA28710 for ; Sun, 18 Dec 2005 01:29:11 -0500 (EST) Received: from maile.online.ge ([213.157.196.85]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EnreZ-0003xO-00 for ipfix-list@mil.doit.wisc.edu; Sun, 18 Dec 2005 00:04:15 -0600 Received: by maile.online.ge (Postfix, from userid 1004) id 9E1422DD2D4; Sun, 18 Dec 2005 10:03:20 +0400 (GET) Received: from SP (unknown [213.157.192.137]) by maile.online.ge (Postfix) with ESMTP id 5C7E82DA3B5 for ; Sun, 18 Dec 2005 10:00:29 +0400 (GET) From: "submit-pacher.com" Subject: HOTMAIL on your mobile phone To: ipfix-list@mil.doit.wisc.edu Content-Type: text/html; charset="windows-1252" Reply-To: giga_b@hotmail.com Date: Sun, 18 Dec 2005 10:00:33 +0400 X-Priority: 3 Message-Id: <20051218060029.5C7E82DA3B5@maile.online.ge>

Free access to Hotmail inbox from your mobile phone:

View list of messages;
Read messages;
Replay messages;
Send messages.

http://www.submit-packer.com

From owsqg@chrissymoran.com Sun Dec 18 10:41:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo0fW-0002Z7-NY for ipfix-archive@megatron.ietf.org; Sun, 18 Dec 2005 10:41:50 -0500 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 KAA23240 for ; Sun, 18 Dec 2005 10:40:48 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Eo0FQ-0007Xe-00 for ipfix-list@mil.doit.wisc.edu; Sun, 18 Dec 2005 09:14:52 -0600 Received: from 66-190-112-048.static.chtn.wv.charter.com ([66.190.112.48]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id jBIFEpaj009337 for ; Sun, 18 Dec 2005 09:14:52 -0600 Received: from mailadmin.safeserver.com ([164.198.28.49] "HELO mail08.emailcourrier.com" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by mail.kt.com with SMTP id hsJigRPpRQDsgw2; Sun, 18 Dec 2005 10:14:47 -0500 Reply-To: "Denver" From: "Denver" To: ipfix-list@mil.doit.wisc.edu Date: Sun, 18 Dec 2005 10:14:47 -0500 X-Mailer: The Bat! (v3.62.14) Message-ID: Subject: see me now MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-----=1402_11K6838T665.8326g" X-Priority: 3 X-MSMail-Priority: Normal -------=1402_11K6838T665.8326g Content-Type: text/html; Content-Transfer-Encoding: quoted-printable If you ca= n't see the picture click here

3D"i`ll

You may unsubscribe here -------=1402_11K6838T665.8326g Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable -------=1402_11K6838T665.8326g-- From zwilling@tiho.com Mon Dec 19 04:46:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoHbY-00049m-1G for ipfix-archive@megatron.ietf.org; Mon, 19 Dec 2005 04:46:52 -0500 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 EAA16184 for ; Mon, 19 Dec 2005 04:45:49 -0500 (EST) Received: from [222.236.224.197] (helo=tiho.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1EoH9t-0002Fi-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Dec 2005 03:18:18 -0600 From: "Zona Zwilling" To: "Redd Falgoust" Message-ID: <000001c6047d$22000e90$d23ba8c0@floriated> Subject: Re: unconditional adapt Date: Mon, 19 Dec 2005 04:18:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60453.392A0690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?222.236.224.197 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60453.392A0690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.experave.com =20 A V C V P M S X L m i i A r e o a e b A A L o r m n v i G L i p i a a i e R i U e d =20 x t n A S M c i =20 =20 r =20 =20 =20 =20 i a =20 =20 a =20 =20 =20 =20 a =20 =20 =20 =20 $6 $6 $9 $8 $6 $9 $7 $1 $9 8.00 9.95 9.95 5.45 4.95 9.95 5.95 23.45 9.95 =20 =20 =20 Journal. Dear Old Buddy Carlos: Boy, have I got news for you. Dont chortle, Jason, its not inconceivable. Your friend Alex could find a way. His gimp doesnt affect that head of his. I believe the fancy word is serpentine. Which is why if he hasnt tried it theres a reason. I guess I cant argue with that. ... So lets go to work, Brer Rabbit. What did you have in mind? Cactus led the way through a wide archway toward a door at the rear of a worn out living room replete with ancient furniture and yellowed antimacassars. My studio isnt as elegant as it was but all the equipments there. You see, Im sort of semi-retired. My financial planners worked out a hell of a retirement program with great tax advantages, so the pressures not so great. Youre only incredible, said Bourne. ------=_NextPart_000_0001_01C60453.392A0690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.experave.com

A
V
C
V
P
M
S
X
L

m
i
i
A
r
e
o
a
e

b
A
A
L
o
r
m
n
v

i
G
L
i
p
i
a
a
i

e
R
i
U
e
d

x
t

n
A
S
M
c
i

r

i
a

=
a

a

= ;

$6
$6
$9
$8
$6
= $9
$7
$1
$9

8.00
9.95
9.95
5.45
4.95
9.95
5.95
23.4= 5
9.95

Journal. Dear Old Buddy Carlos: Boy, have I got news for you.=20 Dont chortle, Jason, its not inconceivable. Your friend Alex could find a way. His gimp doesnt affect that head of his. I believe the fancy word is serpentine. Which is why if he hasnt tried it theres a reason. I guess I cant argue with that. ... So lets go to work, Brer Rabbit. What did you have in mind? Cactus led the way through a wide archway toward a door at the rear of a worn out living room replete with ancient furniture and yellowed antimacassars. My studio isnt as elegant as it was but all the equipments there. You see, Im sort of semi-retired. My financial planners worked out a hell of a retirement program with great tax advantages, so the pressures not so great. Youre only incredible, said Bourne.

------=_NextPart_000_0001_01C60453.392A0690-- From majordomo@mil.doit.wisc.edu Mon Dec 19 09:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoM7U-0004NL-Sd for ipfix-archive@megatron.ietf.org; Mon, 19 Dec 2005 09:36:09 -0500 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 JAA23084 for ; Mon, 19 Dec 2005 09:35:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EoLxT-0006T1-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Dec 2005 08:25:47 -0600 Received: from bantam.cisco.com ([64.102.19.199] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EoLxS-0006Sw-00 for ipfix@net.doit.wisc.edu; Mon, 19 Dec 2005 08:25:46 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJEPia09077; Mon, 19 Dec 2005 09:25:44 -0500 (EST) Received: from [10.61.64.51] (ams-clip-vpn-dhcp51.cisco.com [10.61.64.51]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJEPhC14688; Mon, 19 Dec 2005 15:25:43 +0100 (CET) Message-ID: <43A6C2E6.5000706@cisco.com> Date: Mon, 19 Dec 2005 15:25:42 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Thomas Dietz , "Andrew Johnson" CC: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Floating point numbers in IPFIX Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Andrew, Thomas, > Find my comments inline. > > -- > Thomas Dietz > Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Andrew Johnson > > Sent: Thursday, December 15, 2005 6:47 PM > > To: ipfix@net.doit.wisc.edu > > Subject: [ipfix] Floating point numbers in IPFIX > > > > Hi all > > > > In the IPFIX protocol draft, section 3.1.5, we have a definition > > of a floating point number. This definition allows export of > > floating point numbers using the 32-bit format as specified in > > IEEE.754. This same standard also allows floating point numbers > > to be defined in a 64-bit format. > > > > I would like to see a float64 type added and the abiltity to > > send float64 fields using float32 using a variation of the > > Reduced Size Encoding as used with the integers. > > Fine with me if all the others agree. > I think it makes sense. > > > > I would like to propose that at the next editing phase we add > > the following type to the information model: > > > > 3.1.6. float64 > > > > The type "float64" corresponds to an IEEE double-precision 64-bit > > floating point type as defined in [IEEE.754.1985]. > > > > I guess the definition is ok. > > > > > In the protocol, section 6.2 could also be expanded to encompase > > the Reduced Size encoding for the floating point types. i.e. > > > > 6.2 Reduced Size Encoding of Integer Types > > Note the section says "Integer Types", so I would propose to have a seperate > section. This would also make clear that the reduzed size encoding of floats > is different than those of integers. > Ok. > > > > Information Elements containing integer, float, string, and ... > > ^^^^^^^ > > octetarray types in the information model MAY be encoded using fewer > > octets than those implied by their type in the information model > > definition [IPFIX-INFO], ... > > > > ... > > > > If reduced sizing is used, it MUST only be applied to the following > > integer types: unsigned64, signed64, unsigned32, signed32, > > unsigned16, signed16. ... > > > > @@[NOTE: the signed types above are not in the data model]@@ > So we would need some new definitions in the information model draft for signed64, signed32, and signed16, right? > > > > Reduced sizing can also be used on the float64 and float32. The > > float32 not only has a reduced number range, but due to the > > smaller mantissa is also less precise. > > > > The reduced size encoding MUST NOT be applied to ... > > I think we still need to elaborate this a little bit more, because we have > to explain how mantissa and exponent can be mapped from float64 to float32. > As always, feel free to propose some text. Regards, Benoit. > Regards, > > Thomas > > > > > > > Andrew > > > > > > -- > > 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/ > > > Dear Andrew, -- 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 Dec 19 09:57:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMSJ-0000JL-UH for ipfix-archive@megatron.ietf.org; Mon, 19 Dec 2005 09:57:39 -0500 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 JAA26256 for ; Mon, 19 Dec 2005 09:56:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EoMJv-0001pO-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Dec 2005 08:48:59 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EoMJu-0001pD-00 for ipfix@net.doit.wisc.edu; Mon, 19 Dec 2005 08:48:58 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2005 15:48:52 +0100 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 jBJEmnFZ026641; Mon, 19 Dec 2005 15:48:50 +0100 (MET) Received: from [10.61.81.124] (ams-clip-vpn-dhcp4477.cisco.com [10.61.81.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA12964; Mon, 19 Dec 2005 14:48:48 GMT Message-ID: <43A6C84F.7030600@cisco.com> Date: Mon, 19 Dec 2005 14:48:47 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Floating point numbers in IPFIX References: <43A6C2E6.5000706@cisco.com> In-Reply-To: <43A6C2E6.5000706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > Andrew, Thomas, > >> Find my comments inline. >> >> -- >> Thomas Dietz >> Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany >> >> >> > -----Original Message----- >> > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] >> On Behalf Of Andrew Johnson >> > Sent: Thursday, December 15, 2005 6:47 PM >> > To: ipfix@net.doit.wisc.edu >> > Subject: [ipfix] Floating point numbers in IPFIX >> > > Hi all >> > > In the IPFIX protocol draft, section 3.1.5, we have a definition >> > of a floating point number. This definition allows export of >> > floating point numbers using the 32-bit format as specified in >> > IEEE.754. This same standard also allows floating point numbers >> > to be defined in a 64-bit format. >> > > I would like to see a float64 type added and the abiltity to >> > send float64 fields using float32 using a variation of the >> > Reduced Size Encoding as used with the integers. >> >> Fine with me if all the others agree. >> > > I think it makes sense. > >> > > I would like to propose that at the next editing phase we add >> > the following type to the information model: >> > > 3.1.6. float64 >> > > The type "float64" corresponds to an IEEE double-precision 64-bit >> > floating point type as defined in [IEEE.754.1985]. >> > >> I guess the definition is ok. >> >> > > In the protocol, section 6.2 could also be expanded to encompase >> > the Reduced Size encoding for the floating point types. i.e. >> > > 6.2 Reduced Size Encoding of Integer Types >> Note the section says "Integer Types", so I would propose to have a >> seperate >> section. This would also make clear that the reduzed size encoding of >> floats >> is different than those of integers. >> > > Ok. > >> > > Information Elements containing integer, float, string, and ... >> > ^^^^^^^ >> > octetarray types in the information model MAY be encoded using fewer >> > octets than those implied by their type in the information model >> > definition [IPFIX-INFO], ... >> > > ... >> > > If reduced sizing is used, it MUST only be applied to the >> following > integer types: unsigned64, signed64, unsigned32, >> signed32, > unsigned16, signed16. ... >> > > @@[NOTE: the signed types above are not in the data model]@@ >> > > So we would need some new definitions in the information model draft > for signed64, signed32, and signed16, right? I think that we need the full set of signed types 8/16/32/64 bits >> > > Reduced sizing can also be used on the float64 and float32. The >> > float32 not only has a reduced number range, but due to the >> > smaller mantissa is also less precise. >> > > The reduced size encoding MUST NOT be applied to ... >> >> I think we still need to elaborate this a little bit more, because we >> have >> to explain how mantissa and exponent can be mapped from float64 to >> float32. >> > > As always, feel free to propose some text. Why do we need this? Surely the canonical object is a number, so the conversion is a matter of implementation rather than protocol or object definition. - Stewart > > Regards, Benoit. > >> Regards, >> >> Thomas >> >> > > > Andrew >> > > > -- >> > 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/ >> > Dear Andrew, > > > -- > 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/ > > -- 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 Dec 19 10:04:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMZH-0002qP-DV for ipfix-archive@megatron.ietf.org; Mon, 19 Dec 2005 10:04:51 -0500 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 KAA27325 for ; Mon, 19 Dec 2005 10:03:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EoMUC-000287-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Dec 2005 08:59:36 -0600 Received: from bantam.cisco.com ([64.102.19.199] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EoMUB-000282-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Dec 2005 08:59:35 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJExYT11643; Mon, 19 Dec 2005 09:59:34 -0500 (EST) Received: from [10.61.64.51] (ams-clip-vpn-dhcp51.cisco.com [10.61.64.51]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJExXC25033; Mon, 19 Dec 2005 15:59:33 +0100 (CET) Message-ID: <43A6CAD4.8040907@cisco.com> Date: Mon, 19 Dec 2005 15:59:32 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Sven Anderson CC: Andrew Johnson , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements in a template -> proposed IPFIX text References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE> <43A2E65E.5020800@cisco.com> <43A2F3BD.9070804@CS.Uni-Goettingen.DE> In-Reply-To: <43A2F3BD.9070804@CS.Uni-Goettingen.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sven, > Hi Andrew, > > Andrew Johnson schrieb: >> You are trying to solve the issue of building a flow record with element >> captured from different observation points. The problem with using the >> same I.E.s for the same field but seen in different places is that you >> can't tell which entry in the record applies to which field. Even >> adding >> an order dependence doesn't solve this issue because there is no >> requirement to put all versions of the element in the record. This is >> detailed in your proposal but your solution is quite a complex addition >> to the protocol. > > As long as an observation point can be an superset of other > observation points, as it is defined at the moment, all fields are > amiguous, also if you use the I.E. only once. > >> This is the issue Benoit's proposal is an attempt to solve. For example >> a classification routines may classify a packet as classes 1, 10 and 15 >> similtaneously because these classes have independent properties. In >> this example order may not seem important, but if you want to match the >> classes with some statistics about each class then making it order >> dependent allows the order of each to be alligned. > > I agree in the case of you example. This is another situation, as > these special fields can have different values even in an atomic > observation point. But Benoits example of IPv4 in IPv4 is an case, > where I would say, it's an case of two observation points, before and > after unwrapping. One or two observation points? It really depends how you see this. - one observation point where you observe a single IP-in-IP packet - two observation points: before, and after unwrapping. So, even if your solution is powerful, you must make assumptions about where observation points are. The proposed quick editorial fix proposes a solution without going into the IPFIX device architectural details" Anyway, this is certainly a discussion for IPFIX version 2 :) Regards, Benoit. > That's why I think it matches to my proposal. Don't get me wrong, I > support Benoits proposal, i just would go a little bit further. If > there are multiple I.E.s allowed, is it so much more complexity to > include an 0-length I.E. for separation? Maybe I don't have enough > experience to overview the implications. > > As I'm quite new to the IETF-community: is this a typical situation, > where I should initiate an draft for an IPFIX extension? Or should I > just shut up? ;-) > > > Cheers, > > Sven > -- 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 Dec 19 10:10:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMel-0003wn-6J for ipfix-archive@megatron.ietf.org; Mon, 19 Dec 2005 10:10:31 -0500 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 KAA28005 for ; Mon, 19 Dec 2005 10:09:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EoMSk-00025s-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Dec 2005 08:58:06 -0600 Received: from bantam.cisco.com ([64.102.19.199] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EoMSj-00025n-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Dec 2005 08:58:05 -0600 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJEw3E11509; Mon, 19 Dec 2005 09:58:03 -0500 (EST) Received: from [10.61.64.51] (ams-clip-vpn-dhcp51.cisco.com [10.61.64.51]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJEw0C23565; Mon, 19 Dec 2005 15:58:00 +0100 (CET) Message-ID: <43A6CA78.9080506@cisco.com> Date: Mon, 19 Dec 2005 15:58:00 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Sven Anderson CC: ipfix-protocol@net.doit.wisc.edu, psamp Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements in a template -> proposed IPFIX text References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE> In-Reply-To: <4399B4B2.5060204@CS.Uni-Goettingen.DE> Content-Type: multipart/alternative; boundary="------------030406000303010603060408" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030406000303010603060408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id jBJEw3E11509 Content-Transfer-Encoding: quoted-printable Sven, [sorry for the delay in replying to you] Even if I agree that we will certainly have to solve the issue of=20 exporting structured records in clean way in a future IPFIX version,=20 even if I agree that your proposal is powerful, I was aiming for a quick=20 editorial change in [IPFIX-PROTO]. Let's not forget that the IPFIX=20 drafts are right now under IESG review. Regards, Benoit. > > Benoit Claise wrote: >> I would add: >> >> If an Information Element is required more than once in Template, >> the different occurrences of this Information Element SHOULD follow >> the logical order of their treatments by the Metering Process. >> For example, if a selected packet goes through two hash functions, >> and if the two hash values are sent within a single template, the=20 >> first occurrence of the hash value should belong to the first hash >> function in the Metering Process. For example, when exporting the=20 >> two source IP addresses of an IPv4 in IPv4 packets, the first =20 >> sourceIPv4Address Information Element occurrence should be the IPv4 >> address of the outer header, while the second occurrence should be=20 >> the inner header one. >> >> In section 9 "The Collecting Process's Side", at the very end, I=20 >> would add: >> >> The Collector MUST support the use of Templates containing=20 >> multiple occurrences of >> the similar Information Elements. > > Isn't that quite exactly what I proposed in my mail of 2005/08/04? It=20 > was a long mail I admit, so maybe nobody read it. ;-) That mail is=20 > attached, if somebody now is interested to read it. > > But doesn't make this all the post-/pre- I.E. discussion obsolete?=20 > Wouldn't it be enough just to export two I.E. of the same type? Of=20 > course, with the post-I.E. you have more semantics. But wouldn't it be=20 > better to give this semantics by other means? > > But there are certain amiguities. For instance in your example (IP in=20 > IP), if you also export the packet size (for single packet reports) or=20 > in octet counters in general, is it corresponding to the outer or the=20 > inner packet? That's why I also proposed a kind of separator I.E. with=20 > length 0, which separates different groups of I.E. in the template. =20 > And in each group, every I.E. MUST appear only one time. That way you=20 > always know which I.E. belong together. > > Template example: > > > ** (pseudo I.E. with length 0) > > > That way it's clear, that the counter corresponds to the first packet=20 > state size, which in the IP in IP scenario is the outer packet size. > > J=FCrgen stated to my proposal, that you try to avoid more complex=20 > concepts if possible. But as it seems, it's getting more complex anyway. > > > Cheers, > > Sven > > > -----------------------------------------------------------------------= - > > Subject: > [ipfix-info] Proposal for IFPIX observations at middleboxes > From: > Sven Anderson > Date: > Thu, 04 Aug 2005 19:05:42 +0200 > To: > ipfix-info@net.doit.wisc.edu > > To: > ipfix-info@net.doit.wisc.edu > > > Hi all, > > I will try to explain again my idea for reporting flows from middleboxe= s > as clear and short(?) as possible: > > When IP packets travel through a middlebox, their properties may change. > Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or > replication (multicasting). That means, that if an Observation Domain > includes several Observation Points, and the same packet passes more th= an > one of these Observation Points, some properties can be ambiguous in th= is > Observation Domain. > > You could solve this by saying, that every propery of a flow-report > has to derive from the same observation point. But this would be > restrictive. Sometimes it is desirable, that you can classify a single > Flow by properties, that derive from _different_ Observation Points. Fo= r > example a flow-definition that includes the source IP address before an= d > after a NAT, or the DSCP at three different Observation Points (before > ingress linecard, after ingress linecard, after egress linecard). > > To realise this, you need a way to use certain properties more than one > time in a flow-template, to correspond to the different states at the > different Observation Points. One way to do this, is the introduction o= f > additional post- I.E.s, which then correspond to the first and the last > Observation Point in the Observation Domain. But this is a restriction = to > two special Observation Points, and the second example from above is no= t > solvable with this approach. > > A more general solution would be to allow the use of the same I.E. more > than one time in the same template. The order of the multiple I.E.s > corresponds to the different observations as the packet travels through > the middlebox. The problem here is, that you cannot tell then, to=20 > which of > the different observations the _singular_ I.E.s belong to. > > To solve this, you need a possibility to build goups of I.E.s in the > Template: The I.E. values in one "Observation Group" always derive from > the same Observation Point (for each packet!). The Observation Groups a= re > ordered accordingly to the sequence of Observation Points the packet is > passing. Of course there are also fields which don't depend on the > Observation Point and can be reported in any Observation Group, like > ingressInterface (not egress!), as it is always the same, no matter whe= re > in the middlebox the packet is observed. (You may say, that these field= s > _have_ to be reported in the first group then, if this is an advantage.= ) > > Important to note is, that packets of a Flow defined by (for example) t= wo > Observation Groups don't necessarily pass the same sequence of two > Observation Points. They just share the same Flow poperties at the thei= r > first and second Observation Points respectively. To make sure, that al= l > packets passed the same sequence of Observation Points you have to=20 > include > an (yet to be defined) I.E. "observationPointID" as a Flow Key in each > Observation Group. > > BTW.: It's possible that a Flow has the same observationPointID in > different Observation Groups. For example if your Flow contains two > Observation Groups, corresponding to Observation Points at the ingress=20 > and > egress interface, you could have Flows where ingress and egress interfa= ce > and therefore the observationPointID is the same (e.g. after some NAT). > > The next question is: what is a good way to define these groups? Here a= re > just two ideas: > > - my first idea, which I descibed in an former mail, was to define > "Combined Templates", which are a ordered list of other Templates. Each > Template in the Combined Template represents an Observation Group. The > reports for Combined Templates are just normal reports with all the=20 > Fields > of all the listed Templates concatenated. The disadvantage is, that a > change of IPFIX-PROTO is necessary. > > - another idea is to define a special separator I.E. with length 0, lik= e > "newObservationGroup". This pseudo-field separates the Fields in the > Template into different Observation Groups. In the reports they don't > appear, but the collector has the template and knows where to split. He= re > no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very=20 > similar idea) > > I think this concept is a superset of the proposals of J=FCrgen and Ben= oit. > Instead of using post-I.E.s Benoit could use Templates like this (using > the second grouping-mechanism): > > > [...different Fields...] > > > ** > > > The DSCP field in the second ObservationGroup is the same as his postDS= CP > field. > > J=FCrgen would do it maybe like this: > > > ** > > > [...different Fields...] > > > instead of using an preDestinationIPv4Address Field. > > Why do I like this concept: > > - it includes all the possibilities of the other solutions. > > - you can have as many Observation Groups as you want. (I have an > VPN-Relay here, where I will need 3 Observation Groups, which is not > possible with the pre-/post- solutions.) > > - it is always clear, which fields derive from the same Observation=20 > Points > (same packet state). This is especially true for the counter Fields! Yo= u > can have even the same counter in different Observation Groups, if you > expect the packet size to be changed. > > - you don't need any post-/pre- variants of the I.E.s You just need the > newObservationGroup I.E.. The observationPointID is a good idea anyway,= I > think. > > - you don't need complicated semantics, you just report an ordered > sequence of packet states. (And that's all you know, in fact.) > > I'm not really sure, but I think, that the in- and out- counters also g= et > obsolete then. Wouldn't it be the same as having a counter in the first > and last Observation Group? > > A side note: I think a packet-altering instance - like a NAT process - > which is reporting information to the metering process, should always b= e > seen as _two_ observation points, one before and one after the change. > > Anyway, this is my "work in progress" idea. I hope I could present this > quite complex object in an understandable manner. Now tell me, why it=20 > is a > bad idea. :-) > > > Cheers, > > Sven > --------------030406000303010603060408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sven,

[sorry for the delay in replying to you]

Even if I agree that we will certainly have to solve the issue of exporting structured records in clean way in a future IPFIX version, even if I agree that your proposal is powerful, I was aiming for a quick editorial change in [IPFIX-PROTO]. Let's not forget that the IPFIX drafts are right now under IESG review.

Regards, Benoit.

Benoit Claise wrote:

I would add:

   If an Information Element is required more than once in Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process.
   For example, if a selected packet goes through two hash functions,
   and if the two hash values are sent within a single template, the    first occurrence of the hash value should belong to the first hash
   function in the Metering Process. For example, when exporting the    two source IP addresses of an IPv4 in IPv4 packets, the first    sourceIPv4Address Information Element occurrence should be the IPv4
   address of the outer header, while the second occurrence should be    the inner header one.

In section 9 "The Collecting Process's Side", at the very end, I would add:

     The Collector MUST support the use of Templates containing multiple occurrences of
     the similar Information Elements.

Isn't that quite exactly what I proposed in my mail of 2005/08/04? It was a long mail I admit, so maybe nobody read it. ;-) That mail is attached, if somebody now is interested to read it.

But doesn't make this all the post-/pre- I.E. discussion obsolete? Wouldn't it be enough just to export two I.E. of the same type? Of course, with the post-I.E. you have more semantics. But wouldn't it be better to give this semantics by other means?

But there are certain amiguities. For instance in your example (IP in IP), if you also export the packet size (for single packet reports) or in octet counters in general, is it corresponding to the outer or the inner packet? That's why I also proposed a kind of separator I.E. with length 0, which separates different groups of I.E. in the template. And in each group, every I.E. MUST appear only one time. That way you always know which I.E. belong together.

Template example:
<sourceIPv4Address>
<octetDeltaCount>
*<newObservationGroup>* (pseudo I.E. with length 0)
<sourceIPv4Address>

That way it's clear, that the counter corresponds to the first packet state size, which in the IP in IP scenario is the outer packet size.

Jürgen stated to my proposal, that you try to avoid more complex concepts if possible. But as it seems, it's getting more complex anyway.

Cheers,

Sven

Subject:
[ipfix-info] Proposal for IFPIX observations at middleboxes

From:
Sven Anderson <Sven.Anderson@CS.Uni-Goettingen.DE>

Date:
Thu, 04 Aug 2005 19:05:42 +0200

To:
ipfix-info@net.doit.wisc.edu

To:
ipfix-info@net.doit.wisc.edu

Hi all,

I will try to explain again my idea for reporting flows from middleboxes
as clear and short(?) as possible:

When IP packets travel through a middlebox, their properties may change.
Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or
replication (multicasting). That means, that if an Observation Domain
includes several Observation Points, and the same packet passes more than
one of these Observation Points, some properties can be ambiguous in this
Observation Domain.

You could solve this by saying, that every propery of a flow-report
has to derive from the same observation point. But this would be
restrictive. Sometimes it is desirable, that you can classify a single
Flow by properties, that derive from _different_ Observation Points. For
example a flow-definition that includes the source IP address before and
after a NAT, or the DSCP at three different Observation Points (before
ingress linecard, after ingress linecard, after egress linecard).

To realise this, you need a way to use certain properties more than one
time in a flow-template, to correspond to the different states at the
different Observation Points. One way to do this, is the introduction of
additional post- I.E.s, which then correspond to the first and the last
Observation Point in the Observation Domain. But this is a restriction to
two special Observation Points, and the second example from above is not
solvable with this approach.

A more general solution would be to allow the use of the same I.E. more
than one time in the same template. The order of the multiple I.E.s
corresponds to the different observations as the packet travels through
the middlebox. The problem here is, that you cannot tell then, to which of
the different observations the _singular_ I.E.s belong to.

To solve this, you need a possibility to build goups of I.E.s in the
Template: The I.E. values in one "Observation Group" always derive from
the same Observation Point (for each packet!). The Observation Groups are
ordered accordingly to the sequence of Observation Points the packet is
passing. Of course there are also fields which don't depend on the
Observation Point and can be reported in any Observation Group, like
ingressInterface (not egress!), as it is always the same, no matter where
in the middlebox the packet is observed. (You may say, that these fields
_have_ to be reported in the first group then, if this is an advantage.)

Important to note is, that packets of a Flow defined by (for example) two
Observation Groups don't necessarily pass the same sequence of two
Observation Points. They just share the same Flow poperties at the their
first and second Observation Points respectively. To make sure, that all
packets passed the same sequence of Observation Points you have to include
an (yet to be defined) I.E. "observationPointID" as a Flow Key in each
Observation Group.

BTW.: It's possible that a Flow has the same observationPointID in
different Observation Groups. For example if your Flow contains two
Observation Groups, corresponding to Observation Points at the ingress and
egress interface, you could have Flows where ingress and egress interface
and therefore the observationPointID is the same (e.g. after some NAT).

The next question is: what is a good way to define these groups? Here are
just two ideas:

- my first idea, which I descibed in an former mail, was to define
"Combined Templates", which are a ordered list of other Templates. Each
Template in the Combined Template represents an Observation Group. The
reports for Combined Templates are just normal reports with all the Fields
of all the listed Templates concatenated. The disadvantage is, that a
change of IPFIX-PROTO is necessary.

- another idea is to define a special separator I.E. with length 0, like
"newObservationGroup". This pseudo-field separates the Fields in the
Template into different Observation Groups. In the reports they don't
appear, but the collector has the template and knows where to split. Here
no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very similar idea)

I think this concept is a superset of the proposals of Jürgen and Benoit.
Instead of using post-I.E.s Benoit could use Templates like this (using
the second grouping-mechanism):

<sourceIPv4Address>
[...different Fields...]
<octetDeltaCount>
<DSCP>
*<newObservationGroup>*
<DSCP>

The DSCP field in the second ObservationGroup is the same as his postDSCP
field.

Jürgen would do it maybe like this:

<destinationIPv4Address>
*<newObservationGroup>*
<sourceIPv4Address>
<destinationIPv4Address>
[...different Fields...]
<octetDeltaCount>

instead of using an preDestinationIPv4Address Field.

Why do I like this concept:

- it includes all the possibilities of the other solutions.

- you can have as many Observation Groups as you want. (I have an
VPN-Relay here, where I will need 3 Observation Groups, which is not
possible with the pre-/post- solutions.)

- it is always clear, which fields derive from the same Observation Points
(same packet state). This is especially true for the counter Fields! You
can have even the same counter in different Observation Groups, if you
expect the packet size to be changed.

- you don't need any post-/pre- variants of the I.E.s You just need the
newObservationGroup I.E.. The observationPointID is a good idea anyway, I
think.

- you don't need complicated semantics, you just report an ordered
sequence of packet states. (And that's all you know, in fact.)

I'm not really sure, but I think, that the in- and out- counters also get
obsolete then. Wouldn't it be the same as having a counter in the first
and last Observation Group?

A side note: I think a packet-altering instance - like a NAT process -
which is reporting information to the metering process, should always be
seen as _two_ observation points, one before and one after the change.

Anyway, this is my "work in progress" idea. I hope I could present this
quite complex object in an understandable manner. Now tell me, why it is a
bad idea. :-)

Cheers,

Sven

--------------030406000303010603060408-- -- 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 amindaemcgibbon@uofl.edu Wed Dec 21 07:01:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep2fJ-0004DA-G6 for ipfix-archive@megatron.ietf.org; Wed, 21 Dec 2005 07:01:53 -0500 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 HAA01045 for ; Wed, 21 Dec 2005 07:00:49 -0500 (EST) Received: from [212.98.174.171] (helo=uofl.edu) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Ep2JY-0001bq-00 for ipfix-list@mil.doit.wisc.edu; Wed, 21 Dec 2005 05:39:24 -0600 Message-ID: <000001c60623$2bee5720$e24aa8c0@diligence> Reply-To: "Aminda Mcgibbon" From: "Aminda Mcgibbon" To: "Bartel Eggleton" Subject: Re: angelic successive Date: Wed, 21 Dec 2005 06:39:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C605F9.431AC020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?212.98.174.171 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C605F9.431AC020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://fishili.witahobia.com =20 V A L V X S C M P AL mb ev IA an om IA er ro IU ie it GR ax a=20 LI id pe M n ra A =20 =20 S ia cia $85 $68 $99 $69 $12 $75 $99 $99 $64 .45 00 95 95 3.45 95 95 95 95 =20 =20 I was in a hurry, it goes with running for your life. Ive already explained to Government House that youre an old friend of my brother-in-law. Good. Very good. What will you do now, Dimitri? asked Marie. My options are limited, Im afraid. Our Russian bear not only has more claws than a centipede has legs, shes also computerized with a global network. I shall have to remain buried for quite some time while I construct another existence. From birth, of course. Krupkin turned to the owner of Tranquility Inn. Would it be possible to lease one of these lovely cottages, Mr. St. Jacques? After what you did for David and my sister, dont give it a second thought. This house is your house, Mr. Krupkin, all of it. ------=_NextPart_000_0001_01C605F9.431AC020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://fishili.witahobia.com

V
A
L
V
X
S
C
M
P AL
mb
ev
IA
an
om
IA
er
ro IU
ie
it
GR
ax
a
LI
id
pe M
n
ra
A

S
ia
cia $85
$68
$99
$69
$12
&n= bsp;$75
$99
$99
$64 .45
.00
.95
.95
3.45
.95
.95
.95
.95=

I was in a hurry, it goes with running for your life. Ive already explained to Government House that youre an old friend of my brother-in-law. Good. Very good. What will you do now, Dimitri? asked Marie. My options are limited, Im afraid. Our Russian bear not only has more claws than a centipede has legs, shes also computerized with a global network. I shall have to remain buried for quite some time while I construct another existence. From birth, of course. Krupkin turned to the owner of Tranquility Inn. Would it be possible to lease one of these lovely cottages, Mr. St. Jacques? After what you did for David and my sister, dont give it a second thought. This house is your house, Mr. Krupkin, all of = it.

------=_NextPart_000_0001_01C605F9.431AC020-- From majordomo@mil.doit.wisc.edu Thu Dec 22 06:27:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpObi-0005Fn-UU for ipfix-archive@megatron.ietf.org; Thu, 22 Dec 2005 06:27:41 -0500 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 GAA28210 for ; Thu, 22 Dec 2005 06:26:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EpOGQ-0003qv-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Dec 2005 05:05:38 -0600 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EpOGN-0003qk-00 for ipfix@net.doit.wisc.edu; Thu, 22 Dec 2005 05:05:35 -0600 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id MAA08968; Thu, 22 Dec 2005 12:05:28 +0100 (MET) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id 24EA3CC183; Thu, 22 Dec 2005 12:05:28 +0100 (CET) Message-ID: <43AA8877.4080702@informatik.uni-erlangen.de> Date: Thu, 22 Dec 2005 12:05:27 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg, Germany User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Cc: Gerhard Muenz , Christoph Sommer Subject: [ipfix] Discussion on draft-dressler-ipfix-aggregation-02.txt X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/mixed; boundary="------------000907070707070809040202" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------000907070707070809040202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everybody, at the Paris IETF, we presented and discussed the standardization of aggregation methodology and techniques for flow records based on the -01 version of our draft. Yesterday, we finished the -02 version (see below). We think that this version is almost ready to be submitted for publication as an Informational RFC. We kindly ask you for final comments on the draft. Thank you. Kind regards, Falko. -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ --------------000907070707070809040202 Content-Type: text/html; charset=UTF-8; name="draft-dressler-ipfix-aggregation-02.html" Content-Disposition: inline; filename="draft-dressler-ipfix-aggregation-02.html" Content-Transfer-Encoding: 7bit IPFIX Aggregation

TOC

Network Working Group	F. Dressler
Internet-Draft	C. Sommer
Expires: June 23, 2006	University of Erlangen
	G. Muenz
	University of Tuebingen
	December 20, 2005

IPFIX Aggregation

<draft-dressler-ipfix-aggregation-02.txt>

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 BCP 79.

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 obsoleted 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.

This Internet-Draft will expire on June 23, 2006.

Copyright Notice

Abstract

IPFIX Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX exporters) and analyzers (IPFIX collectors). Using aggregation techniques, measurement information of multiple similar flows is aggregated into one compound meta-flow record. Subsets of flows eligible for aggregation, as well as the degree of similarity, can be customized using aggregation rules.

To ensure efficient communication of both aggregated flows and the aggregation rules used, the IPFIX Protocol and IPFIX Information Model are slightly extended to allow for two new abstract data types and a new type of template set.

1. Introduction
2. Terminology
3. Architecture
4. Methodology
    4.1 Aggregation Rules
    4.2 Field Modifiers
    4.3 Patterns and Common Properties
    4.4 Rule Semantics
    4.5 Example
5. IPFIX Extensions
    5.1 ipv4Network
    5.2 portRanges
    5.3 Data Template
    5.4 Example
6. Application Examples
    6.1 Charging
    6.2 Intrusion Detection
7. Security considerations
8. References
    8.1 Normative References
    8.2 Informative References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements

TOC

1. Introduction

Flow measurement in high-speed large-scale networks easily produces a huge amount of data that can not be handled by a single IPFIX collector or analyzer. Also, many applications processing flow measurement data do not require detailed flow-level information but only information about flow aggregates, where the quality and level of flow aggregation is very application-specific. This document presents a flexible flow aggregation scheme that helps both, reducing the number and size of exported flow records and adapting the transmitted measurement information to the requirements of the application. These goals are achieved by discarding unneeded measurement information and merging multiple individual flows into a smaller number of compound meta-flows before the remaining measurement data is exported to the analyzer. The following sections show how to design and implement IPFIX aggregators and introduce appropriate extensions to the IPFIX protocol.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

TOC

2. Terminology

Apart from the basic terms as defined in [RFC3917] (Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export,” October 2004.), [I-D.ietf-ipfix-protocol] (Claise, B., “IPFIX Protocol Specifications,” September 2005.), and [I-D.ietf-ipfix-architecture] (Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, “Architecture for IP Flow Information Export,” August 2005.), the following terms are used within this document:

Meta-flow:

A meta-flow is an aggregate of individual flows.

Meta-flow record:

A meta-flow record contains the measurement data of a meta-flow. It MAY contain the total count of all packets that belong to the same meta-flow and were observed within a given time interval. Flow properties that were discarded during flow aggregation are no longer contained in the meta-flow record.

Aggregation rule:

An aggregation rule defines the properties of a meta-flow and the content of the corresponding meta-flow record. Optionally, a set of common properties MAY be specified in order to restrict the applicability of the rule to those flows that show certain patterns.

Data Template:

A Data Template, as proposed in Section 5.3 (Data Template), SHOULD be used to define the structure of the meta-flow record and to inform the analyzer about the applied aggregation rule and the common properties.

TOC

3. Architecture

Aggregation of measurement data may take place at two possible stages:

An internal aggregator, as depicted in Figure 1 (Internal Aggregation), is implemented as a process running in an IPFIX enabled device. It aggregates flow data generated by multiple metering processes and exports them as meta-flow records. In practical implementations, metering and aggregation MAY be performed in a single step in order to reduce the number of retained state information.

+------------------------------------------+     +--------------+
| IPFIX-enabled device       .---.   .---. |     |              |
| .--------------------.     | A |   |   | | .-->|   Analyzer   |
| | Metering Process 1 |-.   | g |   | E | | |   |              |
| `--------------------' |   | g |   | x | | |   +--------------+
|                        |   | r |   | p |---'
|           .            '-->| e |   | o | |
|           .                | g |-->| r | |
|           .            .-->| a |   | t |---.
|                        |   | t |   | e | | |   +--------------+
| .--------------------. |   | o |   | r | | |   |              |
| | Metering Process N |-'   | r |   |   | | '-->| Concentrator |
| `--------------------'     `---'   `---' |     |              |
+------------------------------------------+     +--------------+

Figure 1: Internal Aggregation

An external aggregator, called concentrator in IPFIX terminology, may be used where the deployed monitoring devices cannot be modified to incorporate an internal aggregator. Furthermore, concentrators enable cascaded, multi-level aggregation of flow information. As shown in Figure 2 (External Aggregation), a concentrator receives flow records from monitoring devices and/or lower-level concentrators and exports the aggregated meta-flow information to higher-level concentrators and/or analyzers.

+--------------+    +-----------------------+     +--------------+
|              |    | Concentrator          |     |              |
| Concentrator |-.  | .---.   .---.   .---. | .-->|   Analyzer   |
|              | |  | | C |   | A |   |   | | |   |              |
+--------------+ |  | | o |   | g |   | E | | |   +--------------+
	                 '--->| l |   | g |   | x |---'
	                    | | l |   | r |   | p | |
	                    | | e |-->| e |-->| o | |
	                    | | c |   | g |   | r | |
	                 .--->| t |   | a |   | t |---.
+--------------+ |  | | o |   | t |   | e | | |   +--------------+
|              | |  | | r |   | o |   | r | | |   |              |
| IPFIX device |-'  | |   |   | r |   |   | | '-->| Concentrator |
|              |    | `---'   `---'   `---' |     |              |
+--------------+    +-----------------------+     +--------------+

Figure 2: External Aggregation

TOC

4. Methodology

4.1 Aggregation Rules

Regarding the configuration of the aggregator, a rule-based approach is proposed. A list of user-defined aggregation rules is supplied to the aggregator. An aggregation rule consists of multiple aggregation instructions, one for each IPFIX field that is to be considered. An aggregation instruction comprises the following elements:

The IPFIX field the aggregation instruction refers to (e.g. destinationIPv4Address). Only flows that contain the field mentioned will be considered for aggregation in the meta-flow.
One of the field modifiers "discard", "keep", "mask", or "aggregate" that specifies how this field is treated by the aggregator and whether it is included in the meta-flow record or not.
An OPTIONAL pattern for this field that restricts the aggregation to those flows that match the given value(s) (e.g. 10.10.0.0/16). Only flows that match all patterns of the rule will be aggregated in the meta-flow.

With this definition of aggregation instructions each rule unambiguously defines the content of the meta-flow record as well as the template to export the meta-flow information. If a field is present in the meta-flow record and how it is encoded depends on the field modifier. This behavior is explained in Section 4.2 (Field Modifiers). Fields that do not appear in any of the aggregation instructions are not part of the meta-flow record. The usage of patterns in order to define common properties is explained in Section 4.3 (Patterns and Common Properties).

4.2 Field Modifiers

The following field modifiers are applicable to fields that are part of a flow record's Flow Key as defined in [I-D.ietf-ipfix-architecture] (Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, “Architecture for IP Flow Information Export,” August 2005.):

discard:

The field is not included in the meta-flow records, i.e. meta-flows are not distinguishable with respect to this field. Incoming flow records with different values for this IPFIX field are merged.

keep:

The field is included in the meta-flow record, i.e. meta-flows are distinguishable with respect to this field. Incoming flow records with different values for this field are not merged, but contribute to different meta-flows instead.

mask/n (applicable to IP addresses only):

The field is included in the meta-flow record, but the number of significant bits reduced to n bits. Incoming flow records with IP addresses belonging to the same subnet are merged, so meta-flows are distinguishable with respect to resulting subnet addresses only. In accordance with the IPFIX Information Model, the resulting subnet address MAY be encoded with a IP prefix field and a IP mask field. It SHOULD, however, be encoded with a single field of the new abstract data type "ipv4Network" as proposed in Section 5.1 (ipv4Network).

If an aggregation instruction refers to a field that is not part of the Flow Key (e.g. a time stamp or a count) the only possible field modifier is:

aggregate:

The field is included in the meta-flow record. The value for this field is derived from the corresponding values of the original flows by applying an aggregation function. The type of aggregation function to be applied depends on the field type. For example, the meta-flow's start timestamp is set to the minimum of the original start timestamps, packet and byte counts of aggregated flows are summed up. Table 1 (Treatment of Fields Carrying Metering Information) gives an overview of common field types and their associated aggregation function. Refer to the IPFIX Information Model [I-D.ietf-ipfix-info] (Quittek, J., Bryant, S., Claise, B., and J. Meyer, “Information Model for IP Flow Information Export,” September 2005.) for a description of the mentioned fields.

Field	Aggregation Function
minimumPacketLength	minimum
minimumTtl	minimum
flowStartSeconds	minimum
flowStartMilliSeconds	minimum
maximumPacketLength	maximum
maximumTtl	maximum
flowEndSeconds	maximum
flowEndMilliSeconds	maximum
ipv6OptionHeaders	binary OR
tcpControlBits	binary OR
octetDeltaCount	sum
packetDeltaCount	sum

Table 1: Treatment of Fields Carrying Metering Information

Because the export of a meta-flow record requires an appropriate template, a one-to-one relationship between rules and templates can be established.

4.3 Patterns and Common Properties

The applicability of an aggregation rule MAY be restricted to flows whose Flow Keys match certain patterns. Thus, patterns act as filters that enable the selection of flows and meta-flows that are exported to the analyzer. For example, the pattern "80" can be applied to the Flow Key sourceTransportPort in order to export only (meta-)flows originated by an HTTP server. Patterns MUST NOT be used in combination with fields that are not part of the Flow Key, such as the field types shown in Table 1 (Treatment of Fields Carrying Metering Information).

The defined patterns constitute common properties of the aggregated flows. Furthermore, the common properties are the same for all meta-flows resulting from the corresponding aggregation rule. Common properties MAY be exported as regular IPFIX fields. However, in order to reduce redundancy and to make patterns distinguishable from other fields, they SHOULD be transmitted as fixed-value fields using the Data Template presented in Section 5.3 (Data Template). Additionally, encoding common properties as fixed-value fields make the applied patterns visible to the analyzer.

4.4 Rule Semantics

By default, incoming flow records are checked against all aggregation rules. If a rule matches, i.e. if the flow record comprises all required fields and matches all given patterns, the field modifiers are applied and the corresponding meta-flow record is generated or updated. Therefore, incoming flow records that match multiple rules contribute to multiple meta-flows.

In some cases, it is preferred that an incoming flow record that matched a certain rule is not checked against other rules in order to avoid that this flow contributes to multiple meta-flows. Therefore, it is possible to indicate a preceding rule for each aggregation rule. If a preceding rule is given, the aggregator tries to aggregate an incoming flow according to the preceding rule. Only if the preceding rule is not applicable, e.g. because the incoming flow does not match the given pattern, the current rule is applied. Using the preceding rule relationship, rules can be organized in rule chains and rule trees where only the first matching rule is applied in every chain or branch. Consequently, each flow record is counted at most once per chain or branch. Rules that do not define a preceding rule are used to check all incoming flow records and may constitute the beginning of a rule chain or the root of a rule tree.

The Preceding Rule field in the header of the Data Template (see Section 5.3 (Data Template)) is used to identify the preceding rule by its Template ID. If this ID is set to 0, there is no preceding rule and the rule is checked against all incoming records.

4.5 Example

Here is an example rule with four aggregation instructions:

Aggregate

discard sourceTransportPort in 80
keep sourceIPv4Address
mask/24 destinationIPv4Address in 10.10.0.0/16
aggregate packetDeltaCount

This rule aggregates all flows to a destination address in the subnet 10.10.0.0/16 with source port equal to 80. Destination addresses are merged according to subnets in 10.10.x.0/24. The resulting meta-flow records comprise the source address, the destination subnet address, and the packet counter.

TOC

5. IPFIX Extensions

After having a rule's field modifiers applied, all flow records that matched a rule comprise the same fields, so for each rule exactly one template can be used. In order to efficiently transmit aggregated flows, three extensions to IPFIX are proposed:

New abstract data type "ipv4Network"
New abstract data type "portRanges"
New "Data Template" set

5.1 ipv4Network

Currently, the transport of IP network information as specified by IPFIX is done using separate fields for the network address and the corresponding mask. We propose a new abstract data type ipv4Network that represents the common notation of IP networks: address/mask. The new abstract data type is built of an unsigned32 for the IPv4 address and (OPTIONAL) an additional octet specifying the prefix length. The encoding of the IPv4 address corresponds to the definition of the ipv4Address in the IPFIX Information Model.

Although using an ipv4Network field instead of two separate fields for prefix and mask will not reduce the length of resulting flow records, it eases the work of the aggregator: With ipv4Network, the comparison of subnet addresses requires only one field lookup per record instead of two. Furthermore, using the abstract data type ipv4Network reduces the template size by one field equalling four octets. Applications such as IPFIX Aggregation benefit from ipv4Network if network addresses are frequently exported.

5.2 portRanges

For some applications it might be useful to restrict the applicability of an aggregation rule to flows with source or destination port being of a specific set of port numbers. In an aggregation rule, such a set of port numbers can be specified as a pattern. However, the current IPFIX Information Model does not define any data type that allows transmitting a set of port numbers, which is necessary in order to export the pattern as a common property of the resulting meta-flows. Therefore, the new abstract data type portRanges for a list of port ranges is defined in this section.

portRanges is a finite length string of unsigned32 values, each consisting of an unsigned16 for the first port number followed by an unsigned16 for the last port number of the port range. portRanges MAY be used as a variable-length data type as defined in [I-D.ietf-ipfix-protocol] (Claise, B., “IPFIX Protocol Specifications,” September 2005.).

Data types basing on portRanges MAY also be cast down to unsigned16 to represent a single Port. Hence, the transportSourcePort and transportDestinationPort data types, currently based on the unsigned16 abstract data type, MAY be replaced portRanges-based data types.

Table 2 (PortRanges Examples) shows some encoding examples with portRanges.

Ports	Length	Hexadecimal Representation
80	2	0050
1:7	4	0001 0007
80, 443	8	0050 0050 01BB 01BB
1:7, 256:1024	8	0001 0007 0100 0400
20, 80, 443	12	0014 0014 0050 0050 01BB 01BB
1:7, 80, 443	12	0001 0007 0050 0050 01BB 01BB

Table 2: PortRanges Examples

5.3 Data Template

Section Section 4.3 (Patterns and Common Properties) described how patterns are used to restrict the applicability of an aggregation rule and define common properties of the resulting meta-flows. In order to avoid the overhead of the repeated transmission of these common properties in all meta-flow records resulting from a given rule, the new template type Data Template is introduced. This template type allows the exporter to declare common properties to the analyzer. Additionally, each Data Template Record includes a Preceding Rule field that is used to inform the analyzer about the semantics of the aggregation rule sets.

The basic format of a Data Template Set is shown in Figure 3 (Data Template Set Format). It is the same as for a Template Set, except that the Set ID is 4. The format of individual Data Template Records, however, differs from that of the standard Template and is shown in Figure 4 (Data Template Record Format).

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 = 4           |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Data Template Record 1                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              ...                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Data Template Record N                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Padding (opt)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Data Template Set Format

The Data Template Set field definitions are as follows:

Set ID

Type of this template set. A Set ID value of 4 is proposed for the Data Template Set.

Length

Total length of this set in bytes.

Padding

OPTIONAL padding to fill the set to a word boundary. It MUST consist of null-bytes and be at most seven bytes in length

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Template ID                  |  Field Count                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data Count                   |  Preceding Rule               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Field 1 Specifier                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              ...                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Field N Specifier                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        Data 1 Specifier                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              ...                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        Data M Specifier                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          Data 1 Value                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              ...                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          Data M Value                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Data Template Record Format

The Data Template Record field definitions are as follows:

Template ID

Template ID of this Data Template Record. This value is greater than 255.

Field Count

Number of regular fields that will be sent in subsequent Data Records using this Template.

Data Count

Number of fixed-value fields that will be sent in this Template.

Preceding Rule

Template ID of the preceding rule that is checked before, or 0 if all incoming records are to be checked against this rule. When a Data Template refers to a preceding rule, the Exporter SHOULD make sure that the referred Template is also exported in order to ensure that the Collector is able to reconstruct the rule order. Refer to Section 4.4 (Rule Semantics) for a description of organizing rules in chains or trees.

Field N Specifier

Information Element identifier, Field length and an Enterprise Number (if needed) of field N. Refer to [I-D.ietf-ipfix-protocol] (Claise, B., “IPFIX Protocol Specifications,” September 2005.) for more information on Field Specifiers

Data M Specifier

Same as "Field N Specifier", but used for common properties of all Data Records of this Template. Together with Data M Value, a similar encoding like TLV (type-length-value) is achieved.

Data M Value

Bit representation of a common property as would be transmitted in a Data Record.

Table 3 (Relation between field modifiers, meta-flow records, and Data Templates) illustrates the relationship between field modifiers and common properties (defined as patterns) on the one hand, and the resulting regular and fixed-value fields in the Data Template on the other hand. It can be seen that the analyzer is able to deduce all instructions of the aggregation rule considering the structure of the Data Template, except the combination "discard without pattern" that does not result in any field.

field modifier	pattern	field in meta-flow record	fixed-value field in Data Template
discard	no	N/A	N/A
discard	yes	N/A	yes, contains pattern
keep	no	yes	N/A
keep	yes	yes, if pattern specifies a range of values	yes, contains pattern
mask	no	yes, IP network address	N/A
mask	yes	yes, IP network address	yes, contains pattern

Table 3: Relation between field modifiers, meta-flow records, and Data Templates

5.4 Example

In this example we assume the concentrator was given the following aggregation rule:

Aggregate

discard sourceIPv4Address in 10.0.0.0/23
keep destinatonTransportPort
aggregate packetDeltaCount

We further assume the concentrator receives the following flow records:

Source IP	Source Port	Destination IP	Destination Port	Packets
10.0.0.1	64235	10.0.0.10	80	10
10.0.1.2	64236	10.0.0.11	110	10
10.0.0.3	64237	10.0.0.12	80	10
10.0.2.4	64238	10.0.0.13	80	10
10.0.2.5	64239	10.0.0.14	80	10

Table 4: Incoming Flows

Based on the aggregation rule stated above the concentrator would now first send a Data Template Set with the Data Template Record corresponding to the given rule:

Field	Value
Template ID	10001
Field Count	2
Data Count	2
Preceding Rule	0
Field 1 Type	Destination Port
Field 2 Type	Packets
Data 1 Type	Source IP Prefix
Data 2 Type	Source IP Mask
Data 1 Value	10.0.0.0
Data 2 Value	23

Table 5: Data Template used

In case that the abstract data type ipv4Network was used for a new data type Source IP Network, it would look like this:

Field	Value
Template ID	10001
Field Count	2
Data Count	2
Preceding Rule	0
Field 1 Type	Destination Port
Field 2 Type	Packets
Data 1 Type	Source IP Network
Data 1 Value	10.0.0.0/23

Table 6: Data Template used

Secondly, a Data Set of this Data Template is exported containing the meta-flows resulting from the given rule. Note that the flows' common property, a source IP address in 10.0.0.0/23, was already transmitted in the template. The exported meta-flow records contain the aggregated packet counts and the destination port, which is the only discriminating Flow Key property.

Destination Port	Packets
80	20
110	10

Table 7: Aggregated Flows

TOC

6. Application Examples

6.1 Charging

Charging applications require separate flow accounting for individual end systems. However, detailed information about all individual flows sent or received by the end system is not required. The required level of flow aggregation can be achieved with an aggregation rules that discards all Flow Key properties except the IP address of the involved end systems.

The example ruleset can be used for charging end systems in the subnet 10.10.0.0/16:

Aggregate

keep destinationIPv4Address in 10.10.0.0/16
aggregate packetDeltaCount

Aggregate

keep sourceIPv4Address in 10.10.0.0/16
aggregate packetDeltaCount

Meta-flow records resulting from the first rule contain packet counts of the inbound traffic separated by host IP addresses. The second rule produces the corresponding records for the outbound traffic. Protocol and port information is omitted.

6.2 Intrusion Detection

If flow accounting is employed for intrusion detection, e.g. in order to detect denial-of-service attacks, information about the transport layer protocol and attacked service, i.e. the destination port, is mostly required. On the other hand, the analysis is typically based on flow aggregates exchanged between subnets since processing individual flows would require to much processing power. Detailed information about the flows between individual end systems is only required if an already detected attack should be analyzed in more detail.

An example ruleset might consist of the following instructions:

Aggregate

mask/24 destinationIPv4Address in 10.10.0.0/16
mask/24 sourceIPv4Address
keep protocolIdentifier
keep destinationTransportPort
aggregate packetDeltaCount

Meta-flow records are created for all packets directed to /24 subnets in the protected network 10.10.0.0/16. The destination port and the protocol are preserved whereas the source port is discarded.

TOC

7. Security considerations

As all methods described in this document are merely variations on methods already introduced in [I-D.ietf-ipfix-protocol] (Claise, B., “IPFIX Protocol Specifications,” September 2005.), the same rules regarding exchange of flow information apply.

TOC

8. References

TOC

8.1 Normative References

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.

TOC

8.2 Informative References

[I-D.ietf-ipfix-architecture]	Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, “Architecture for IP Flow Information Export,” draft-ietf-ipfix-architecture-09 (work in progress), August 2005.
[I-D.ietf-ipfix-protocol]	Claise, B., “IPFIX Protocol Specifications,” draft-ietf-ipfix-protocol-19 (work in progress), September 2005.
[I-D.ietf-ipfix-info]	Quittek, J., Bryant, S., Claise, B., and J. Meyer, “Information Model for IP Flow Information Export,” draft-ietf-ipfix-info-11 (work in progress), September 2005.
[RFC3917]	Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export,” RFC 3917, October 2004.

TOC

Authors' Addresses

	Falko Dressler
	University of Erlangen
	Department of Computer Science 7
	Martensstr. 3
	Erlangen 91058
	Germany
Phone:	+49 9131 85-27914
Email:	dressler@informatik.uni-erlangen.de
URI:	http://www7.informatik.uni-erlangen.de/

	Christoph Sommer
	University of Erlangen
	Department of Computer Science 7
	Martensstr. 3
	Erlangen 91058
	Germany
Email:	sichsomm@stud.informatik.uni-erlangen.de

	Gerhard Muenz
	University of Tuebingen
	Computer Networks and Internet
	Auf der Morgenstelle 10C
	Tuebingen 72076
	Germany
Phone:	+49 7071 29-70534
Email:	muenz@informatik.uni-tuebingen.de
URI:	http://net.informatik.uni-tuebingen.de/

TOC

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 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.

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

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.

--------------000907070707070809040202 Content-Type: text/plain; name="draft-dressler-ipfix-aggregation-02.txt" Content-Disposition: inline; filename="draft-dressler-ipfix-aggregation-02.txt" Content-Transfer-Encoding: 7bit Network Working Group F. Dressler Internet-Draft C. Sommer Expires: June 23, 2006 University of Erlangen G. Muenz University of Tuebingen December 20, 2005 IPFIX Aggregation 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 BCP 79. 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 obsoleted 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. This Internet-Draft will expire on June 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IPFIX Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX exporters) and analyzers (IPFIX collectors). Using aggregation techniques, measurement information of multiple similar flows is aggregated into one compound meta-flow record. Subsets of flows eligible for aggregation, as well as the degree of similarity, can be Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 1] Internet-Draft IPFIX Aggregation December 2005 customized using aggregation rules. To ensure efficient communication of both aggregated flows and the aggregation rules used, the IPFIX Protocol and IPFIX Information Model are slightly extended to allow for two new abstract data types and a new type of template set. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Aggregation Rules . . . . . . . . . . . . . . . . . . . . 5 4.2 Field Modifiers . . . . . . . . . . . . . . . . . . . . . 6 4.3 Patterns and Common Properties . . . . . . . . . . . . . . 7 4.4 Rule Semantics . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IPFIX Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 ipv4Network . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 portRanges . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3 Data Template . . . . . . . . . . . . . . . . . . . . . . 10 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Application Examples . . . . . . . . . . . . . . . . . . . . . 16 6.1 Charging . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2 Intrusion Detection . . . . . . . . . . . . . . . . . . . 16 7. Security considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1 Normative References . . . . . . . . . . . . . . . . . . . 17 8.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 2] Internet-Draft IPFIX Aggregation December 2005 1. Introduction Flow measurement in high-speed large-scale networks easily produces a huge amount of data that can not be handled by a single IPFIX collector or analyzer. Also, many applications processing flow measurement data do not require detailed flow-level information but only information about flow aggregates, where the quality and level of flow aggregation is very application-specific. This document presents a flexible flow aggregation scheme that helps both, reducing the number and size of exported flow records and adapting the transmitted measurement information to the requirements of the application. These goals are achieved by discarding unneeded measurement information and merging multiple individual flows into a smaller number of compound meta-flows before the remaining measurement data is exported to the analyzer. The following sections show how to design and implement IPFIX aggregators and introduce appropriate extensions to the IPFIX protocol. 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 [RFC2119]. 2. Terminology Apart from the basic terms as defined in [RFC3917], [I-D.ietf-ipfix- protocol], and [I-D.ietf-ipfix-architecture], the following terms are used within this document: Meta-flow: A meta-flow is an aggregate of individual flows. Meta-flow record: A meta-flow record contains the measurement data of a meta-flow. It MAY contain the total count of all packets that belong to the same meta-flow and were observed within a given time interval. Flow properties that were discarded during flow aggregation are no longer contained in the meta-flow record. Aggregation rule: An aggregation rule defines the properties of a meta-flow and the content of the corresponding meta-flow record. Optionally, a set of common properties MAY be specified in order to restrict the applicability of the rule to those flows that show certain patterns. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 3] Internet-Draft IPFIX Aggregation December 2005 Data Template: A Data Template, as proposed in Section 5.3, SHOULD be used to define the structure of the meta-flow record and to inform the analyzer about the applied aggregation rule and the common properties. 3. Architecture Aggregation of measurement data may take place at two possible stages: o An internal aggregator, as depicted in Figure 1, is implemented as a process running in an IPFIX enabled device. It aggregates flow data generated by multiple metering processes and exports them as meta-flow records. In practical implementations, metering and aggregation MAY be performed in a single step in order to reduce the number of retained state information. +------------------------------------------+ +--------------+ | IPFIX-enabled device .---. .---. | | | | .--------------------. | A | | | | .-->| Analyzer | | | Metering Process 1 |-. | g | | E | | | | | | `--------------------' | | g | | x | | | +--------------+ | | | r | | p |---' | . '-->| e | | o | | | . | g |-->| r | | | . .-->| a | | t |---. | | | t | | e | | | +--------------+ | .--------------------. | | o | | r | | | | | | | Metering Process N |-' | r | | | | '-->| Concentrator | | `--------------------' `---' `---' | | | +------------------------------------------+ +--------------+ Figure 1: Internal Aggregation o An external aggregator, called concentrator in IPFIX terminology, may be used where the deployed monitoring devices cannot be modified to incorporate an internal aggregator. Furthermore, concentrators enable cascaded, multi-level aggregation of flow information. As shown in Figure 2, a concentrator receives flow records from monitoring devices and/or lower-level concentrators and exports the aggregated meta-flow information to higher-level concentrators and/or analyzers. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 4] Internet-Draft IPFIX Aggregation December 2005 +--------------+ +-----------------------+ +--------------+ | | | Concentrator | | | | Concentrator |-. | .---. .---. .---. | .-->| Analyzer | | | | | | C | | A | | | | | | | +--------------+ | | | o | | g | | E | | | +--------------+ '--->| l | | g | | x |---' | | l | | r | | p | | | | e |-->| e |-->| o | | | | c | | g | | r | | .--->| t | | a | | t |---. +--------------+ | | | o | | t | | e | | | +--------------+ | | | | | r | | o | | r | | | | | | IPFIX device |-' | | | | r | | | | '-->| Concentrator | | | | `---' `---' `---' | | | +--------------+ +-----------------------+ +--------------+ Figure 2: External Aggregation 4. Methodology 4.1 Aggregation Rules Regarding the configuration of the aggregator, a rule-based approach is proposed. A list of user-defined aggregation rules is supplied to the aggregator. An aggregation rule consists of multiple aggregation instructions, one for each IPFIX field that is to be considered. An aggregation instruction comprises the following elements: o The IPFIX field the aggregation instruction refers to (e.g. destinationIPv4Address). Only flows that contain the field mentioned will be considered for aggregation in the meta-flow. o One of the field modifiers "discard", "keep", "mask", or "aggregate" that specifies how this field is treated by the aggregator and whether it is included in the meta-flow record or not. o An OPTIONAL pattern for this field that restricts the aggregation to those flows that match the given value(s) (e.g. 10.10.0.0/16). Only flows that match all patterns of the rule will be aggregated in the meta-flow. With this definition of aggregation instructions each rule unambiguously defines the content of the meta-flow record as well as the template to export the meta-flow information. If a field is present in the meta-flow record and how it is encoded depends on the field modifier. This behavior is explained in Section 4.2. Fields that do not appear in any of the aggregation instructions are not part of the meta-flow record. The usage of patterns in order to define common properties is explained in Section 4.3. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 5] Internet-Draft IPFIX Aggregation December 2005 4.2 Field Modifiers The following field modifiers are applicable to fields that are part of a flow record's Flow Key as defined in [I-D.ietf-ipfix- architecture]: discard: The field is not included in the meta-flow records, i.e. meta- flows are not distinguishable with respect to this field. Incoming flow records with different values for this IPFIX field are merged. keep: The field is included in the meta-flow record, i.e. meta-flows are distinguishable with respect to this field. Incoming flow records with different values for this field are not merged, but contribute to different meta-flows instead. mask/n (applicable to IP addresses only): The field is included in the meta-flow record, but the number of significant bits reduced to n bits. Incoming flow records with IP addresses belonging to the same subnet are merged, so meta-flows are distinguishable with respect to resulting subnet addresses only. In accordance with the IPFIX Information Model, the resulting subnet address MAY be encoded with a IP prefix field and a IP mask field. It SHOULD, however, be encoded with a single field of the new abstract data type "ipv4Network" as proposed in Section 5.1. If an aggregation instruction refers to a field that is not part of the Flow Key (e.g. a time stamp or a count) the only possible field modifier is: aggregate: The field is included in the meta-flow record. The value for this field is derived from the corresponding values of the original flows by applying an aggregation function. The type of aggregation function to be applied depends on the field type. For example, the meta-flow's start timestamp is set to the minimum of the original start timestamps, packet and byte counts of aggregated flows are summed up. Table 1 gives an overview of common field types and their associated aggregation function. Refer to the IPFIX Information Model [I-D.ietf-ipfix-info] for a description of the mentioned fields. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 6] Internet-Draft IPFIX Aggregation December 2005 +-----------------------+----------------------+ | Field | Aggregation Function | +-----------------------+----------------------+ | minimumPacketLength | minimum | | minimumTtl | minimum | | flowStartSeconds | minimum | | flowStartMilliSeconds | minimum | | maximumPacketLength | maximum | | maximumTtl | maximum | | flowEndSeconds | maximum | | flowEndMilliSeconds | maximum | | ipv6OptionHeaders | binary OR | | tcpControlBits | binary OR | | octetDeltaCount | sum | | packetDeltaCount | sum | +-----------------------+----------------------+ Table 1: Treatment of Fields Carrying Metering Information Because the export of a meta-flow record requires an appropriate template, a one-to-one relationship between rules and templates can be established. 4.3 Patterns and Common Properties The applicability of an aggregation rule MAY be restricted to flows whose Flow Keys match certain patterns. Thus, patterns act as filters that enable the selection of flows and meta-flows that are exported to the analyzer. For example, the pattern "80" can be applied to the Flow Key sourceTransportPort in order to export only (meta-)flows originated by an HTTP server. Patterns MUST NOT be used in combination with fields that are not part of the Flow Key, such as the field types shown in Table 1. The defined patterns constitute common properties of the aggregated flows. Furthermore, the common properties are the same for all meta- flows resulting from the corresponding aggregation rule. Common properties MAY be exported as regular IPFIX fields. However, in order to reduce redundancy and to make patterns distinguishable from other fields, they SHOULD be transmitted as fixed-value fields using the Data Template presented in Section 5.3. Additionally, encoding common properties as fixed-value fields make the applied patterns visible to the analyzer. 4.4 Rule Semantics By default, incoming flow records are checked against all aggregation rules. If a rule matches, i.e. if the flow record comprises all Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 7] Internet-Draft IPFIX Aggregation December 2005 required fields and matches all given patterns, the field modifiers are applied and the corresponding meta-flow record is generated or updated. Therefore, incoming flow records that match multiple rules contribute to multiple meta-flows. In some cases, it is preferred that an incoming flow record that matched a certain rule is not checked against other rules in order to avoid that this flow contributes to multiple meta-flows. Therefore, it is possible to indicate a preceding rule for each aggregation rule. If a preceding rule is given, the aggregator tries to aggregate an incoming flow according to the preceding rule. Only if the preceding rule is not applicable, e.g. because the incoming flow does not match the given pattern, the current rule is applied. Using the preceding rule relationship, rules can be organized in rule chains and rule trees where only the first matching rule is applied in every chain or branch. Consequently, each flow record is counted at most once per chain or branch. Rules that do not define a preceding rule are used to check all incoming flow records and may constitute the beginning of a rule chain or the root of a rule tree. The Preceding Rule field in the header of the Data Template (see Section 5.3) is used to identify the preceding rule by its Template ID. If this ID is set to 0, there is no preceding rule and the rule is checked against all incoming records. 4.5 Example Here is an example rule with four aggregation instructions: 1. Aggregate * discard sourceTransportPort in 80 * keep sourceIPv4Address * mask/24 destinationIPv4Address in 10.10.0.0/16 * aggregate packetDeltaCount This rule aggregates all flows to a destination address in the subnet 10.10.0.0/16 with source port equal to 80. Destination addresses are merged according to subnets in 10.10.x.0/24. The resulting meta-flow records comprise the source address, the destination subnet address, and the packet counter. 5. IPFIX Extensions After having a rule's field modifiers applied, all flow records that matched a rule comprise the same fields, so for each rule exactly one template can be used. In order to efficiently transmit aggregated flows, three extensions to IPFIX are proposed: Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 8] Internet-Draft IPFIX Aggregation December 2005 o New abstract data type "ipv4Network" o New abstract data type "portRanges" o New "Data Template" set 5.1 ipv4Network Currently, the transport of IP network information as specified by IPFIX is done using separate fields for the network address and the corresponding mask. We propose a new abstract data type ipv4Network that represents the common notation of IP networks: address/mask. The new abstract data type is built of an unsigned32 for the IPv4 address and (OPTIONAL) an additional octet specifying the prefix length. The encoding of the IPv4 address corresponds to the definition of the ipv4Address in the IPFIX Information Model. Although using an ipv4Network field instead of two separate fields for prefix and mask will not reduce the length of resulting flow records, it eases the work of the aggregator: With ipv4Network, the comparison of subnet addresses requires only one field lookup per record instead of two. Furthermore, using the abstract data type ipv4Network reduces the template size by one field equalling four octets. Applications such as IPFIX Aggregation benefit from ipv4Network if network addresses are frequently exported. 5.2 portRanges For some applications it might be useful to restrict the applicability of an aggregation rule to flows with source or destination port being of a specific set of port numbers. In an aggregation rule, such a set of port numbers can be specified as a pattern. However, the current IPFIX Information Model does not define any data type that allows transmitting a set of port numbers, which is necessary in order to export the pattern as a common property of the resulting meta-flows. Therefore, the new abstract data type portRanges for a list of port ranges is defined in this section. portRanges is a finite length string of unsigned32 values, each consisting of an unsigned16 for the first port number followed by an unsigned16 for the last port number of the port range. portRanges MAY be used as a variable-length data type as defined in [I-D.ietf-ipfix- protocol]. Data types basing on portRanges MAY also be cast down to unsigned16 to represent a single Port. Hence, the transportSourcePort and transportDestinationPort data types, currently based on the unsigned16 abstract data type, MAY be replaced portRanges-based data types. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 9] Internet-Draft IPFIX Aggregation December 2005 Table 2 shows some encoding examples with portRanges. +---------------+--------+---------------------------------+ | Ports | Length | Hexadecimal Representation | +---------------+--------+---------------------------------+ | 80 | 2 | 0050 | | 1:7 | 4 | 0001 0007 | | 80, 443 | 8 | 0050 0050 01BB 01BB | | 1:7, 256:1024 | 8 | 0001 0007 0100 0400 | | 20, 80, 443 | 12 | 0014 0014 0050 0050 01BB 01BB | | 1:7, 80, 443 | 12 | 0001 0007 0050 0050 01BB 01BB | +---------------+--------+---------------------------------+ Table 2: PortRanges Examples 5.3 Data Template Section Section 4.3 described how patterns are used to restrict the applicability of an aggregation rule and define common properties of the resulting meta-flows. In order to avoid the overhead of the repeated transmission of these common properties in all meta-flow records resulting from a given rule, the new template type Data Template is introduced. This template type allows the exporter to declare common properties to the analyzer. Additionally, each Data Template Record includes a Preceding Rule field that is used to inform the analyzer about the semantics of the aggregation rule sets. The basic format of a Data Template Set is shown in Figure 3. It is the same as for a Template Set, except that the Set ID is 4. The format of individual Data Template Records, however, differs from that of the standard Template and is shown in Figure 4. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 10] Internet-Draft IPFIX Aggregation December 2005 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 = 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data Template Record 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data Template Record N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Data Template Set Format The Data Template Set field definitions are as follows: Set ID Type of this template set. A Set ID value of 4 is proposed for the Data Template Set. Length Total length of this set in bytes. Padding OPTIONAL padding to fill the set to a word boundary. It MUST consist of null-bytes and be at most seven bytes in length Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 11] Internet-Draft IPFIX Aggregation December 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Count | Preceding Rule | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field 1 Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field N Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Data Template Record Format The Data Template Record field definitions are as follows: Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 12] Internet-Draft IPFIX Aggregation December 2005 Template ID Template ID of this Data Template Record. This value is greater than 255. Field Count Number of regular fields that will be sent in subsequent Data Records using this Template. Data Count Number of fixed-value fields that will be sent in this Template. Preceding Rule Template ID of the preceding rule that is checked before, or 0 if all incoming records are to be checked against this rule. When a Data Template refers to a preceding rule, the Exporter SHOULD make sure that the referred Template is also exported in order to ensure that the Collector is able to reconstruct the rule order. Refer to Section 4.4 for a description of organizing rules in chains or trees. Field N Specifier Information Element identifier, Field length and an Enterprise Number (if needed) of field N. Refer to [I-D.ietf-ipfix-protocol] for more information on Field Specifiers Data M Specifier Same as "Field N Specifier", but used for common properties of all Data Records of this Template. Together with Data M Value, a similar encoding like TLV (type-length-value) is achieved. Data M Value Bit representation of a common property as would be transmitted in a Data Record. Table 3 illustrates the relationship between field modifiers and common properties (defined as patterns) on the one hand, and the resulting regular and fixed-value fields in the Data Template on the other hand. It can be seen that the analyzer is able to deduce all instructions of the aggregation rule considering the structure of the Data Template, except the combination "discard without pattern" that does not result in any field. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 13] Internet-Draft IPFIX Aggregation December 2005 +----------------+----------------+----------------+----------------+ | field modifier | pattern | field in | fixed-value | | | | meta-flow | field in Data | | | | record | Template | +----------------+----------------+----------------+----------------+ | discard | no | N/A | N/A | | discard | yes | N/A | yes, contains | | | | | pattern | | keep | no | yes | N/A | | keep | yes | yes, if | yes, contains | | | | pattern | pattern | | | | specifies a | | | | | range of | | | | | values | | | mask | no | yes, IP | N/A | | | | network | | | | | address | | | mask | yes | yes, IP | yes, contains | | | | network | pattern | | | | address | | +----------------+----------------+----------------+----------------+ Table 3: Relation between field modifiers, meta-flow records, and Data Templates 5.4 Example In this example we assume the concentrator was given the following aggregation rule: 1. Aggregate * discard sourceIPv4Address in 10.0.0.0/23 * keep destinatonTransportPort * aggregate packetDeltaCount We further assume the concentrator receives the following flow records: +------------+------------+-------------+-------------+-------------+ | Source IP | Source | Destination | Destination | Packets | | | Port | IP | Port | | +------------+------------+-------------+-------------+-------------+ | 10.0.0.1 | 64235 | 10.0.0.10 | 80 | 10 | | 10.0.1.2 | 64236 | 10.0.0.11 | 110 | 10 | | 10.0.0.3 | 64237 | 10.0.0.12 | 80 | 10 | | 10.0.2.4 | 64238 | 10.0.0.13 | 80 | 10 | | 10.0.2.5 | 64239 | 10.0.0.14 | 80 | 10 | +------------+------------+-------------+-------------+-------------+ Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 14] Internet-Draft IPFIX Aggregation December 2005 Table 4: Incoming Flows Based on the aggregation rule stated above the concentrator would now first send a Data Template Set with the Data Template Record corresponding to the given rule: +----------------+------------------+ | Field | Value | +----------------+------------------+ | Template ID | 10001 | | Field Count | 2 | | Data Count | 2 | | Preceding Rule | 0 | | Field 1 Type | Destination Port | | Field 2 Type | Packets | | Data 1 Type | Source IP Prefix | | Data 2 Type | Source IP Mask | | Data 1 Value | 10.0.0.0 | | Data 2 Value | 23 | +----------------+------------------+ Table 5: Data Template used In case that the abstract data type ipv4Network was used for a new data type Source IP Network, it would look like this: +----------------+-------------------+ | Field | Value | +----------------+-------------------+ | Template ID | 10001 | | Field Count | 2 | | Data Count | 2 | | Preceding Rule | 0 | | Field 1 Type | Destination Port | | Field 2 Type | Packets | | Data 1 Type | Source IP Network | | Data 1 Value | 10.0.0.0/23 | +----------------+-------------------+ Table 6: Data Template used Secondly, a Data Set of this Data Template is exported containing the meta-flows resulting from the given rule. Note that the flows' common property, a source IP address in 10.0.0.0/23, was already transmitted in the template. The exported meta-flow records contain the aggregated packet counts and the destination port, which is the only discriminating Flow Key property. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 15] Internet-Draft IPFIX Aggregation December 2005 +------------------+---------+ | Destination Port | Packets | +------------------+---------+ | 80 | 20 | | 110 | 10 | +------------------+---------+ Table 7: Aggregated Flows 6. Application Examples 6.1 Charging Charging applications require separate flow accounting for individual end systems. However, detailed information about all individual flows sent or received by the end system is not required. The required level of flow aggregation can be achieved with an aggregation rules that discards all Flow Key properties except the IP address of the involved end systems. The example ruleset can be used for charging end systems in the subnet 10.10.0.0/16: 1. Aggregate * keep destinationIPv4Address in 10.10.0.0/16 * aggregate packetDeltaCount 2. Aggregate * keep sourceIPv4Address in 10.10.0.0/16 * aggregate packetDeltaCount Meta-flow records resulting from the first rule contain packet counts of the inbound traffic separated by host IP addresses. The second rule produces the corresponding records for the outbound traffic. Protocol and port information is omitted. 6.2 Intrusion Detection If flow accounting is employed for intrusion detection, e.g. in order to detect denial-of-service attacks, information about the transport layer protocol and attacked service, i.e. the destination port, is mostly required. On the other hand, the analysis is typically based on flow aggregates exchanged between subnets since processing individual flows would require to much processing power. Detailed information about the flows between individual end systems is only required if an already detected attack should be analyzed in more detail. An example ruleset might consist of the following instructions: Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 16] Internet-Draft IPFIX Aggregation December 2005 1. Aggregate * mask/24 destinationIPv4Address in 10.10.0.0/16 * mask/24 sourceIPv4Address * keep protocolIdentifier * keep destinationTransportPort * aggregate packetDeltaCount Meta-flow records are created for all packets directed to /24 subnets in the protected network 10.10.0.0/16. The destination port and the protocol are preserved whereas the source port is discarded. 7. Security considerations As all methods described in this document are merely variations on methods already introduced in [I-D.ietf-ipfix-protocol], the same rules regarding exchange of flow information apply. 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 8.2 Informative References [I-D.ietf-ipfix-architecture] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", draft-ietf-ipfix-architecture-09 (work in progress), August 2005. [I-D.ietf-ipfix-protocol] Claise, B., "IPFIX Protocol Specifications", draft-ietf-ipfix-protocol-19 (work in progress), September 2005. [I-D.ietf-ipfix-info] Quittek, J., Bryant, S., Claise, B., and J. Meyer, "Information Model for IP Flow Information Export", draft-ietf-ipfix-info-11 (work in progress), September 2005. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 17] Internet-Draft IPFIX Aggregation December 2005 Authors' Addresses Falko Dressler University of Erlangen Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27914 Email: dressler@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/ Christoph Sommer University of Erlangen Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Email: sichsomm@stud.informatik.uni-erlangen.de Gerhard Muenz University of Tuebingen Computer Networks and Internet Auf der Morgenstelle 10C Tuebingen 72076 Germany Phone: +49 7071 29-70534 Email: muenz@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/ Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 18] Internet-Draft IPFIX Aggregation December 2005 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 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. 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dressler, et al. draft-dressler-ipfix-aggregation-02.txt [Page 19] --------------000907070707070809040202-- -- 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 Dec 22 10:00:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpRvS-0004P9-Ci for ipfix-archive@megatron.ietf.org; Thu, 22 Dec 2005 10:00:14 -0500 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 JAA22056 for ; Thu, 22 Dec 2005 09:59:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EpRln-0001V7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Dec 2005 08:50:15 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EpRll-0001Uw-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 22 Dec 2005 08:50:14 -0600 Received: from [10.147.67.245] (i4dhcp245 [10.147.67.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id jBMEndw10957; Thu, 22 Dec 2005 15:49:39 +0100 (MET) Message-ID: <43AABD02.7050503@fokus.fraunhofer.de> Date: Thu, 22 Dec 2005 15:49:38 +0100 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Sven Anderson , Andrew Johnson , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements in a template -> proposed IPFIX text References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE> <43A2E65E.5020800@cisco.com> <43A2F3BD.9070804@CS.Uni-Goettingen.DE> <43A6CAD4.8040907@cisco.com> In-Reply-To: <43A6CAD4.8040907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit and Sven , I definitely see the need to solve this in IPFIX and not only in PSAMP. So I think we have no other option than going for a simple solution now. Maybe Svens ideas can go into an individual draft or he can try to integrate it in one of the current IPFIX extension drafts? Regards Tanja Benoit Claise wrote: > Sven, > >> Hi Andrew, >> >> Andrew Johnson schrieb: >> >>> You are trying to solve the issue of building a flow record with >>> element >>> captured from different observation points. The problem with using the >>> same I.E.s for the same field but seen in different places is that you >>> can't tell which entry in the record applies to which field. Even >>> adding >>> an order dependence doesn't solve this issue because there is no >>> requirement to put all versions of the element in the record. This is >>> detailed in your proposal but your solution is quite a complex addition >>> to the protocol. >> >> >> As long as an observation point can be an superset of other >> observation points, as it is defined at the moment, all fields are >> amiguous, also if you use the I.E. only once. >> >>> This is the issue Benoit's proposal is an attempt to solve. For >>> example >>> a classification routines may classify a packet as classes 1, 10 and 15 >>> similtaneously because these classes have independent properties. In >>> this example order may not seem important, but if you want to match the >>> classes with some statistics about each class then making it order >>> dependent allows the order of each to be alligned. >> >> >> I agree in the case of you example. This is another situation, as >> these special fields can have different values even in an atomic >> observation point. But Benoits example of IPv4 in IPv4 is an case, >> where I would say, it's an case of two observation points, before and >> after unwrapping. > > One or two observation points? It really depends how you see this. > - one observation point where you observe a single IP-in-IP packet > - two observation points: before, and after unwrapping. > > So, even if your solution is powerful, you must make assumptions about > where observation points are. > The proposed quick editorial fix proposes a solution without going > into the IPFIX device architectural details" > > Anyway, this is certainly a discussion for IPFIX version 2 :) > > Regards, Benoit. > >> That's why I think it matches to my proposal. Don't get me wrong, I >> support Benoits proposal, i just would go a little bit further. If >> there are multiple I.E.s allowed, is it so much more complexity to >> include an 0-length I.E. for separation? Maybe I don't have enough >> experience to overview the implications. >> >> As I'm quite new to the IETF-community: is this a typical situation, >> where I should initiate an draft for an IPFIX extension? Or should I >> just shut up? ;-) >> >> >> Cheers, >> >> Sven >> > > > -- > 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/ -- Dipl.-Ing. Tanja Zseby Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- 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 morimicha@ecicnet.org Thu Dec 22 14:16:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpVvL-0002p8-5f for ipfix-archive@megatron.ietf.org; Thu, 22 Dec 2005 14:16:23 -0500 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 OAA21517 for ; Thu, 22 Dec 2005 14:15:16 -0500 (EST) Received: from down.doit.wisc.edu ([144.92.9.126] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EpVoe-0006U0-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Dec 2005 13:09:28 -0600 Received: from ecicnet.org (men75-2-82-66-214-239.fbx.proxad.net [82.66.214.239]) by smtp.doit.wisc.edu (8.12.11/8.13.1) with SMTP id jBMJ9Pvb031689 for ; Thu, 22 Dec 2005 13:09:26 -0600 Message-ID: <000001c6072b$2e967bc0$1fc3a8c0@uvular> Reply-To: "Michal Mor" From: "Michal Mor" To: "Rachele Sommerfield" Subject: Re: germanium palatial Date: Thu, 22 Dec 2005 14:09:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60701.45C073C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60701.45C073C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.inwardoge.com =20 =20 L X M C V A S V P evitra anax eridia lALIS from $ 3.75 per piII ALlUM from $ 1.21 per piII mbien oma lAGRA from $ 3.33 per piII ropecia=20 ------=_NextPart_000_0001_01C60701.45C073C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.inwardoge.com

evitra
anax
eridia
lA= LIS from $ 3.75 per piII
ALlUM from $ 1.21 = per piII
mbien
oma
lAGRA = from $ 3.33 per = piII
ropecia
------=_NextPart_000_0001_01C60701.45C073C0-- From philoo@house.mn Sat Dec 24 03:24:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eq4hX-0003jI-EL for ipfix-archive@megatron.ietf.org; Sat, 24 Dec 2005 03:24:27 -0500 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 DAA19229 for ; Sat, 24 Dec 2005 03:23:19 -0500 (EST) Received: from 218-161-68-226.dynamic.hinet.net ([218.161.68.226] helo=house.mn) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Eq4LT-0002Pl-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Dec 2005 02:01:40 -0600 Message-ID: <000001c60860$3c60b050$f46da8c0@verdant> Reply-To: "Philomel Barbara" From: "Philomel Barbara" To: "Love Scheiber" Subject: Re: weatherbound attackable Date: Sat, 24 Dec 2005 03:01:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60836.538AA850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60836.538AA850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 http://www.someconro.com =20 =20 V S P M C A X L V i agra o ma r opecia er idia i alis mb ien an ax e vitra a lium from 3.35$ per one portion =20 =20 =20 from 3.85$ per one portion =20 =20 =20 from 1.25$ per one portion ------=_NextPart_000_0001_01C60836.538AA850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,

http://www.someconro.com

V
S
P
M
C
A
X
L
V

i = agra
o ma
r opecia
er idia
i = alis
mb ien
an ax
e vitra
a = lium

from 3.35$ = per one = portion

&n= bsp;from 3.85$ per one = portion

from 1.25$ per one = portion

------=_NextPart_000_0001_01C60836.538AA850-- From majordomo@mil.doit.wisc.edu Sat Dec 24 14:41:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqFGj-0003xy-F3 for ipfix-archive@megatron.ietf.org; Sat, 24 Dec 2005 14:41:32 -0500 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 OAA19950 for ; Sat, 24 Dec 2005 14:40:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1EqEtv-00077K-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Dec 2005 13:17:55 -0600 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EqEtt-00076r-00 for ipfix@net.doit.wisc.edu; Sat, 24 Dec 2005 13:17:54 -0600 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Dec 2005 11:17:52 -0800 Received: from [10.21.89.109] (sjc-vpn5-365.cisco.com [10.21.89.109]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBOJHkpf012968; Sat, 24 Dec 2005 11:17:47 -0800 (PST) Message-ID: <43AD9ED2.1030805@cisco.com> Date: Sat, 24 Dec 2005 19:17:38 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Falko Dressler CC: ipfix@net.doit.wisc.edu, Gerhard Muenz , Christoph Sommer Subject: Re: [ipfix] Discussion on draft-dressler-ipfix-aggregation-02.txt References: <43AA8877.4080702@informatik.uni-erlangen.de> In-Reply-To: <43AA8877.4080702@informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Falko, > We kindly ask you for final comments on the draft. The middle of figure 2 is badly indented. In section 4.2, the "discard" and "keep" actions define the fields to be either "non-key" or "key" fields respectively. "Key" fields are used to differentiate flows, and can be indicated using the flowKeyIndicator IE #173. Insert "while" in the "Aggregate" section of 4.2: For example, the meta-flow's start timestamp is set to the minimum of the original start timestamps, *while* packet and byte counts of aggregated flows are summed up. Regarding table 1, it may be necessary to define aggregation actions for every existing IE to ensure that everyone aggregates them the same way - and there may be IEs which simply cannot be sensibly aggregated (eg, address, port, AS, protocol, vlan). In section 4.4 Rule Semantics: Consequently, each flow record is counted at most once per chain or branch. "tree" would be better than "branch". 4.5 Example My interpretation of this example is: This rule aggregates all flows - no; only flows containing at least sourceTransportPort, sourceIPv4Address, destinationIPv4Address and packetDeltaCount. to a destination address in the subnet 10.10.0.0/16 - what happens to flows to a destination address outwith this subnet? eg, are they discarded, or aggregated seperately? This should be clarified under 4.1. with source port equal to 80. - no; sourceTransportPort of 80 is discarded. - clarify the effect of a pattern in a discard rule? Destination addresses are merged according to subnets in 10.10.x.0/24. - surely 10.10.0.x/24 ? The resulting meta-flow records comprise the source address, the destination subnet address, and the packet counter. - better to use the proper IE names as in the aggregation rules. 5.2 portRanges Therefore, the new abstract data type portRanges for a list of port ranges is defined in this section. The inclusion of the word "port" in the name makes the type quite specific. Better to introduce a more generic type such as "numberRange", and make an IE called "portRange" based on the "numberRange" type. Data types basing on portRanges MAY also be cast down to unsigned16 to represent a single Port. Better to use the familiar IPFIX phrase, "Reduced Size Encoding". Under table 6, Note that the flows' common property, a source IP address in 10.0.0.0/23, was already transmitted in the template. Rather, this is a property of the *discarded* flows! The common property of the undiscarded flows is that srcIP is NOT in 10.0.0.0/23. Regarding the example in 5.4, surely the flow to port 110 will match the rule "discard sourceIPv4Address in 10.0.0.0/23", and so this won't appear in table 7? Can you make an example where field count != data count, and relate field count and data count to M and N? Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 polu@thinblueline.com Sun Dec 25 22:32:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqj6Q-0000mZ-Kh for ipfix-archive@megatron.ietf.org; Sun, 25 Dec 2005 22:32:50 -0500 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 WAA25958 for ; Sun, 25 Dec 2005 22:31:41 -0500 (EST) Received: from [218.109.237.75] (helo=thinblueline.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Eqiha-0002Qv-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Dec 2005 21:07:10 -0600 From: "Agathangelos Politte" To: "Loup Pickett" Message-ID: <000001c609c9$6ee892d0$63caa8c0@ballistic> Subject: Re: catbird ridge Date: Sun, 25 Dec 2005 22:06:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6099F.86128AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6099F.86128AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.livorundeci.com =20 L P S M C V X A V evitr-a ropeci-a o-ma eridi-a i-alis al-ium an-ax mbie-n i-agra =20 =20 =20 =20 $3,85 $1,25 =20 =20 $3,35 ------=_NextPart_000_0001_01C6099F.86128AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.livorundeci.com

L
P

evitr-a

ropeci-a

o-ma

eridi-a

i-alis

al-ium
an-ax

mbie-n

i-agra

$3,85

$1,25

$3,35

------=_NextPart_000_0001_01C6099F.86128AD0-- From gvxjjhz@mcihispeed.net Mon Dec 26 12:08:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqvpe-0006oq-0y for ipfix-archive@megatron.ietf.org; Mon, 26 Dec 2005 12:08:22 -0500 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 MAA06560 for ; Mon, 26 Dec 2005 12:07:11 -0500 (EST) Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1EqvPL-0002MD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 26 Dec 2005 10:41:11 -0600 Received: from softbank218123244064.bbtec.net (softbank218123244064.bbtec.net [218.123.244.64]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id jBQGf800007700 for ; Mon, 26 Dec 2005 10:41:10 -0600 Received: from FK86150384362177 (modemcable8.8-069.dfd.usa.net 11.36.152.32) (authenticated bits=3) by ksee24mail.com (8.12.10/8.12.9) with ESMTP id iem6II88nb439894 for ; Mon, 26 Dec 2005 11:41:04 -0500 (envelope-from gvxjjhz@mcihispeed.net) Message-ID: <3br60pr35$e59srh65v72$81v85emy0@U95787> From: "Bernadine Goldstein" To: Subject: Costing to much for you Prescription Drugs??? Check this out! Date: Mon, 26 Dec 2005 11:41:04 -0500 MIME-Version: 1.0 X-Mailer: The Bat! (v3.62.14) Content-Type: multipart/mixed; boundary="-----=685845_7702_003P89D39.03240WSRY51523l" -------=685845_7702_003P89D39.03240WSRY51523l Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

hello guys!!

We wi= sh you a happy cristmass ;)
We wish you to forget about all of your pro= blems in the new year !!!

A= nd we can help you ot get rid of some of the most importaint: erectile dis= function; pre-time ejacjulation!

W= ith our revolutional herbal pills it`s not more a problem.
All you have to do is just take everyday two pills of Herbal-V. Herbal-V IS 100% NATURAL. Herbal-V HAS NO KNOWN SIDE EFFECTS.

Herbal-V pills contain a number of herbs like Hygrophila, Saffron, Bleph= aris edulis and others which are known as natural aphrodisiacs for many ye= ars.

Herbal-V helped many thousands of our happy customers and their mates al= l over the world to improve their sexual life and it will certainly help y= ou to improve performance and pleasure.

No prior prescription needed. Worldwide shipping via Hedex/DHL
Fully descreet and anonymous!
SPECIAL CRISTMASS PRICES!!

<= center>order today the Herbal-V = and forget about sex problems!

or just get out from our list,
and kee= p your problems
ruining your life!

-------=685845_7702_003P89D39.03240WSRY51523l Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable -------=685845_7702_003P89D39.03240WSRY51523l-- From majordomo@mil.doit.wisc.edu Wed Dec 28 11:36:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EreHl-0004Gm-Cz for ipfix-archive@megatron.ietf.org; Wed, 28 Dec 2005 11:36:23 -0500 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 LAA06346 for ; Wed, 28 Dec 2005 11:35:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Erduy-0000TY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Dec 2005 10:12:48 -0600 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Erdux-0000TM-00 for ipfix@net.doit.wisc.edu; Wed, 28 Dec 2005 10:12:47 -0600 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id RAA19293; Wed, 28 Dec 2005 17:12:39 +0100 (MET) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id E945FCC1DD; Wed, 28 Dec 2005 17:12:37 +0100 (CET) Message-ID: <43B2B973.2030602@informatik.uni-erlangen.de> Date: Wed, 28 Dec 2005 17:12:35 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg, Germany User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Aitken Cc: ipfix@net.doit.wisc.edu, Gerhard Muenz , Christoph Sommer Subject: Re: [ipfix] Discussion on draft-dressler-ipfix-aggregation-02.txt References: <43AA8877.4080702@informatik.uni-erlangen.de> <43AD9ED2.1030805@cisco.com> In-Reply-To: <43AD9ED2.1030805@cisco.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear Paul, thanks a lot for proofreading and commenting the draft. Most editorial comments will be included in the next version of the draft. Some of your points are commented inline. I wish you a happy new year! Cheers, Falko Paul Aitken wrote: > Falko, > >> We kindly ask you for final comments on the draft. > > > > The middle of figure 2 is badly indented. > > > > In section 4.2, the "discard" and "keep" actions define the fields to be > either "non-key" or "key" fields respectively. "Key" fields are used to > differentiate flows, and can be indicated using the flowKeyIndicator IE > #173. > > > > Insert "while" in the "Aggregate" section of 4.2: > > For example, the meta-flow's start timestamp is set to the minimum of > the original start timestamps, *while* packet and byte counts of > aggregated flows are summed up. > > > > Regarding table 1, it may be necessary to define aggregation actions for > every existing IE to ensure that everyone aggregates them the same way - > and there may be IEs which simply cannot be sensibly aggregated (eg, > address, port, AS, protocol, vlan). > We already listed all IEs that need special handling. Maybe we can elaborate that in more detail. > > > In section 4.4 Rule Semantics: > > Consequently, each flow record is counted at most once per chain or > branch. > > "tree" would be better than "branch". > > > > 4.5 Example > > My interpretation of this example is: > > This rule aggregates all flows > > - no; only flows containing at least sourceTransportPort, > sourceIPv4Address, destinationIPv4Address and packetDeltaCount. > > > to a destination address in the subnet 10.10.0.0/16 > > - what happens to flows to a destination address outwith this subnet? > eg, are they discarded, or aggregated seperately? > This should be clarified under 4.1. > The answer is "nothing, i.e. discard". I agree, we have to clarify that. > > with source port equal to 80. > > - no; sourceTransportPort of 80 is discarded. > - clarify the effect of a pattern in a discard rule? > OK, we'll clarify that. > > Destination addresses are merged according to subnets in 10.10.x.0/24. > > - surely 10.10.0.x/24 ? > Nope, 10.10.x.0/24 is correct. The last byte will always be zero because of the mask operator. > > The resulting meta-flow records comprise the source address, > the destination subnet address, and the packet counter. > > - better to use the proper IE names as in the aggregation rules. > We used the IE names from the IPFIX Info Model?! > > > 5.2 portRanges > > Therefore, the new abstract > data type portRanges for a list of port ranges is defined in this > section. > > The inclusion of the word "port" in the name makes the type quite > specific. Better to introduce a more generic type such as "numberRange", > and make an IE called "portRange" based on the "numberRange" type. > Good comment but difficult to realize. portRange is a "numberRange" using 16 Bit numbers. Possibly, multiple types have to be defined for this case. So far, we only see an application for transport ports... > > Data types basing on portRanges MAY also be cast down to unsigned16 > to represent a single Port. > > Better to use the familiar IPFIX phrase, "Reduced Size Encoding". > OK. > > > Under table 6, > > Note that the flows' > common property, a source IP address in 10.0.0.0/23, was already > transmitted in the template. > > Rather, this is a property of the *discarded* flows! The common property > of the undiscarded flows is that srcIP is NOT in 10.0.0.0/23. > > NACK, not the flows have been discarded but the "field" from a flow record. > > Regarding the example in 5.4, surely the flow to port 110 will match the > rule "discard sourceIPv4Address in 10.0.0.0/23", and so this won't > appear in table 7? > > Can you make an example where field count != data count, and relate > field count and data count to M and N? > > > Cheers. -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ -- 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 blakeu@ranc.com Thu Dec 29 11:34:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es0jr-0005Ey-Lz for ipfix-archive@megatron.ietf.org; Thu, 29 Dec 2005 11:34:51 -0500 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 LAA15659 for ; Thu, 29 Dec 2005 11:33:40 -0500 (EST) Received: from 81-203-122-224.user.ono.com ([81.203.122.224] helo=ranc.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Es0MX-0001xt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Dec 2005 10:10:45 -0600 From: "Mamie Blake" To: "Tryggve Knickerbocker" Message-ID: <000001c60c92$6363ef10$3dbea8c0@vanish> Subject: Re: global impugnable Date: Thu, 29 Dec 2005 11:10:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60C68.7A8DE710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60C68.7A8DE710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable XA VI VA CI NA AG LIU ALI X RA M S =20 from $3.33 from $1.21 from $3.75 http://www.oboherwis.com ------=_NextPart_000_0001_01C60C68.7A8DE710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

AG
LIU
ALI

from $3.33

from $1.21
from = $3.75

http://www.oboherwis.com

------=_NextPart_000_0001_01C60C68.7A8DE710-- From shewmak@fedt.dk Fri Dec 30 19:44:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUrB-0003tO-E6 for ipfix-archive@megatron.ietf.org; Fri, 30 Dec 2005 19:44:25 -0500 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 TAA06496 for ; Fri, 30 Dec 2005 19:43:12 -0500 (EST) Received: from zaqdadc4cfa.zaq.ne.jp ([218.220.76.250] helo=fedt.dk) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1EsUYy-0001zP-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Dec 2005 18:25:36 -0600 Message-ID: <000001c60da0$b6818db0$2396a8c0@embalmment> Reply-To: "Lleu Shewmaker" From: "Lleu Shewmaker" To: "Hanne Padron" Subject: Re: onefigure panoramic Date: Fri, 30 Dec 2005 19:25:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60D76.CDAB85B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?218.220.76.250 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60D76.CDAB85B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable VI VA CI XA AG LIU ALI NA RA M S X from $3.33 from $1.21 from $3.75 =20 http://www.themanwo.com ------=_NextPart_000_0001_01C60D76.CDAB85B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

VI

VA

CI

XA

AG

LIU
ALI

NA

RA

M
S
X

from $3.33

from $1.21

from $3.75

http://www.themanwo.com

= ------=_NextPart_000_0001_01C60D76.CDAB85B0--