From owner-rtfm@auckland.ac.nz Thu Feb 1 14:15:35 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 OAA08479 for ; Thu, 1 Feb 2001 14:15:34 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id GAA02739; Fri, 2 Feb 2001 06:49:47 +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 GAA02732 for ; Fri, 2 Feb 2001 06:49:45 +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 f11HnlV54646 for ; Thu, 1 Feb 2001 18:49:47 +0100 (CET) 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 SAA24223 for ; Thu, 1 Feb 2001 18:49:42 +0100 Message-ID: <3A79A176.2E143A61@ccrle.nec.de> Date: Thu, 01 Feb 2001 18:48:38 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: RTFM mailing list Subject: charter goal #1b Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Goal 1 of the suggested charter: > Develop a standard for describing traffic flows, and for > reporting them from a meter to a flow flow data collection > system. Such a standard would meet a clearly-expressed > need for many system vendors. Now the second issue (#1b): > Develop a standard for reporting them from a meter to a > flow data collection system. - What would be the resulting benefit? A meter reporting actively is highly desirable. I have been working in several projects where meters for accounting were required. In this application the meter is required to notify the reader when a new flow (table entry) is established and - even more important - when a flow times out and accounting for that session can be completed. - Is it or does it appear to be technically feasible? Yes, definitely. The current RTFM architecture and the Meter MIB comply with the SNMP policy of assigning the active part to the reader (SNMP manager) and the passive part to the meter (SNMP agent), except for some extraordinary situations. Now this policy has to be violated. The meter will notify the reader in ordinary cases. This is technically no problem nor even with SNMP. - Is "now" the right time to work on this item? Yes, there are a lot of applications that would benefit from such an improvement of the current RTFM architecture. - Can we expect sufficient support by technical, experts, i.e. who is willing to contribute? Yes, definitely. There a many people in the NeTraMet user community waiting for such an improvement. Several of them will be willing to help and contribute their ideas and concerns. - What would be the expected output documents? A revision of the RTFM architecture and the Meter MIB - What timeframe would be appropriate? I estimate one year or less. - Is the IETF the right place for this item? Yes, no question. It is a modification of IETF documents including an IETF standard. 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 Thu Feb 1 14:15:41 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 OAA08490 for ; Thu, 1 Feb 2001 14:15:39 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id GAA02417; Fri, 2 Feb 2001 06:43:33 +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 GAA02400; Fri, 2 Feb 2001 06:43:14 +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 f11HhEV54411; Thu, 1 Feb 2001 18:43:14 +0100 (CET) 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 SAA24117; Thu, 1 Feb 2001 18:43:09 +0100 Message-ID: <3A799FEF.5D5544EF@ccrle.nec.de> Date: Thu, 01 Feb 2001 18:42:07 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: rtfm@auckland.ac.nz Subject: Re: DRAFT charter for proposed RTFM2 WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit I have some comments on the goals suggested in the charter. I suggest to discuss the goals item by item. For each item we may consider - What would be the resulting benefit? - Is it or does it appear to be technically feasible? - Is "now" the right time to work on this item? - Can we expect sufficient support by technical, experts, i.e. who is willing to contribute? - What would be the expected output documents? - What timeframe would be appropriate? - Is the IETF the right place for this item? I'll send some followup messages starting a discussion on these questions for each goal of the suggested charter. Please anyone feel free to suggest further goals on this list. 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 Nevil Brownlee wrote: > > Hello all: > > Back in December we held a well-attended BOF session at the San Diego > IETF meeting. Consensus of the meeting was that not only were there > worthwhile things for a new Working Group to do, but there were people > at the meeting who were preapred to do the work. > > The BOF minutes (on the RTFM home page at > www.auckland.ac.nz/net/Internet/rtfm) record our consensus that > we should work on a draft charter on the RTFM email list. > > I've been waiting for some guidance on a proposed charter from our Area > Directors, but I see that scheduling is open now for the next IETF > meeting in Minneapolis next March. If we want a session there, we need > to get moving. To kick off discussion, I've attached a draft WG > charter below. Would you please read it, and: > > a) If you think the draft charter is badly worded, doesn't say > the right things, or leaves out things which you think are > important, send your comments to the list. > > b) If you (and/or your company) would be prepared to work on documents, > please, please send a note saying which ones either to the list, > or directly to me. > > If a new WG is to be chartered, we need to demonstrate strong support > for it, and well-defined goals. Tell us what you think! > > 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 > > Charter for a Proposed RTFM2 Working Group > > **** DRAFT **** Fri 15 Dec 00 **** > > In October 1999 RFCs 2720-2724 were published, specifying the RTFM > Traffic Measurement Architecture. Since then many sites have been > using the NeTraMet implementation for production traffic data > collection, and others have used it as the basis of further > developments in the field of network traffic measurement. From > this development work a need has arisen to extend the RTFM > Architecture. > > Furthermore, over the last few years interest in flow measurement > has steadily increased, and many commercial products for this are > now available. Experience in this field indicates that although > the current RTFM architecture provides a very general definition > of flows and an effective method of collecting flow data, there is > a clear need for new, standard approaches to this problem. > > As well as extending the original RTFM architecture, the Working > Group will develop new approaches to traffic flow measurement, > as follows .. > > Goals: > > 1 Develop a standard for describing traffic flows, and for > reporting them from a meter to a flow flow data collection > system. Such a standard would meet a clearly-expressed > need for many system vendors. > > 2 Define a distributed metering architecture to support metrics > defined within the IPPM framework, e.g. one-way delay, > connectivity, one-way loss rate. This architecture will > include remote packet capture, and will addres privacy > concerns such as the inadvertant disclosure of user > information and the need to authenticate and authorise > access to captured data. > > 3.1 Develop a high-level interface to the current RTFM system, > so as to make RTFM capabilities easily and directly accessible > to new application programs. > > 3.2 Standardise some of the 'new attributes' described in > RFC 2724. Extend the RTFM architecture, e.g. by adding > 'list-valued' attributes to the RTFM meter. > > Milestones: > > Documents > [questions, comments/suggestion please.. > - what other documents will be needed? > - what should be in the documents (ideas for a > 'contents' list for each would be very welcome!) > - who's volunteering to contribute to them? > - when could first drafts be ready? > ] > > * RTFM2 Flow Definition and Reporting Scheme > Defines a flexible description of flows which all vendors > can use when configuring meters. The flow definitions > should be flexible enough to handle layer 2, 3 and 4/5 > attributes, making them suitable for traffic engineering, > accounting, and network operations for at least all > IETF-specified protocols. > Specifies protocol for reporting flow data from meters. > > > * Requirements for Distributed Metering > > * Architecture for Distributed Metering > > * Remote Packet Capture Protocol > > * Distributing Metering Control Protocol > > * High-Level Interface to RTFM > > * Revised RTFM Architecture > * RTFM Meter MIB Extensions > > ------------------------------------------------------------------------------- From owner-rtfm@auckland.ac.nz Thu Feb 1 14:28:35 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 OAA09209 for ; Thu, 1 Feb 2001 14:28:33 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id GAA02592; Fri, 2 Feb 2001 06:46:49 +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 GAA02587 for ; Fri, 2 Feb 2001 06:46:47 +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 f11HknV54510 for ; Thu, 1 Feb 2001 18:46:49 +0100 (CET) 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 SAA24180 for ; Thu, 1 Feb 2001 18:46:44 +0100 Message-ID: <3A79A0C5.59316D52@ccrle.nec.de> Date: Thu, 01 Feb 2001 18:45:41 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: RTFM mailing list Subject: charter goal #1a Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Goal 1 of the suggested charter: > Develop a standard for describing traffic flows, and for > reporting them from a meter to a flow flow data collection > system. Such a standard would meet a clearly-expressed > need for many system vendors. For me there are two issues in here, so I start with the first one (#1a): > Develop a standard for describing traffic flows Let me give my interpretation of this phrase first: There are already several standards out there describing traffic flows. RTFM (Meter MIB) is obviously one, but there are others, e.g. IntServ, that include their own flow model, because they need one and there is no suitable standard. I understand this goal as an approach to a one size fits all traffic description. Please correct me if I'm wrong. (If I'm wrong, then some of the statements below are also wrong.) - What would be the resulting benefit? I consider the benefit to be rather high, because, there are a lot incompatible flow description formats out there and for users it is sometimes very confusing and annoying because automatic translations between many of them are not possible. - Is it or does it appear to be technically feasible? I doubt that it is (please object if you have a different view!). For some differences between existing flow description formats there are good reasons, e.g. because of different usage cases. Take the DiffServ flow model and the rtfm flow model. In DiffServ a flow can be described in various ways and typically with a small number of attributes in simple conjunctions. For rtfm, a high number of attributes is available and you can create complex dependencies among them. This would not fit DiffServ, but is quite useful for detailed traffic measurements. Maybe we can come up with a flow model fitting a restricted set of applications. Then we should try to identify these applications. - Is "now" the right time to work on this item? Yes, The number of traffic flow models I see is continuously growing and the earlier there is a commonly usable model, the better. - Can we expect sufficient support by technical, experts, i.e. who is willing to contribute? I expect this. But what I also would expect is a lot of experts disagreeing with the result, however it will look like, because they have been using different models so far and the new model will probably not be as well suited as their own tailored one. - What would be the expected output documents? A document defining a flow model, probably based on a more basic information model, such as the CIM model used in the policy wg. - What timeframe would be appropriate? Certainly, setting up a model could be done within some more than half a year. However, since this model could affect a lot of people I'm afraid that agreeing on a model would take very long. - Is the IETF the right place for this item? Yes definitely. This is directly related to a lot of work done on the IP network layer. 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 Sat Feb 3 23:25: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 XAA10894 for ; Sat, 3 Feb 2001 23:25:07 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id PAA09026; Sun, 4 Feb 2001 15:40:07 +1300 (NZDT) Received: from kosh.narus.com (kosh.narus.com [64.240.193.204]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id PAA09002; Sun, 4 Feb 2001 15:39:51 +1300 (NZDT) Received: from franklin.narus.com (franklin [192.168.2.17]) by kosh.narus.com (8.9.3/8.9.3) with ESMTP id RAA21363; Sat, 3 Feb 2001 17:52:55 -0800 Received: by franklin.narus.com with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Feb 2001 18:38:25 -0800 Message-ID: <580E532D9F7A9B4BAE8A130848E0DDA75F8141@franklin.narus.com> From: Stas Khirman To: Juergen Quittek , Nevil Brownlee Cc: rtfm@auckland.ac.nz Subject: RE: DRAFT charter for proposed RTFM2 WG Date: Sat, 3 Feb 2001 18:38:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi, Last IETF meeting presentations and discussions show that "Remote Packet Capturing" issues have natural relationship to the flow monitoring. Are we considering design of the "Packet Capturing" standards as the one of the RTFM2 future goals ? Are we going to reflect our decision (positive or negative) it in RTFM2 chapter? On my personal opinion, practical implementation of the distributed flow monitoring system have to include some sort of the packet (or part of them) capturing and reporting (as described at draft-bullard-pcap-00.txt). This functionality is crucial for number of applications, such as protocol recognition (using data signature of the first data packets) , off-line analysis (OCxMON approach) and so on. From other hand, high data volume make packet capturing impractical without flow aggregation and classification (like it described in the draft-quittek-pcap-ext-00.txt). This consideration make flow monitoring and selective packet capturing natural allies and, on my personal opinion, have to be a considered by RTFM2 WG. Sincerely Stas Khirman -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Thursday, February 01, 2001 9:42 AM To: Nevil Brownlee Cc: rtfm@auckland.ac.nz Subject: Re: DRAFT charter for proposed RTFM2 WG I have some comments on the goals suggested in the charter. I suggest to discuss the goals item by item. For each item we may consider - What would be the resulting benefit? - Is it or does it appear to be technically feasible? - Is "now" the right time to work on this item? - Can we expect sufficient support by technical, experts, i.e. who is willing to contribute? - What would be the expected output documents? - What timeframe would be appropriate? - Is the IETF the right place for this item? I'll send some followup messages starting a discussion on these questions for each goal of the suggested charter. Please anyone feel free to suggest further goals on this list. 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 Nevil Brownlee wrote: > > Hello all: > > Back in December we held a well-attended BOF session at the San Diego > IETF meeting. Consensus of the meeting was that not only were there > worthwhile things for a new Working Group to do, but there were people > at the meeting who were preapred to do the work. > > The BOF minutes (on the RTFM home page at > www.auckland.ac.nz/net/Internet/rtfm) record our consensus that > we should work on a draft charter on the RTFM email list. > > I've been waiting for some guidance on a proposed charter from our Area > Directors, but I see that scheduling is open now for the next IETF > meeting in Minneapolis next March. If we want a session there, we need > to get moving. To kick off discussion, I've attached a draft WG > charter below. Would you please read it, and: > > a) If you think the draft charter is badly worded, doesn't say > the right things, or leaves out things which you think are > important, send your comments to the list. > > b) If you (and/or your company) would be prepared to work on documents, > please, please send a note saying which ones either to the list, > or directly to me. > > If a new WG is to be chartered, we need to demonstrate strong support > for it, and well-defined goals. Tell us what you think! > > 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 > > Charter for a Proposed RTFM2 Working Group > > **** DRAFT **** Fri 15 Dec 00 **** > > In October 1999 RFCs 2720-2724 were published, specifying the RTFM > Traffic Measurement Architecture. Since then many sites have been > using the NeTraMet implementation for production traffic data > collection, and others have used it as the basis of further > developments in the field of network traffic measurement. From > this development work a need has arisen to extend the RTFM > Architecture. > > Furthermore, over the last few years interest in flow measurement > has steadily increased, and many commercial products for this are > now available. Experience in this field indicates that although > the current RTFM architecture provides a very general definition > of flows and an effective method of collecting flow data, there is > a clear need for new, standard approaches to this problem. > > As well as extending the original RTFM architecture, the Working > Group will develop new approaches to traffic flow measurement, > as follows .. > > Goals: > > 1 Develop a standard for describing traffic flows, and for > reporting them from a meter to a flow flow data collection > system. Such a standard would meet a clearly-expressed > need for many system vendors. > > 2 Define a distributed metering architecture to support metrics > defined within the IPPM framework, e.g. one-way delay, > connectivity, one-way loss rate. This architecture will > include remote packet capture, and will addres privacy > concerns such as the inadvertant disclosure of user > information and the need to authenticate and authorise > access to captured data. > > 3.1 Develop a high-level interface to the current RTFM system, > so as to make RTFM capabilities easily and directly accessible > to new application programs. > > 3.2 Standardise some of the 'new attributes' described in > RFC 2724. Extend the RTFM architecture, e.g. by adding > 'list-valued' attributes to the RTFM meter. > > Milestones: > > Documents > [questions, comments/suggestion please.. > - what other documents will be needed? > - what should be in the documents (ideas for a > 'contents' list for each would be very welcome!) > - who's volunteering to contribute to them? > - when could first drafts be ready? > ] > > * RTFM2 Flow Definition and Reporting Scheme > Defines a flexible description of flows which all vendors > can use when configuring meters. The flow definitions > should be flexible enough to handle layer 2, 3 and 4/5 > attributes, making them suitable for traffic engineering, > accounting, and network operations for at least all > IETF-specified protocols. > Specifies protocol for reporting flow data from meters. > > > * Requirements for Distributed Metering > > * Architecture for Distributed Metering > > * Remote Packet Capture Protocol > > * Distributing Metering Control Protocol > > * High-Level Interface to RTFM > > * Revised RTFM Architecture > * RTFM Meter MIB Extensions > > ---------------------------------------------------------------------------- --- From owner-rtfm@auckland.ac.nz Mon Feb 5 13:18:25 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 NAA13356 for ; Mon, 5 Feb 2001 13:18:23 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA19688; Tue, 6 Feb 2001 05:38:07 +1300 (NZDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA19677 for ; Tue, 6 Feb 2001 05:38:04 +1300 (NZDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA12518; Mon, 5 Feb 2001 17:37:55 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA19368; Mon, 5 Feb 2001 17:37:52 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 17:37:46 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A273BFE@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Juergen Quittek'" , RTFM mailing list Subject: RE: charter goal #1a Date: Mon, 5 Feb 2001 17:37:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk See comments inline > -----Original Message----- > From: Juergen Quittek [SMTP:quittek@ccrle.nec.de] > Sent: Thursday, February 01, 2001 6:46 PM > To: RTFM mailing list > Subject: charter goal #1a > > Goal 1 of the suggested charter: > > > Develop a standard for describing traffic flows, and for > > reporting them from a meter to a flow flow data collection > > system. Such a standard would meet a clearly-expressed > > need for many system vendors. > > For me there are two issues in here, so I start with the first > one (#1a): > > > Develop a standard for describing traffic flows > > Let me give my interpretation of this phrase first: > There are already several standards out there describing traffic > flows. RTFM (Meter MIB) is obviously one, but there are others, > e.g. IntServ, that include their own flow model, because they > need one and there is no suitable standard. > > I understand this goal as an approach to a one size fits all > traffic description. Please correct me if I'm wrong. (If I'm > wrong, then some of the statements below are also wrong.) > In fact, the goal just states a standard for describing traffic flows is to be developed. This is somewhat surprising, since, also in my view, the RTFM is just such a standard. So what was wrong with the first version? If the goal is developing a one size fits all traffic description, it should be made more clear in the charter. > - What would be the resulting benefit? > I consider the benefit to be rather high, because, there are a lot > incompatible flow description formats out there and for users it > is sometimes very confusing and annoying because automatic > translations between many of them are not possible. > > - Is it or does it appear to be technically feasible? > I doubt that it is (please object if you have a different view!). > For some differences between existing flow description formats there > are good reasons, e.g. because of different usage cases. Take the > DiffServ flow model and the rtfm flow model. In DiffServ a flow can > be described in various ways and typically with a small number of > attributes in simple conjunctions. For rtfm, a high number of attributes > is available and you can create complex dependencies among them. > This would not fit DiffServ, but is quite useful for detailed traffic > measurements. > > Maybe we can come up with a flow model fitting a restricted set of > applications. Then we should try to identify these applications. > Or may be we just need new attributes to add to the old model. See below. > > - Is "now" the right time to work on this item? > Yes, The number of traffic flow models I see is continuously growing > and the earlier there is a commonly usable model, the better. > > - Can we expect sufficient support by technical, > experts, i.e. who is willing to contribute? > I expect this. But what I also would expect is a lot of experts > disagreeing with the result, however it will look like, because > they have been using different models so far and the new model > will probably not be as well suited as their own tailored one. > > - What would be the expected output documents? > A document defining a flow model, probably based on a more basic > information model, such as the CIM model used in the policy wg. > Let me be a bit provocative here. Sorry if this was already discussed in San Diego. Would it be a "new flow model" or just (being one-size-fits-all) the sum of all descriptions currently out there? The "new attributes" RFC already went in this direction by including IntServ and DiffServ attributes. So why not just add even more new attributes? Why a "new flow model"? What would be different? The level of abstraction? > - What timeframe would be appropriate?> > Certainly, setting up a model could be done within some more > than half a year. However, since this model could affect a lot > of people I'm afraid that agreeing on a model would take very long. > > - Is the IETF the right place for this item? > Yes definitely. This is directly related to a lot of work done > on the IP network layer. > > Juergen > Cornelia PS.: Obviously I would be willing to contribute to the work of the WG. -------------------- Cornelia Kappler Standards & Technology ICM N MC ST3 Siemens AG, Siemensdamm 62, 13629 Berlin, Germany From owner-rtfm@auckland.ac.nz Mon Feb 5 13:24:18 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 NAA13357 for ; Mon, 5 Feb 2001 13:18:23 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA19687; Tue, 6 Feb 2001 05:38:07 +1300 (NZDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA19676 for ; Tue, 6 Feb 2001 05:38:04 +1300 (NZDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA12529; Mon, 5 Feb 2001 17:37:59 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA19417; Mon, 5 Feb 2001 17:37:58 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 17:37:53 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A273BFF@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Juergen Quittek'" , RTFM mailing list Subject: RE: charter goal #1b Date: Mon, 5 Feb 2001 17:37:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rtfm@auckland.ac.nz Precedence: bulk > -----Original Message----- > From: Juergen Quittek [SMTP:quittek@ccrle.nec.de] > Sent: Thursday, February 01, 2001 6:49 PM > To: RTFM mailing list > Subject: charter goal #1b > > Goal 1 of the suggested charter: > > > Develop a standard for describing traffic flows, and for > > reporting them from a meter to a flow flow data collection > > system. Such a standard would meet a clearly-expressed > > need for many system vendors. > > Now the second issue (#1b): > > > Develop a standard for reporting them from a meter to a > > flow data collection system. > > - What would be the resulting benefit? > A meter reporting actively is highly desirable. I have been > working in several projects where meters for accounting were > required. In this application the meter is required to notify > the reader when a new flow (table entry) is established and > - even more important - when a flow times out and accounting > for that session can be completed. > I agree with this suggestion. However, as for 1a, I think the wording of the goals can be improved. My understanding is a standard for reporting flows already was specified in the rtfm architecture. What Juergen proposes is an extension to the standard. So what is meant by the goal. Extending the standard, or completely reworking it? If it is extensions, I think a list of possible extensions should be given in the charter. If it is a complete rework, reasons should be given why the current standard is insufficient, and what will be different with a new standard. > - Is it or does it appear to be technically feasible? > Yes, definitely. The current RTFM architecture and the Meter > MIB comply with the SNMP policy of assigning the active part > to the reader (SNMP manager) and the passive part to the > meter (SNMP agent), except for some extraordinary situations. > > Now this policy has to be violated. The meter will notify > the reader in ordinary cases. This is technically no problem > nor even with SNMP. > > - Is "now" the right time to work on this item? > Yes, there are a lot of applications that would benefit from > such an improvement of the current RTFM architecture. > > - Can we expect sufficient support by technical, > experts, i.e. who is willing to contribute? > Yes, definitely. There a many people in the NeTraMet user > community waiting for such an improvement. Several of them > will be willing to help and contribute their ideas and > concerns. > > - What would be the expected output documents? > A revision of the RTFM architecture and the Meter MIB > > - What timeframe would be appropriate? > I estimate one year or less. > > - Is the IETF the right place for this item? > Yes, no question. It is a modification of IETF documents > including an IETF standard. > > Cornelia > > -------------------- Cornelia Kappler Standards & Technology ICM N MC ST3 Siemens AG, Siemensdamm 62, 13629 Berlin, Germany From owner-rtfm@auckland.ac.nz Mon Feb 5 13:28: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 NAA13704 for ; Mon, 5 Feb 2001 13:28:19 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA19704; Tue, 6 Feb 2001 05:38:12 +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 FAA19678; Tue, 6 Feb 2001 05:38:05 +1300 (NZDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA25164; Mon, 5 Feb 2001 17:38:00 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA19436; Mon, 5 Feb 2001 17:38:01 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 17:37:56 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A273C00@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Nevil Brownlee'" , rtfm@auckland.ac.nz Subject: charter goal 2 Date: Mon, 5 Feb 2001 17:37:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rtfm@auckland.ac.nz Precedence: bulk > 2 Define a distributed metering architecture to support metrics > defined within the IPPM framework, e.g. one-way delay, > connectivity, one-way loss rate. This architecture will > include remote packet capture, and will addres privacy > concerns such as the inadvertant disclosure of user > information and the need to authenticate and authorise > access to captured data. > > So I figure the distributed metering architecture is necessary for supporting the metrics of ippm. However, there seem to be more reasons for developing it, such as remote packet capture. The benefit of the latter is improved processing performance (?). Therefore the goal should be re-formulated along the lines. E.g. "Define a distributed metering architecture. Such a distributed architecture would on the one hand support metrics based on distributed measurements such as those developed by the ippm. On the other hand, it would support remote packet capture, with the benefit of improved metering performance." (I'm not sure I grasp the full benefits of remote packet capture.) The other thing I dislike about this goal is that rtfm IS already distributed: Many meters can report to a single reader. The reason ippm metrics cannot be supported is that readers don't do any processing, at least not any that is standardized. So I would like to discuss whether "distributed metering architecture" is indeed the correct term. What we are rather doing is introducing yet another layer in the measurement hierarchy. Finally, remote packet capture is possibly another form of distributed metering than that needed for ippm metrics. For ippm metrics you necessarily have a n:1 relation beween points of measurement and meters. With remote packet capture, you might just have a 1:1 relation. So may be remote packet capture should be a separate goal. Cornelia -------------------- Cornelia Kappler Standards & Technology ICM N MC ST3 Siemens AG, Siemensdamm 62, 13629 Berlin, Germany From owner-rtfm@auckland.ac.nz Mon Feb 5 16:19:25 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 QAA17871 for ; Mon, 5 Feb 2001 16:19:24 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA28253; Tue, 6 Feb 2001 08:26:02 +1300 (NZDT) Received: from taomime.bcbssc.com (taomime.bcbssc.com [207.19.198.72]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA28232; Tue, 6 Feb 2001 08:25:54 +1300 (NZDT) Received: from bcbssc.com (207.19.198.72) by taomime.bcbssc.com (NPlex 2.0.108); 5 Feb 2001 14:25:10 -0500 Message-ID: Date: Mon, 5 Feb 2001 14:22:00 -0500 From: "ELAINE SHARP" To: Kappler Cornelia Cc: rtfm@auckland.ac.nz, Nevil Brownlee Subject: RE:charter goal 2 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Please remove my name from your mailing list. Thanks Elaine.Sharp@bcbssc.com ------------------( Forwarded letter 1 follows )-------------------- Date: Mon, 5 Feb 2001 17:37:51 +0100 To: Nevil.Brownlee[n.brownlee]@auckland.ac.nz.inet, rtfm@auckland.ac.nz.inet From: Kappler.Cornelia[Cornelia.Kappler]@icn.siemens.de.inet Sender: owner-rtfm@auckland.ac.nz.inet Subject: charter goal 2 > 2 Define a distributed metering architecture to support metrics > defined within the IPPM framework, e.g. one-way delay, > connectivity, one-way loss rate. This architecture will > include remote packet capture, and will addres privacy > concerns such as the inadvertant disclosure of user > information and the need to authenticate and authorise > access to captured data. > > So I figure the distributed metering architecture is necessary for supporting the metrics of ippm. However, there seem to be more reasons for developing it, such as remote packet capture. The benefit of the latter is improved processing performance (?). Therefore the goal should be re-formulated along the lines. E.g. "Define a distributed metering architecture. Such a distributed architecture would on the one hand support metrics based on distributed measurements such as those developed by the ippm. On the other hand, it would support remote packet capture, with the benefit of improved metering performance." (I'm not sure I grasp the full benefits of remote packet capture.) The other thing I dislike about this goal is that rtfm IS already distributed: Many meters can report to a single reader. The reason ippm metrics cannot be supported is that readers don't do any processing, at least not any that is standardized. So I would like to discuss whether "distributed metering architecture" is indeed the correct term. What we are rather doing is introducing yet another layer in the measurement hierarchy. Finally, remote packet capture is possibly another form of distributed metering than that needed for ippm metrics. For ippm metrics you necessarily have a n:1 relation beween points of measurement and meters. With remote packet capture, you might just have a 1:1 relation. So may be remote packet capture should be a separate goal. Cornelia -------------------- Cornelia Kappler Standards & Technology ICM N MC ST3 Siemens AG, Siemensdamm 62, 13629 Berlin, Germany From owner-rtfm@auckland.ac.nz Mon Feb 5 17:56:00 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 RAA19957 for ; Mon, 5 Feb 2001 17:55:59 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id JAA05631; Tue, 6 Feb 2001 09:50:22 +1300 (NZDT) Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.40.144]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id JAA05626; Tue, 6 Feb 2001 09:50:18 +1300 (NZDT) Received: from sphynx (adsl-151-202-200-249.nyc.adsl.bellatlantic.net [151.202.200.249]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with SMTP id PAA12499; Mon, 5 Feb 2001 15:49:03 -0500 (EST) Reply-To: From: "Carter Bullard" To: "'Kappler Cornelia'" , "'Nevil Brownlee'" , Subject: RE: charter goal 2 Date: Mon, 5 Feb 2001 15:48:55 -0500 MIME-Version: 1.0 Message-ID: <38E99DA2CEFA7248B5828BBF99344D8604CB11@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4D486782CA36D4118A530000D11EA42A273C00@blns204e.bln.icn.siemens.de> Importance: Normal Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007E_01C08F8B.24629340" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C08F8B.24629340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hey Kappler, I believe that distributed monitoring pertains to metrics that can only be determined through the use of multiple monitors measuring the same network event. One-way delay is a great example of this. You have to have time determination at two points along the path. Some packet loss metrics can only be measured with two meters, and some reachability metrics require two meters. Connectivity monitors in asymmetric networks require multiple monitors. I see Remote Packet Capture as supporting distributed monitoring, rather than distributed monitoring enabling/ supporting Remote Packet Capture. Remote packet capture enables a single meter to monitor at multiple points in the network at the same time. Remote packet capture is not a meter, it is merely a tap, that can support any kind of meter you want to build (assuming its a packet meter ;o). Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 813-9426 Fax +1 212 813-9426 > -----Original Message----- > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > Behalf Of Kappler Cornelia > Sent: Monday, February 05, 2001 11:38 AM > To: 'Nevil Brownlee'; rtfm@auckland.ac.nz > Subject: charter goal 2 > > > > > > 2 Define a distributed metering architecture to support metrics > > defined within the IPPM framework, e.g. one-way delay, > > connectivity, one-way loss rate. This architecture will > > include remote packet capture, and will addres privacy > > concerns such as the inadvertant disclosure of user > > information and the need to authenticate and authorise > > access to captured data. > > > > > So I figure the distributed metering architecture is > necessary for supporting the metrics of ippm. However, there > seem to be more reasons for developing it, such as remote > packet capture. The benefit of the latter is improved > processing performance (?). Therefore the goal should be > re-formulated along the lines. E.g. > > "Define a distributed metering architecture. Such a > distributed architecture would on the one hand support > metrics based on distributed measurements such as those > developed by the ippm. On the other hand, it would support > remote packet capture, with the benefit of improved metering > performance." (I'm not sure I grasp the full benefits of > remote packet capture.) > > The other thing I dislike about this goal is that rtfm IS > already distributed: Many meters can report to a single > reader. The reason ippm metrics cannot be supported is that > readers don't do any processing, at least not any that is > standardized. So I would like to discuss whether "distributed > metering architecture" is indeed the correct term. What we > are rather doing is introducing yet another layer in the > measurement hierarchy. > > Finally, remote packet capture is possibly another form of > distributed metering than that needed for ippm metrics. For > ippm metrics you necessarily have a n:1 relation beween > points of measurement and meters. With remote packet capture, > you might just have a 1:1 relation. So may be remote packet > capture should be a separate goal. > > Cornelia > > > -------------------- > Cornelia Kappler > Standards & Technology > ICM N MC ST3 > Siemens AG, Siemensdamm 62, 13629 Berlin, Germany > > > > > ------=_NextPart_000_007E_01C08F8B.24629340 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBjCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/ LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIEkDCCA/mgAwIBAgIQO4H/J4r5o7F3uerKvfXEkzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMTAxMTgw MDAwMDBaFw0wMjAxMTgyMzU5NTlaMIIBFDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOQ2FydGVyIEJ1bGxhcmQxITAfBgkqhkiG9w0BCQEWEmNh cnRlckBxb3NpZW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy15wPC/ETaGFY9Z2 drqsUQSgumRuFUpc1/+A3UTQcAwYGrf6cgBmqWVLuwgPWjsiUG/mkFksv0EhfDtEAuexuwcXC01u DtDZsKBqIUx5p9rzY1fJRVzv2YGEhwvQuk3s3z0ewWvglK1s2s9psntyT/74nyenSTxxACzKBHkQ 9kECAwEAAaOCASYwggEiMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBCDAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBEGCWCGSAGG+EIBAQQEAwIH gDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5Yzcz NTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVhZGIyYmQyZTg5MjE3YWQ2YmYz ZDUxMTQ4OWNhM2JmNDdmOGYzZWE0NTBjMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVy aXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAQu+Udo1OWlH/28dM4UtX1Spz 8RGBNHRWqzQOJ2w5O6O//5uRdrNwQVvz/fsRA9f2Eqp3xh9cHMro03R12Vdz9n6H/PuT7rA4IE/P djeIrBoa5Rvx9rTM1XDL+it12j1iz74nQ3T3rubXRta/w515za359TzQEeExDKmWSYCzt60xggQv MIIEKwIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQO4H/J4r5o7F3 uerKvfXEkzAJBgUrDgMCGgUAoIICozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMTAyMDUyMDQ4NTNaMCMGCSqGSIb3DQEJBDEWBBQ/ZmK+JVH2PNWO7xb9uqFH6TeL PzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhA7gf8nivmjsXe56sq99cSTMIH0Bgsq hkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENs YXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQO4H/ J4r5o7F3uerKvfXEkzANBgkqhkiG9w0BAQEFAASBgBFToMes+3UObzC66QhH4i6C/avK/6Znfpux jj97CDczKbtyjpi8kJqDVOVUG+w35gg751gHK/ow1nnJDZa6s4+uyjJhzg0PgfjnPxRh1uOOzR9o wB0PK1cbrBeREmAJzAQBZVU3ysg2L7K7mpRN23V7oGBMi9E52mEXFO6sSHmuAAAAAAAA ------=_NextPart_000_007E_01C08F8B.24629340-- From owner-rtfm@auckland.ac.nz Tue Feb 6 06:43:00 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 GAA11092 for ; Tue, 6 Feb 2001 06:42:58 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id WAA24506; Tue, 6 Feb 2001 22:59:05 +1300 (NZDT) Received: from mail.accuris.ie (mail.accuris.ie [195.7.42.139]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id WAA24501 for ; Tue, 6 Feb 2001 22:59:03 +1300 (NZDT) Received: from dublin.accuris.ie (unverified) by mail.accuris.ie (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 6 Feb 2001 09:59:18 +0000 Received: by dublin.accuris.ie with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 09:53:11 -0000 Message-ID: <577D56F824BAD411A1230008C728534A0812B3@dublin.accuris.ie> From: "Wang, Hai" To: "'rtfm@auckland.ac.nz'" Subject: running NeTraMet in a PC Date: Tue, 6 Feb 2001 09:53:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello everybody, I tried to run NeTraMet in a PC running winNT4.0, I followed the readme for the instruction, but I couldn't proceed it because I couldn't get several procedures done written in the Readme file: Step 4 Edit the pd.bat file so that it is correct for the ethernet card(s) you are using. The DRIVERS directory contains packet drivers for NE2000, SMC_WD and 3C509 cards; these have been modified so as to support NeTraMet's 'high-performance packet driver' option. If you are using any other kind of ethernet card you'll have to copy a packet driver for it into this directory. Questions: I am using Ethernet Card 3c900-combo, I don't know how to edit pad.bat to reflect the card because I don't know the meaning of the parameters following "\drivers\3c900-combo". Step 5 : I am using 32-bit NeTraMet, but I couldn't find the file "EMM386.EXE" from my PC' WINDOWS. If anyone of you has some ideas how to solve the problem, please reply to me, I appreciate it. Thank you in advance! Hai Wang PS: I am wondering whether there is any other impelemtations besides NetRaMet? Accuris Limited, East Point Bussiness Park, Direct: +353 1 8875582 Dublin 3, Fax : +353 1 8875100 Ireland From owner-rtfm@auckland.ac.nz Tue Feb 6 10:53:23 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 KAA19154 for ; Tue, 6 Feb 2001 10:53:18 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA04706; Wed, 7 Feb 2001 02:49:39 +1300 (NZDT) Received: from taomime.bcbssc.com (taomime.bcbssc.com [207.19.198.72]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA04696; Wed, 7 Feb 2001 02:49:30 +1300 (NZDT) Received: from bcbssc.com (207.19.198.72) by taomime.bcbssc.com (NPlex 2.0.108); 6 Feb 2001 08:50:27 -0500 Message-ID: Date: Tue, 6 Feb 2001 08:47:00 -0500 From: "ELAINE SHARP" To: carter@qosient.com Cc: rtfm@auckland.ac.nz, Nevil Brownlee , Kappler Cornelia MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=":-Fischer-Intl-Naples,Fl-*MIX*-63000--7a00:6691:545c--*GCS*" Subject: RE: charter goal 2 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is the preamble of a multipart MIME formatted message. If you are reading this text your mail system is most likely not capable of properly decoding MIME messages. To extract the contents of this message, save it to a file and then use an external MIME decoding utility. --:-Fischer-Intl-Naples,Fl-*MIX*-63000--7a00:6691:545c--*GCS* Content-Type: text/plain; charset="ISO-8859-1" Content-ID: Content-Disposition: inline; filename="" Content-Transfer-Encoding: 8bit Would you mind removing my name from your email list please! Thanks! Elaine.Sharp@bcbssc.com ------------------( Forwarded letter 1 follows )-------------------- Date: Mon, 5 Feb 2001 15:48:55 -0500 To: Kappler.Cornelia[Cornelia.Kappler]@icn.siemens.de.inet, Nevil.Brownlee[n.brownlee]@auckland.ac.nz.inet, rtfm@auckland.ac.nz.inet From: Carter.Bullard[carter]@qosient.com.inet Sender: owner-rtfm@auckland.ac.nz.inet Reply-To: carter@qosient.com.inet Subject: RE: charter goal 2 Hey Kappler, I believe that distributed monitoring pertains to metrics that can only be determined through the use of multiple monitors measuring the same network event. One-way delay is a great example of this. You have to have time determination at two points along the path. Some packet loss metrics can only be measured with two meters, and some reachability metrics require two meters. Connectivity monitors in asymmetric networks require multiple monitors. I see Remote Packet Capture as supporting distributed monitoring, rather than distributed monitoring enabling/ supporting Remote Packet Capture. Remote packet capture enables a single meter to monitor at multiple points in the network at the same time. Remote packet capture is not a meter, it is merely a tap, that can support any kind of meter you want to build (assuming its a packet meter ;o). Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 813-9426 Fax +1 212 813-9426 > -----Original Message----- > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > Behalf Of Kappler Cornelia > Sent: Monday, February 05, 2001 11:38 AM > To: 'Nevil Brownlee'; rtfm@auckland.ac.nz > Subject: charter goal 2 > > > > > > 2 Define a distributed metering architecture to support metrics > > defined within the IPPM framework, e.g. one-way delay, > > connectivity, one-way loss rate. This architecture will > > include remote packet capture, and will addres privacy > > concerns such as the inadvertant disclosure of user > > information and the need to authenticate and authorise > > access to captured data. > > > > > So I figure the distributed metering architecture is > necessary for supporting the metrics of ippm. However, there > seem to be more reasons for developing it, such as remote > packet capture. The benefit of the latter is improved > processing performance (?). Therefore the goal should be > re-formulated along the lines. E.g. > > "Define a distributed metering architecture. Such a > distributed architecture would on the one hand support > metrics based on distributed measurements such as those > developed by the ippm. On the other hand, it would support > remote packet capture, with the benefit of improved metering > performance." (I'm not sure I grasp the full benefits of > remote packet capture.) > > The other thing I dislike about this goal is that rtfm IS > already distributed: Many meters can report to a single > reader. The reason ippm metrics cannot be supported is that > readers don't do any processing, at least not any that is > standardized. So I would like to discuss whether "distributed > metering architecture" is indeed the correct term. What we > are rather doing is introducing yet another layer in the > measurement hierarchy. > > Finally, remote packet capture is possibly another form of > distributed metering than that needed for ippm metrics. For > ippm metrics you necessarily have a n:1 relation beween > points of measurement and meters. With remote packet capture, > you might just have a 1:1 relation. So may be remote packet > capture should be a separate goal. > > Cornelia > > > -------------------- > Cornelia Kappler > Standards & Technology > ICM N MC ST3 > Siemens AG, Siemensdamm 62, 13629 Berlin, Germany > > > > > --:-Fischer-Intl-Naples,Fl-*MIX*-63000--7a00:6691:545c--*GCS* Content-Type: application/octet-stream; name="smime.p7s" Content-ID: Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK BjCCAjwwggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAw MDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5Rm/baNWYS2Z SHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIeaBpsQoXPftFg5 a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg1y2H e6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvz sHLmlYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBC jhdQHGR6uD6ZSXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrng v2U2k8LS12vc3lnWojX4RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0G CSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqd ufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIz tW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1Ud EwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3 AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60 jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4Km saiSxVhqwY0DPOvDzQWikK5uMIIEkDCCA/mgAwIBAgIQO4H/J4r5o7F3uerKvfXEkzAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20v cmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNV BAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZDAeFw0wMTAxMTgwMDAwMDBaFw0wMjAxMTgyMzU5NTlaMIIB FDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOQ2FydGVyIEJ1bGxhcmQxITAfBgkqhkiG9w0B CQEWEmNhcnRlckBxb3NpZW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA y15wPC/ETaGFY9Z2drqsUQSgumRuFUpc1/+A3UTQcAwYGrf6cgBmqWVLuwgPWjsiUG/m kFksv0EhfDtEAuexuwcXC01uDtDZsKBqIUx5p9rzY1fJRVzv2YGEhwvQuk3s3z0ewWvg lK1s2s9psntyT/74nyenSTxxACzKBHkQ9kECAwEAAaOCASYwggEiMAkGA1UdEwQCMAAw RAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBCDAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEG AwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1 OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVhZGIyYmQyZTg5MjE3YWQ2YmYzZDUx MTQ4OWNhM2JmNDdmOGYzZWE0NTBjMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwu dmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAQu+Udo1OWlH/ 28dM4UtX1Spz8RGBNHRWqzQOJ2w5O6O//5uRdrNwQVvz/fsRA9f2Eqp3xh9cHMro03R1 2Vdz9n6H/PuT7rA4IE/PdjeIrBoa5Rvx9rTM1XDL+it12j1iz74nQ3T3rubXRta/w515 za359TzQEeExDKmWSYCzt60xggQvMIIEKwIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQO4H/J4r5o7F3uerKvfXE kzAJBgUrDgMCGgUAoIICozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMTAyMDUyMDQ4NTNaMCMGCSqGSIb3DQEJBDEWBBQ/ZmK+JVH2PNWO7xb9 uqFH6TeLPzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA7gf8nivmjsXe56sq99cSTMIH0BgsqhkiG9w0BCRAC CzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90 IFZhbGlkYXRlZAIQO4H/J4r5o7F3uerKvfXEkzANBgkqhkiG9w0BAQEFAASBgBFToMes +3UObzC66QhH4i6C/avK/6Znfpuxjj97CDczKbtyjpi8kJqDVOVUG+w35gg751gHK/ow 1nnJDZa6s4+uyjJhzg0PgfjnPxRh1uOOzR9owB0PK1cbrBeREmAJzAQBZVU3ysg2L7K7 mpRN23V7oGBMi9E52mEXFO6sSHmuAAAAAAAA --:-Fischer-Intl-Naples,Fl-*MIX*-63000--7a00:6691:545c--*GCS*-- From owner-rtfm@auckland.ac.nz Tue Feb 6 22:08: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 WAA08624 for ; Tue, 6 Feb 2001 22:08:32 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA20812; Wed, 7 Feb 2001 14:32:46 +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 OAA20794; Wed, 7 Feb 2001 14:32:40 +1300 (NZDT) From: Nevil Brownlee To: "Wang, Hai" Cc: "'rtfm@auckland.ac.nz'" Subject: Re: running NeTraMet in a **Windows** PC In-Reply-To: <577D56F824BAD411A1230008C728534A0812B3@dublin.accuris.ie> Message-ID: Date: Wed, 7 Feb 2001 14:33:38 +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 Hai Wang: > I tried to run NeTraMet in a PC running winNT4.0, I followed the > readme for the instruction, but I couldn't proceed it because I couldn't get > several procedures done written in the Readme file: You've been trying to use the DOS version of NeTraMet on a Windows PC, which is why you're puzzled by references to 'packet drivers.' Try the Windows version, which you'll find as MSW_NTM44b6.zip in the beta-versions directory of the NeTraMet distribution sites. > PS: I am wondering whether there is any other impelemtations besides > NetRaMet? I presume you mean 'implementations of RTFM?' IBM research did one for AIX, but never issued a public release. I'd be delighted to hear of any others ... 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 Wed Feb 7 07:33:18 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 HAA28479 for ; Wed, 7 Feb 2001 07:33:17 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA10043; Thu, 8 Feb 2001 00:03:45 +1300 (NZDT) Received: from mail.accuris.ie (mail.accuris.ie [195.7.42.139]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA10033; Thu, 8 Feb 2001 00:03:37 +1300 (NZDT) Received: from dublin.accuris.ie (unverified) by mail.accuris.ie (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 7 Feb 2001 11:04:01 +0000 Received: by dublin.accuris.ie with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 10:57:42 -0000 Message-ID: <577D56F824BAD411A1230008C728534A0812B4@dublin.accuris.ie> From: "Wang, Hai" To: "'n.brownlee@auckland.ac.nz'" Cc: "'rtfm@auckland.ac.nz'" Date: Wed, 7 Feb 2001 10:57:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello Nevil Brownlee, Thank you very much. By the way I want to know if the source code of NeTraMet windows version is available now? Regards! Hai Wang >Hello Hai Wang: > I tried to run NeTraMet in a PC running winNT4.0, I followed the > readme for the instruction, but I couldn't proceed it because I couldn't get > several procedures done written in the Readme file: You've been trying to use the DOS version of NeTraMet on a Windows PC, which is why you're puzzled by references to 'packet drivers.' Try the Windows version, which you'll find as MSW_NTM44b6.zip in the beta-versions directory of the NeTraMet distribution sites. > PS: I am wondering whether there is any other impelemtations besides > NetRaMet? I presume you mean 'implementations of RTFM?' IBM research did one for AIX, but never issued a public release. I'd be delighted to hear of any others ... 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 Cheers! Hai Wang Accuris Limited, East Point Bussiness Park, Direct: +353 1 8875582 Dublin 3, Fax : +353 1 8875100 Ireland From owner-rtfm@auckland.ac.nz Wed Feb 7 07:55:35 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 HAA28659 for ; Wed, 7 Feb 2001 07:55:34 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA11523; Thu, 8 Feb 2001 00:35:38 +1300 (NZDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA11518 for ; Thu, 8 Feb 2001 00:35:35 +1300 (NZDT) From: nick.farrow@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 7 Feb 2001 11:32:46 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <13895NCW>; Wed, 7 Feb 2001 11:31:19 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207A0A640@mbtlipnt02.btlabs.bt.co.uk> To: rtfm@auckland.ac.nz Subject: RE: charter goal Date: Wed, 7 Feb 2001 11:31:08 -0000 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, We (BT labs UK) did some work with our own versions of RTFM for windows boxes a couple of years back. The idea being that it would be useful to network managers internally for network diagnostics of end nodes, which had a RTFM meter running in the background. So we were trying to use RTFM to address questions like ' why is my pc's network running slowly' what are the 'top ten networks visited by this node' etc. Such questions ( requirements ?) lead us to have a certain view of what RTFM should do ideally. Each of us based on our background probably have our own individual ideas on what an idealised RTFM architecture should be able to do. But there are clearly certain areas of commonality. Flow Capture - Is implicitly 'limited' to the attributes of the MIB and supporting SRL. In RTFM2 do we want to continue with the churn of adding extra attributes, and language updates. Is SRL sufficient ? If we want RTFM to be used in real world environments to help with debugging VOIP control, MIP, tunnels services etc then a more open architecture/language needs to be in place. Again along the same theme 'knowing' about control traffic of upper protocols could be very useful and lead to a wider adoption of RTFM2, but this is outside the current scope of RTFM capture. So do we want RTFM to be a very generalised system for 'flow' capture above the current stack limits, or is it sufficient just to keep within the current architecture boundaries. Flow Analysis - If RTFM2 had an extended architecture then this would naturally follow, having trapped flows of a certain type basic analysis could be used to check/detect certain service characteristics. For instance an edge router could detect MIP nodes trying to find an agent. So knowing you have an ICMP packet tells you very little without further analyis. Flow Reporting (Post analysis) - Needs a real lift ! I know a push facility has been talked about. Again a general architecture is need to enable RTFM sinks to get the information in the way they want (not just the meter manager). So you cannot second guess this, apart from being very flexible. Push, pull, send event. Push being driven by a variety of ways, on a trigger network event, under instructions from the RTFM sink (i.e. dump analysis into this DB every hour, or analysis on these flows looks like a security breach, send an alert event). Visualisation - We found that to be used in the real world, we needed an added layer. One that enabled managers to deploy a rule set, and view the information that cameback in a variety of ways. This meant that for a given ruleset the meter could provide a number of 'viewers' to provide differing visualisation on the flow information, the viewers were responsible for pulling the flows off based on their needs. So in an RTFM2 world, whilst we may not want to be involved in this, we should bear in mind how the results will be used. Of course if the flow reporting is extended, and in essence forms a 'contract' between meter and sink then this could be sufficient. In essence is RTFM (almost) a standard programable network stack component or a 'vertical application' in its own right ? These issues I feel should be addressed in any charter. These of course are just my own personal views and do not represent any company related standpoint. Regards Nick Farrow BT Labs UK From owner-rtfm@auckland.ac.nz Wed Feb 7 19:37:59 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 TAA12978 for ; Wed, 7 Feb 2001 19:37:57 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA04620; Thu, 8 Feb 2001 12:23:37 +1300 (NZDT) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA04604 for ; Thu, 8 Feb 2001 12:23:34 +1300 (NZDT) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f17NMre12876; Thu, 8 Feb 2001 09:22:53 +1000 (EST) To: nick.farrow@bt.com cc: rtfm@auckland.ac.nz Subject: Re: charter goal In-reply-to: Your message of "Wed, 07 Feb 2001 11:31:08 GMT." <5104D4DBC598D211B5FE0000F8FE7EB207A0A640@mbtlipnt02.btlabs.bt.co.uk> Date: Thu, 08 Feb 2001 09:23:23 +1000 Message-ID: <28408.981588203@dstc.edu.au> From: George Michaelson Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Vale nnstat. it was all so much simpler when the datarate was within the processing power at hand. I succeeded in using the caida tools with pcap to snarf enough packetflows to find out some traffic shaping, it was a revalation that could still be done. But I wouldn't base billing on it. Which seems to me to say we're all dancing around netflow. Surely this can't be good, to dangle on a provider-specific tool? Um, is that cantrip on-charter? -George From owner-rtfm@auckland.ac.nz Thu Feb 8 04:06:09 2001 Received: from net.auckland.ac.nz (net.auckland.ac.nz [130.216.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03128 for ; Thu, 8 Feb 2001 04:06:07 -0500 (EST) Received: (from majordom@localhost) by net.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA23403; Thu, 8 Feb 2001 20:41:26 +1300 (NZDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by net.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA23367 for ; Thu, 8 Feb 2001 20:41:23 +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 f187aaA65992 for ; Thu, 8 Feb 2001 08:36:37 +0100 (CET) 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 IAA18631 for ; Thu, 8 Feb 2001 08:36:20 +0100 Message-ID: <3A824C93.2F3FF42C@ccrle.nec.de> Date: Thu, 08 Feb 2001 08:36:51 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: RTFM mailing list Subject: charter goal #2b Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit The second part of charter goal #2, the remote packet capturing, is easier to discus than the first part, because some concrete suggestion have been made already in the drafts for the BOF: > Define a distributed metering architecture to support metrics > defined within the IPPM framework, e.g. one-way delay, > connectivity, one-way loss rate. This architecture will > include remote packet capture, and will address privacy > concerns such as the inadvertant disclosure of user > information and the need to authenticate and authorise > access to captured data. Remote packet capturing can be seen as just one component of a distributed metering architecture. I think this topic would be a worthwhile goal of a future RTFM2 WG, even if we decided not to work on a distributed metering architecture (I don't suggest this). It is not a big effort like the architecture and some technical solutions exist already. Work on this goal could be just standardizing LFAP, probably with some modifications, or following thesuggestions in the drafts for the BOF, or something different. Two aspects of remote packet capturing are to be covered: configuring remote packet capturing devices and transmitting captured packets (or just their headers). - What would be the resulting benefit? There are already some solutions concerning or related to remote packet capture, for example Cisco netflow or LFAP from cabletron. However there are no standards yet. Furthermore, there is an increasing need for remote packet capture, for example for the applications I described in my previous mail on the distributed metering architecture. - Is it or does it appear to be technically feasible? Yes, the existing proprietary solutions demonstrate this. - Is "now" the right time to work on this item? I wonder why this topic has not already been solved by this IETF for a long time. For me, "now" is already very late. - Can we expect sufficient support by technical, experts, i.e. who is willing to contribute? Yes, we have some people together, who are willing to work on this and on the BOF also LFAP people offered support. - What would be the expected output documents? I would expect two output documents: A protocol for transmitting information about captured packets and a document (a MIB?) on configuring packet capturing devices. - What timeframe would be appropriate? I guess, a year would be sufficient. - Is the IETF the right place for this item? Yes, certainly. 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 Thu Feb 8 04:09:38 2001 Received: from net.auckland.ac.nz (net.auckland.ac.nz [130.216.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03127 for ; Thu, 8 Feb 2001 04:06:07 -0500 (EST) Received: (from majordom@localhost) by net.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA23273; Thu, 8 Feb 2001 20:41:10 +1300 (NZDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by net.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA23198 for ; Thu, 8 Feb 2001 20:40:57 +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 f187ZkA65955; Thu, 8 Feb 2001 08:35:46 +0100 (CET) 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 IAA18619; Thu, 8 Feb 2001 08:35:30 +0100 Message-ID: <3A824C61.19CA675C@ccrle.nec.de> Date: Thu, 08 Feb 2001 08:36:01 +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 #1b References: <4D486782CA36D4118A530000D11EA42A273BFF@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, thanks for the comments. Kappler Cornelia wrote: > [...] > > > Develop a standard for reporting them from a meter to a > > > flow data collection system. > > > > - What would be the resulting benefit? > > A meter reporting actively is highly desirable. I have been > > working in several projects where meters for accounting were > > required. In this application the meter is required to notify > > the reader when a new flow (table entry) is established and > > - even more important - when a flow times out and accounting > > for that session can be completed. > > > I agree with this suggestion. > > However, as for 1a, I think the wording of the goals can be improved. > My understanding is a standard for reporting flows already was specified > in the rtfm architecture. What Juergen proposes is an extension to the > standard. So what is meant by the goal. Extending the standard, or > completely reworking it? > > If it is extensions, I think a list of possible extensions should be > given in the charter. > > If it is a complete rework, reasons should be given why the current > standard is insufficient, and what will be different with a new standard. > I tend to do neither extend the standard, nor rework it completely. For me this is more an evolvement. The standard is out for some time, and some shortcomings (and many benefits!) have been observed. Now, we should work on the shortcomings. This does not need a complete rework, but an improvement of some things. I doubt, that we can have this as pure extensions without modifying the existing definitions. 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 Thu Feb 8 04:27:44 2001 Received: from net.auckland.ac.nz (net.auckland.ac.nz [130.216.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03304 for ; Thu, 8 Feb 2001 04:27:42 -0500 (EST) Received: (from majordom@localhost) by net.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA23278; Thu, 8 Feb 2001 20:41:10 +1300 (NZDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by net.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA23250 for ; Thu, 8 Feb 2001 20:41:06 +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 f187aGA65987 for ; Thu, 8 Feb 2001 08:36:16 +0100 (CET) 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 IAA18625 for ; Thu, 8 Feb 2001 08:36:00 +0100 Message-ID: <3A824C7F.7341E08F@ccrle.nec.de> Date: Thu, 08 Feb 2001 08:36:31 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: RTFM mailing list Subject: charter goal #2a Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, with some delay, I'd like to continue commenting the charter goals. Suggested goal 2 is: > Define a distributed metering architecture to support metrics > defined within the IPPM framework, e.g. one-way delay, > connectivity, one-way loss rate. This architecture will > include remote packet capture, and will address privacy > concerns such as the inadvertant disclosure of user > information and the need to authenticate and authorise > access to captured data. As Cornelia and Carter already stated, there are two issues in here, remote packet capturing and a distributed metering architecture. I discuss them separately starting with the distributed metering architecture. - 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. - Is it or does it appear to be technically feasible? I believe so. Also I believe, it would be a lot of work. - Is "now" the right time to work on this item? It seems to be a good time to start working on this issue, because the IPPM wg has made a lot of progress which can be used here. Also it is a good time to start before IPPM has completed their tasks, because a discussion with this group would certainly provide valuable input. - Can we expect sufficient support by technical, experts, i.e. who is willing to contribute? Well, this goal is rather ambitious. We would need a lot of help to come up with a good architecture. - What would be the expected output documents? At first a requirements document appears to be appropriate, and an architecture document. At this point in time it is hard to say what else would be required. Certainly, packet caturing standard would be required, but I believe, more than this is needed. - What timeframe would be appropriate? As I said, I think this is an ambitious goal and two years might be a realistic minimum time frame. - Is the IETF the right place for this item? Yes, of course. 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 Thu Feb 8 11:04: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 LAA11485 for ; Thu, 8 Feb 2001 11:04:32 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA10143; Fri, 9 Feb 2001 03:19:15 +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 DAA10138 for ; Fri, 9 Feb 2001 03:19:13 +1300 (NZDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA11757; Thu, 8 Feb 2001 09:25:04 -0500 (EST) Received: from cnc-exc1.ctron.com(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma011676; Thu, 8 Feb 01 09:24:51 -0500 Received: from cnc-exc1.ctron.com (localhost [127.0.0.1]) by cnc-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1FJGYA61; Thu, 8 Feb 2001 09:18:51 -0500 Received: from 10.8.9.39 by cnc-exc1.ctron.com (InterScan E-Mail VirusWall NT); Thu, 08 Feb 2001 09:18:51 -0500 (Eastern Standard Time) Message-ID: <3A82AA3D.C2DAC212@enterasys.com> Date: Thu, 08 Feb 2001 09:16:29 -0500 From: David Harrington Reply-To: dbh@enterasys.com Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: RTFM Mailing list Subject: Re: charter goal References: <28408.981588203@dstc.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit At IETF49, Enterasys/Riverstone (previously Cabletron) announced that the LFAP protocol was now open-source, and we are interested in having the RTFM WG consider it as a proposed starting point for a vendor-neutral industry standard for a push-style flow accounting protocol extension to RTFM. see http://www.nmops.org/draft-rfced-info-calato-01.txt for the latest revision. dbh George Michaelson wrote: > > Vale nnstat. it was all so much simpler when the datarate was within the > processing power at hand. > > I succeeded in using the caida tools with pcap to snarf enough packetflows > to find out some traffic shaping, it was a revalation that could still be > done. But I wouldn't base billing on it. > > Which seems to me to say we're all dancing around netflow. Surely this > can't be good, to dangle on a provider-specific tool? > > Um, is that cantrip on-charter? > > -George -- --- 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 Thu Feb 8 21:10:40 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 VAA23243 for ; Thu, 8 Feb 2001 21:10:37 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id NAA07474; Fri, 9 Feb 2001 13:24:21 +1300 (NZDT) Received: from immtapop3.bellatlantic.net (immtapop3.bellatlantic.net [199.45.40.140] (may be forged)) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA07460 for ; Fri, 9 Feb 2001 13:24:19 +1300 (NZDT) Received: from sphynx (adsl-151-202-198-45.nyc.adsl.bellatlantic.net [151.202.198.45]) by immtapop3.bellatlantic.net (8.9.1/8.9.1) with SMTP id TAA13605; Thu, 8 Feb 2001 19:23:29 -0500 (EST) Reply-To: From: "Carter Bullard" To: "'Juergen Quittek'" , "'RTFM mailing list'" Subject: RE: charter goal #2b Date: Thu, 8 Feb 2001 19:23:12 -0500 Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CB1A@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C09204.9EB9B8F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3A824C93.2F3FF42C@ccrle.nec.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C09204.9EB9B8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey Juergen, Thanks for driving the discussion. > Two aspects of remote packet capturing are to be covered: > configuring remote packet capturing devices and transmitting > captured packets (or just their headers). > > - What would be the resulting benefit? > There are already some solutions concerning or related to remote > packet capture, for example Cisco netflow or LFAP from cabletron. > However there are no standards yet. Furthermore, there is an > increasing need for remote packet capture, for example for the > applications I described in my previous mail on the distributed > metering architecture. Not to take away from your benefit section, or any part of your discussion, but the Packet Capture Group in RMON is a much better example for prior work in the area of remote packet capture. It is an IETF standard and has been implemented by a large number of vendors, so there is precedence for working on the technology. The issue is that the RMON architecture has fundamental shortcomings. RMON's local storage requirement is the biggest one, as it places HUGE resource issues on probes, and the limited filter support doesn't have flow based semantics so you can not automatically capture the return traffic for a given flow. Neither Netflow nor LFAP have any support for packet capture, nor do I see a role for either in the work that needs to be done to realize this part of the technology. > > - Is the IETF the right place for this item? Yes, certainly. > > Juergen Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 813-9426 Fax +1 212 813-9426 ------=_NextPart_000_002F_01C09204.9EB9B8F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: charter goal #2b

Hey Juergen,
Thanks for driving the discussion.

> Two aspects of remote packet capturing are to be = covered:
> configuring remote packet capturing devices and = transmitting
> captured packets (or just their headers).
> 
> - What would be the resulting benefit?
>   There are already some solutions = concerning or related to remote
>   packet capture, for example Cisco = netflow or LFAP from cabletron.
>   However there are no standards yet. = Furthermore, there is an
>   increasing need for remote packet = capture, for example for the
>   applications I described in my = previous mail on the distributed
>   metering architecture.

Not to take away from your benefit section, or any = part of
your discussion, but the Packet Capture Group in RMON = is a much
better example for prior work in the area of remote = packet
capture.  It is an IETF standard and has been = implemented by a
large number of vendors, so there is precedence for = working
on the technology.  The issue is that the RMON = architecture
has fundamental shortcomings.  RMON's local = storage requirement
is the biggest one, as it places HUGE resource issues = on probes,
and the limited filter support doesn't have flow = based semantics
so you can not automatically capture the return = traffic for a given
flow.

Neither Netflow nor LFAP have any support for packet = capture, nor
do I see a role for either in the work that needs to = be done
to realize this part of the technology.

>
> - Is the IETF the right place for this = item?

    Yes, certainly.

>
>     Juergen

Carter

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

carter@qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

------=_NextPart_000_002F_01C09204.9EB9B8F0-- From owner-rtfm@auckland.ac.nz Thu Feb 8 22:13:24 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 WAA24922 for ; Thu, 8 Feb 2001 22:13:23 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA16659; Fri, 9 Feb 2001 14:11:59 +1300 (NZDT) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA16654 for ; Fri, 9 Feb 2001 14:11:57 +1300 (NZDT) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f191BNe09444 for ; Fri, 9 Feb 2001 11:11:23 +1000 (EST) To: "'RTFM mailing list'" Subject: Re: charter goal #2b In-reply-to: Your message of "Thu, 08 Feb 2001 19:23:12 EST." <38E99DA2CEFA7248B5828BBF99344D86CB1A@ptah.newyork.qosient.com> Date: Fri, 09 Feb 2001 11:11:54 +1000 Message-ID: <15145.981681114@dstc.edu.au> From: George Michaelson Sender: owner-rtfm@auckland.ac.nz Precedence: bulk here'z another one. Packet capture is going to trigger the 'mandated access point for tapping' debate. Some people live in countries considering this as a requirement for ISPs, who are claiming (amongst other things) can't be done. But if RTFM goes down this path to do monitoring and metrics for self-referential reasons, somebody is going to point the finger this way. cheers -George From owner-rtfm@auckland.ac.nz Fri Feb 9 05:21:54 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 FAA13318 for ; Fri, 9 Feb 2001 05:21:53 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id VAA08636; Fri, 9 Feb 2001 21:32:25 +1300 (NZDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1] (may be forged)) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id VAA08631 for ; Fri, 9 Feb 2001 21:32:22 +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 f198WEA85862; Fri, 9 Feb 2001 09:32:14 +0100 (CET) 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 JAA29524; Fri, 9 Feb 2001 09:31:56 +0100 Message-ID: <3A83AB19.A9AE8258@ccrle.nec.de> Date: Fri, 09 Feb 2001 09:32:26 +0100 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 mailing list'" Subject: Re: charter goal #2b References: <38E99DA2CEFA7248B5828BBF99344D86CB1A@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: > [...] > > Neither Netflow nor LFAP have any support for packet capture, nor > do I see a role for either in the work that needs to be done > to realize this part of the technology. Well, yes and no. They do packet capturing and report a summary. I consider this also as one of the requirements for packet capturing. However, you are completely right, that they do not offer sufficient means for reporting details on single captured packets. I could imagine to extend LFAP in this direction, but I doubt that this would be the right idea. 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 Fri Feb 9 07:15: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 HAA13773 for ; Fri, 9 Feb 2001 07:15:45 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA14568; Fri, 9 Feb 2001 23:40:25 +1300 (NZDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id XAA14557 for ; Fri, 9 Feb 2001 23:40:15 +1300 (NZDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id LAA81812 for ; Fri, 9 Feb 2001 11:39:36 +0100 Received: from MOLTRASIO (dhcp16-85.zurich.ibm.com [9.4.16.85]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id LAA91534 for ; Fri, 9 Feb 2001 11:39:28 +0100 Message-ID: <000a01c09284$9a90e7a0$55100409@zurich.ibm.com> From: "Lucas Heusler" To: Date: Fri, 9 Feb 2001 11:39:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0928C.FB40D260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0928C.FB40D260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe rtfm lsh@zurich.ibm.com ------=_NextPart_000_0007_01C0928C.FB40D260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe rtfm lsh@zurich.ibm.com
------=_NextPart_000_0007_01C0928C.FB40D260-- From owner-rtfm@auckland.ac.nz Fri Feb 9 08:22:57 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 IAA15833 for ; Fri, 9 Feb 2001 08:22:56 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id AAA17411; Sat, 10 Feb 2001 00:37:29 +1300 (NZDT) Received: from immtapop3.bellatlantic.net (immtapop3.bellatlantic.net [199.45.40.140]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id AAA17406 for ; Sat, 10 Feb 2001 00:37:27 +1300 (NZDT) Received: from sphynx (adsl-151-202-198-45.nyc.adsl.bellatlantic.net [151.202.198.45]) by immtapop3.bellatlantic.net (8.9.1/8.9.1) with SMTP id GAA15475; Fri, 9 Feb 2001 06:37:18 -0500 (EST) Reply-To: From: "Carter Bullard" To: "'George Michaelson'" , "'RTFM mailing list'" Subject: RE: charter goal #2b Date: Fri, 9 Feb 2001 06:37:17 -0500 Message-ID: <38E99DA2CEFA7248B5828BBF99344D8604CB57@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C09262.C06097E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <15145.981681114@dstc.edu.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C09262.C06097E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is this a technical issue? Carter > -----Original Message----- > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > Behalf Of George Michaelson > Sent: Thursday, February 08, 2001 8:12 PM > To: 'RTFM mailing list' > Subject: Re: charter goal #2b > > > > here'z another one. > > Packet capture is going to trigger the 'mandated access point > for tapping' > debate. Some people live in countries considering this as a > requirement for > ISPs, who are claiming (amongst other things) can't be done. > > But if RTFM goes down this path to do monitoring and metrics for > self-referential reasons, somebody is going to point the > finger this way. > > cheers > -George > ------=_NextPart_000_004B_01C09262.C06097E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: charter goal #2b

Is this a technical issue?

Carter

> -----Original Message-----
> From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.n= z]On
> Behalf Of George Michaelson
> Sent: Thursday, February 08, 2001 8:12 PM
> To: 'RTFM mailing list'
> Subject: Re: charter goal #2b
>
>
>
> here'z another one.
>
> Packet capture is going to trigger the 'mandated = access point
> for tapping'
> debate. Some people live in countries = considering this as a
> requirement for
> ISPs, who are claiming (amongst other things) = can't be done.
>
> But if RTFM goes down this path to do monitoring = and metrics for
> self-referential reasons, somebody is going to = point the
> finger this way.
>
> cheers
>       -George
>

------=_NextPart_000_004B_01C09262.C06097E0-- From owner-rtfm@auckland.ac.nz Fri Feb 9 08:47:50 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 IAA16920 for ; Fri, 9 Feb 2001 08:47:49 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA18458; Sat, 10 Feb 2001 01:00:42 +1300 (NZDT) Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.40.143]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA18452 for ; Sat, 10 Feb 2001 01:00:41 +1300 (NZDT) Received: from sphynx (adsl-151-202-198-45.nyc.adsl.bellatlantic.net [151.202.198.45]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with SMTP id HAA28620; Fri, 9 Feb 2001 07:00:29 -0500 (EST) Reply-To: From: "Carter Bullard" To: "'Juergen Quittek'" Cc: "'RTFM mailing list'" Subject: RE: charter goal #2b Date: Fri, 9 Feb 2001 07:00:12 -0500 Message-ID: <38E99DA2CEFA7248B5828BBF99344D8604CB58@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C09265.F6334040" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3A83AB19.A9AE8258@ccrle.nec.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C09265.F6334040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey Juergen, I would like to differentiate packet capture from packet processing. Cisco does not implement Netflow in its switches by creating a duplicated stream of packets and processing them in parallel within its routing or switching function. Nor do most integrated RMON implementations involve copying packets in order to do their accounting. Although it may sound like a very subtle distinction to differentiate packet stream duplication and packet processing, it actually is very important to understanding what is being proposed. It would probably be more appropriate to call the mechanism remote packet duplication, as it could be confused with multicasting. But a general packet duplication mechanism may be the right way to describe it. I also believe that packet processing should be disjoint from packet stream duplication, so I do not see any reason for a metering or summary function to be a part of the proposed remote packet capture facility. This would be the job of an RTFM or RMON probe that could be coupled to the RPCAP mechanism. No sense in making it more complicated than it should be. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 813-9426 Fax +1 212 813-9426 > -----Original Message----- > From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On > Behalf Of Juergen Quittek > Sent: Friday, February 09, 2001 3:32 AM > To: Carter Bullard > Cc: 'RTFM mailing list' > Subject: Re: charter goal #2b > > > > Carter Bullard wrote: > > > [...] > > > > Neither Netflow nor LFAP have any support for packet capture, nor > > do I see a role for either in the work that needs to be done > > to realize this part of the technology. > > Well, yes and no. They do packet capturing and report a summary. > I consider this also as one of the requirements for packet capturing. > However, you are completely right, that they do not offer sufficient > means for reporting details on single captured packets. I > could imagine > to extend LFAP in this direction, but I doubt that this would be the > right idea. > > 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_004F_01C09265.F6334040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: charter goal #2b

Hey Juergen,
   I would like to differentiate packet = capture from packet
processing.  Cisco does not implement Netflow in = its switches
by creating a duplicated stream of packets and = processing
them in parallel within its routing or switching = function.
Nor do most integrated RMON implementations involve = copying
packets in order to do their accounting.  = Although it may
sound like a very subtle distinction to differentiate = packet
stream duplication and packet processing, it actually = is very
important to understanding what is being = proposed.

   It would probably be more appropriate to = call the mechanism
remote packet duplication, as it could be confused = with
multicasting.  But a general packet duplication = mechanism
may be the right way to describe it.

   I also believe that packet processing = should be disjoint
from packet stream duplication, so I do not see any = reason for a
metering or summary function to be a part of the = proposed
remote packet capture facility.  This would be = the job of an
RTFM or RMON probe that could be coupled to the RPCAP = mechanism.
No sense in making it more complicated than it should = be.

Carter

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

carter@qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

> -----Original Message-----
> From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.n= z]On
> Behalf Of Juergen Quittek
> Sent: Friday, February 09, 2001 3:32 AM
> To: Carter Bullard
> Cc: 'RTFM mailing list'
> Subject: Re: charter goal #2b
>
>
> > Carter Bullard wrote:
> >
>  [...]
> >
> > Neither Netflow nor LFAP have any support = for packet capture, nor
> > do I see a role for either in the work that = needs to be done
> > to realize this part of the = technology.
>
> Well, yes and no. They do packet capturing and = report a summary.
> I consider this also as one of the requirements = for packet capturing.
> However, you are completely right, that they do = not offer sufficient
> means for reporting details on single captured = packets. I
> could imagine
> to extend LFAP in this direction, but I doubt = that this would be the
> right idea.
>
>     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_004F_01C09265.F6334040-- From owner-rtfm@auckland.ac.nz Wed Feb 14 11:53:51 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 LAA06637 for ; Wed, 14 Feb 2001 11:53:49 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA13503; Thu, 15 Feb 2001 04:09:27 +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 EAA13498 for ; Thu, 15 Feb 2001 04:09:24 +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 QAA14648; Wed, 14 Feb 2001 16:07:07 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id QAA19759; Wed, 14 Feb 2001 16:07:06 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 14 Feb 2001 16:07:06 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Subject: PAM2001 registration opens (reminder) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 3 Jan 2001 14:53:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Subject: PAM2001 registration opens Passive & Active Measurement: PAM-2001 Registration Opens A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 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. Registration for this workshop has now been opened. To register online, go to: http://www.ripe.net/cgi-bin/pamreg Also available on the web-site are the preliminary program: http://www.ripe.net/pam2001/program.html as well as general information on the workshop: http://www.ripe.net/pam2001/ and hotel information: http://www.ripe.net/pam2001/hotels.html Rooms are available at the conference hotel. The rate is 285 Euro/night (including taxes, approximately 255 US$). To reserve a room, call, fax or email the hotel. Contact details can be found on the web page. If you prefer to stay in another hotel, then there are rooms available in all price classes between 35 Euro/night and 1500 Euro/night within a 5 km radius of the conference site. A selection of hotels and links to reservation sites can be found on the webpage. There are still opportunities 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. 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.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) From owner-rtfm@auckland.ac.nz Fri Feb 16 15:01:44 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 PAA08510 for ; Fri, 16 Feb 2001 15:01:42 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA18508; Sat, 17 Feb 2001 07:27:00 +1300 (NZDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA18502 for ; Sat, 17 Feb 2001 07:26:57 +1300 (NZDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA14697; Fri, 16 Feb 2001 19:26:55 +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 TAA19636; Fri, 16 Feb 2001 19:26:50 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2650.21) id <1Z3XHY0F>; Fri, 16 Feb 2001 19:26:49 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A273C26@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Juergen Quittek'" , RTFM mailing list Subject: RE: charter goal #2a Date: Fri, 16 Feb 2001 19:26:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rtfm@auckland.ac.nz Precedence: bulk > -----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. The ones you cite however seem to be doable with the just a single meter or a collection of old-fashioned meters. 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 From owner-rtfm@auckland.ac.nz Fri Feb 16 15:05:53 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 PAA08589 for ; Fri, 16 Feb 2001 15:05:51 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA18440; Sat, 17 Feb 2001 07:25:08 +1300 (NZDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA18434 for ; Sat, 17 Feb 2001 07:25:05 +1300 (NZDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA14631; Fri, 16 Feb 2001 19:25:00 +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 TAA19429; Fri, 16 Feb 2001 19:24:59 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2650.21) id <1Z3XHY9V>; Fri, 16 Feb 2001 19:24:58 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A273C25@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Juergen Quittek'" , Kappler Cornelia Cc: RTFM mailing list Subject: RE: charter goal #1b Date: Fri, 16 Feb 2001 19:24:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hi Juergen, > > > > However, as for 1a, I think the wording of the goals can be improved. > > My understanding is a standard for reporting flows already was specified > > in the rtfm architecture. What Juergen proposes is an extension to the > > standard. So what is meant by the goal. Extending the standard, or > > completely reworking it? > > > > If it is extensions, I think a list of possible extensions should be > > given in the charter. > > > > If it is a complete rework, reasons should be given why the current > > standard is insufficient, and what will be different with a new standard. > > > > I tend to do neither extend the standard, nor rework it completely. > For me this is more an evolvement. The standard is out for some time, > and some shortcomings (and many benefits!) have been observed. > Now, we should work on the shortcomings. This does not need a complete > rework, but an improvement of some things. I doubt, that we can have > this as pure extensions without modifying the existing definitions. > Can you be more concrete? Like an example of what definition could use modification. Sorry for sounding out-of-date, this probably was discussed in San Diego. But then the charter should also be plausible to the not-deeply-involved technical person, shouldn't it? Cornelia. From owner-rtfm@auckland.ac.nz Tue Feb 27 22:45:31 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 WAA12521 for ; Tue, 27 Feb 2001 22:44:54 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA21517; Wed, 28 Feb 2001 14:05:15 +1300 (NZDT) Received: from smtp4ve.mailsrvcs.net (smtp4vepub.gte.net [206.46.170.25]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA21468 for ; Wed, 28 Feb 2001 14:04:54 +1300 (NZDT) Received: from sphynx (adsl-151-202-198-72.nyc.adsl.bellatlantic.net [151.202.198.72]) by smtp4ve.mailsrvcs.net (8.9.1/8.9.1) with SMTP id BAA4608222 for ; Wed, 28 Feb 2001 01:10:32 GMT Reply-To: From: "Carter Bullard" To: Subject: updated draft-bullard-pcap-01.txt Date: Tue, 27 Feb 2001 20:04:13 -0500 Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CB54@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C0A0F8.6EBDCD00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C0A0F8.6EBDCD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Gentle people, I submitted an update to draft-bullard-pcap-01.txt to be published today. I've included it below, and it is also available via anonymous ftp as ftp://qosient.com/pub/ietf/drafts/draft-bullard-pcap-01.txt. Basically this update adds one new element to the packet capture header, the original packet capture length, moves a few things around, and defines all the fields. It also presents a header for when you want to capture multiple packets at a time, a kind of group capture header. Basic text has only minor modifications. Still very much a draft, but it tries to capture some of the suggestions from the BOF and the RMON meeting. Any comments, opinions, are very much welcome! 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 Internet Draft C. Bullard Document: draft-bullard-pcap-01 QoSient, LLC Category: Informational March, 2001 Remote Packet Capture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 2 Abstract This memo describes a set of recommendations for remote packet capture. The approach is designed to address deployment, performance and privacy issues that limit the usefulness of existing packet capture technology. Bullard Informational-Expires September 2001 1 Remote Packet Capture March, 2001 3 Table of Contents 1 Copyright Notice..............................................1 2 Abstract......................................................1 3 Table of Contents.............................................2 4 Overview......................................................2 5 Remote Packet Capture Requirements/Goals......................3 5.1 High Performance Packet Capture...............................3 5.2 Distributed Monitoring Applications...........................3 5.3 Support Remote Captured Packet Storage........................4 5.4 Wireline Packet Timestamping..................................4 5.5 Address Privacy Threat Issues.................................4 5.5.1 Content Separation............................................4 5.5.2 Captured Content Protection...................................4 5.6 Partial Packet Capture........................................5 5.7 Captured Packet Transport.....................................5 6 Recommendations...............................................5 6.1 Packet Header Capture.........................................5 6.2 Captured Packet Encapsulation Header..........................6 6.2.1 Source Identifier.............................................6 6.2.2 ifIndex.......................................................6 6.2.3 Status........................................................6 6.2.4 Sequence Number...............................................7 6.2.5 Time Stamp....................................................7 6.2.6 CapLength.....................................................7 6.2.7 PktLength.....................................................7 6.2.8 Captured Packet Data..........................................7 6.2.9 Pad...........................................................7 6.3 Multiple Captured Packet Encapsulation Header.................8 6.4 In-Band Captured Packet Transport.............................8 7 Security Considerations.......................................9 8 References....................................................9 9 Acknowledgments...............................................9 10 Author's Addresses............................................9 11 Full Copyright Statement.....................................10 4 Overview Packet capture is a fundamental mechanism in Internet network management and is used in support of a wide range of network operational functions, such as fault detection, protocol functional assurance, performance analysis, and security assessment. The IETF has specified technology for remote packet capture in RMON, STD-59[2], and working groups, such as RMON and IPPM, continue to describe various aspects of packet capture technology in RMON2, RFC-2021[3], SMON, RFC- 2613[4], and IPPM, RFC-2330[5]. Bullard Informational-Expires September 2001 2 Remote Packet Capture March, 2001 With new network paradigms and new network analytic requirements, existing packet capture technology is finding its limits, and vendors are generating proprietary mechanisms to overcome these hurdles. To address the issue of proprietary remote packet capture mechanisms in the switched network environment, the SMON MIB introduced the concept of an extended data source mechanism. This facility is designed to support vendors supplied "Copy Port" functions, and does not address the general issue of proprietary remote packet capture. This proposal recommends specification of a remote packet capture source facility that can act as a reliable external packet capture point in Internet networks. Designed to support a number of existing applications, such as RMON and RTFM, a remote packet capture facility should also enable new applications, such as those emerging from the IPPM and TE WGs. This proposal recommends that in order to overcome the perceived limitations of existing technology, new remote packet capture mechanisms should be required to support full wire speed packet header capture with wireline timestamping and in-band transport of the captured data. 5 Remote Packet Capture Requirements/Goals 5.1 High Performance Packet Capture A remote packet capture source facility should perform at a level that assures comprehensive packet capture at full duplex line rate, without packet loss. If packet loss does occur, the condition should be detectable and possibly quantifiable. Existing RMON packet capture technology cannot support sustained packet capture at existing link speeds, primarily due to local storage requirements. Port mirroring, or port copy, based packet capture technology, can perform full packet capture at wireline rates, but these mechanisms have inherent congestion problems when mirroring full duplex interfaces, and congestion related packet loss is not detectable or reportable. 5.2 Distributed Monitoring Applications A remote packet capture facility should provide reliable packet capture in asymmetric network architectures. Remote capture facilities should also support distributed monitoring applications, such as those where the same packet must be monitored at multiple points along its path. Both of these situations require multiple remote capture points with packet event correlation handled by a mediation device. Remote packet strategies should support this type of application. Bullard Informational-Expires September 2001 3 Remote Packet Capture March, 2001 5.3 Support Remote Captured Packet Storage One of the primary performance limitations in existing remote packet capture technology is the architectural requirement for local storage of captured packets. Because of the need to support very high-speed packet capture, any new remote packet strategy should support remote capture storage. 5.4 Wireline Packet Timestamping In order to perform time dependant analysis of network events, accurate time reporting is critical. All packet capture technology should support/conform to the wireline timestamp guidelines as described in the IPPM WG Framework document, RFC-2330. 5.5 Address Privacy Threat Issues Packet capture can pose a threat to individual privacy as it can be used to support unauthorized disclosure. In order to address this important issue, new packet capture technology must adopt strategies that help to minimize these threats when packet capture is used to support authorized tasks. 5.5.1 Content Separation Network management functions, such as RMON, must inspect some aspect of network datagram content in order to perform the designed function. If a particular network management function is an authorized function, then the minimum set of packet data required to support the authorized function will represent authorized data. All other packet contents can be referred to as unauthorized data content. Current packet capture technology does not support the separation of authorized data from unauthorized data, and as a result, current technology can pose a threat to privacy even when used to support authorized functions. A primary requirement of future packet capture technology should be that the facility support selective capture of authorized information. 5.5.2 Captured Content Protection Captured packet contents MUST be protected from unauthorized modification and/or disclosure. Integrity protection for captured packet contents is very important not only because network management decisions and actions will be made based on captured packet contents, but because fraudulent packet capture data can have significant impacts on individual privacy. Bullard Informational-Expires September 2001 4 Remote Packet Capture March, 2001 5.6 Partial Packet Capture Remote packet capture facilities should provide selective length packet capture. Applications may require full packet capture of a subset of network traffic, such as ICMP packets, but require only partial packet contents for other network traffic. A few examples would be Layer 2 headers capture to support the RMON Ethernet History function, or simple MPLS tags capture to support emerging TE performance measurements. 5.7 Captured Packet Transport One of the primary limitations of RMON packet capture is the architectural requirement that captured packets be stored locally on the probe. This single requirement limits the capacity for an RMON probe to capture packets in quantity, which limits either the capture load or the capture duration. The ability to transport captured packets off the probe to a mediation device can overcome this basic architectural barrier. 6 Recommendations 6.1 Packet Header Capture In order to support performance, security and application specific issues in remote packet capture, this proposal recommends that remote packet capture technology support packet capture on protocol header boundaries. If a network management function has authority to access IP header content information from packets of interest, such as the information needed to compile a RMON HostTopN list, the remote packet data source that is supplying the information needed for this function should be designed to provide only the IP header from packets of interest. This approach will significantly reduce the captured packet load, and limit the capture to the minimum set of information required of the application. And because there are hardware packet classifiers that are currently available that can make header boundary determinations at wireline speeds, this approach can be implemented as an integrated mechanism in high performance equipment. Bullard Informational-Expires September 2001 5 Remote Packet Capture March, 2001 6.2 Captured Packet Encapsulation Header To support distributed packet capture, partial packet capture, and wireline timestamping, this proposal recommends pre-pending captured packet data with a captured packet header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifIndex | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp (sec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp (usec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CapLength | PktLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Captured Packet Data +-+-+-+-+-+-+-+-+ | | Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Draft PCAP Header Format 6.2.1 Source Identifier This uniquely identifies the source of this packet capture to the mediation device. 6.2.2 ifIndex This uniquely identifies the interface on which the packet was captured. 6.2.3 Status This bit field contains indicators that are specific to this particular packet, or all the packets in a particular group. Including direction (ingress or egress), whether the packet was going to be forwarded or dropped, etc.... Bullard Informational-Expires September 2001 6 Remote Packet Capture March, 2001 6.2.4 Sequence Number This unsigned integer is used to indicate the sequence number of the captured packet. This is used help the mediation device realize if any packets have been dropped by the capture facility. 6.2.5 Time Stamp The time stamp is the wireline timestamp of this captured packet data. This value is generated through guidelines set by the IPPM Framework. 6.2.6 CapLength This 16-bit unsigned value is the length of the captured packet data buffer. 6.2.7 PktLength This 16-bit unsigned value is the actual length of the capture packet. 6.2.8 Captured Packet Data This is the actual packet data that was captured. If the capLength field is zero (0), then this field is omitted. 6.2.9 Pad The pad is a MUST be zero (MBZ) 8 bit value that is added so that the entire captured packet structure is 16-bit aligned. Bullard Informational-Expires September 2001 7 Remote Packet Capture March, 2001 6.3 Multiple Captured Packet Encapsulation Header To support collecting multiple packets together into a single captured packet buffer, a multiple captured packet header is defined. The values, such as Source Identifier, ifIndex, Status and Time Stamp apply to all the packets included in the buffer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifIndex | Group Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp (sec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Stamp (usec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CapLength | PktLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Offset (usec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Captured Packet Data +-+-+-+-+-+-+-+-+ | | Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CapLength | PktLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Offset (usec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Captured Packet Data +-+-+-+-+-+-+-+-+ | | Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Draft PCAP Header Format 6.4 In-Band Captured Packet Transport In order to support high-speed integrated implementations, as well as to meet the requirement to support security protection for captured packets, this proposal recommends In-Band transport of captured packets. In-Band transport can be accomplished through the use of Layer 2 encapsulation, IP header encapsulation or UDP/TCP transport strategies. NSAP identifiers may need to be allocated to identify the packet as a Bullard Informational-Expires September 2001 8 Remote Packet Capture March, 2001 packet capture transport packet, when using Layer 2 and IP transport schemes. In-Band transport may involve fragmentation when supporting large packet capture sizes. 7 Security Considerations Protection against known security threats such as unauthorized access, modification or disclosure of remotely captured packet content can be accomplished using existing IETF specified technology, particularly SNMPv3 and IPSec. Threats against captured packet data while resident in a persistent store is beyond the scope of this document. 8 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Waldbusser, S., "Remote Network Monitoring Management Information Base", STD-59, May 2000 3 Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997 4 Waterman, R., Lahaye, B., Romascanu, D. Waldbusser, S., "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999 5 Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998 9 Acknowledgments 10 Author's Addresses Carter Bullard QoSient, LLC. 300 E. 56th Street, Suite 18K New York, New York 10022-1439 Phone: +1 212 588 9133 Email: carter@qosient.com Bullard Informational-Expires September 2001 9 Remote Packet Capture March, 2001 11 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bullard Informational-Expires September 2001 10 ------=_NextPart_000_0047_01C0A0F8.6EBDCD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable updated draft-bullard-pcap-01.txt

Gentle people,
I submitted an update to draft-bullard-pcap-01.txt to = be
published today.   I've included it below, = and it is
also available via anonymous ftp as
ftp:= //qosient.com/pub/ietf/drafts/draft-bullard-pcap-01.txt.

Basically this update adds one new element to the = packet
capture header, the original packet capture length, = moves
a few things around, and defines all the = fields.  It also
presents a header for when you want to capture = multiple
packets at a time, a kind of group capture = header.  Basic
text has only minor modifications.

Still very much a draft, but it tries to capture some = of
the suggestions from the BOF and the RMON = meeting.

Any comments, opinions, are very much welcome!

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




       Internet = Draft           &n= bsp;           &nb= sp;           &nbs= p;        C. Bullard
       Document: = draft-bullard-pcap-01        &nbs= p;            = ;     QoSient, LLC
       Category: = Informational          =             &= nbsp;            = March, 2001
     
     
          &nbs= p;            = ;       Remote Packet Capture
          &nbs= p;            = ;    <draft-bullard-pcap-01.txt>
     
     Status of this Memo
     
     This document is an = Internet-Draft and is in full conformance with all
     provisions of Section 10 of = RFC2026 [1]. 
     
     Internet-Drafts are working = documents of the Internet Engineering Task
     Force (IETF), its areas, and = its working groups. Note that other groups
     may also distribute working = documents as Internet-Drafts.
     
     Internet-Drafts are draft = documents valid for a maximum of six months
     and may be updated, = replaced, or obsoleted by other documents at any
     time. It is inappropriate to = use Internet- Drafts as reference material
     or to cite them other than = as "work in progress."
     
     The list of current = Internet-Drafts can be accessed at
     http://www.ietf.org/i= etf/1id-abstracts.txt
     
     The list of Internet-Draft = Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html<= /A>.
     
     
     
     1 Copyright Notice
     
     Copyright (C) The Internet = Society (2001).  All Rights Reserved.
     
     
     2 Abstract
     
     This memo describes a set of = recommendations for remote packet capture. 
     The approach is designed to = address deployment, performance and privacy
     issues that limit the = usefulness of existing packet capture technology.
     














     = Bullard           =     Informational-Expires September = 2001           &nb= sp; 1
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     
     3 Table of Contents
     
     1     = Copyright Notice..............................................1
     2     = Abstract......................................................1
     3     = Table of Contents.............................................2
     4     = Overview......................................................2
     5     = Remote Packet Capture Requirements/Goals......................3
     5.1   High = Performance Packet Capture...............................3
     5.2   Distributed = Monitoring Applications...........................3
     5.3   Support = Remote Captured Packet Storage........................4
     5.4   Wireline = Packet Timestamping..................................4
     5.5   Address = Privacy Threat Issues.................................4
     5.5.1 Content = Separation............................................4
     5.5.2 Captured Content = Protection...................................4
     5.6   Partial = Packet Capture........................................5
     5.7   Captured = Packet Transport.....................................5
     6     = Recommendations...............................................5
     6.1   Packet = Header Capture.........................................5
     6.2   Captured = Packet Encapsulation Header..........................6
     6.2.1 Source = Identifier.............................................6
     6.2.2 = ifIndex.......................................................6
     6.2.3 = Status........................................................6
     6.2.4 Sequence = Number...............................................7
     6.2.5 Time = Stamp....................................................7
     6.2.6 = CapLength.....................................................7
     6.2.7 = PktLength.....................................................7
     6.2.8 Captured Packet = Data..........................................7
     6.2.9 = Pad...........................................................7
     6.3   Multiple = Captured Packet Encapsulation Header.................8
     6.4   In-Band = Captured Packet Transport.............................8
     7     = Security Considerations.......................................9
     8     = References....................................................9
     9     = Acknowledgments...............................................9
     10    = Author's Addresses............................................9
     11    Full = Copyright Statement.....................................10
     
     
     4 Overview
     
     Packet capture is a = fundamental mechanism in Internet network
     management and is used in = support of a wide range of network
     operational functions, such = as fault detection, protocol functional
     assurance, performance = analysis, and security assessment.  The IETF has
     specified technology for = remote packet capture in RMON, STD-59[2], and
     working groups, such as RMON = and IPPM, continue to describe various
     aspects of packet capture = technology in RMON2, RFC-2021[3], SMON, RFC-
     2613[4], and IPPM, = RFC-2330[5].
     
      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     2
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     With new network paradigms = and new network analytic requirements,
     existing packet capture = technology is finding its limits, and vendors
     are generating proprietary = mechanisms to overcome these hurdles.  To
     address the issue of = proprietary remote packet capture mechanisms in
     the switched network = environment, the SMON MIB introduced the concept
     of an extended data source = mechanism.  This facility is designed to
     support vendors supplied = "Copy Port" functions, and does not address
     the general issue of = proprietary remote packet capture.
     
     This proposal recommends = specification of a remote packet capture
     source facility that can act = as a reliable external packet capture
     point in Internet = networks.  Designed to support a number of existing
     applications, such as RMON = and RTFM, a remote packet capture facility
     should also enable new = applications, such as those emerging from the
     IPPM and TE WGs.
     
     This proposal recommends = that in order to overcome the perceived
     limitations of existing = technology, new remote packet capture
     mechanisms should be = required to support full wire speed packet header
     capture with wireline = timestamping and in-band transport of the
     captured data.
     
     
     5 Remote Packet Capture = Requirements/Goals
     
     5.1  High Performance = Packet Capture
     
     A remote packet capture = source facility should perform at a level that
     assures comprehensive packet = capture at full duplex line rate, without
     packet loss.  If packet = loss does occur, the condition should be
     detectable and possibly = quantifiable.
     
     Existing RMON packet capture = technology cannot support sustained packet
     capture at existing link = speeds, primarily due to local storage
     requirements.  Port = mirroring, or port copy, based packet capture
     technology, can perform full = packet capture at wireline rates, but
     these mechanisms have = inherent congestion problems when mirroring full
     duplex interfaces, and = congestion related packet loss is not detectable
     or reportable.
     
     
     5.2  Distributed = Monitoring Applications
     
     A remote packet capture = facility should provide reliable packet capture
     in asymmetric network = architectures.  Remote capture facilities should
     also support distributed = monitoring applications, such as those where
     the same packet must be = monitored at multiple points along its path.
     
     Both of these situations = require multiple remote capture points with
     packet event correlation = handled by a mediation device.  Remote packet
     strategies should support = this type of application.
     
     
     
      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     3
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     5.3  Support Remote = Captured Packet Storage
     
     One of the primary = performance limitations in existing remote packet
     capture technology is the = architectural requirement for local storage
     of captured packets.  = Because of the need to support very high-speed
     packet capture, any new = remote packet strategy should support remote
     capture storage.
     
     
     5.4  Wireline Packet = Timestamping
     
     In order to perform time = dependant analysis of network events, accurate
     time reporting is = critical.  All packet capture technology should
     support/conform to the = wireline timestamp guidelines as described in
     the IPPM WG Framework = document, RFC-2330.
     
     
     5.5  Address Privacy = Threat Issues
     
     Packet capture can pose a = threat to individual privacy as it can be
     used to support unauthorized = disclosure.  In order to address this
     important issue, new packet = capture technology must adopt strategies
     that help to minimize these = threats when packet capture is used to
     support authorized tasks. =
     
     
     5.5.1   Content = Separation
     
     Network management = functions, such as RMON, must inspect some aspect of
     network datagram content in = order to perform the designed function.  If
     a particular network = management function is an authorized function,
     then the minimum set of = packet data required to support the authorized
     function will represent = authorized data.  All other packet contents can
     be referred to as = unauthorized data content.
     
     Current packet capture = technology does not support the separation of
     authorized data from = unauthorized data, and as a result, current
     technology can pose a threat = to privacy even when used to support
     authorized functions. =
     
     A primary requirement of = future packet capture technology should be
     that the facility support = selective capture of authorized information.
     
     
     5.5.2   Captured = Content Protection
     
     Captured packet contents = MUST be protected from unauthorized
     modification and/or = disclosure.
     
     Integrity protection for = captured packet contents is very important not
     only because network = management decisions and actions will be made
     based on captured packet = contents, but because fraudulent packet
     capture data can have = significant impacts on individual privacy.
     
      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     4
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     
     
     5.6  Partial Packet = Capture
     
     Remote packet capture = facilities should provide selective length packet
     capture.  Applications = may require full packet capture of a subset of
     network traffic, such as = ICMP packets, but require only partial packet
     contents for other network = traffic.
     
     A few examples would be = Layer 2 headers capture to support the RMON
     Ethernet History function, = or simple MPLS tags capture to support
     emerging TE performance = measurements.
     
     
     5.7  Captured Packet = Transport
     
     One of the primary = limitations of RMON packet capture is the
     architectural requirement = that captured packets be stored locally on
     the probe.  This single = requirement limits the capacity for an RMON
     probe to capture packets in = quantity, which limits either the capture
     load or the capture = duration.
     
     The ability to transport = captured packets off the probe to a mediation
     device can overcome this = basic architectural barrier.
     
     
     6  Recommendations =
     
     6.1 Packet Header Capture =
     
     In order to support = performance, security and application specific
     issues in remote packet = capture, this proposal recommends that remote
     packet capture technology = support packet capture on protocol header
     boundaries.
     
     If a network management = function has authority to access IP header
     content information from = packets of interest, such as the information
     needed to compile a RMON = HostTopN list, the remote packet data source
     that is supplying the = information needed for this function should be
     designed to provide only the = IP header from packets of interest.
     
     This approach will = significantly reduce the captured packet load, and
     limit the capture to the = minimum set of information required of the
     application.
     
     And because there are = hardware packet classifiers that are currently
     available that can make = header boundary determinations at wireline
     speeds, this approach can be = implemented as an integrated mechanism in
     high performance equipment. =
     




      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     5
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     
     6.2 Captured Packet = Encapsulation Header
     
     To support distributed = packet capture, partial packet capture, and
     wireline timestamping, this = proposal recommends pre-pending captured
     packet data with a captured = packet header.
     
     
         = 0            =        = 1            =        = 2            =        3   
         0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =            Source = Identifier          &nb= sp;            | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            = ifIndex           = = |            = = Status            = |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             = Sequence = Number           &= nbsp;            = |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             Time = Stamp = (sec)           &n= bsp;           | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             Time = Stamp = (usec)           &= nbsp;          |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |         = CapLength          &nbs= p;  |           = PktLength           | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
        = |            =          Captured Packet = Data      +-+-+-+-+-+-+-+-+
        = |            =             &= nbsp;           &n= bsp;          = |      Pad      | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     
          &nbs= p;            = ;     Draft PCAP Header Format
     
     
     6.2.1   Source = Identifier
     
     This uniquely identifies the = source of this packet capture to the
     mediation device.
     
     
     6.2.2   ifIndex =
         =
     This uniquely identifies the = interface on which the packet was
     captured.
     
     
     6.2.3   Status =
     
     This bit field contains = indicators that are specific to this particular
     packet, or all the packets = in a particular group.  Including direction
     (ingress or egress), whether = the packet was going to be forwarded or
     dropped, etc....
     




      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     6
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     6.2.4   Sequence = Number
     
     This unsigned integer is = used to indicate the sequence number of the
     captured packet.  This = is used help the mediation device realize if any
     packets have been dropped by = the capture facility.
     
     
     6.2.5   Time Stamp =
     
     The time stamp is the = wireline timestamp of this captured packet data. 
     This value is generated = through guidelines set by the IPPM Framework.
     
     
     6.2.6   CapLength =
     
     This 16-bit unsigned value = is the length of the captured packet data
     buffer.
     
     
     6.2.7   PktLength =
     
     This 16-bit unsigned value = is the actual length of the capture packet.
     
     
     6.2.8   Captured = Packet Data
     
     This is the actual packet = data that was captured.  If the capLength
     field is zero (0), then this = field is omitted.
     
     
     6.2.9   Pad =
     
     The pad is a MUST be zero = (MBZ) 8 bit value that is added so that the
     entire captured packet = structure is 16-bit aligned.
     



















      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     7
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     
     6.3 Multiple Captured Packet = Encapsulation Header
     
     To support collecting = multiple packets together into a single captured
     packet buffer, a multiple = captured packet header is defined.  The
     values, such as Source = Identifier, ifIndex, Status and Time Stamp apply
     to all the packets included = in the buffer.
     
     
         = 0            =        = 1            =        = 2            =        3   
         0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =            Source = Identifier          &nb= sp;            | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            = ifIndex           = |         Group  = Status         |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             = Sequence = Number           &= nbsp;            = |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             Time = Stamp = (sec)           &n= bsp;           | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             Time = Stamp = (usec)           &= nbsp;          |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |         = CapLength          &nbs= p;  |           = PktLength           | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             Time = Offset = (usec)           &= nbsp;         |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
        = |            =          Captured Packet = Data      +-+-+-+-+-+-+-+-+
        = |            =             &= nbsp;           &n= bsp;          = |      Pad      | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |         = CapLength          &nbs= p;  |           = PktLength           | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             Time = Offset = (usec)           &= nbsp;         |
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |
        = |            =          Captured Packet = Data      +-+-+-+-+-+-+-+-+
        = |            =             &= nbsp;           &n= bsp;          = |      Pad      | =
        = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     
          &nbs= p;            = ;     Draft PCAP Header Format
     
     
     
     6.4 In-Band Captured Packet = Transport
     
     In order to support = high-speed integrated implementations, as well as
     to meet the requirement to = support security protection for captured
     packets, this proposal = recommends In-Band transport of captured
     packets.
     
     In-Band transport can be = accomplished through the use of Layer 2
     encapsulation, IP header = encapsulation or UDP/TCP transport strategies. 
     NSAP identifiers may need to = be allocated to identify the packet as a

      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     8
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     packet capture transport = packet, when using Layer 2 and IP transport
     schemes.
     
     In-Band transport may = involve fragmentation when supporting large
     packet capture sizes. =
     
     
     7  Security = Considerations
     
     Protection against known = security threats such as unauthorized access,
     modification or disclosure = of remotely captured packet content can be
     accomplished using existing = IETF specified technology, particularly
     SNMPv3 and IPSec.
     
     Threats against captured = packet data while resident in a persistent
     store is beyond the scope of = this document.
     
     
     8  References
     
     
        1  = Bradner, S., "The Internet Standards Process -- Revision 3", = BCP
           9, = RFC 2026, October 1996.
         =
        2  = Waldbusser, S., "Remote Network Monitoring Management Information =
           = Base", STD-59, May 2000
         =
        3  = Waldbusser, S., "Remote Network Monitoring Management Information =
           = Base Version 2 using SMIv2", RFC 2021, January 1997
         =
        4  = Waterman, R., Lahaye, B., Romascanu, D. Waldbusser, S., "Remote =
           = Network Monitoring MIB Extensions for Switched Networks  Version =
           = 1.0", RFC 2613, June 1999
         =
        5  = Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework for IP =
           = Performance Metrics", RFC 2330, May 1998
         =
     
     
     9 Acknowledgments
     
     
     10 Author's Addresses =
     
     Carter Bullard
     QoSient, LLC.
     300 E. 56th Street, Suite = 18K
     New York, New York  = 10022-1439
     Phone: +1 212 588 9133 =
     Email: carter@qosient.com =
     



      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;     9
=0C
          &nbs= p;            = ;      Remote Packet = Capture           =    March, 2001

     
     11 Full Copyright Statement =
     
     Copyright (C) The Internet = Society (2000). All Rights Reserved.
     
     This document and = translations of it may be copied and furnished to
     others, and derivative works = that comment on or otherwise explain it
     or assist in its = implementation may be prepared, copied, published
     and distributed, in whole or = in part, without restriction of any
     kind, provided that the = above copyright notice and this paragraph are
     included on all such copies = and derivative works. However, this
     document itself may not be = modified in any way, such as by removing
     the copyright notice or = references to the Internet Society or other
     Internet organizations, = except as needed for the purpose of
     developing Internet = standards in which case the procedures for
     copyrights defined in the = Internet Standards process must be
     followed, or as required to = translate it into languages other than
     English.
     
     The limited permissions = granted above are perpetual and will not be
     revoked by the Internet = Society or its successors or assigns.
     
     This document and the = information contained herein is provided on an
     "AS IS" basis and = THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
     TASK FORCE DISCLAIMS ALL = WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
     BUT NOT LIMITED TO ANY = WARRANTY THAT THE USE OF THE INFORMATION
     HEREIN WILL NOT INFRINGE ANY = RIGHTS OR ANY IMPLIED WARRANTIES OF
     MERCHANTABILITY OR FITNESS = FOR A PARTICULAR PURPOSE.
     

























      
     = Bullard          = Informational-Expires September = 2001           &nb= sp;    10

------=_NextPart_000_0047_01C0A0F8.6EBDCD00--