From owner-rtfm@auckland.ac.nz Wed Mar 14 00:58:19 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05307 for ; Wed, 14 Mar 2001 00:58:18 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id RAA17740; Wed, 14 Mar 2001 17:04:46 +1300 (NZDT) Received: from nevil.caida.org (bluebottle.itss.auckland.ac.nz [130.216.4.28]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id RAA17732 for ; Wed, 14 Mar 2001 17:04:44 +1300 (NZDT) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: RTFM: Informal get-together at Minneapolis IETF Message-ID: Date: Wed, 14 Mar 2001 16:11:58 +1200 (NZT) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: It seems we're unlikely to get an RTFM2 WG approved as proposed at our San Diego BOF. Which is why there's no follow-on session in Minneapolis. Instead we'll hold our now-traditional informal get-together at Wednesday lunchtime. If we need more time we'll arrange that, probably Wednesday evening (any suggestions as to a suitable time would be appreciated). Discussion topics: - Vendor-neutral description of flows and ways to report them - Distributed monitoring (hardware requirements, data gathering, potential uses, etc.) I'll post a notice on the IETF Notice Board when we've managed to organise a meeting place. See you in Minneapolis, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------C From owner-rtfm@auckland.ac.nz Wed Mar 14 07:13:22 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22416 for ; Wed, 14 Mar 2001 07:13:21 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA21106; Wed, 14 Mar 2001 23:23:52 +1300 (NZDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id XAA21100; Wed, 14 Mar 2001 23:23:48 +1300 (NZDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA25340; Wed, 14 Mar 2001 11:23:38 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA10738; Wed, 14 Mar 2001 11:22:40 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 11:22:38 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42ABDEFFD@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Nevil Brownlee'" , rtfm@auckland.ac.nz Subject: RE: RTFM: Informal get-together at Minneapolis IETF Date: Wed, 14 Mar 2001 11:22:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-rtfm@auckland.ac.nz Precedence: bulk > It seems we're unlikely to get an RTFM2 WG approved as proposed at our > San Diego BOF. Which is why there's no follow-on session in > Minneapolis. > Could you give some details what is the problem? Is it that they are not happy with the topic, with the support by the community, or is it that the approval is just delayed? > Instead we'll hold our now-traditional informal get-together at > Wednesday lunchtime. If we need more time we'll arrange that, probably > Wednesday evening (any suggestions as to a suitable time would be > appreciated). > > Discussion topics: > - Vendor-neutral description of flows and ways to report them > - Distributed monitoring (hardware requirements, data gathering, > potential uses, etc.) > Wouldn't it make sense to also discuss the further proceedings to achieve WG status (mind you, I won't be able to participate - just following from a distance) Cornelia. From owner-rtfm@auckland.ac.nz Fri Mar 16 19:11:36 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15797 for ; Fri, 16 Mar 2001 19:11:34 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id LAA05600; Sat, 17 Mar 2001 11:42:09 +1300 (NZDT) Received: from nevil.caida.org (bluebottle.itss.auckland.ac.nz [130.216.4.28]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id LAA05595 for ; Sat, 17 Mar 2001 11:42:07 +1300 (NZDT) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: RTFM: Informal get-together at Minneapolis IETF Message-ID: Date: Sat, 17 Mar 2001 10:49:18 +1200 (NZT) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello Cornelia: The problem (as I see it) is that IESG doesn't think RTFM is widely used, because no-one is selling an RTFM meter built into a router or switch. Without more (hardware) implementation experience, it's hard to press for changes to the exisiting RTFM architecture. To move forward, and do the new things we talked about at the BOF in San Diego, it needs to be framed within a new Working Group. Such a group would have a better chance of getting chartered. Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------C From owner-rtfm@auckland.ac.nz Mon Mar 19 13:26:21 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17479 for ; Mon, 19 Mar 2001 13:26:20 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA06564; Tue, 20 Mar 2001 05:00:15 +1200 (NZST) Received: from caida.org (ipn.caida.org [192.172.226.30]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA06555 for ; Tue, 20 Mar 2001 05:00:13 +1200 (NZST) Received: from localhost (nevil@localhost) by caida.org (8.9.3+Sun/8.9.1) with ESMTP id JAA12502 for ; Mon, 19 Mar 2001 09:00:11 -0800 (PST) Date: Mon, 19 Mar 2001 09:00:11 -0800 (PST) From: Nevil Brownlee To: Subject: RTFM get-together Wed 21 March Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: The RTFM INformal get-together at the Minneapolis IETF will be held in: Directors Row 2 starting at: 1140, Wednesday 21 March Items to discuss: What to do next? Possible WG (or WGs) on - Standard Flow Export - Distributed measurements - Other router-based measurements Cheers, Nevil ------------------------------------------------------------- Nevil Brownlee Internet Researcher Phone: (858) 534 8338 CAIDA, San Diego From owner-rtfm@auckland.ac.nz Tue Mar 20 00:24:39 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07852 for ; Tue, 20 Mar 2001 00:24:37 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id PAA04036; Tue, 20 Mar 2001 15:06:10 +1200 (NZST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id PAA03906 for ; Tue, 20 Mar 2001 15:05:39 +1200 (NZST) Received: from ccrle.nec.de (pcp001402pcs.wireless.meeting.ietf.org [135.222.67.134]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2K2vxw08117; Mon, 19 Mar 2001 20:57:59 -0600 (CST) Message-ID: <3AB6C71C.A81979B8@ccrle.nec.de> Date: Tue, 20 Mar 2001 03:57:32 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Kappler Cornelia CC: RTFM mailing list Subject: Re: charter goal #2a References: <4D486782CA36D4118A530000D11EA42A273C26@blns204e.bln.icn.siemens.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hi Cornelia, Kappler Cornelia wrote: > > > -----Original Message----- > > From: Juergen Quittek [SMTP:quittek@ccrle.nec.de] > > Sent: Thursday, February 08, 2001 8:37 AM > > To: RTFM mailing list > > Subject: charter goal #2a > > > Juergen, > > > - What would be the resulting benefit? > > I observe a growing need for traffic metering in the Internet, > > mainly driven by two application areas: IP charging & accounting > > and monitoring service level agreements. Both are requirements > > of service providers. > > In charging and accounting, the requirement is to measure volume > > or session duration for specific users and for specific (value > > added) services. > > In SLA monitoring an ISP (or the customer) needs to check if a > > service (VPN, e-commerce server, access bandwidth & volume, etc) > > complies to some service level agreement. > > In both areas a non-proprietary (and available!) distribute > > metering architecture would be of high benefit. > > > I understood when Carter explained distributed metering is useful for > specific metrics in which the same packet needs to be captured twice > (correct?) as e.g. delay and reachabilty. Yes, for these applications you need to measure at more than one place. > > The ones you cite however seem to be doable with the just a single > meter or a collection of old-fashioned meters. Well, if your clocks are sufficiently precise and synchronized also for the measurements you mentioned above, a set of "old-fashioned" meters could be fine. However, one of my motivations for developing a distributed metering architecture is that it exploits the capabilities of modern routers with little overhead required. "Modern" routers, e.g. with DiffServ support, already have some packet classifier built in hardware or software. I believe that this existing functionality can be used for metering. One of the reasons why it is not being used so far might be that the implementation effort is high. Implementing e.g. the Meter MIB is not a trivial task. But if only a small, simple extension of the existing device is required, it might be easier to convince manufacturers to implement it. So basic packet capturing and very simple classification should be suggested for distributed metering devices sending captured packets or summaries of these to a central and more complex software meter. > > E.g. for charging I might just count the number of packets as they > leave the network, their QoS, and note their source/destination. > > A number of *communicating* meters is needed for SLA monitoring. > If the SLA specifies e.g. total bandwidth per traffic class for a > specific customer, I need to count the average number of packets per > traffic class of this customer coming out of the network and add the > contribution of all egress points. This number needs to be compared > to the average total bandwidth of this traffic class and customer > trying to gain access to the network. So this is distributed. > However, since I don't need to look at the individual packet, why > don't I just compile information from several ordinary meters? > > Cornelia -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., C&C Research Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de From owner-rtfm@auckland.ac.nz Mon Mar 26 00:53:13 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26736 for ; Mon, 26 Mar 2001 00:53:09 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id PAA18223; Mon, 26 Mar 2001 15:57:20 +1200 (NZST) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id PAA18211 for ; Mon, 26 Mar 2001 15:57:19 +1200 (NZST) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: RTFM Get-together report: Standard Flow Export Message-ID: Date: Mon, 26 Mar 2001 15:58:45 +1200 (New Zealand Standard Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk RTFM Informal Get-together, Minneapolis IETF, 1145, Wed 21 Mar 01 Notes by Nevil Brownlee (CAIDA / U Auckland) 21 people were present. Nevil Brownlee reported on the RTFM2 BOF held at the San Diego IETF meeting last December. The BOF was followed up with some interesting discussion on the mailing list, but it appears unlikely that RTFM2 will progress to become a new IETF Working Group. The rest of the meeting was spent discussing other ways of proceeding. These were: A. Standard Flow Export The requirement here is for a standard definition of traffic flows, together with effective transport mechanisms allowing both push and pull of large amounts of flow data. Current systems for this (in the public domain) include NetFlow (Cisco), LFAP (Riverstone) and RTFM. A working group to develop such a standard would fit well in the Ops & Management Area. Mike McFaden (Riverstone) and Chris Elliott (Cisco) agreed to start moves towards forming a Working Group, by initiating discussion on the RTFM mailing list, To begin with, we'd like to gather opinions as to what we really mean when we speak of 'flows.' [Nevil volunteered to add everyone at the get-together to the RTFM list, rtfm@auckland.ac.nz. It's a majordomo list, majordomo@auckland.ac.nz] To get a Working Group chartered we need: - One or more Internet Drafts, at least one of which should be a 'requirements' draft. (These are submitted and published as individual drafts.) - A draft charter, setting out clearly what the WG wants to do, including realistic Goals and Milestones. - Two or three co-chairs to run a BOF. - Support from Area Director(s). To get a BOF scheduled at the next IETF meeting, (London early in August) we need to see drafts published by about the end of April. Anyone willing / able to write such drafts is encouraged to do so; Nevil is prepared to act as document editor to collate material sent to the mailing list. B. Transport Performance Measuremnt (TPM) in RMON Carter Bullard reported that the RMON WG has TPM as a work item, and suggested that it could be a good place (within the IETF) for new work on measurements, e.g. implementing some of the IPPM metrics. There was general agreement. [At the RMON WG meeting Thursday monring (22 Mar), the WG decided that they would not proceed further with TPM.] C. Measurements in Routers Nevil reported discussions with our Transport Area Directors on this topic. It seems there could well be support for a Transport Area Working Group on this topic. Nevil is preparing a short document setting out the kinds of measurements users (i.e. ISPs) would like to make in routers. He'd like to hear opinions, suggestions etc. on this (via the RTFM mailing list) from anyone who's interested. Even better, he'd like to hear from people (and/or vendors) who'd be prepared to contribute to such a WG. The meeting finished at 1220. +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From owner-rtfm@auckland.ac.nz Mon Mar 26 14:05:32 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14323 for ; Mon, 26 Mar 2001 14:05:30 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA14029; Tue, 27 Mar 2001 05:25:47 +1200 (NZST) Received: from riverstonenet.com (mail.riverstonenetworks.net [63.113.148.10]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA14023 for ; Tue, 27 Mar 2001 05:25:45 +1200 (NZST) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA08554; Mon, 26 Mar 2001 09:25:15 -0800 (PST) Received: from valhalla.yagosys.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id JAA04611; Mon, 26 Mar 2001 09:25:14 -0800 Message-Id: <4.3.2.7.1.20010326092734.0374ef08@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Mar 2001 09:28:31 -0800 To: rtfm@auckland.ac.nz From: Michael MacFaden Subject: Fwd: Standard Flow Export - definition of 'flows' Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rtfm@auckland.ac.nz Precedence: bulk >At 03:58 PM 3/26/2001 +1200, Nevil Brownlee >[snip] >>A. Standard Flow Export >> >>The requirement here is for a standard definition >>of traffic flows, together with effective transport >>mechanisms allowing both push and pull of large >>amounts of flow data. Current systems for this >>(in the public domain) include NetFlow (Cisco), >>LFAP (Riverstone) and RTFM. A working group to >>develop such a standard would fit well in the >>Ops & Management Area. >> >>Mike McFaden (Riverstone) and Chris Elliott (Cisco) >>agreed to start moves towards forming a Working Group, >>by initiating discussion on the RTFM mailing list, >>To begin with, we'd like to gather opinions as to what >>we really mean when we speak of 'flows.' > >Great, so let's begin! > >Rekhter and Davies use the following in >"MPLS Technologies and Applications" on > >page 155: > individual application flows - microflows > >page 196 > A traffic trunk is defined as a collection of individual TCP, > or UDP, flows, known as "microflows" that share two > common properties. The first one is that all microflows > are forwarded along the same common path. > The second is that they all share the same Class of Service. > >But as Rekhter and Davies point out, scaling anything that deals >with microflows is difficult and thus is quickly relegated further >towards the edge of a network as traffic volume increases. > >Regards, >Mike MacFaden >www.riverstonenet.com From owner-rtfm@auckland.ac.nz Mon Mar 26 17:37:34 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19583 for ; Mon, 26 Mar 2001 17:37:32 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA09112; Tue, 27 Mar 2001 08:49:31 +1200 (NZST) Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA09074 for ; Tue, 27 Mar 2001 08:49:24 +1200 (NZST) Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 14hdux-0002Cn-00 for rtfm@auckland.ac.nz; Mon, 26 Mar 2001 14:48:47 -0600 Date: Mon, 26 Mar 2001 14:48:47 -0600 From: Dave Plonka To: rtfm@auckland.ac.nz Subject: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'") Message-ID: <20010326144847.A6526@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <4.3.2.7.1.20010326092734.0374ef08@mordor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.1.20010326092734.0374ef08@mordor>; from mrm@riverstonenet.com on Mon, Mar 26, 2001 at 09:28:31AM -0800 Organization: UW-Madison, DoIT, Network Engineering Technology X-VMS-Error: %SYSTEM-E-NOTCREATOR, request denied X-Shakespearean-Insult: Thou gleeking tardy-gaited flap-dragon Sender: owner-rtfm@auckland.ac.nz Precedence: bulk On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > >At 03:58 PM 3/26/2001 +1200, Nevil Brownlee > >[snip] > >>A. Standard Flow Export > >> > >>The requirement here is for a standard definition > >>of traffic flows, together with effective transport > >>mechanisms allowing both push and pull of large > >>amounts of flow data. Current systems for this > >>(in the public domain) include NetFlow (Cisco), > >>LFAP (Riverstone) and RTFM. A working group to > >>develop such a standard would fit well in the > >>Ops & Management Area. > >> > >>Mike McFaden (Riverstone) and Chris Elliott (Cisco) > >>agreed to start moves towards forming a Working Group, > >>by initiating discussion on the RTFM mailing list, > >>To begin with, we'd like to gather opinions as to what > >>we really mean when we speak of 'flows.' > > > >Great, so let's begin! In my mind, the IP flow definition would go something more along these lines: An IP flow is a unidirectional series of IP packets of a given protocol, traveling between a source and destination, within a certain period of time. The source and destination are defined, at least, by IP address, forming a "host pair". For IP protocols which further qualify the source and destination endpoints with a /port/ number, those port numbers become part of the source and destination, forming a "host and port quadruple" (source-address, source-port, destination-address, destination-port). Some of that is glommed from my paper here: http://net.doit.wisc.edu/~plonka/lisa/FlowScan/#ToC4 http://net.doit.wisc.edu/~plonka/lisa/FlowScan/out.ps.gz where I referenced Claffy, K. C. and Braun, Hans-Werner and Polyzos, George C.: http://www.caida.org/outreach/papers/itf.html > >Rekhter and Davies use the following in > >"MPLS Technologies and Applications" on > > > >page 155: > > individual application flows - microflows > > > >page 196 > > A traffic trunk is defined as a collection of individual TCP, > > or UDP, flows, known as "microflows" that share two > > common properties. The first one is that all microflows > > are forwarded along the same common path. I follow-up with a seperate post regarding the consequences of including the "forwarded along the same common path" statement in the flow definition. > > The second is that they all share the same Class of Service. > > > >But as Rekhter and Davies point out, scaling anything that deals > >with microflows is difficult and thus is quickly relegated further > >towards the edge of a network as traffic volume increases. I'll post another follow-up focusing on flow duration. This is directly related to scaling as it defines how much state information a device must keep regarding flows. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI From owner-rtfm@auckland.ac.nz Mon Mar 26 17:46:33 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19786 for ; Mon, 26 Mar 2001 17:46:30 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id JAA12916; Tue, 27 Mar 2001 09:04:46 +1200 (NZST) Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id JAA12901 for ; Tue, 27 Mar 2001 09:04:43 +1200 (NZST) Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 14he9n-0002WL-00 for rtfm@auckland.ac.nz; Mon, 26 Mar 2001 15:04:07 -0600 Date: Mon, 26 Mar 2001 15:04:07 -0600 From: Dave Plonka To: rtfm@auckland.ac.nz Subject: IP flow def'n: "forwarded along the same common path"? multicast consequences? Message-ID: <20010326150407.A8554@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <4.3.2.7.1.20010326092734.0374ef08@mordor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.1.20010326092734.0374ef08@mordor>; from mrm@riverstonenet.com on Mon, Mar 26, 2001 at 09:28:31AM -0800 Organization: UW-Madison, DoIT, Network Engineering Technology X-VMS-Error: %SYSTEM-F-SHMGSNOTMAP, shared memory global section not mapped during creation X-Shakespearean-Insult: Thou fobbing common-kissing canker-blossom Sender: owner-rtfm@auckland.ac.nz Precedence: bulk On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > >Rekhter and Davies use the following in > >"MPLS Technologies and Applications" on > > > >page 155: > > individual application flows - microflows > > > >page 196 > > A traffic trunk is defined as a collection of individual TCP, > > or UDP, flows, known as "microflows" that share two > > common properties. The first one is that all microflows > > are forwarded along the same common path. > > The second is that they all share the same Class of Service. If "forwarded along the same common path" were part of our flow definition I'm wondering if that means an IP flow would be defined by input and output ifIndex as NetFlow or LFAP flows are currently with a single input and output ifIndex? If so, this is somewhat problematic for IP mulicast traffic since the set of egress interfaces can change on a multicast-aware IP router or switch. It would be a shame to have to terminate/export multicast flows whenever the set of egress interfaces changed because of a new host joining an existing multicast group. I think I'm OK with leaving the ingress interface (ifIndex) as part of the flow def'n. but I'm wondering if we can create a new method by which output ifIndexes can be added and removed without terminating the flow. (A flow update... this means that each flow would need to have a unique identifier/handle/label by which the flow could be referred in an update.) I just wanted to mention this issue now (so as not to forget it)... perhaps it can be revisited when export PDUs are discussed. However, I do think it's important to be sure that we consider the consequences if the flow definition causing us to have to terminate an export multicast flows every time a multicast group join or leave occurs. That said, "forwarded along the same common path" (as defined by an "ifIndex pair") is a clause to use for unicast IP traffic. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI From owner-rtfm@auckland.ac.nz Mon Mar 26 22:41:58 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28057 for ; Mon, 26 Mar 2001 22:41:53 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA25850; Tue, 27 Mar 2001 13:47:38 +1200 (NZST) Received: from exc-sc1.yagosys.com (host3.riverstonenetworks.net [63.113.148.3] (may be forged)) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA25841 for ; Tue, 27 Mar 2001 13:47:35 +1200 (NZST) Received: from riverstonenet.com (JACK65 [134.141.180.80]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HXFCF81W; Mon, 26 Mar 2001 17:47:21 -0800 Message-ID: <3ABFEFC5.D1AEEA1E@riverstonenet.com> Date: Mon, 26 Mar 2001 20:41:25 -0500 From: Paul Calato X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "rtfm@auckland.ac.nz" Subject: Re: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'") References: <4.3.2.7.1.20010326092734.0374ef08@mordor> <20010326144847.A6526@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit I'll muddy the waters a little further. A flow is a user defined key. One customer may need to have data collected based on source and destination IP, while another needs it based on source and destination AS and still another needs it based solely on ingress port. Thus you either have to have an all encompasing key so that the aggregates can be calculated with post processing or you need a way to allow the key to be set. Paul Dave Plonka wrote: > > On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > > > >At 03:58 PM 3/26/2001 +1200, Nevil Brownlee > > >[snip] > > >>A. Standard Flow Export > > >> > > >>The requirement here is for a standard definition > > >>of traffic flows, together with effective transport > > >>mechanisms allowing both push and pull of large > > >>amounts of flow data. Current systems for this > > >>(in the public domain) include NetFlow (Cisco), > > >>LFAP (Riverstone) and RTFM. A working group to > > >>develop such a standard would fit well in the > > >>Ops & Management Area. > > >> > > >>Mike McFaden (Riverstone) and Chris Elliott (Cisco) > > >>agreed to start moves towards forming a Working Group, > > >>by initiating discussion on the RTFM mailing list, > > >>To begin with, we'd like to gather opinions as to what > > >>we really mean when we speak of 'flows.' > > > > > >Great, so let's begin! > > In my mind, the IP flow definition would go something more along these > lines: > > An IP flow is a unidirectional series of IP packets of a given > protocol, traveling between a source and destination, within a > certain period of time. > > The source and destination are defined, at least, by IP address, > forming a "host pair". > > For IP protocols which further qualify the source and destination > endpoints with a /port/ number, those port numbers become part of > the source and destination, forming a "host and port quadruple" > (source-address, source-port, destination-address, > destination-port). > > Some of that is glommed from my paper here: > > http://net.doit.wisc.edu/~plonka/lisa/FlowScan/#ToC4 > http://net.doit.wisc.edu/~plonka/lisa/FlowScan/out.ps.gz > > where I referenced Claffy, K. C. and Braun, Hans-Werner and Polyzos, > George C.: > > http://www.caida.org/outreach/papers/itf.html > > > >Rekhter and Davies use the following in > > >"MPLS Technologies and Applications" on > > > > > >page 155: > > > individual application flows - microflows > > > > > >page 196 > > > A traffic trunk is defined as a collection of individual TCP, > > > or UDP, flows, known as "microflows" that share two > > > common properties. The first one is that all microflows > > > are forwarded along the same common path. > > I follow-up with a seperate post regarding the consequences of > including the "forwarded along the same common path" statement in the > flow definition. > > > > The second is that they all share the same Class of Service. > > > > > >But as Rekhter and Davies point out, scaling anything that deals > > >with microflows is difficult and thus is quickly relegated further > > >towards the edge of a network as traffic volume increases. > > I'll post another follow-up focusing on flow duration. This is > directly related to scaling as it defines how much state information a > device must keep regarding flows. > > Dave > > -- > plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI From owner-rtfm@auckland.ac.nz Tue Mar 27 03:30:39 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15241 for ; Tue, 27 Mar 2001 03:30:38 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id TAA25519; Tue, 27 Mar 2001 19:19:20 +1200 (NZST) Received: from archief.telin.nl (ijszee.telin.nl [195.169.16.25]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id TAA25513 for ; Tue, 27 Mar 2001 19:19:18 +1200 (NZST) Received: from telin.nl ([195.169.16.249]) by archief.telin.nl (Lotus Domino Release 5.0.5) with ESMTP id 2001032709312322:1325 ; Tue, 27 Mar 2001 09:31:23 +0200 Message-ID: <3AC04072.F27B63F1@telin.nl> Date: Tue, 27 Mar 2001 09:25:38 +0200 From: Remco Poortinga Organization: Telematica Instituut X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rtfm@auckland.ac.nz Subject: Re: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'") References: <4.3.2.7.1.20010326092734.0374ef08@mordor> <20010326144847.A6526@doit.wisc.edu> X-MIMETrack: Itemize by SMTP Server on ARCHIEF/SRV/TELIN/NL(Release 5.0.5 |September 22, 2000) at 03/27/2001 09:31:23 AM, Serialize by Router on ARCHIEF/SRV/TELIN/NL(Release 5.0.5 |September 22, 2000) at 03/27/2001 09:31:58 AM, Serialize complete at 03/27/2001 09:31:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, Dave Plonka wrote: > [snip] > In my mind, the IP flow definition would go something more along these > lines: > > An IP flow is a unidirectional series of IP packets of a given > protocol, [insert] and Class of Service (and maybe more/others if we look at the IPv6 header?) >traveling between a source and destination, within a > certain period of time. > The source and destination are defined, at least, by IP address, > forming a "host pair". > > For IP protocols which further qualify the source and destination > endpoints with a /port/ number, those port numbers become part of > the source and destination, forming a "host and port quadruple" > (source-address, source-port, destination-address, > destination-port). > Cheers, Remco From owner-rtfm@auckland.ac.nz Tue Mar 27 09:59:55 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19053 for ; Tue, 27 Mar 2001 09:59:54 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA18881; Wed, 28 Mar 2001 01:16:53 +1200 (NZST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA18874 for ; Wed, 28 Mar 2001 01:16:51 +1200 (NZST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f2RDH4e90482; Tue, 27 Mar 2001 15:17:04 +0200 (CEST) Received: from ccrle.nec.de (belem.heidelberg.ccrle.nec.de [192.168.102.178]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA08999; Tue, 27 Mar 2001 15:14:15 +0200 Message-ID: <3AC092BB.FD1B5BD0@ccrle.nec.de> Date: Tue, 27 Mar 2001 15:16:43 +0200 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: plonka@doit.wisc.edu CC: rtfm@auckland.ac.nz Subject: Re: IP flow def'n: "forwarded along the same common path"? multicast consequences? References: <4.3.2.7.1.20010326092734.0374ef08@mordor> <20010326150407.A8554@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Dave Plonka wrote: > > On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > >Rekhter and Davies use the following in > > >"MPLS Technologies and Applications" on > > > > > >page 155: > > > individual application flows - microflows > > > > > >page 196 > > > A traffic trunk is defined as a collection of individual TCP, > > > or UDP, flows, known as "microflows" that share two > > > common properties. The first one is that all microflows > > > are forwarded along the same common path. > > > The second is that they all share the same Class of Service. > > If "forwarded along the same common path" were part of our flow > definition I'm wondering if that means an IP flow would be defined by > input and output ifIndex as NetFlow or LFAP flows are currently with a > single input and output ifIndex? > > If so, this is somewhat problematic for IP mulicast traffic since the > set of egress interfaces can change on a multicast-aware IP router or > switch. It would be a shame to have to terminate/export multicast > flows whenever the set of egress interfaces changed because of a new > host joining an existing multicast group. > > I think I'm OK with leaving the ingress interface (ifIndex) as part of > the flow def'n. but I'm wondering if we can create a new method by > which output ifIndexes can be added and removed without terminating the > flow. (A flow update... this means that each flow would need to have a > unique identifier/handle/label by which the flow could be referred in > an update.) > > I just wanted to mention this issue now (so as not to forget it)... > perhaps it can be revisited when export PDUs are discussed. > > However, I do think it's important to be sure that we consider the > consequences if the flow definition causing us to have to terminate an > export multicast flows every time a multicast group join or leave > occurs. > > That said, "forwarded along the same common path" (as defined by an > "ifIndex pair") is a clause to use for unicast IP traffic. I don't think the term "path" is appropriate here. You did well by defining it given by an "ifIndex pair", but the general understanding of the term is different and more general, particularly in the definition of an MPLS traffic trunk cited above. In an MPLS domain, each packet with the same source and destination address takes exactly the same path, not just in terms of interfaces of a single device, but in terms of all routers in the domain. This does not hold in general in IP networks. If we adopt the term path, but define it differently (as you suggested), we will confuse a lot of people. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., C&C Research Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de From owner-rtfm@auckland.ac.nz Tue Mar 27 12:05:46 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23088 for ; Tue, 27 Mar 2001 12:05:45 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA24760; Wed, 28 Mar 2001 03:06:11 +1200 (NZST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id DAA24748 for ; Wed, 28 Mar 2001 03:06:09 +1200 (NZST) Received: from brazil.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Mar 2001 16:05:57 +0100 Date: Tue, 27 Mar 2001 16:11:52 +0100 (BST) From: Marcelo Pias To: Dave Plonka cc: rtfm@auckland.ac.nz Subject: Re: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'") In-Reply-To: <20010326144847.A6526@doit.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello, On Mon, 26 Mar 2001, Dave Plonka wrote: > On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > > > >At 03:58 PM 3/26/2001 +1200, Nevil Brownlee > > >[snip] > > >>A. Standard Flow Export > > >> > > >>The requirement here is for a standard definition > > >>of traffic flows, together with effective transport > > >>mechanisms allowing both push and pull of large > > >>amounts of flow data. Current systems for this > > >>(in the public domain) include NetFlow (Cisco), > > >>LFAP (Riverstone) and RTFM. A working group to > > >>develop such a standard would fit well in the > > >>Ops & Management Area. > > >> > > >>Mike McFaden (Riverstone) and Chris Elliott (Cisco) > > >>agreed to start moves towards forming a Working Group, > > >>by initiating discussion on the RTFM mailing list, > > >>To begin with, we'd like to gather opinions as to what > > >>we really mean when we speak of 'flows.' > > > > > >Great, so let's begin! > > In my mind, the IP flow definition would go something more along these > lines: > > An IP flow is a unidirectional series of IP packets of a given > protocol, traveling between a source and destination, within a > certain period of time. > I think the above definition fits quite well in a general sense. Things that I believe should be considered are: (a) granularity of flow (fine or bulk). Do we need to have this distinction in the definition? Or it's just matter of how you identify a flow? (b) a flow definition *without including ways to identify a flow* (c) flow identification as any combination of IP address, port numbers, flow label (ipv6), flowID, ifIndex... My suggestion would be to not mix "flow definition" with its identification since we can use any combination of identification which would lead to a more generic definition. Cheers. Marcelo From owner-rtfm@auckland.ac.nz Tue Mar 27 12:27:20 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23646 for ; Tue, 27 Mar 2001 12:27:19 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA27025; Wed, 28 Mar 2001 03:50:13 +1200 (NZST) Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id DAA27020 for ; Wed, 28 Mar 2001 03:50:12 +1200 (NZST) Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 14hvj2-0004Oz-00; Tue, 27 Mar 2001 09:49:40 -0600 Date: Tue, 27 Mar 2001 09:49:40 -0600 From: Dave Plonka To: rtfm@auckland.ac.nz Cc: Paul Calato Subject: Re: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'") Message-ID: <20010327094940.A16702@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <4.3.2.7.1.20010326092734.0374ef08@mordor> <20010326144847.A6526@doit.wisc.edu> <3ABFEFC5.D1AEEA1E@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3ABFEFC5.D1AEEA1E@riverstonenet.com>; from calato@riverstonenet.com on Mon, Mar 26, 2001 at 08:41:25PM -0500 Organization: UW-Madison, DoIT, Network Engineering Technology X-VMS-Error: %RMS-F-NORMAL, normal successful completion X-Shakespearean-Insult: Thou craven ill-nurtured gudgeon Sender: owner-rtfm@auckland.ac.nz Precedence: bulk On Mon, Mar 26, 2001 at 08:41:25PM -0500, Paul Calato wrote: > > I'll muddy the waters a little further. A flow is a user > defined key. One customer may need to have data collected > based on source and destination IP, while another needs > it based on source and destination AS and still another > needs it based solely on ingress port. > > Thus you either have to have an all encompasing key so that > the aggregates can be calculated with post processing or > you need a way to allow the key to be set. OK, then I see a couple sorts of directions we could go with this flow definition: 1) A simple definition, such as: A "standard" IP flow is a seqeunce of IP packets [...]. This sort of defintion lets the implementor know what information they must maintain in the "flow" and what may be discarded. (For instance, mid-flow packet arrival times and IP payload can be discarded.) This definition is a sort of recipe for converting a trace consisting of IP packet headers into flow records. Note that this sort definition does not preclude an implementor from providing aggregate counters that tally totals across like flows. 2) A complex definition, such as: A "standard" IP flow as a nebulous thing, defined by set of user-defined "keys" [...]. This sounds like the sort that Paul suggests, and I think is what NeTraMet allows. This definition ties the concept of arbitrary aggregation (for counters) into the flow definition. Is this necessary? Perhaps we wouldn't really lose anything by writing the simpler definition (1) because aggregation can still be subsequently defined and implemented on either the router/switch or in the collector/post-processor. With this 2nd type of definition, the term "flow" remains nebulous (as it is today). Personally, I'd like to be able to talk with someone about "RFCn standard" IP flows, and have a pretty good idea what they are talking about without them having to enumerate the application-specific key values. I'd rather those be a function of the flow's IP protocol. If you agree, then perhaps we can first define the standard IP flow - the atomic data object. Then, using terminology such as Paul suggested, we can define the methods of aggregation which can be applied to those primitive data objects. Dave > Dave Plonka wrote: > > > > On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > > > > > >At 03:58 PM 3/26/2001 +1200, Nevil Brownlee > > > >[snip] > > > >>A. Standard Flow Export > > > >> > > > >>The requirement here is for a standard definition > > > >>of traffic flows, together with effective transport > > > >>mechanisms allowing both push and pull of large > > > >>amounts of flow data. Current systems for this > > > >>(in the public domain) include NetFlow (Cisco), > > > >>LFAP (Riverstone) and RTFM. A working group to > > > >>develop such a standard would fit well in the > > > >>Ops & Management Area. > > > >> > > > >>Mike McFaden (Riverstone) and Chris Elliott (Cisco) > > > >>agreed to start moves towards forming a Working Group, > > > >>by initiating discussion on the RTFM mailing list, > > > >>To begin with, we'd like to gather opinions as to what > > > >>we really mean when we speak of 'flows.' > > > > > > > >Great, so let's begin! > > > > In my mind, the IP flow definition would go something more along these > > lines: > > > > An IP flow is a unidirectional series of IP packets of a given > > protocol, traveling between a source and destination, within a > > certain period of time. > > > > The source and destination are defined, at least, by IP address, > > forming a "host pair". > > > > For IP protocols which further qualify the source and destination > > endpoints with a /port/ number, those port numbers become part of > > the source and destination, forming a "host and port quadruple" > > (source-address, source-port, destination-address, > > destination-port). > > > > Some of that is glommed from my paper here: > > > > http://net.doit.wisc.edu/~plonka/lisa/FlowScan/#ToC4 > > http://net.doit.wisc.edu/~plonka/lisa/FlowScan/out.ps.gz > > > > where I referenced Claffy, K. C. and Braun, Hans-Werner and Polyzos, > > George C.: > > > > http://www.caida.org/outreach/papers/itf.html > > > > > >Rekhter and Davies use the following in > > > >"MPLS Technologies and Applications" on > > > > > > > >page 155: > > > > individual application flows - microflows > > > > > > > >page 196 > > > > A traffic trunk is defined as a collection of individual TCP, > > > > or UDP, flows, known as "microflows" that share two > > > > common properties. The first one is that all microflows > > > > are forwarded along the same common path. > > > > I follow-up with a seperate post regarding the consequences of > > including the "forwarded along the same common path" statement in the > > flow definition. > > > > > > The second is that they all share the same Class of Service. > > > > > > > >But as Rekhter and Davies point out, scaling anything that deals > > > >with microflows is difficult and thus is quickly relegated further > > > >towards the edge of a network as traffic volume increases. > > > > I'll post another follow-up focusing on flow duration. This is > > directly related to scaling as it defines how much state information a > > device must keep regarding flows. -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI From owner-rtfm@auckland.ac.nz Tue Mar 27 12:55:37 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24359 for ; Tue, 27 Mar 2001 12:55:35 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA28855; Wed, 28 Mar 2001 04:21:59 +1200 (NZST) Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id EAA28850 for ; Wed, 28 Mar 2001 04:21:58 +1200 (NZST) Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 14hwDn-0005AH-00; Tue, 27 Mar 2001 10:21:27 -0600 Date: Tue, 27 Mar 2001 10:21:27 -0600 From: Dave Plonka To: rtfm@auckland.ac.nz Cc: Remco Poortinga Subject: Re: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'") Message-ID: <20010327102127.B16702@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <4.3.2.7.1.20010326092734.0374ef08@mordor> <20010326144847.A6526@doit.wisc.edu> <3AC04072.F27B63F1@telin.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3AC04072.F27B63F1@telin.nl>; from poortinga@telin.nl on Tue, Mar 27, 2001 at 09:25:38AM +0200 Organization: UW-Madison, DoIT, Network Engineering Technology X-VMS-Error: %SYSTEM-W-VECALIGN, vector alignment exception, reason mask=00, virtual address=000004F4, PC=7FED6580, PS=00000000 X-Shakespearean-Insult: Thou warped dismal-dreaming hedge-pig Sender: owner-rtfm@auckland.ac.nz Precedence: bulk On Tue, Mar 27, 2001 at 09:25:38AM +0200, Remco Poortinga wrote: > Hello all, > > Dave Plonka wrote: > > > [snip] > > In my mind, the IP flow definition would go something more along these > > lines: > > > > An IP flow is a unidirectional series of IP packets of a given > > protocol, > > [insert] > and Class of Service > (and maybe more/others if we look at the IPv6 header?) Rather than attempting to enumerate all the "keys" which could be used to define an IP flow, I've been wondering if these "keys" should be defined to be whatever set of IP header fields which the router is capable of using to make filtering or forward decisions. I.e. It may be permissible for a given device, which is capable of only "traditional" routing based on IP destination and has simple ACLs to block by address and port, to maintain flow records defined solely by IP protocol and src/dst addresses. However, another piece of gear which is capable of doing some sort of policy routing based upon port numbers should have a standard flow [export] implementation that must be capable of including the TCP/UDP port numbers as a key that defines a flow. Similarly, if a router is MPLS-capable, then the flow's LSP might be one of the keys that define a flow. As such, the work required (on the part of the router) to maintain flow information, should be somewhat similar to that of the filter-based forwarding or policy routing features that the router already implements. Hopefully, this will keep the flow features from being prohibitive to implement because of the performance deficit. For example, LFAP currently doesn't report TCP flags values in TCP flows because its low-level flow "engine" can't observe these flags from arbitrary packets amidst a flow. (Since Riverstone routers don't have any options to forward based upon TCP flags values, this makes some sense.) Also, a vendor, who adds some fancy policy routing or QoS features, would be required to correspondingly improve the flow features (to make them aware of the new "key" values) to maintain compliance with the "standard IP flow" spec. Unfortunately, I'm thinking we're getting into murky waters here since all these new policy-based filtering and forwarding features are not standards-defined, correct? Is there some shorthand way that we can say that the flows should be as "smart" as the router? Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI From owner-rtfm@auckland.ac.nz Tue Mar 27 14:15:11 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26728 for ; Tue, 27 Mar 2001 14:15:10 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA02802; Wed, 28 Mar 2001 05:28:44 +1200 (NZST) Received: from smtp5ve.mailsrvcs.net (smtp5vepub.gte.net [206.46.170.26]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA02795 for ; Wed, 28 Mar 2001 05:28:42 +1200 (NZST) Received: from sphynx (adsl-151-202-195-5.nyc.adsl.bellatlantic.net [151.202.195.5]) by smtp5ve.mailsrvcs.net (8.9.1/8.9.1) with SMTP id RAA17424049; Tue, 27 Mar 2001 17:35:45 GMT Reply-To: From: "Carter Bullard" To: "'Juergen Quittek'" , Cc: Subject: RE: IP flow def'n: "forwarded along the same common path"? multicast consequences? Date: Tue, 27 Mar 2001 12:28:05 -0500 Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CBB5@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C0B6B9.53C72920" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AC092BB.FD1B5BD0@ccrle.nec.de> Importance: Normal Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C0B6B9.53C72920 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Gentle people, I would recommend adopting the terminology that IPPM is using. Flows can easily be defined using the "Type-P" notation. Its extensible and it provides the direct hook back to the IPPM framework, which could/should be used as a guide. Interface numbers and prev/next hop AS numbers are not derivable from packet contents, and as such, may not be appropriate for identifying packet flows in a generic sense. Its great that they can be provided in flow reports, but it may not be appropriate to make them a part of the standard flow key definition. As an example, there are no AS numbers in an OSPF or RIP network, but there are plenty of flows. There are area numbers in OSPF, but nothing in RIP. In load balanced multi-trunk environments, there can be many interfaces that are used to support a single VoIP call, but the design should allow for the single flow to reported once. And finally, a flow meter implemented on a single ingress interface may not know what the ultimate egress interface will be for a packet that it is classifying and reporting on, so the output interface can't be a part of this particular flow model. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > Behalf Of Juergen Quittek > Sent: Tuesday, March 27, 2001 8:17 AM > To: plonka@doit.wisc.edu > Cc: rtfm@auckland.ac.nz > Subject: Re: IP flow def'n: "forwarded along the same common path"? > multicast consequences? > > > Dave Plonka wrote: > > > > On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > > >Rekhter and Davies use the following in > > > >"MPLS Technologies and Applications" on > > > > > > > >page 155: > > > > individual application flows - microflows > > > > > > > >page 196 > > > > A traffic trunk is defined as a collection of individual TCP, > > > > or UDP, flows, known as "microflows" that share two > > > > common properties. The first one is that all microflows > > > > are forwarded along the same common path. > > > > The second is that they all share the same Class of Service. > > > > If "forwarded along the same common path" were part of our flow > > definition I'm wondering if that means an IP flow would be > defined by > > input and output ifIndex as NetFlow or LFAP flows are > currently with a > > single input and output ifIndex? > > > > If so, this is somewhat problematic for IP mulicast traffic > since the > > set of egress interfaces can change on a multicast-aware IP > router or > > switch. It would be a shame to have to terminate/export multicast > > flows whenever the set of egress interfaces changed because of a new > > host joining an existing multicast group. > > > > I think I'm OK with leaving the ingress interface (ifIndex) > as part of > > the flow def'n. but I'm wondering if we can create a new method by > > which output ifIndexes can be added and removed without > terminating the > > flow. (A flow update... this means that each flow would > need to have a > > unique identifier/handle/label by which the flow could be > referred in > > an update.) > > > > I just wanted to mention this issue now (so as not to forget it)... > > perhaps it can be revisited when export PDUs are discussed. > > > > However, I do think it's important to be sure that we consider the > > consequences if the flow definition causing us to have to > terminate an > > export multicast flows every time a multicast group join or leave > > occurs. > > > > That said, "forwarded along the same common path" (as defined by an > > "ifIndex pair") is a clause to use for unicast IP traffic. > > I don't think the term "path" is appropriate here. You did well by > defining it given by an "ifIndex pair", but the general understanding > of the term is different and more general, particularly in the > definition of an MPLS traffic trunk cited above. > > In an MPLS domain, each packet with the same source and destination > address takes exactly the same path, not just in terms of interfaces > of a single device, but in terms of all routers in the domain. > This does not hold in general in IP networks. > > If we adopt the term path, but define it differently (as you > suggested), > we will confuse a lot of people. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., C&C Research Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > ------=_NextPart_000_003F_01C0B6B9.53C72920 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: IP flow def'n: "forwarded along the same common = path"? multicast consequences?

Gentle people,
I would recommend adopting the terminology that IPPM = is using.
Flows can easily be defined using the = "Type-P" notation.  Its
extensible and it provides the direct hook back to = the IPPM
framework, which could/should be used as a = guide.

Interface numbers and prev/next hop AS numbers are = not
derivable from packet contents, and as such, may not = be
appropriate for identifying packet flows in a generic = sense.
Its great that they can be provided in flow reports, = but it
may not be appropriate to make them a part of the = standard
flow key definition.

As an example, there are no AS numbers in an OSPF or = RIP
network, but there are plenty of flows.  There = are area
numbers in OSPF, but nothing in RIP.  In load = balanced
multi-trunk environments, there can be many = interfaces that
are used to support a single VoIP call, but the = design
should allow for the single flow to reported = once.  And
finally, a flow meter implemented on a single = ingress
interface may not know what the ultimate egress = interface
will be for a packet that it is classifying and = reporting
on, so the output interface can't be a part of this = particular
flow model.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com


> -----Original Message-----
> From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.n= z]On
> Behalf Of Juergen Quittek
> Sent: Tuesday, March 27, 2001 8:17 AM
> To: plonka@doit.wisc.edu
> Cc: rtfm@auckland.ac.nz
> Subject: Re: IP flow def'n: "forwarded = along the same common path"?
> multicast consequences?
>
>
> Dave Plonka wrote:
> >
> > On Mon, Mar 26, 2001 at 09:28:31AM -0800, = Michael MacFaden wrote:
> > > >Rekhter and Davies use the = following in
> > > >"MPLS Technologies and = Applications" on
> > > >
> > > >page 155:
> > > >    individual = application flows - microflows
> > > >
> > > >page 196
> > > >    A traffic trunk = is defined as a collection of individual TCP,
> > > >    or UDP, flows, = known as "microflows"  that share two
> > > >    common = properties.   The first one is that all microflows
> > > >    are forwarded = along the same common path.
> > > >    The second is = that they all share the same Class of Service.
> >
> > If "forwarded along the same common = path" were part of our flow
> > definition I'm wondering if that means an = IP flow would be
> defined by
> > input and output ifIndex as NetFlow or LFAP = flows are
> currently with a
> > single input and output ifIndex?
> >
> > If so, this is somewhat problematic for IP = mulicast traffic
> since the
> > set of egress interfaces can change on a = multicast-aware IP
> router or
> > switch.  It would be a shame to have = to terminate/export multicast
> > flows whenever the set of egress interfaces = changed because of a new
> > host joining an existing multicast = group.
> >
> > I think I'm OK with leaving the ingress = interface (ifIndex)
> as part of
> > the flow def'n. but I'm wondering if we can = create a new method by
> > which output ifIndexes can be added and = removed without
> terminating the
> > flow.  (A flow update... this means = that each flow would
> need to have a
> > unique identifier/handle/label by which the = flow could be
> referred in
> > an update.)
> >
> > I just wanted to mention this issue now (so = as not to forget it)...
> > perhaps it can be revisited when export = PDUs are discussed.
> >
> > However, I do think it's important to be = sure that we consider the
> > consequences if the flow definition causing = us to have to
> terminate an
> > export multicast flows every time a = multicast group join or leave
> > occurs.
> >
> > That said, "forwarded along the same = common path" (as defined by an
> > "ifIndex pair") is a clause to = use for unicast IP traffic.
>
> I don't think the term "path" is = appropriate here. You did well by
> defining it given by an "ifIndex = pair", but the general understanding
> of the term is different and more general, = particularly in the
> definition of an MPLS traffic trunk cited = above.
>
> In an MPLS domain, each packet with the same = source and destination
> address takes exactly the same path, not just in = terms of interfaces
> of a single device, but in terms of all routers = in the domain.
> This does not hold in general in IP = networks.
>
> If we adopt the term path, but define it = differently (as you
> suggested),
> we will confuse a lot of people.
>
>     Juergen
> --
> Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
> NEC Europe Ltd., C&C Research = Laboratories   Fax: +49 6221 90511-55
> Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
>

------=_NextPart_000_003F_01C0B6B9.53C72920-- From owner-rtfm@auckland.ac.nz Wed Mar 28 05:10:55 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18963 for ; Wed, 28 Mar 2001 05:10:54 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA16478; Wed, 28 Mar 2001 20:38:56 +1200 (NZST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA16470 for ; Wed, 28 Mar 2001 20:38:53 +1200 (NZST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f2S8d2e06403; Wed, 28 Mar 2001 10:39:02 +0200 (CEST) Received: from ccrle.nec.de (belem.heidelberg.ccrle.nec.de [192.168.102.178]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA15138; Wed, 28 Mar 2001 10:36:08 +0200 Message-ID: <3AC1A32B.415D3DBC@ccrle.nec.de> Date: Wed, 28 Mar 2001 10:39:07 +0200 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: carter@qosient.com CC: rtfm@auckland.ac.nz, plonka@doit.wisc.edu Subject: Re: IP flow def'n: "forwarded along the same common path"? multicast consequences? References: <38E99DA2CEFA7248B5828BBF99344D86CBB5@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit > Carter Bullard wrote: > > Gentle people, > I would recommend adopting the terminology that IPPM is using. > Flows can easily be defined using the "Type-P" notation. Its > extensible and it provides the direct hook back to the IPPM > framework, which could/should be used as a guide. > > Interface numbers and prev/next hop AS numbers are not > derivable from packet contents, and as such, may not be > appropriate for identifying packet flows in a generic sense. > Its great that they can be provided in flow reports, but it > may not be appropriate to make them a part of the standard > flow key definition. > > As an example, there are no AS numbers in an OSPF or RIP > network, but there are plenty of flows. There are area > numbers in OSPF, but nothing in RIP. In load balanced > multi-trunk environments, there can be many interfaces that > are used to support a single VoIP call, but the design > should allow for the single flow to reported once. And Well, we are already back to the requirements. Your requirement here is having a single VoIP data stream being reported as a single flow. Another one could be having packets accounted separately if they leave a router at different interfaces. At first sight, both requirements seem reasonable to me, but maybe they contradict each other as you claim. So, lets first find out what our requirements are. Then it should be much easier to agree on a flow model. If the Type-P notation matches our requirements, it could be a very good idea to use it. > finally, a flow meter implemented on a single ingress > interface may not know what the ultimate egress interface > will be for a packet that it is classifying and reporting > on, so the output interface can't be a part of this particular > flow model. Here we have another requirement. While your first one was a kind of usage requirement, this looks like an implementation requirement. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., C&C Research Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Carter > > Carter Bullard > QoSient, LLC > 300 E. 56th Street, Suite 18K > New York, New York 10022 > > carter@qosient.com > Phone +1 212 588-9133 > Fax +1 212 588-9134 > http://qosient.com > > > -----Original Message----- > > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > > Behalf Of Juergen Quittek > > Sent: Tuesday, March 27, 2001 8:17 AM > > To: plonka@doit.wisc.edu > > Cc: rtfm@auckland.ac.nz > > Subject: Re: IP flow def'n: "forwarded along the same common path"? > > multicast consequences? > > > > > > Dave Plonka wrote: > > > > > > On Mon, Mar 26, 2001 at 09:28:31AM -0800, Michael MacFaden wrote: > > > > >Rekhter and Davies use the following in > > > > >"MPLS Technologies and Applications" on > > > > > > > > > >page 155: > > > > > individual application flows - microflows > > > > > > > > > >page 196 > > > > > A traffic trunk is defined as a collection of individual TCP, > > > > > or UDP, flows, known as "microflows" that share two > > > > > common properties. The first one is that all microflows > > > > > are forwarded along the same common path. > > > > > The second is that they all share the same Class of Service. > > > > > > If "forwarded along the same common path" were part of our flow > > > definition I'm wondering if that means an IP flow would be > > defined by > > > input and output ifIndex as NetFlow or LFAP flows are > > currently with a > > > single input and output ifIndex? > > > > > > If so, this is somewhat problematic for IP mulicast traffic > > since the > > > set of egress interfaces can change on a multicast-aware IP > > router or > > > switch. It would be a shame to have to terminate/export multicast > > > flows whenever the set of egress interfaces changed because of a new > > > host joining an existing multicast group. > > > > > > I think I'm OK with leaving the ingress interface (ifIndex) > > as part of > > > the flow def'n. but I'm wondering if we can create a new method by > > > which output ifIndexes can be added and removed without > > terminating the > > > flow. (A flow update... this means that each flow would > > need to have a > > > unique identifier/handle/label by which the flow could be > > referred in > > > an update.) > > > > > > I just wanted to mention this issue now (so as not to forget it)... > > > perhaps it can be revisited when export PDUs are discussed. > > > > > > However, I do think it's important to be sure that we consider the > > > consequences if the flow definition causing us to have to > > terminate an > > > export multicast flows every time a multicast group join or leave > > > occurs. > > > > > > That said, "forwarded along the same common path" (as defined by an > > > "ifIndex pair") is a clause to use for unicast IP traffic. > > > > I don't think the term "path" is appropriate here. You did well by > > defining it given by an "ifIndex pair", but the general understanding > > of the term is different and more general, particularly in the > > definition of an MPLS traffic trunk cited above. > > > > In an MPLS domain, each packet with the same source and destination > > address takes exactly the same path, not just in terms of interfaces > > of a single device, but in terms of all routers in the domain. > > This does not hold in general in IP networks. > > > > If we adopt the term path, but define it differently (as you > > suggested), > > we will confuse a lot of people. > > > > Juergen > > -- > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > NEC Europe Ltd., C&C Research Laboratories Fax: +49 6221 90511-55 > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > From owner-rtfm@auckland.ac.nz Wed Mar 28 11:06:01 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02885 for ; Wed, 28 Mar 2001 11:06:00 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA07877; Thu, 29 Mar 2001 02:28:13 +1200 (NZST) Received: from smtp5ve.mailsrvcs.net (smtp5vepub.gte.net [206.46.170.26]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA07869 for ; Thu, 29 Mar 2001 02:28:10 +1200 (NZST) Received: from sphynx (adsl-151-202-197-36.nyc.adsl.bellatlantic.net [151.202.197.36]) by smtp5ve.mailsrvcs.net (8.9.1/8.9.1) with SMTP id OAA17188479 for ; Wed, 28 Mar 2001 14:35:31 GMT Reply-To: From: "Carter Bullard" To: Subject: TLV structure for IP flow reporting Date: Wed, 28 Mar 2001 09:27:49 -0500 Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CBB7@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C0B769.4FE10550" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AC1A32B.415D3DBC@ccrle.nec.de> Importance: Normal Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C0B769.4FE10550 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Gentle people, Argus is IP flow monitor that has a push data model and a TLV data format for its flow reports. It is open source software, and has been around for a while. I can offer this as an example implementation for discussion. http://qosient.com/argus If it would help the effort, I can give a discussion of Argus's design strategy at the London IETF. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com ------=_NextPart_000_0058_01C0B769.4FE10550 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable TLV structure for IP flow reporting

Gentle people,
   Argus is IP flow monitor that has a push = data model
and a TLV data format for its flow reports.  It = is open
source software, and has been around for a = while.  I can
offer this as an example implementation for = discussion.

   http://qosient.com/argus

If it would help the effort, I can give a discussion = of
Argus's design strategy at the London IETF.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

------=_NextPart_000_0058_01C0B769.4FE10550--