From owner-rtfm@auckland.ac.nz Thu Oct 5 20:31:16 2000 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 UAA09378 for ; Thu, 5 Oct 2000 20:31:13 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id KAA14706; Fri, 6 Oct 2000 10:32:26 +1300 (NZDT) 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 KAA14592; Fri, 6 Oct 2000 10:31:58 +1300 (NZDT) From: Nevil Brownlee To: Marcelo Pias Cc: rtfm@auckland.ac.nz Subject: Re: We're on board In-Reply-To: <3.0.6.32.20001004220003.00894580@127.0.0.1> Message-ID: Date: Fri, 6 Oct 2000 09:31:52 +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 > >You're right, the Meter MIB only does pull behaviour. But there's > >nothing in the RTFM Architecture which imposes that limitation, so I > >agree, it would be a good thing to explore this so as to provide a > >well-defined 'push' interface, API or whatever. Good idea. Let's get > >it out on the mailing list / in an I-D! > > That's true the meter MIB doesn't say anything about this... I assume in > order to have this kind of collection, will require modification within the > MIB... But also, the meter itself will need to cope with this... Do you > believe that this a protocol issue only? I don't know about it being a 'protocol issue,' but its certainly something which has strong effects on the meter design - if one chose to stay with SNMP, the meter would have to send event notifications (trap messages in SNMPv1), which would of course need changes to the MIB. Building a meter which, for example, could be run as a thread, and used via a well-defined API so as to write flow data directly to a file or database - now that would be an interesting topic to discuss .. Cheers, Nevil +---------------------------------------------------------------------+ | 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 Fri Oct 6 00:37:08 2000 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 AAA13180 for ; Fri, 6 Oct 2000 00:37:06 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA29819; Fri, 6 Oct 2000 14:34:22 +1300 (NZDT) 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 OAA29800 for ; Fri, 6 Oct 2000 14:34:16 +1300 (NZDT) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: More new attribute work item ideas Message-ID: Date: Fri, 6 Oct 2000 13:34:11 +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 Hello all: Following the note I sent to the list 11 Sep 00 about implementing new attributes in the RTFM MIB, I have two further proposals - 1) Another group of list-valued attributes, To/From ASNListPDUs and To/From ASNListOctets These would build lists of the packets and bytes sent to each ASN for a flow's source (From list) and destination (To list). 2) Another column in the Reader Control table, specifying the minimum number of packets a flow should have if it is to read by a meter reader. This would provide a filter so that only 'busy' flows would be read by that meter, which would be very useful for applications like nifty (my flow analyser - tests of this reduced the number of flows of interest from 120,000 to about 10,000). The default value for this filter would be zero, i.e. all flows would be retrieved. Any comments or suggestions? I plan to finish my I-D and send it in to be published early nect week. Cheers, Nevil +---------------------------------------------------------------------+ | 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 Fri Oct 6 08:16:31 2000 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 IAA29782 for ; Fri, 6 Oct 2000 08:16:29 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA17298; Fri, 6 Oct 2000 23:09:04 +1300 (NZDT) 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 XAA17272; Fri, 6 Oct 2000 23:08:53 +1300 (NZDT) Received: from riogrande.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Oct 2000 11:08:29 +0100 Date: Fri, 6 Oct 2000 11:08:07 +0000 (UTC) From: Marcelo Pias To: Nevil Brownlee cc: rtfm@auckland.ac.nz, Jon Crowcroft Subject: Push mode (was Re: We're on board) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi Nevil, comments in line... On Fri, 6 Oct 2000, Nevil Brownlee wrote: > > > > >You're right, the Meter MIB only does pull behaviour. But there's > > >nothing in the RTFM Architecture which imposes that limitation, so I > > >agree, it would be a good thing to explore this so as to provide a > > >well-defined 'push' interface, API or whatever. Good idea. Let's get > > >it out on the mailing list / in an I-D! > > > > That's true the meter MIB doesn't say anything about this... I assume in > > order to have this kind of collection, will require modification within the > > MIB... But also, the meter itself will need to cope with this... Do you > > believe that this a protocol issue only? > > I don't know about it being a 'protocol issue,' but its certainly > something which has strong effects on the meter design - if one chose > to stay with SNMP, the meter would have to send event notifications > (trap messages in SNMPv1), which would of course need changes to the > MIB. Building a meter which, for example, could be run as a thread, > and used via a well-defined API so as to write flow data directly to a > file or database - now that would be an interesting topic to discuss .. I'd point out now three situations where push mode may be used: Accounting protocol +------------+ +-------------+--------------+----------->| Acct server| | | | +------------+ | | | +--------+ +--------+ +--------+ +-------------+ |Reader 1| |Reader 2| ... |Reader n|------>| Local store | +--------+ +--------+ +--------+ +-------------+ ^ ^ ^ \ | / \ | / Push mode (RTFM push-mode protocol?) \ | / +----------+ | Meters | +----------+ First: Each reader subscribes as a listener to the event: "flowdata record ready". When this event occurs, the meter push the flowdata record out to the list of listeners through the network... Readers may control this through an interface provided by the meter. (e.g. API) Accounting protocol +------------+ +-------------+--------------+----------->| Acct server| | | | +------------+ | | | +--------+ +--------+ +--------+ |Reader 1| |Reader 2| ... |Reader n| +--------+ +--------+ +--------+ ^ ^ ^ \ | / \ | / Push mode (RTFM push-mode Protocol?) \ | / +-------------+ | Application | +-------------+ ^ | Pull mode (SNMP,HTTP...) v +----------+ | Meters | +----------+ Second: this would cope with situations where the meter doesn't support push mode... Basically, it's the same as the above but with an application translating from pull mode to push mode... Accounting protocol +------------+ +-------------+--------------+------------->| Acct server| | | | +------------+ | | | +--------+ +--------+ +--------+ |Reader 1| |Reader 2| ... |Reader n| +--------+ +--------+ +--------+ ^ ^ ^ \ | / \ | / Push mode (Local communication) \ | / +----------+ | Meters | +----------+ Third: the meter and reader would be running on the same machine. Thus, the communication is local, and the meter may be running as a thread as you've suggested... And the reader, would then send the flow data to appropriate remote/local store such as a file, remote database, AAA server... This is where I can see useful a well-defined API...Actually, we've done implementations which covers the second and third scenarios above with very good results... For the first one, we have already started the design of the appropriate data structure and control needed. Any comments from the list? Cheers. Marcelo ---------------------------------------------------------- Marcelo Pias - University College London (UCL) www.cs.ucl.ac.uk/staff/m.pias/ From owner-rtfm@auckland.ac.nz Fri Oct 6 23:00:36 2000 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 XAA18642 for ; Fri, 6 Oct 2000 23:00:35 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA28880; Sat, 7 Oct 2000 13:58:46 +1300 (NZDT) Received: from kobe.ccrle.nec.de (root@kobe.ccrle.nec.de [195.37.70.5]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA28864; Sat, 7 Oct 2000 13:58:39 +1300 (NZDT) From: quittek@ccrle.nec.de Received: from ccrle.nec.de (quittek@localhost [127.0.0.1]) by kobe.ccrle.nec.de (8.9.3/8.9.3) with ESMTP id CAA16438; Sat, 7 Oct 2000 02:15:18 +0200 Message-ID: <39DE6B12.D79A0F98@ccrle.nec.de> Date: Sat, 07 Oct 2000 02:15:14 +0200 Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Pias CC: Nevil Brownlee , rtfm@auckland.ac.nz, Jon Crowcroft Subject: Re: Push mode (was Re: We're on board) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, All three situations you describe comply with the RRTFM architecture. The architecture is not restricted to pull mode. However, the Meter MIB is, at least so far. Now it is the question, whether we want to extend the Meter MIB such that it offers also push mode communication. Is this another item for the revived working group's agenda? If yes, here are some thoughts on this issue: In general there is no need, because the combination of Expression MIB (draft-ietf-disman-express-mib-12.txt) and Event MIB (draft-ietf-disman-event-mib-10.txt) should be sufficent to observe the flow table and to generate notifications. As far as I kbow, both MIBs are close to becoming an RFC on the standards track. However, using these MIBs could be a rather complicated and unflexible way. So, if we think that push mode is desirable, we should go for a Meter MIB extension. But also here I see some problems. If the Meter wants to notify some entity via SNMP is has to send an SNMP notification. Where such a notification is sent to is usually not configurable by the MIB portion defining the notification, but it is defined either by the SNMP agent's configuration file or by managed objects in another MIB portion. In both cases, it might be impossible to configure the destination for a single notification. Very often, all notifications are sent to the same set of managers. Unfortunately, what we would probably like to have is sending notifications concerning a specific flow to exactly the set of readers which (dynamically) have been registered for this flow. Maybe somebody on the list knows how to overcome this problem? Let's assume we have solved this problem. Then our next step would be defining conditions on which notifications are generated. I see several possible conditions, among them - a new entry in the flow table is generated - a flow table entry times out, i.e. no new packets for some time - the number of octets of a flow exceeds a given number - ... We have to collect all conditions, that might be required by users of the Meter MIB and find ways of integrating them into the MIB. Marcelo Pias wrote: > > Hi Nevil, > > comments in line... > > On Fri, 6 Oct 2000, Nevil Brownlee wrote: > > > > > > > > >You're right, the Meter MIB only does pull behaviour. But there's > > > >nothing in the RTFM Architecture which imposes that limitation, so I > > > >agree, it would be a good thing to explore this so as to provide a > > > >well-defined 'push' interface, API or whatever. Good idea. Let's get > > > >it out on the mailing list / in an I-D! > > > > > > That's true the meter MIB doesn't say anything about this... I assume in > > > order to have this kind of collection, will require modification within the > > > MIB... But also, the meter itself will need to cope with this... Do you > > > believe that this a protocol issue only? > > > > I don't know about it being a 'protocol issue,' but its certainly > > something which has strong effects on the meter design - if one chose > > to stay with SNMP, the meter would have to send event notifications > > (trap messages in SNMPv1), which would of course need changes to the > > MIB. Building a meter which, for example, could be run as a thread, > > and used via a well-defined API so as to write flow data directly to a > > file or database - now that would be an interesting topic to discuss .. > > I'd point out now three situations where push mode may be used: > > Accounting protocol +------------+ > +-------------+--------------+----------->| Acct server| > | | | +------------+ > | | | > +--------+ +--------+ +--------+ +-------------+ > |Reader 1| |Reader 2| ... |Reader n|------>| Local store | > +--------+ +--------+ +--------+ +-------------+ > ^ ^ ^ > \ | / > \ | / Push mode (RTFM push-mode protocol?) > \ | / > +----------+ > | Meters | > +----------+ > > First: Each reader subscribes as a listener to the event: > "flowdata record ready". When this event occurs, the meter push the > flowdata record out to the list of listeners through the network... > Readers may control this through an interface provided by the meter. (e.g. API) > > Accounting protocol +------------+ > +-------------+--------------+----------->| Acct server| > | | | +------------+ > | | | > +--------+ +--------+ +--------+ > |Reader 1| |Reader 2| ... |Reader n| > +--------+ +--------+ +--------+ > ^ ^ ^ > \ | / > \ | / Push mode (RTFM push-mode Protocol?) > \ | / > +-------------+ > | Application | > +-------------+ > ^ > | Pull mode (SNMP,HTTP...) > v > +----------+ > | Meters | > +----------+ > > Second: this would cope with situations where the meter > doesn't support push mode... Basically, it's the same as the above > but with an application translating from pull mode to push mode... > > Accounting protocol +------------+ > +-------------+--------------+------------->| Acct server| > | | | +------------+ > | | | > +--------+ +--------+ +--------+ > |Reader 1| |Reader 2| ... |Reader n| > +--------+ +--------+ +--------+ > ^ ^ ^ > \ | / > \ | / Push mode (Local communication) > \ | / > +----------+ > | Meters | > +----------+ > > Third: the meter and reader would be running on the same > machine. Thus, the communication is local, and the meter may be > running as a thread as you've suggested... And the reader, would then > send the flow data to appropriate remote/local store such as a file, > remote database, AAA server... > > > This is where I can see useful a well-defined API...Actually, we've > done implementations which covers the second and third scenarios above with > very good results... For the first one, we have already started the > design of the appropriate data structure and control needed. > > Any comments from the list? > > Cheers. Marcelo > > ---------------------------------------------------------- > Marcelo Pias - University College London (UCL) > www.cs.ucl.ac.uk/staff/m.pias/ From owner-rtfm@auckland.ac.nz Fri Oct 6 23:09:16 2000 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 XAA18685 for ; Fri, 6 Oct 2000 23:09:10 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA29240; Sat, 7 Oct 2000 14:08:33 +1300 (NZDT) Received: from kobe.ccrle.nec.de (root@kobe.ccrle.nec.de [195.37.70.5]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA29224; Sat, 7 Oct 2000 14:08:23 +1300 (NZDT) From: quittek@ccrle.nec.de Received: from ccrle.nec.de (quittek@localhost [127.0.0.1]) by kobe.ccrle.nec.de (8.9.3/8.9.3) with ESMTP id CAA16456; Sat, 7 Oct 2000 02:25:07 +0200 Message-ID: <39DE6D5F.E004159A@ccrle.nec.de> Date: Sat, 07 Oct 2000 02:25:03 +0200 Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Pias CC: Nevil Brownlee , rtfm@auckland.ac.nz, Jon Crowcroft Subject: Re: Push mode (was Re: We're on board) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, All three situations you describe comply with the RRTFM architecture. The architecture is not restricted to pull mode. However, the Meter MIB is, at least so far. Now it is the question, whether we want to extend the Meter MIB such that it offers also push mode communication. Is this another Item for the revived working group's agenda? If yes, here are some thoughts on this issue: In general there is no need, because the combination of Expression MIB (draft-ietf-disman-express-mib-12.txt) and Event MIB (draft-ietf-disman-event-mib-10.txt) should be sufficent to observe the flow table and to generate notifications. As far as I kbow, both MIBs are close to becoming an RFC on the standards track. However, using these MIBs could be a rather complicated and unflexible way. So, if we think that push mode is desirable, we should go for a Meter MIB extension. But also here I see some problems. If the Meter wants to notify some entity via SNMP is has to send an SNMP notification. Where such a notification is sent to is usually not configurable by the MIB portion defining the notification, but it is defined either by the SNMP agent's configuration file or by managed objects in another MIB portion. In both cases, it might be impossible to configure the destination for a single notification. Very often, all notifications are sent to the same set of managers. Unfortunately, what we would probably like to have is sending notifications concerning a specific flow to exactly the set of readers which (dynamically) have been registered for this flow. Maybe somebody on the list knows how to overcome this problem? Let's assume we have solved this problem. Then our next step would be defining conditions on which notifications are generated. I see several possible conditions, among them - a new entry in the flow table is generated - a flow table entry times out, i.e. no new packets for some time - the number of octets of a flow exceeds a given number - ... We have to collect all conditions, that might be required by users of the Meter MIB and find ways of integrating them into the MIB. 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 Marcelo Pias wrote: > > Hi Nevil, > > comments in line... > > On Fri, 6 Oct 2000, Nevil Brownlee wrote: > > > > > > > > >You're right, the Meter MIB only does pull behaviour. But there's > > > >nothing in the RTFM Architecture which imposes that limitation, so I > > > >agree, it would be a good thing to explore this so as to provide a > > > >well-defined 'push' interface, API or whatever. Good idea. Let's get > > > >it out on the mailing list / in an I-D! > > > > > > That's true the meter MIB doesn't say anything about this... I assume in > > > order to have this kind of collection, will require modification within the > > > MIB... But also, the meter itself will need to cope with this... Do you > > > believe that this a protocol issue only? > > > > I don't know about it being a 'protocol issue,' but its certainly > > something which has strong effects on the meter design - if one chose > > to stay with SNMP, the meter would have to send event notifications > > (trap messages in SNMPv1), which would of course need changes to the > > MIB. Building a meter which, for example, could be run as a thread, > > and used via a well-defined API so as to write flow data directly to a > > file or database - now that would be an interesting topic to discuss .. > > I'd point out now three situations where push mode may be used: > > Accounting protocol +------------+ > +-------------+--------------+----------->| Acct server| > | | | +------------+ > | | | > +--------+ +--------+ +--------+ +-------------+ > |Reader 1| |Reader 2| ... |Reader n|------>| Local store | > +--------+ +--------+ +--------+ +-------------+ > ^ ^ ^ > \ | / > \ | / Push mode (RTFM push-mode protocol?) > \ | / > +----------+ > | Meters | > +----------+ > > First: Each reader subscribes as a listener to the event: > "flowdata record ready". When this event occurs, the meter push the > flowdata record out to the list of listeners through the network... > Readers may control this through an interface provided by the meter. (e.g. API) > > Accounting protocol +------------+ > +-------------+--------------+----------->| Acct server| > | | | +------------+ > | | | > +--------+ +--------+ +--------+ > |Reader 1| |Reader 2| ... |Reader n| > +--------+ +--------+ +--------+ > ^ ^ ^ > \ | / > \ | / Push mode (RTFM push-mode Protocol?) > \ | / > +-------------+ > | Application | > +-------------+ > ^ > | Pull mode (SNMP,HTTP...) > v > +----------+ > | Meters | > +----------+ > > Second: this would cope with situations where the meter > doesn't support push mode... Basically, it's the same as the above > but with an application translating from pull mode to push mode... > > Accounting protocol +------------+ > +-------------+--------------+------------->| Acct server| > | | | +------------+ > | | | > +--------+ +--------+ +--------+ > |Reader 1| |Reader 2| ... |Reader n| > +--------+ +--------+ +--------+ > ^ ^ ^ > \ | / > \ | / Push mode (Local communication) > \ | / > +----------+ > | Meters | > +----------+ > > Third: the meter and reader would be running on the same > machine. Thus, the communication is local, and the meter may be > running as a thread as you've suggested... And the reader, would then > send the flow data to appropriate remote/local store such as a file, > remote database, AAA server... > > > This is where I can see useful a well-defined API...Actually, we've > done implementations which covers the second and third scenarios above with > very good results... For the first one, we have already started the > design of the appropriate data structure and control needed. > > Any comments from the list? > > Cheers. Marcelo > > ---------------------------------------------------------- > Marcelo Pias - University College London (UCL) > www.cs.ucl.ac.uk/staff/m.pias/ From owner-rtfm@auckland.ac.nz Mon Oct 9 19:18:14 2000 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 TAA11098 for ; Mon, 9 Oct 2000 19:18:12 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id KAA11162; Tue, 10 Oct 2000 10:11:00 +1300 (NZDT) 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 KAA11114; Tue, 10 Oct 2000 10:10:42 +1300 (NZDT) Received: from 132.146.124.145 by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 9 Oct 2000 22:10:34 +0100 Message-Id: <3.0.6.32.20001009221012.008de7d0@127.0.0.1> X-Sender: marcpias/pop.cs.ucl.ac.uk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 09 Oct 2000 22:10:12 +0100 To: quittek@ccrle.nec.de From: Marcelo Pias Subject: Re: Push mode (was Re: We're on board) Cc: Nevil Brownlee , rtfm@auckland.ac.nz, Jon Crowcroft In-Reply-To: <39DE6B12.D79A0F98@ccrle.nec.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Juergen, >Now it is the question, whether we want to extend the Meter MIB such >that >it offers also push mode communication. Is this another item for the >revived working group's agenda? I'd suggest this as a new work item... I'd be interested to work on this too... Maybe, it could follow any of these two paths: 1. Define the appropriate mechanisms and needed changes within the RTFM MIB to cope with push mode. 2. Specify a protocol to carry "flow data" between meters and readers using push mode... This could be multicast from meter to readers using a reliable multicast protocol or something (assuming the no. of readers are enough to justify multicasting the data, instead of single unicast sessions...) I'd appreciate any comment/suggests on this... Cheers. Marcelo ------------------------------------------------------------ UCL - University College London > >If yes, here are some thoughts on this issue: > >In general there is no need, because the combination of Expression MIB >(draft-ietf-disman-express-mib-12.txt) and Event MIB >(draft-ietf-disman-event-mib-10.txt) should be sufficent to observe the >flow table and to generate notifications. As far as I kbow, both MIBs >are close to becoming an RFC on the standards track. However, using >these MIBs could be a rather complicated and unflexible way. > >So, if we think that push mode is desirable, we should go for a Meter >MIB >extension. But also here I see some problems. If the Meter wants to >notify >some entity via SNMP is has to send an SNMP notification. Where such a >notification is sent to is usually not configurable by the MIB portion >defining the notification, but it is defined either by the SNMP agent's >configuration file or by managed objects in another MIB portion. > >In both cases, it might be impossible to configure the destination for a >single notification. Very often, all notifications are sent to the same >set of managers. > >Unfortunately, what we would probably like to have is sending >notifications >concerning a specific flow to exactly the set of readers which >(dynamically) >have been registered for this flow. Maybe somebody on the list knows how >to >overcome this problem? > >Let's assume we have solved this problem. Then our next step would be >defining conditions on which notifications are generated. I see several >possible conditions, among them > >- a new entry in the flow table is generated >- a flow table entry times out, i.e. no new packets for some time >- the number of octets of a flow exceeds a given number >- ... > >We have to collect all conditions, that might be required by users of >the >Meter MIB and find ways of integrating them into the MIB. > > >Marcelo Pias wrote: >> >> Hi Nevil, >> >> comments in line... >> >> On Fri, 6 Oct 2000, Nevil Brownlee wrote: >> >> > >> > >> > > >You're right, the Meter MIB only does pull behaviour. But there's >> > > >nothing in the RTFM Architecture which imposes that limitation, so I >> > > >agree, it would be a good thing to explore this so as to provide a >> > > >well-defined 'push' interface, API or whatever. Good idea. Let's get >> > > >it out on the mailing list / in an I-D! >> > > >> > > That's true the meter MIB doesn't say anything about this... I assume in >> > > order to have this kind of collection, will require modification within the >> > > MIB... But also, the meter itself will need to cope with this... Do you >> > > believe that this a protocol issue only? >> > >> > I don't know about it being a 'protocol issue,' but its certainly >> > something which has strong effects on the meter design - if one chose >> > to stay with SNMP, the meter would have to send event notifications >> > (trap messages in SNMPv1), which would of course need changes to the >> > MIB. Building a meter which, for example, could be run as a thread, >> > and used via a well-defined API so as to write flow data directly to a >> > file or database - now that would be an interesting topic to discuss .. >> >> I'd point out now three situations where push mode may be used: >> >> Accounting protocol +------------+ >> +-------------+--------------+----------->| Acct server| >> | | | +------------+ >> | | | >> +--------+ +--------+ +--------+ +-------------+ >> |Reader 1| |Reader 2| ... |Reader n|------>| Local store | >> +--------+ +--------+ +--------+ +-------------+ >> ^ ^ ^ >> \ | / >> \ | / Push mode (RTFM push-mode protocol?) >> \ | / >> +----------+ >> | Meters | >> +----------+ >> >> First: Each reader subscribes as a listener to the event: >> "flowdata record ready". When this event occurs, the meter push the >> flowdata record out to the list of listeners through the network... >> Readers may control this through an interface provided by the meter. (e.g. API) >> >> Accounting protocol +------------+ >> +-------------+--------------+----------->| Acct server| >> | | | +------------+ >> | | | >> +--------+ +--------+ +--------+ >> |Reader 1| |Reader 2| ... |Reader n| >> +--------+ +--------+ +--------+ >> ^ ^ ^ >> \ | / >> \ | / Push mode (RTFM push-mode Protocol?) >> \ | / >> +-------------+ >> | Application | >> +-------------+ >> ^ >> | Pull mode (SNMP,HTTP...) >> v >> +----------+ >> | Meters | >> +----------+ >> >> Second: this would cope with situations where the meter >> doesn't support push mode... Basically, it's the same as the above >> but with an application translating from pull mode to push mode... >> >> Accounting protocol +------------+ >> +-------------+--------------+------------->| Acct server| >> | | | +------------+ >> | | | >> +--------+ +--------+ +--------+ >> |Reader 1| |Reader 2| ... |Reader n| >> +--------+ +--------+ +--------+ >> ^ ^ ^ >> \ | / >> \ | / Push mode (Local communication) >> \ | / >> +----------+ >> | Meters | >> +----------+ >> >> Third: the meter and reader would be running on the same >> machine. Thus, the communication is local, and the meter may be >> running as a thread as you've suggested... And the reader, would then >> send the flow data to appropriate remote/local store such as a file, >> remote database, AAA server... >> >> >> This is where I can see useful a well-defined API...Actually, we've >> done implementations which covers the second and third scenarios above with >> very good results... For the first one, we have already started the >> design of the appropriate data structure and control needed. >> >> Any comments from the list? >> >> Cheers. Marcelo >> >> ---------------------------------------------------------- >> Marcelo Pias - University College London (UCL) >> www.cs.ucl.ac.uk/staff/m.pias/ > From owner-rtfm@auckland.ac.nz Tue Oct 10 01:46:10 2000 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 BAA21430 for ; Tue, 10 Oct 2000 01:46:05 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id QAA22864; Tue, 10 Oct 2000 16:33:10 +1300 (NZDT) Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA22759; Tue, 10 Oct 2000 16:32:40 +1300 (NZDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id XAA22638; Mon, 9 Oct 2000 23:31:20 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma022635; Mon, 9 Oct 00 23:30:27 -0400 Received: from ctron-exc1.ctron.com (ctron-exc1.ctron.com [134.141.77.90]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id XAA28350; Mon, 9 Oct 2000 23:25:24 -0400 (EDT) Received: from ctron-exc1.ctron.com (localhost [127.0.0.1]) by ctron-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4S6YY01T; Mon, 9 Oct 2000 23:25:26 -0400 Received: from 134.141.150.157 by ctron-exc1.ctron.com (InterScan E-Mail VirusWall NT); Mon, 09 Oct 2000 23:25:24 -0400 (Eastern Daylight Time) Message-ID: <39E28C18.7E8DFBDC@enterasys.com> Date: Mon, 09 Oct 2000 23:25:12 -0400 From: David Harrington Reply-To: dharrington@mediaone.net Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Marcelo Pias CC: quittek@ccrle.nec.de, Nevil Brownlee , rtfm@auckland.ac.nz, Jon Crowcroft Subject: Re: Push mode (was Re: We're on board) References: <3.0.6.32.20001009221012.008de7d0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo Pias wrote: > > Juergen, > > >Now it is the question, whether we want to extend the Meter MIB such > >that > >it offers also push mode communication. Is this another item for the > >revived working group's agenda? > > I'd suggest this as a new work item... I'd be interested to work on this > too... > > Maybe, it could follow any of these two paths: > > 1. Define the appropriate mechanisms and needed changes within the RTFM MIB > to cope with push mode. > > 2. Specify a protocol to carry "flow data" between meters and readers using > push mode... This could be multicast from meter to readers using a reliable > multicast protocol or something (assuming the no. of readers are enough to > justify multicasting the data, instead of single unicast sessions...) > I believe SNMPv3, with its Inform, is a protocol capable of handling push needs. > I'd appreciate any comment/suggests on this... > > Cheers. Marcelo > > ------------------------------------------------------------ > UCL - University College London > > > > >If yes, here are some thoughts on this issue: > > > >In general there is no need, because the combination of Expression MIB > >(draft-ietf-disman-express-mib-12.txt) and Event MIB > >(draft-ietf-disman-event-mib-10.txt) should be sufficent to observe the > >flow table and to generate notifications. As far as I kbow, both MIBs > >are close to becoming an RFC on the standards track. However, using > >these MIBs could be a rather complicated and unflexible way. > > > >So, if we think that push mode is desirable, we should go for a Meter > >MIB > >extension. But also here I see some problems. If the Meter wants to > >notify > >some entity via SNMP is has to send an SNMP notification. Where such a > >notification is sent to is usually not configurable by the MIB portion > >defining the notification, but it is defined either by the SNMP agent's > >configuration file or by managed objects in another MIB portion. > > > >In both cases, it might be impossible to configure the destination for a > >single notification. Very often, all notifications are sent to the same > >set of managers. > > > >Unfortunately, what we would probably like to have is sending > >notifications > >concerning a specific flow to exactly the set of readers which > >(dynamically) > >have been registered for this flow. Maybe somebody on the list knows how > >to > >overcome this problem? > > > >Let's assume we have solved this problem. Then our next step would be > >defining conditions on which notifications are generated. I see several > >possible conditions, among them > > > >- a new entry in the flow table is generated > >- a flow table entry times out, i.e. no new packets for some time > >- the number of octets of a flow exceeds a given number > >- ... > > > >We have to collect all conditions, that might be required by users of > >the > >Meter MIB and find ways of integrating them into the MIB. > > > > > >Marcelo Pias wrote: > >> > >> Hi Nevil, > >> > >> comments in line... > >> > >> On Fri, 6 Oct 2000, Nevil Brownlee wrote: > >> > >> > > >> > > >> > > >You're right, the Meter MIB only does pull behaviour. But there's > >> > > >nothing in the RTFM Architecture which imposes that limitation, so I > >> > > >agree, it would be a good thing to explore this so as to provide a > >> > > >well-defined 'push' interface, API or whatever. Good idea. Let's get > >> > > >it out on the mailing list / in an I-D! > >> > > > >> > > That's true the meter MIB doesn't say anything about this... I > assume in > >> > > order to have this kind of collection, will require modification > within the > >> > > MIB... But also, the meter itself will need to cope with this... Do you > >> > > believe that this a protocol issue only? > >> > > >> > I don't know about it being a 'protocol issue,' but its certainly > >> > something which has strong effects on the meter design - if one chose > >> > to stay with SNMP, the meter would have to send event notifications > >> > (trap messages in SNMPv1), which would of course need changes to the > >> > MIB. Building a meter which, for example, could be run as a thread, > >> > and used via a well-defined API so as to write flow data directly to a > >> > file or database - now that would be an interesting topic to discuss .. > >> > >> I'd point out now three situations where push mode may be used: > >> > >> Accounting protocol +------------+ > >> +-------------+--------------+----------->| Acct server| > >> | | | +------------+ > >> | | | > >> +--------+ +--------+ +--------+ +-------------+ > >> |Reader 1| |Reader 2| ... |Reader n|------>| Local store | > >> +--------+ +--------+ +--------+ +-------------+ > >> ^ ^ ^ > >> \ | / > >> \ | / Push mode (RTFM push-mode protocol?) > >> \ | / > >> +----------+ > >> | Meters | > >> +----------+ > >> > >> First: Each reader subscribes as a listener to the event: > >> "flowdata record ready". When this event occurs, the meter push the > >> flowdata record out to the list of listeners through the network... > >> Readers may control this through an interface provided by the meter. > (e.g. API) > >> > >> Accounting protocol +------------+ > >> +-------------+--------------+----------->| Acct server| > >> | | | +------------+ > >> | | | > >> +--------+ +--------+ +--------+ > >> |Reader 1| |Reader 2| ... |Reader n| > >> +--------+ +--------+ +--------+ > >> ^ ^ ^ > >> \ | / > >> \ | / Push mode (RTFM push-mode Protocol?) > >> \ | / > >> +-------------+ > >> | Application | > >> +-------------+ > >> ^ > >> | Pull mode (SNMP,HTTP...) > >> v > >> +----------+ > >> | Meters | > >> +----------+ > >> > >> Second: this would cope with situations where the meter > >> doesn't support push mode... Basically, it's the same as the above > >> but with an application translating from pull mode to push mode... > >> > >> Accounting protocol +------------+ > >> +-------------+--------------+------------->| Acct server| > >> | | | +------------+ > >> | | | > >> +--------+ +--------+ +--------+ > >> |Reader 1| |Reader 2| ... |Reader n| > >> +--------+ +--------+ +--------+ > >> ^ ^ ^ > >> \ | / > >> \ | / Push mode (Local communication) > >> \ | / > >> +----------+ > >> | Meters | > >> +----------+ > >> > >> Third: the meter and reader would be running on the same > >> machine. Thus, the communication is local, and the meter may be > >> running as a thread as you've suggested... And the reader, would then > >> send the flow data to appropriate remote/local store such as a file, > >> remote database, AAA server... > >> > >> > >> This is where I can see useful a well-defined API...Actually, we've > >> done implementations which covers the second and third scenarios above with > >> very good results... For the first one, we have already started the > >> design of the appropriate data structure and control needed. > >> > >> Any comments from the list? > >> > >> Cheers. Marcelo > >> > >> ---------------------------------------------------------- > >> Marcelo Pias - University College London (UCL) > >> www.cs.ucl.ac.uk/staff/m.pias/ > > -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-rtfm@auckland.ac.nz Tue Oct 10 06:15:42 2000 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 GAA00448 for ; Tue, 10 Oct 2000 06:15:40 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id VAA17172; Tue, 10 Oct 2000 21:09:24 +1300 (NZDT) 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 VAA17162; Tue, 10 Oct 2000 21:09:17 +1300 (NZDT) 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 e9A8IEV02992; Tue, 10 Oct 2000 10:18:14 +0200 (CEST) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA21057; Tue, 10 Oct 2000 10:09:01 +0200 Message-ID: <39E2CFD5.C1313DB5@ccrle.nec.de> Date: Tue, 10 Oct 2000 10:14:13 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Marcelo Pias CC: quittek@ccrle.nec.de, Nevil Brownlee , rtfm@auckland.ac.nz, Jon Crowcroft Subject: Re: Push mode (was Re: We're on board) References: <3.0.6.32.20001009221012.008de7d0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo Pias wrote: > > Juergen, > > >Now it is the question, whether we want to extend the Meter MIB such > >that > >it offers also push mode communication. Is this another item for the > >revived working group's agenda? > > I'd suggest this as a new work item... I'd be interested to work on this > too... > > Maybe, it could follow any of these two paths: > > 1. Define the appropriate mechanisms and needed changes within the RTFM MIB > to cope with push mode. What could such a mechanism be? Any idea? > > 2. Specify a protocol to carry "flow data" between meters and readers using > push mode... This could be multicast from meter to readers using a reliable > multicast protocol or something (assuming the no. of readers are enough to > justify multicasting the data, instead of single unicast sessions...) Do you assume multiple readersn of the same information? I doubt. I think if there are multiple readers, they will use different information. > > I'd appreciate any comment/suggests on this... > > Cheers. Marcelo > > ------------------------------------------------------------ > UCL - University College London > > > > >If yes, here are some thoughts on this issue: > > > >In general there is no need, because the combination of Expression MIB > >(draft-ietf-disman-express-mib-12.txt) and Event MIB > >(draft-ietf-disman-event-mib-10.txt) should be sufficent to observe the > >flow table and to generate notifications. As far as I kbow, both MIBs > >are close to becoming an RFC on the standards track. However, using > >these MIBs could be a rather complicated and unflexible way. > > > >So, if we think that push mode is desirable, we should go for a Meter > >MIB > >extension. But also here I see some problems. If the Meter wants to > >notify > >some entity via SNMP is has to send an SNMP notification. Where such a > >notification is sent to is usually not configurable by the MIB portion > >defining the notification, but it is defined either by the SNMP agent's > >configuration file or by managed objects in another MIB portion. > > > >In both cases, it might be impossible to configure the destination for a > >single notification. Very often, all notifications are sent to the same > >set of managers. > > > >Unfortunately, what we would probably like to have is sending > >notifications > >concerning a specific flow to exactly the set of readers which > >(dynamically) > >have been registered for this flow. Maybe somebody on the list knows how > >to > >overcome this problem? > > > >Let's assume we have solved this problem. Then our next step would be > >defining conditions on which notifications are generated. I see several > >possible conditions, among them > > > >- a new entry in the flow table is generated > >- a flow table entry times out, i.e. no new packets for some time > >- the number of octets of a flow exceeds a given number > >- ... > > > >We have to collect all conditions, that might be required by users of > >the > >Meter MIB and find ways of integrating them into the MIB. > > > > > >Marcelo Pias wrote: > >> > >> Hi Nevil, > >> > >> comments in line... > >> > >> On Fri, 6 Oct 2000, Nevil Brownlee wrote: > >> > >> > > >> > > >> > > >You're right, the Meter MIB only does pull behaviour. But there's > >> > > >nothing in the RTFM Architecture which imposes that limitation, so I > >> > > >agree, it would be a good thing to explore this so as to provide a > >> > > >well-defined 'push' interface, API or whatever. Good idea. Let's get > >> > > >it out on the mailing list / in an I-D! > >> > > > >> > > That's true the meter MIB doesn't say anything about this... I > assume in > >> > > order to have this kind of collection, will require modification > within the > >> > > MIB... But also, the meter itself will need to cope with this... Do you > >> > > believe that this a protocol issue only? > >> > > >> > I don't know about it being a 'protocol issue,' but its certainly > >> > something which has strong effects on the meter design - if one chose > >> > to stay with SNMP, the meter would have to send event notifications > >> > (trap messages in SNMPv1), which would of course need changes to the > >> > MIB. Building a meter which, for example, could be run as a thread, > >> > and used via a well-defined API so as to write flow data directly to a > >> > file or database - now that would be an interesting topic to discuss .. > >> > >> I'd point out now three situations where push mode may be used: > >> > >> Accounting protocol +------------+ > >> +-------------+--------------+----------->| Acct server| > >> | | | +------------+ > >> | | | > >> +--------+ +--------+ +--------+ +-------------+ > >> |Reader 1| |Reader 2| ... |Reader n|------>| Local store | > >> +--------+ +--------+ +--------+ +-------------+ > >> ^ ^ ^ > >> \ | / > >> \ | / Push mode (RTFM push-mode protocol?) > >> \ | / > >> +----------+ > >> | Meters | > >> +----------+ > >> > >> First: Each reader subscribes as a listener to the event: > >> "flowdata record ready". When this event occurs, the meter push the > >> flowdata record out to the list of listeners through the network... > >> Readers may control this through an interface provided by the meter. > (e.g. API) > >> > >> Accounting protocol +------------+ > >> +-------------+--------------+----------->| Acct server| > >> | | | +------------+ > >> | | | > >> +--------+ +--------+ +--------+ > >> |Reader 1| |Reader 2| ... |Reader n| > >> +--------+ +--------+ +--------+ > >> ^ ^ ^ > >> \ | / > >> \ | / Push mode (RTFM push-mode Protocol?) > >> \ | / > >> +-------------+ > >> | Application | > >> +-------------+ > >> ^ > >> | Pull mode (SNMP,HTTP...) > >> v > >> +----------+ > >> | Meters | > >> +----------+ > >> > >> Second: this would cope with situations where the meter > >> doesn't support push mode... Basically, it's the same as the above > >> but with an application translating from pull mode to push mode... > >> > >> Accounting protocol +------------+ > >> +-------------+--------------+------------->| Acct server| > >> | | | +------------+ > >> | | | > >> +--------+ +--------+ +--------+ > >> |Reader 1| |Reader 2| ... |Reader n| > >> +--------+ +--------+ +--------+ > >> ^ ^ ^ > >> \ | / > >> \ | / Push mode (Local communication) > >> \ | / > >> +----------+ > >> | Meters | > >> +----------+ > >> > >> Third: the meter and reader would be running on the same > >> machine. Thus, the communication is local, and the meter may be > >> running as a thread as you've suggested... And the reader, would then > >> send the flow data to appropriate remote/local store such as a file, > >> remote database, AAA server... > >> > >> > >> This is where I can see useful a well-defined API...Actually, we've > >> done implementations which covers the second and third scenarios above with > >> very good results... For the first one, we have already started the > >> design of the appropriate data structure and control needed. > >> > >> Any comments from the list? > >> > >> Cheers. Marcelo > >> > >> ---------------------------------------------------------- > >> Marcelo Pias - University College London (UCL) > >> www.cs.ucl.ac.uk/staff/m.pias/ > > -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-rtfm@auckland.ac.nz Tue Oct 10 10:35:48 2000 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 KAA05020 for ; Tue, 10 Oct 2000 10:35:43 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA29172; Wed, 11 Oct 2000 01:35:20 +1300 (NZDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA29166 for ; Wed, 11 Oct 2000 01:35:15 +1300 (NZDT) From: nick.farrow@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 10 Oct 2000 13:34:16 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Tue, 10 Oct 2000 13:34:15 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207A0A55D@mbtlipnt02.btlabs.bt.co.uk> To: rtfm@auckland.ac.nz Subject: RE: We're on board Date: Tue, 10 Oct 2000 13:29:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi, An idea we used a couple of years back, would seem to be appropriate, why not use HTTP ? For the work we did with RTFM here (BT Labs UK) , I coded and HTTP daemon ontop of the RTFM tables allowing browsers to interrogate the flow data directly ( with suitable formatting etc). This was passive so the manager still had control via snmp. I would like to have junked snmp and used xml as a schema allowing for real peer to peer interactions and push with HTTP. You could have then loaded dynamically upgrades for the supported objects, and in general greater flexibility.... but I moved onto other things. Just an idea ! Regards Nick Farrow From owner-rtfm@auckland.ac.nz Tue Oct 17 11:55:37 2000 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 LAA15033 for ; Tue, 17 Oct 2000 11:55:35 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA22315; Wed, 18 Oct 2000 03:04:08 +1300 (NZDT) 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 DAA22306 for ; Wed, 18 Oct 2000 03:04:03 +1300 (NZDT) 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 e9HE3vF21099; Tue, 17 Oct 2000 16:03:57 +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 QAA19721; Tue, 17 Oct 2000 16:03:58 +0200 Message-ID: <39EC5C2F.9DCC04B8@ccrle.nec.de> Date: Tue, 17 Oct 2000 16:03:27 +0200 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rtfm@auckland.ac.nz CC: mobivas@ccrle.nec.de Subject: I-D on high-level interface to RTFM architecture Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, Marcelo Pias and myself have posted an Internet draft on an interface to the RTFM architecture. It is a high-level interface fitting the needs of application, which integrates traffic measurement. You'll find the draft at http://www.ietf.org/internet-drafts/draft-quittek-rtfm-generic-interface-00.txt We derived the interface definition from two APIs implemented independently at University College London and at NEC Europe. The interface definition in the draft is not complete so far, but we posted it already in order to get feedback at an early stage. So, please comment on it. 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 Oct 17 12:38:54 2000 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 MAA16102 for ; Tue, 17 Oct 2000 12:38:52 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA25228; Wed, 18 Oct 2000 04:10:59 +1300 (NZDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id EAA25222 for ; Wed, 18 Oct 2000 04:10:54 +1300 (NZDT) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA24525; Tue, 17 Oct 2000 17:10:12 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id RAA15676; Tue, 17 Oct 2000 17:10:12 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Tue, 17 Oct 2000 17:10:12 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Subject: PAM2001 Call For Papers (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Passive & Active Measurement: PAM-2001 Second call for papers A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 Program Committee: Henk Uijterwaal RIPE-NCC, NL, Conference Chair Nevil Brownlee U.Auckland, NZ Randy Bush Verio, USA kc Claffy CAIDA, USA Les Cottrell SLAC, USA Geoff Huston Telstra, AU Daniel Karrenberg RIPE-NCC, NL Ian Graham U.Waikato, NZ Yasuichi Kitamura APAN, Japan Will Leland Telcordia, USA Tony McGregor U.Waikato, NZ Ronn Ritke NLANR, USA Rick Whitner Agilent, USA As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Papers are invited from the research, provider and any other communities on topics in the areas above, or any other area of network traffic measurement. Areas of interest include, but are not limited to: 1. 'Experience' papers, which describe practical uses of measurements, especially in large networks. 2. Papers on modelling network traffic, in particular if they are backed up by measurements of real traffic. 3. Papers describing network research that can be applied to existing networks. Extended abstracts (about 500 words, plain ASCII preferred) must be submitted by e-mail to pam2001@ripe.net by 12 November 2000. Paper submissions must contain the following: paper title, full name(s) of the author(s), organisational affiliation(s) and 1 email address where the author(s) can be contacted. Abstracts will be reviewed and acceptance notified no later than 18 December 2001. Papers, maximum 15 printed pages, must be submitted electronically by 5 March 2001. Details of acceptable paper formats will be published on the conference web site, http://www.ripe.net/pam2001 There will be an opportunity for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001@ripe.net by 5 March 2001. The program committee is investigating the possibility of organising one or more tutorial sessions in conjunction with the conference. Proposals for tutorials (about 500 words, plain ASCII) should be sent by email to the conference chair by 12 November 2000. The workshop will be held at the Barbizon Golden Tulip hotel in Amsterdam. Special room rates will be available for the conference. The conference fee will be (approximately) 175 Euro (US$165). The exact conference fee and details on registration will be published on the workshop's web page late November. The conference fee will include a printed copy of the papers selected for presentation at the workshop. Papers selected for publication will also be published on the web. Important dates: * 12 November 2000: Deadline for abstracts * 18 December 2000: Notification of acceptance * 5 March 2001: Final papers due * 23-24 April 2001: Conference Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001@ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From owner-rtfm@auckland.ac.nz Wed Oct 25 14:22:24 2000 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 OAA20196 for ; Wed, 25 Oct 2000 14:22:21 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA21232; Thu, 26 Oct 2000 05:37:46 +1300 (NZDT) Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA21224 for ; Thu, 26 Oct 2000 05:37:42 +1300 (NZDT) Received: from hermwas.is.co.za (hermwas.is.co.za [196.23.0.8]) by mercury.is.co.za (Postfix) with ESMTP id 6F8602B1F4 for ; Wed, 25 Oct 2000 18:36:19 +0200 (SAST) Received: (from hvisage@localhost) by hermwas.is.co.za (8.9.3/8.9.3) id SAA01228 for rtfm@auckland.ac.nz; Wed, 25 Oct 2000 18:36:19 +0200 (SAT) Date: Wed, 25 Oct 2000 18:36:18 +0200 From: Hendrik Visage To: rtfm@auckland.ac.nz Subject: NetraMet development question Message-ID: <20001025183618.E14889@hermwas.is.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi there, I'd like to add some more functionality to the NetFlowMet et.al. to be able report on more NetFlow V5 data. (Possible V8 data too). Which version should I do the changes to be able to put it back into NetraMet quick & cleanly as possible?? BTW: What's the expected release date of 4.4, ie. moving out of beta? GReetz Hendrik Visage From owner-rtfm@auckland.ac.nz Thu Oct 26 07:01:32 2000 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 HAA19494 for ; Thu, 26 Oct 2000 07:01:30 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id WAA22478; Thu, 26 Oct 2000 22:06:29 +1300 (NZDT) Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id WAA22467 for ; Thu, 26 Oct 2000 22:06:25 +1300 (NZDT) Received: from hermwas.is.co.za (hermwas.is.co.za [196.23.0.8]) by mercury.is.co.za (Postfix) with ESMTP id C83712AB78 for ; Thu, 26 Oct 2000 11:06:09 +0200 (SAST) Received: (from hvisage@localhost) by hermwas.is.co.za (8.9.3/8.9.3) id LAA05105 for rtfm@auckland.ac.nz; Thu, 26 Oct 2000 11:06:09 +0200 (SAT) Date: Thu, 26 Oct 2000 11:06:09 +0200 From: Hendrik Visage To: rtfm@auckland.ac.nz Subject: NetraMet "inconsistency" Message-ID: <20001026110609.K14889@hermwas.is.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi there, I'm trying to look at precedence traffic through our routers. However, I don't seem to be able to account for ALL the traffic. Please advise on the following usage and why the other traffic, Following .srl: --srl-- #Making use of NetFlowMet save MeterID; save DSCodePoint; save SourceInterface; save DestInterface; count; SET 7;# NeMaC command FORMAT FlowRuleSet MeterID FlowIndex FirstTime " " ToPDUs ToOctets " <-> " FromPDUs FromOctets " [ " DSCodePoint " ]" "{ " SourceInterface "->" DestInterface " }" ; Statistics; --srl-- nm_rc output: #--- netracollector udp-8995, udp-8996, udp-8997 243 flows 11kpps 5MBps 11:02:30 Thu 26 Oct 2000 --- 10% 17 1 1342 3m 759 419kB <-> 2k 2MB [ 0 ]2->1 } 7% 17 3 1373 2m 785 426kB <-> 2k 1MB [ 0 ]5->1 } 5% 17 2 1423 10m 965 1MB <-> 0 0B [ 16 ]1->19 } 5% 17 1 1338 3m 1k 582kB <-> 1k 704kB [ 0 ]8->1 } 5% 17 3 1366 2m 2k 936kB <-> 2k 338kB [ 0 ]11->1 } 5% 17 1 1343 3m 1k 1MB <-> 0 0B [ 0 ]1->1 } 5% 17 3 1374 2m 1k 678kB <-> 2k 494kB [ 0 ]7->1 } 4% 17 3 1370 2m 1k 1MB <-> 0 0B [ 0 ]1->1 } 4% 17 3 1375 2m 759 437kB <-> 2k 633kB [ 0 ]9->1 } 4% 17 1 1336 3m 1k 753kB <-> 980 300kB [ 0 ]44->1 } 47% bytes in 233 other flows GReetz Hendrik From owner-rtfm@auckland.ac.nz Thu Oct 26 20:52:56 2000 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 UAA16247 for ; Thu, 26 Oct 2000 20:52:50 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA11444; Fri, 27 Oct 2000 12:05:03 +1300 (NZDT) 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 MAA11365; Fri, 27 Oct 2000 12:04:51 +1300 (NZDT) From: Nevil Brownlee To: Hendrik Visage Cc: rtfm@auckland.ac.nz Subject: Re: NetraMet "inconsistency" In-Reply-To: <20001026110609.K14889@hermwas.is.co.za> Message-ID: Date: Fri, 27 Oct 2000 12:04:55 +1300 (New Zealand Daylight 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 Hello Hendrik: > I'm trying to look at precedence traffic through our routers. However, > I don't seem to be able to account for ALL the traffic. > > Please advise on the following usage and why the other traffic, > nm_rc output: > > #--- netracollector udp-8995, udp-8996, udp-8997 243 flows 11kpps 5MBps 11:02:30 Thu 26 Oct 2000 --- > 10% 17 1 1342 3m 759 419kB <-> 2k 2MB [ 0 ]2->1 } > 7% 17 3 1373 2m 785 426kB <-> 2k 1MB [ 0 ]5->1 } nm_rc only displays the top n (default top 10) flows, which is why you're only seeing 10. To see all the flows, use NeMaC instead; you'll get all the flow records written to a flow data file. If you're writing rulesets to aggregate the flows (so as to reduce the amount of data you collect), remember that because each packet has only a single codepoint (rather than two, as for IP addresses), you can't use the DSCodePoint attribute as a way of determining flow direction. (You probably don't want to do that anyway :-) The way in which the DSCodePoint attribute should be implemented is one of the topics to be discussed in an RTFM2 BOF at the San Diego IETF meeting this December; your input to that would be much appreciated. Cheers, Nevil PS: NeTraMet-specific topics (such as your question about nm_rc) should really be sent to the NeTraMet mailing list. +---------------------------------------------------------------------+ | 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