From tqtf-admin@advanced.org Fri Feb 1 06:52:10 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18688 for ; Fri, 1 Feb 2002 06:52:10 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g11BqBmQ026760 for ; Fri, 1 Feb 2002 06:52:11 -0500 Date: Fri, 1 Feb 2002 06:52:11 -0500 Message-Id: <200202011152.g11BqBmQ026760@mailhost.advanced.org> Subject: advanced.org mailing list memberships reminder From: mailman-owner@advanced.org To: ippm-archive@ietf.org X-No-Archive: yes Sender: tqtf-admin@advanced.org Errors-To: tqtf-admin@advanced.org X-BeenThere: tqtf@thinkquest.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a reminder, sent out once a month, about your advanced.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@advanced.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@advanced.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@advanced.org jTPE http://mailhost.advanced.org/mailman/options/ippm/ippm-archive@lists.ietf.org From ippm-admin@advanced.org Fri Feb 1 19:54:48 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15238 for ; Fri, 1 Feb 2002 19:54:48 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g120r2mQ011294; Fri, 1 Feb 2002 19:53:02 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g120qjmQ011109; Fri, 1 Feb 2002 19:52:45 -0500 From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , "Merike Kaeo" Date: Fri, 1 Feb 2002 19:53:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Last Call for draft-ietf-ippm-loss-pattern-06.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Folks, The latest draft of the One-way Loss Pattern Sample Metrics has all the fixes and changes suggested during the previous last-call period. Although the chairs do not feel the changes are substantive, there are enough and enough time has elapsed (partially due to delays on our part) that we would like to do another brief last-call. Assuming no major objections or changes, we will submit this document to the IESG for consideration as an Informational RFC. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). The Working Group last-call will end on Monday, February 28, 2002 at noon EST. One pointer to the draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-pattern-06.txt Thanks! --Matt and Merike _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 1 20:03:18 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15357 for ; Fri, 1 Feb 2002 20:03:18 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g12122mQ013341; Fri, 1 Feb 2002 20:02:02 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g1211lmQ013152; Fri, 1 Feb 2002 20:01:47 -0500 From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , "Merike Kaeo" Date: Fri, 1 Feb 2002 20:02:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Working Group last call: draft-ietf-ippm-ipdv-08.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The latest draft of the IP Packet Delay Variation Metric has all the fixes and changes suggested on this list as well as previous IETF meetings. Since there have been no substantive changes suggested to this document since the last version, the co-chairs propose a Working Group last-call for this document, draft-ietf-ippm-ipdv-08.txt. Assuming no major objections or changes, we will submit this document to the IESG for consideration as an Proposed Standard RFC. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). Because multiple last-calls are outstanding, the Working Group last-call period for this document will be extended, and will end on Monday, February 25, 2002 at noon EST. One pointer for the document is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-08.txt --Matt Zekauskas & Merike Kaeo _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 4 07:22:04 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20052 for ; Mon, 4 Feb 2002 07:22:04 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g14CL2mQ028590; Mon, 4 Feb 2002 07:21:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g14CKqmQ028401 for ; Mon, 4 Feb 2002 07:20:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19756; Mon, 4 Feb 2002 07:20:51 -0500 (EST) Message-Id: <200202041220.HAA19756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rmonmib@ietf.org, ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 04 Feb 2002 07:20:50 -0500 Subject: [ippm] I-D ACTION:draft-stephan-ippm-mib-02.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP measurement MIB Author(s) : E. Stephan Filename : draft-stephan-ippm-mib-02.txt Pages : 64 Date : 01-Feb-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, It defines a registry of the IPPM working group metrics and specifies the objects used for managing IPPM metrics measures, for pushing alarms and for reporting the measures results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stephan-ippm-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stephan-ippm-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stephan-ippm-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020201164309.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stephan-ippm-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-stephan-ippm-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020201164309.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 4 10:40:21 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25968 for ; Mon, 4 Feb 2002 10:40:19 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g14Fa6mQ027798; Mon, 4 Feb 2002 10:36:06 -0500 Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g14AObmQ017095 for ; Mon, 4 Feb 2002 05:24:38 -0500 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1AK0RP4P>; Mon, 4 Feb 2002 11:24:24 +0100 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: ippm@advanced.org, rmonmib@ietf.org Date: Mon, 4 Feb 2002 11:24:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AD66.21B4C8D0" Subject: [ippm] IPPM-MIB released Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1AD66.21B4C8D0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AD66.21B4C8D0" ------_=_NextPart_001_01C1AD66.21B4C8D0 Content-Type: text/plain; charset="iso-8859-1" Hi al, The IPPM-MIB have been released http://www.ietf.org/internet-drafts/draft-stephan-ippm-mib-02.txt. the memo fixes 2 issues: provide a registry of the metrics; provide a reporting mode to the control and the protocols. > Abstract: > This memo defines a portion of the Management Information Base > (MIB) for use with network management protocols in TCP/IP-based > internets. In particular, It defines a registry of the IPPM > working > group metrics and specifies the objects used for managing IPPM > metrics measures, for pushing alarms and for reporting the > measures results. > > Alarms are triggered by up and down thredholds or long duration thresholds. Reports are pushed to applications or polled. > best regards. > Emile > > > -------------------------------------------------------------------------- > ------ > > E. Stephan Tel: (+ 33) > 2 96 05 36 10 > France Telecom R&D, Dpt. CPN Fax: (+ 33) 2 96 05 18 52 > 2 avenue Pierre Marzin > F-22307 Lannion cedex > mel: emile.stephan@francetelecom.com > > -------------------------------------------------------------------------- > ------ > > <> ------_=_NextPart_001_01C1AD66.21B4C8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPPM-MIB released

Hi al,

The IPPM-MIB have = been released http://www.ietf.org/internet-drafts/draft-stephan-ippm= -mib-02.txt.

the memo fixes 2 = issues:
        provide a registry of the metrics;
        provide a reporting mode to the control and the = protocols.

      Abstract:
      This memo defines a = portion of the Management Information Base
         (MIB) = for use with network management protocols in TCP/IP-based
         = internets. In particular, It defines a registry of the IPPM working =
         group = metrics and specifies the objects used for managing IPPM
         = metrics measures, for pushing alarms and for reporting the measures = results.


      Alarms are triggered = by up and down thredholds or long duration thresholds.
      Reports are pushed = to applications or polled.


      best regards.
      Emile

      ---------------------------------------------------------= -----------------------

              E. = Stephan           = ;            =        =         Tel: (+ 33) 2 96 05 36 = 10
              France = Telecom R&D, Dpt. CPN    Fax: (+ 33) 2 96 05 18 = 52
              2 avenue = Pierre = Marzin           =   
              F-22307 = Lannion cedex=20
                mel: = emile.stephan@francetelecom.com
      ---------------------------------------------------------= -----------------------


= <<draft-stephan-ippm-mib-02.txt>> =20 ------_=_NextPart_001_01C1AD66.21B4C8D0-- ------_=_NextPart_000_01C1AD66.21B4C8D0 Content-Type: text/plain; name="draft-stephan-ippm-mib-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-stephan-ippm-mib-02.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= Network Working Group E. = Stephan =0A= =0A= Internet Draft France Telecom = R&D =0A= =0A= Document: draft-stephan-ippm-mib-02.txt February 01, = 2002 =0A= =0A= Category: Informational = =0A= =0A= =0A= =0A= IPPM measurement MIB =0A= =0A= =0A= Status of this Memo =0A= =0A= This document is an Internet-Draft and is in full conformance with = =0A= all provisions of Section 10 of RFC2026 [1] except that the right to = =0A= produce derivative works is not granted. =0A= =0A= =0A= Internet-Drafts are working documents of the Internet Engineering = =0A= Task Force (IETF), its areas, and its working groups. Note that = other =0A= groups may also distribute working documents as Internet-Drafts. =0A= Internet-Drafts are draft documents valid for a maximum of six = months =0A= and may be updated, replaced, or obsoleted by other documents at any = =0A= time. It is inappropriate to use Internet- Drafts as reference =0A= material or to cite them other than as "work in progress." =0A= =0A= The list of current Internet-Drafts can be accessed at =0A= http://www.ietf.org/ietf/1id-abstracts.txt. =0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at =0A= http://www.ietf.org/shadow.html. =0A= =0A= =0A= Abstract =0A= =0A= This memo defines a portion of the Management Information Base (MIB) = =0A= for use with network management protocols in TCP/IP-based internets. = =0A= In particular, It defines a registry of the IPPM working group =0A= metrics and specifies the objects used for managing IPPM metrics =0A= measures, for pushing alarms and for reporting the measures results. = =0A= =0A= Table of Contents =0A= =0A= 1. = Introduction................................................2 =0A= 2. The IPPM = Framework..........................................3 =0A= 3. The SNMP Management = Framework...............................3 =0A= 4. = Overview....................................................4 =0A= 4.1. Textual = Conventions.........................................5 =0A= 4.2. Structure of = MIB............................................7 =0A= 4.3. Row addition in an application = namespace....................9 =0A= 4.4. Control of Remote Measurement = Devices......................10 =0A= 4.5. Resource Sharing Among Multiple Management = Stations........10 =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 1] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= 4.6. Row Addition Among Multiple Management = Stations............11 =0A= 5. IPPM-MIB metrics = registry..................................11 =0A= 5.1. registry = framework.........................................11 =0A= 5.2. IPPM = RFC...................................................11 =0A= 5.3. IPPM = draft.................................................12 =0A= 5.4. I-D = draft..................................................12 =0A= 6. IPPM-MIB conceptual = presentation...........................13 =0A= 6.1. IPPM-MIB = diagram...........................................13 =0A= 6.2. conceptual programming = interface...........................14 =0A= 6.3. SNMP = mapping...............................................14 =0A= 7. measurement = architectures..................................15 =0A= 7.1. Proxy = architecture.........................................15 =0A= 7.2. probe = architecture.........................................16 =0A= 7.3. Reporting = architecture.....................................17 =0A= 7.4. gateway = architecture.......................................18 =0A= 7.5. = Security...................................................19 =0A= 8. Reporting mode integration with the control and test =0A= = protocols................................................20 =0A= 8.1. = Integration................................................20 =0A= 8.2. Setup of the = measure.......................................20 =0A= 8.3. Setup of the report of a = measure...........................21 =0A= 8.4. writing the measure results in the = IPPM-MIB................21 =0A= 8.5. report download and = upload.................................21 =0A= 8.6. Default = value..............................................22 =0A= 9. = Definition.................................................22 =0A= 10. Security = Considerations....................................59 =0A= 10.1. = Privacy.....................................................59 =0A= 10.2. Measurement = aspects.........................................59 =0A= 10.3. Management = aspects..........................................60 =0A= 11. = References.................................................61 =0A= 12. = Acknowledgments............................................63 =0A= 13. Author's = Addresses.........................................63 =0A= =0A= =0A= 1. Introduction =0A= =0A= This memo defines a MIB for managing the measures using the IP =0A= performance metrics specified by the IPPM Working Group. =0A= =0A= It specifies the objects to manage the measure of performance = metrics =0A= standardized by IPPM Working Group. There are built on notions =0A= introduced and discussed in the IPPM Framework document, RFC 2330 = =0A= [2]. =0A= =0A= This memo defines a Management Information Base (MIB) so it is =0A= intended to be respectful of the "Boilerplate for IETF MIBs" defined = =0A= in http://www.ops.ietf.org/mib-boilerplate.html. =0A= =0A= There are companion documents to the IPPM MIB both in the Transport = =0A= Area (See section 2) and in the Operations and Management Area (See = =0A= section 3). The reader should be familiar with these documents. =0A= =0A= Stephan Informational - Expires August 2002 [Page 2] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= 2. The IPPM Framework =0A= =0A= The IPPM Framework consists in 3 major components: =0A= =0A= A general framework for defining performance metrics, described = =0A= in the Framework for IP Performance Metrics, RFC 2330 [2]; =0A= =0A= A set of standardized metrics which conform to this framework. = =0A= The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]. The = One-=0A= way Delay Metric for IPPM, RFC 2679 [4]. The One-way Packet Loss =0A= Metric for IPPM, RFC 2680 [5]. The Round-trip Delay Metric for IPPM, = =0A= RFC 2681 [6]; =0A= =0A= Emerging metrics which are being specified in respect of this =0A= framework; =0A= =0A= =0A= 3. The SNMP Management Framework =0A= =0A= The SNMP Management Framework consists of five major components: =0A= =0A= An overall architecture, described in RFC 2571 [7]. =0A= =0A= Mechanisms for describing and naming objects and events for the = =0A= purpose of management. The first version of this Structure of =0A= Management Information (SMI) is called SMIv1 and described in STD = 16, =0A= RFC 1155 [8], STD 16, RFC 1212 [9] and RFC 1215 [10]. The second = =0A= version, called SMIv2, is described in STD 58, RFC 2578 [11], STD = 58, =0A= RFC 2579 [12] and STD 58, RFC 2580 [13]. =0A= =0A= Message protocols for transferring management information. The = =0A= first version of the SNMP message protocol is called SNMPv1 and =0A= described in STD 15, RFC 1157 [14]. A second version of the SNMP =0A= message protocol, which is not an Internet standards track protocol, = =0A= is called SNMPv2c and described in RFC 1901 [15] and RFC 1906 [16]. = =0A= The third version of the message protocol is called SNMPv3 and =0A= described in RFC 1906 [16], RFC 2572 [17] and RFC 2574 [18]. =0A= =0A= Protocol operations for accessing management information. The = =0A= first set of protocol operations and associated PDU formats is =0A= described in STD 15, RFC 1157 [14]. A second set of protocol =0A= operations and associated PDU formats is described in RFC 1905 [19]. = =0A= =0A= A set of fundamental applications described in RFC 2573 [20] = and =0A= the view-based access control mechanism described in RFC 2575 [21]. = =0A= =0A= A more detailed introduction to the current SNMP Management = Framework =0A= can be found in RFC 2570 [22]. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 3] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= Managed objects are accessed via a virtual information store, termed = =0A= the Management Information Base or MIB. Objects in the MIB are =0A= defined using the mechanisms defined in the SMI. =0A= =0A= This memo specifies a MIB module that is compliant to the SMIv2. A = =0A= MIB conforming to the SMIv1 can be produced through the appropriate = =0A= translations. The resulting translated MIB must be semantically =0A= equivalent, except where objects or events are omitted because no = =0A= translation is possible (use of Counter64). Some machine readable = =0A= information in SMIv2 will be converted into textual descriptions in = =0A= SMIv1 during the translation process. However, this loss of machine = =0A= readable information is not considered to change the semantics of = the =0A= MIB. =0A= =0A= Managed objects are accessed via a virtual information store, termed = =0A= the Management Information Base or MIB. Objects in the MIB are =0A= defined using the subset of Abstract Syntax Notation One (ASN.1) =0A= defined in the SMI. In particular, each object type is named by an = =0A= OBJECT IDENTIFIER, an administratively assigned name. =0A= =0A= The object type together with an object instance serves to uniquely = =0A= identify a specific instantiation of the object. For human =0A= convenience, we often use a textual string, termed the descriptor, = to =0A= refer to the object type. =0A= =0A= =0A= 4. Overview =0A= =0A= Although the number of measurements devices that implement the IPPM = =0A= metrics is growing there is not currently any standardized = management =0A= interface to manage remotely these metrics. This memo defines a =0A= Management Information Base for managing the measures of IPPM =0A= metrics. =0A= =0A= To permit metrics to be referenced by other MIBs and other protocols = =0A= the IPPM-MIB defines a registry of the current metrics and a =0A= framework for the integration of the future metrics in the registry. = =0A= =0A= As the specification of new metrics is a continuous process this = memo =0A= defines a framework for the integration of the future standardized = =0A= metric. Specialized tables may augment the measure table to address = =0A= future needs. =0A= =0A= The MIB architecture is inspired by the RMON model [23],[24] which = =0A= specify the MIB for the monitoring of a single point of measure. The = =0A= IPPM-MIB differs from this model because IPPM metrics measurements = =0A= involve several point of measures and need common references for = time =0A= and for measure identification. The IPPM-MIB defines an absolute =0A= timeFilter and introduces a framework where each application manages = =0A= its measures in an owner namespace and may grant other owner to =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 4] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= access its measure results for aggregated metrics computation, =0A= reporting or alarming. =0A= =0A= Different architectures may be used to perform metric measurements = =0A= using a control protocol and a test protocol. Different control =0A= frameworks are suitable for performing a measure. The memo list them = =0A= while looking for how to integrate them together with the IPPM-MIB. = =0A= This section is informational but helps to specify the relationship = =0A= among the test protocol, the control protocol and IPPM-MIB. =0A= =0A= Special care has been taken to provide a reporting mode suitable for = =0A= control protocol and test protocol. It addresses the need to provide = =0A= access to result for the applications. Moreover it may be used to = =0A= reduce the number of control frameworks. =0A= =0A= This MIB is intended to handle multiple concurrent SNMP applications = =0A= access. They are not in constant contact with the measurement =0A= devices. For this reason, this MIB allows continuous measures =0A= collection and statistics computation. =0A= =0A= The objects defined in this document are not intended for direct =0A= manipulation by humans. =0A= =0A= 4.1. Textual Conventions =0A= =0A= Four type of data are introduced as a textual convention in this = =0A= MIB document, TypeP and GMTDateAndTime, GmtTimeFilter =0A= IppmReportDefinition and IppmStandardMetrics. =0A= =0A= =0A= 4.1.1. Packet of type P =0A= =0A= The section 13 of the IPPM framework [2] introduces the generic =0A= notion of a "packet of type P" because in some contexts the metric's = =0A= value depends on the type of the packets involved in the metric. In = =0A= the definition of a metric the type P will be explicitly defined, = =0A= partially defined or left generic. Measurement of metrics defined = =0A= with generic type P made specific when performing actual =0A= measurements. This naming convention serves as an important reminder = =0A= that one must be conscious of the exact type of traffic being =0A= measured. =0A= =0A= The standardization of the management of the IPPM measures relies on = =0A= the capability to configure finely and unambiguously the type P of = =0A= the packets and the parameters of the protocols suites of the type = P. =0A= =0A= RMON2 introduced the concept of protocols identifiers. The RFC2895 = =0A= [25] specifies a macro for the definition of protocol identifier. = The =0A= RFC2896 [26] defines the protocols identifiers for different =0A= protocols encapsulation trees. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 5] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER = =0A= defined for identifying protocols suite in the RMON2. It is achieved = =0A= by defining the TypeP as new syntax in a SMIv2 TEXTUAL-CONVENTION. = =0A= =0A= 4.1.1.1. Internet addresses =0A= =0A= The section 14 of the IPPM framework defines for the common case of = a =0A= unidirectional path through the Internet the term "Src" and "Dst". = =0A= "Src" denotes the IP address of the beginning of the path, and "Dst" = =0A= denotes the IP address of the end. =0A= =0A= The section 3 of the RMON PI Reference specifies the Protocol =0A= Identifier Encoding rules which consists briefly in a recursive =0A= length value format. "Src" and "Dst" are protocol identifier =0A= parameters. Their values are encoded in separated fields using the = =0A= protocol identifier encoding rule but without trailing parameters. = =0A= =0A= The packet encapsulation defined in an instance of TypeP embeds the = =0A= format of "Src" and "Dst" and their values. These addresses type and = =0A= value depend on the type P of the packet, IP version 4, V6, IP in = =0A= IP... Both participate to the completion of the packet encoding. = =0A= =0A= Examples: =0A= =0A= RFC2896 defines the protocols identifiers ip and ipip4. Should there = =0A= be a Internet tunnel end-point of the IP address 192.168.1.1 in the = =0A= tunnel 128.2.6.7. The TypeP of the source address of the tunnel, = Src, =0A= is 8.0.0.8.0.0.0.0.17.2.0.0 (ip.ipip4). The trailer 2.0.0 in the =0A= TypeP indicates that there are 2 parameters. In the IPPM context =0A= these 2 parameters are provided in Src which has the value =0A= 10.4.192.168.1.1.4.128.2.6.7. =0A= =0A= =0A= 4.1.2. Report definition =0A= =0A= A report consists in sending or logging a subset of results of =0A= measure. The elaboration of the report consist in actions to do on = =0A= the measure results. A action is performed either: =0A= =0A= + for each result; =0A= + on the results corresponding to a measure cycle; =0A= + on the results available at the measure completion. =0A= =0A= To preserve the scalability of the whole measurement system it =0A= limits: =0A= =0A= + the among of data sent to the applications; =0A= + The bandwidth consumption for uploading the result; =0A= + The number of alarms sent to the applications; =0A= + The among of data saved in the point of measure; =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 6] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= The comparison of the measure results with a metric threshold =0A= identifies particular measures value and time that concern directly = =0A= services availability. =0A= =0A= The comparison of the duration of repeated events with a duration = =0A= threshold identifies particular measure value and time that concern = =0A= directly SLA. =0A= =0A= The combination of IPPM metrics results, threshold events and event = =0A= filtering provide a very efficient solution to report results, = events =0A= and alarms. =0A= =0A= A report is described using The using the TEXTUAL-CONVENTION =0A= IppmReportDefinition. The report setup must not increase = dramatically =0A= the size of the control protocol measure setup: =0A= =0A= + A basic report is defined in the object =0A= ippmReportSetupDefinition; =0A= + More elaborated reports are described using a metric = threshold =0A= to generate alarms and events. =0A= + Pushing of alarms and reports requires an NMS address. =0A= + SLA alarms are described using an events duration threshold. = =0A= =0A= The TEXTUAL-CONVENTION IppmReportDefinition specifies the list of = =0A= events and actions which are used to elaborate a report. =0A= =0A= 4.1.3. IppmStandardMetrics =0A= =0A= The TEXTUAL-CONVENTION IppmStandardMetrics defines the standardized = =0A= IPPM metrics. =0A= =0A= 4.2. Structure of MIB =0A= =0A= The MIB is arranged as follow: =0A= =0A= - Ippm metrics registry =0A= =0A= - ippmOwnersGroup =0A= =0A= - ippmSystemGroup =0A= =0A= - ippmMeasureGroup =0A= =0A= - ippmHistoryGroup =0A= =0A= - ippmNetworkMeasureGroup =0A= =0A= - ippmAggregatedMeasureGroup =0A= =0A= - ippmReportGroup =0A= =0A= Stephan Informational - Expires August 2002 [Page 7] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= - ippmNotifications =0A= =0A= =0A= =0A= 4.2.1. The registry of the metrics =0A= =0A= This group associates an OBJECT IDENTIFIER to each metrics. =0A= =0A= 4.2.2. The ippmOwners Group =0A= =0A= This group controls the SNMP applications which are granted to = =0A= manage the measurement device. =0A= =0A= 4.2.3. The ippmSystem Group =0A= =0A= This group consists of a set of parameters describing the clock =0A= synchronization over the time. =0A= =0A= This group is the most important part of the memo. =0A= =0A= Section 6.3. of the IPPM Framework said that =0A= "Those who develop such measurement methodologies should strive to: = =0A= + minimize their uncertainties/errors, =0A= + understand and document the sources of uncertainty/error, and = =0A= + quantify the amounts of uncertainty/error." =0A= =0A= The aim of this group is to have these values available to compute = =0A= reliable statistics. Then the implementation of this group is =0A= mandatory either the time synchronization is automatic or not. =0A= =0A= 4.2.4. The ippmMeasureGroup =0A= =0A= This group controls all the measures. It consists of the =0A= ippmMetricsTable, ippmMeasureTable. =0A= =0A= The SNMP agent describes in the ippmMetricsTable the local =0A= implementation of the standardized metrics. =0A= =0A= The customers of the agent manage their measures in the =0A= ippmMeasureTable and in the auxiliaries measures tables. =0A= ippmMeasureTable holds the management part of a measure while the = =0A= technical parameters are handled in the corresponding auxiliary =0A= table. =0A= =0A= The results of the measures are logged in the ippmHistoryTable. =0A= =0A= 4.2.5. The ippmNetworkMeasure Group =0A= =0A= This group controls the network measures defined by the customers. = =0A= The results are saved in the ippmHistoryTable. =0A= =0A= Stephan Informational - Expires August 2002 [Page 8] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= ippmNetworkMeasureTable is an auxiliary table of ippmMeasureTable in = =0A= charge of the configuration of the network measure. =0A= =0A= 4.2.6. The ippmAggregatedMeasure Group =0A= =0A= ippmAggregatedMeasureTable is an auxiliary table of ippmMeasureTable = =0A= in charge of the consolidation of the results previously performed = =0A= and saved in the ippmHistoryTable. The aggregated results are saved = =0A= in the ippmHistoryTable and may be used for higher aggregated =0A= measures. =0A= =0A= 4.2.7. The report Group =0A= =0A= This group controls the report of the measures. ippmReportSetupTable = =0A= is an auxiliary table of ippmMeasureTable in charge of the =0A= configuration of the reports. =0A= The reports are saved in the ippmReportTable or sent directly to =0A= applications. =0A= =0A= 4.2.8. The notification Group =0A= =0A= The Notification grop is a list of notifications. They are used to = =0A= push alarms or reports to the applications. =0A= =0A= 4.3. Row addition in an application namespace =0A= =0A= The dynamic rows created by an owner are identified in its = namespace. =0A= =0A= An identifier of an instance of an object is defined as a list of = =0A= objects in the clause INDEX. An identifier of an instance of an =0A= object in an owner namespace is defined as a list of objects in the = =0A= clause INDEX where the first object type is OwnerString =0A= =0A= As the OBJECT IDENTIFIER which identify the instance begins with the = =0A= owner value the remaining fields value of the index may be chosen = =0A= independently from a namespace to another. =0A= =0A= it allows the user to choose arbitrary values for the remaining =0A= fields of the INDEX clause without checking for these fields values = =0A= existence in the MIB tables. It permits to the owner to use the same = =0A= fields values across MIBs implementation. =0A= =0A= It avoids polling to be done to determine the next free index. It = =0A= avoids 2 applications to find the same free index value. =0A= =0A= The usage of owner namespace increases the speed of the management = =0A= operations while reducing bandwidth consumption and CPU load in the = =0A= agents and applications. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 9] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= Measures are requested by NMSs. An instance of an object managed by = a =0A= NMS is identified by the NMS OwnerString and the private index =0A= provided by the NMS. =0A= =0A= As the NMS manages its private range of index, it simply choose one = =0A= when it wishes to create a new control entry. For the same reason = the =0A= setup of a measure on several points of measures consists simply in = =0A= sending the same copy of the measure setup to the different points = of =0A= measures involved. =0A= =0A= 4.4. Control of Remote Measurement Devices =0A= =0A= Due to the complex nature of the available functions in these =0A= devices, the functions often need user configuration. In many cases, = =0A= the function requires parameters to be set up for a data collection = =0A= operation. The operation can proceed only after these parameters are = =0A= fully set up. =0A= =0A= Functional groups in this MIB have one or more tables in which to = =0A= set up control parameters, and one or more data tables in which to = =0A= place the results of the operation. The control tables are typically = =0A= read/write in nature, while the data tables are typically read/only. = =0A= =0A= Because the parameters in the control table often describe =0A= resulting data in the data table, many of the parameters can be =0A= modified only when the control entry is not active. Thus, the method = =0A= for modifying these parameters is to de-activate the entry, perform = =0A= the SNMP Set operations to modify the entry, and then re-activate = the =0A= entry. Deleting the control entry causes the deletion of any =0A= associated data entries. =0A= =0A= 4.5. Resource Sharing Among Multiple Management Stations =0A= =0A= When multiple user applications wish to use functions that compete = =0A= for a finite amount of resources on a device, a method to facilitate = =0A= this sharing of resources is required. An owner namespace is = provided =0A= for each application which initiate function in this MIB to avoid = =0A= these conflicts and to help resolve them when they occur. Each =0A= function has a label identifying the initiator (owner) of the =0A= function. This label is set by the initiator to provide for the =0A= following possibilities: =0A= =0A= + A application recognizes resources it owns and no longer =0A= needs. =0A= A application may grant another one to use or manage part of = its =0A= resources. =0A= The agent administrator can identify the application that owns = =0A= the resource and negotiate for it to be freed. =0A= The agent administrator may decide to unilaterally free =0A= resources a application has reserved. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 10] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= The resources owned by the device itself or by the agent =0A= administrator is set to a string starting with 'monitor'. =0A= =0A= =0A= 4.6. Row Addition Among Multiple Management Stations =0A= =0A= Each application is associated with an owner namespace. The indexes = =0A= of the rows which belong to an application start with this =0A= Ownerstring value. =0A= =0A= The addition of new rows is achieved using the RowStatus method =0A= described in RFC 1903 [2] . In this MIB, rows are often added to a = =0A= table in order to configure a function. This configuration usually = =0A= involves parameters that control the operation of the function. The = =0A= agent must check these parameters to make sure their are appropriate = =0A= given restrictions defined in this MIB as well as any implementation = =0A= specific restrictions such as lack of resources. =0A= =0A= =0A= 5. IPPM-MIB metrics registry =0A= =0A= The previous IPPM-MIB [27] includes an IPPM metrics registry in the =0A= table ippmMetricTable using constant integer. That is not suitable for = =0A= cross reference inter MIBs. So the new version of the registry use =0A= OBJECT IDENTIFIER to identify the metrics. =0A= =0A= The registry includes a node to register the metrics included in WG =0A= draft. That will permit interoperability verification during the =0A= standardization process. =0A= =0A= The registry includes a node to register the metrics included in ID =0A= draft. That will permit easy software integration of specific metrics. = =0A= =0A= The implicit registration framework avoid to wait for the registry set = =0A= up. =0A= =0A= 5.1. registry framework =0A= =0A= The structure of the registry has three branches. The node rfc(1) =0A= registers the identifiers of metrics specified in a RFC. The node =0A= draft(2) registers the identifiers of metrics specified in a IPPM WG = =0A= draft. The node id(3) registers the identifiers of metrics specified in = =0A= an I-D draft. =0A= =0A= The location of the memo fixes the node of the metric (rfc, draft or = =0A= id). An identification rule determines the sub identifier of each = metric =0A= in this node. =0A= =0A= =0A= 5.2. IPPM RFC =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 11] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= Metrics specified in a WG RFC are registered in the node rfc(1). =0A= =0A= 5.2.1. Identification rules =0A= =0A= The chronological order of standardization of the metrics in the IPPM = WG =0A= determines each metric sub identifier. =0A= =0A= The RFC number determines the chronological order of the RFCs. =0A= =0A= There are several metrics defined in a document. The sequential order = of =0A= the metrics definitions is considered as the chronological order. =0A= =0A= 5.2.2. Integration of a new WG RFC =0A= =0A= As metric specification is a continuous process this memo defines a =0A= framework for the integration of the new RFCs. =0A= =0A= The metrics defined in a new IPPM RFC are registered using the rules = =0A= defined in the section named " Identification rules " and a new version = =0A= of the registry is published. =0A= =0A= 5.2.3. Implicit integration of metrics defined in a new WG RFC =0A= =0A= When a new RFC appears the identifiers of the corresponding metrics = may =0A= be determined by the rules defined in the section named " = Identification =0A= rules" without waiting the new version of the registry to be published. = =0A= =0A= 5.3. IPPM draft =0A= =0A= Metrics specified in an IPPM draft are registered in the node draft(2). = =0A= =0A= 5.3.1. Identification rules =0A= =0A= The chronological order of the draft is the order of the memos in the = =0A= internet draft list. There are several metrics defined in a document. = =0A= The sequential order of the metrics definitions is considered as the = =0A= chronological order. =0A= =0A= 5.3.2. Integration of new WG drafts =0A= =0A= Generally metrics are implemented during the specification process. At = =0A= this step the metric is not identified as an IPPM metric. There is a = =0A= need to provide temporary metrics identifiers to facilitate software = =0A= integration and to permit interoperability measurement among different = =0A= implementations. Otherwise implementers will choose arbitrary =0A= identifiers and interoperability verification will be impossible. =0A= =0A= 5.4. I-D draft =0A= =0A= Metrics specified in a I-D draft that concern IPPM WG may be associated = =0A= with temporary identifier in the subtree id(3). =0A= =0A= Stephan Informational - Expires August 2002 [Page 12] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= 6. IPPM-MIB conceptual presentation =0A= =0A= 6.1. IPPM-MIB diagram =0A= =0A= Conceptual view of objects configured using the IPPM-MIB. =0A= =0A= +--------------------------------------------------------+ = =0A= | IPPM-MIB entity | =0A= | | =0A= | +---------------------+ +-------------------+ | =0A= | | | | | | =0A= | | Measure scheduler | | Result storage | | =0A= | | | | | | =0A= | | ^ | | ^ ^^^ | | =0A= | | | | | | ||| | | =0A= | | | | | | ||| | | =0A= | +----------|----------+ +-|---|||-----------+ | =0A= | | | ||| | =0A= | +----------|--------------|---|||-----------+ | =0A= | | | owner | ||| | | =0A= | | | Acces | ||| | | =0A= | | | Control | ||| | | =0A= | | | | ||| | | =0A= | +----------|--------------|---|||-----------+ | =0A= | | | ||| | =0A= +------------------|--------------|---|||----------------+ =0A= | | ||| =0A= | | ||| =0A= +----------------+ | +----------+-+ ||| +-------------+ =0A= | ControlMeasure | | | GetResult | ||| | CreateResult| =0A= |----------------+-+ |------------| ||+--+-------------| =0A= | | | | || | | =0A= | owner | | owner | || | owner | =0A= | privateNdx | | privateNdx | || | privateNdx | =0A= | metrics | | metric | || | metrics | =0A= | scheduler | | timestamp | || | timestamp | =0A= | addresses | +------------+ || | value | =0A= | status | || +-------------+ =0A= +----------------+ || =0A= || =0A= +---------------------------+| =0A= | | =0A= +---------+---------+ +------+-----------------+ =0A= |GetMeasureResults | |GetMeasureMetricResults | =0A= |-------------------| |------------------------| =0A= | | | | =0A= | owner | | owner | =0A= | privateNdx | | privateNdx | =0A= +-------------------+ | metric | =0A= +------------------------+ =0A= =0A= Stephan Informational - Expires August 2002 [Page 13] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= The managed objects of the IPPM-MIB are the measures and the = results. =0A= =0A= =0A= 6.2. conceptual programming interface =0A= =0A= This section describes a conceptual programming interface for the = =0A= integration of the IPPM-MIB in a point of measure. =0A= =0A= 6.2.1. Measure control =0A= =0A= A measure is created/deleted/suspended through the ControlMeasure() = =0A= call. =0A= =0A= 6.2.2. Result log =0A= =0A= A result of a measure is created in the IPPM-MIB History table using = =0A= a CreateResult() call. Results belong to a measure and are managed = =0A= according to the setup of the measure. =0A= =0A= 6.2.3. reporting =0A= =0A= Results are reported using the method GetResult(), =0A= GetMeasureMetricResults() and GetMeasureResults() respectively to = get =0A= a singleton result, the singletons result of a metric measure and = =0A= finally to get the singletons result of a measure. = =0A= =0A= 6.2.4. logical calls =0A= =0A= Objects are managed using 5 main primitives: =0A= =0A= controlMeasure(); =0A= CreateResult(); =0A= GetResult(); =0A= GetMeasureMetricResults(); =0A= GetMeasureResults(). =0A= =0A= 6.3. SNMP mapping =0A= =0A= ControlMeasure() corresponds to a SNMP set-request on a conceptual = =0A= row of ippmMeasureEntry and on a conceptual row =0A= ippmNetworkMeasureEntry. =0A= =0A= CreateResult() is a internal interface for adding measure results in = =0A= the ippmHistoryTable. =0A= =0A= GetResult() corresponds to a SNMP get-request on a result. =0A= =0A= GetMeasureMetricResults() corresponds to a SNMP walk on the results = =0A= of a metric measure subtree. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 14] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= GetMeasureResults() corresponds to a SNMP walk on the results of a = =0A= measure subtree. =0A= =0A= =0A= 7. measurement architectures =0A= =0A= There are four main measurement architectures. =0A= =0A= 7.1. Proxy architecture =0A= =0A= =0A= +----+ +----+ =0A= |NMS1| |NMS2| =0A= +----+ +----+ =0A= ^ ^ =0A= | | =0A= +----------+ +----------+ =0A= | | =0A= SNMP or Sibling =0A= | | =0A= v v =0A= +----------------+ =0A= |IPPM-MIB entity | =0A= +----------------+ =0A= ^ ^ =0A= | | =0A= OWDP-Control =0A= | | =0A= +----------+ +----------+ =0A= | | =0A= v v =0A= +----------------+ +------------------+ =0A= | Packets-Sender |--OWDP-Test-->| Packets-Receiver | =0A= +----------------+ +------------------+ =0A= =0A= In this architecture the different NMS access the IPPM-MIB entity to = =0A= query for measurements. The IPPM-MIB controls that the NMS is = granted =0A= to perform the measure asked. Each NMS access the results of its =0A= measurements in the IPPM-MIB statistics table. =0A= =0A= The measurements setup/teardown and the data collection are done =0A= using the control protocol and the test protocol. =0A= =0A= In this mode the NMS does not depend nor on the control protocol nor = =0A= on the test protocol. The entities involved in the measure do not = =0A= need to implement the IPPM-MIB nor SNMP. This mode permits =0A= lightweight implementation in the point of measures and = heterogeneous =0A= control protocols to coexist. =0A= =0A= Finally the proxy is a check point where measure activity may be = =0A= logged and where access to measure setups may be controlled finely. = =0A= =0A= Stephan Informational - Expires August 2002 [Page 15] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= That provide a reliable architecture to manage the security of a =0A= measurement system. =0A= =0A= =0A= 7.2. probe architecture =0A= =0A= =0A= In this architecture the IPPM-MIB is implemented directly in each = =0A= point of measure. =0A= =0A= =0A= =0A= +----+ +----+ =0A= |NMS1| |NMS2| =0A= +----+ +----+ =0A= ^ ^ =0A= | | =0A= | | =0A= SNMP SNMP =0A= | | =0A= | +------------------------+ =0A= | | | =0A= +------------------------+ | =0A= | | | | =0A= | | | | =0A= | | | | =0A= v v v v =0A= +----------------+ +------------------+ =0A= |IPPM-MIB entity | |IPPM-MIB entity | =0A= +----------------+ +------------------+ =0A= | Packets-Sender |--OWDP-Test-->| Packets-Receiver | =0A= +----------------+ +------------------+ =0A= =0A= =0A= =0A= The measurements setup/teardown are done directly using the SNMP =0A= protocol. Each NMS access directly the results of the measurement in = =0A= the IPPM-MIB history group. =0A= =0A= Each IPPM-MIB controls that the NMS is granted to perform the = measure =0A= asked. =0A= =0A= In this mode there is no need for a control protocol while the =0A= implementation of the IPPM-MIB and SNMP increases the complexity of = =0A= the point of measure. =0A= =0A= It increases the complexity of the probes management because the =0A= network manager has to configure all the probes each time there is a = =0A= modification in the system of measurement. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 16] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= 7.3. Reporting architecture =0A= =0A= In this architecture the protocol SNMP is only used to read the =0A= results of the measures in the IPPM-MIB History Table and to inform = =0A= the NMS that an event has occurs. =0A= =0A= =0A= =0A= +----+ +----+ =0A= |NMS1| |NMS2| = =0A= +----+ +----+ =0A= ^ ^ ^ ^ =0A= | | | | =0A= SNMP| SNMP| =0A= | | | | =0A= | | | | =0A= | OWDP | OWDP =0A= |Control |Control =0A= | | | | =0A= | | +------------------------------+ =0A= | | | | | =0A= | | +--|---------------------------+ | =0A= | | | | | | =0A= | +--|--|------------------------+ | | =0A= | | | | | | | =0A= +--------+---------------------+ | | =0A= | | | | | | | | =0A= | | | | | | | | =0A= v v v v v v v v =0A= +------------------+ +------------------+ =0A= |IPPM-MIB reporting| |IPPM-MIB reporting| =0A= | entity | | entity | =0A= +------------------+ +------------------+ =0A= | Packets-Sender |--OWDP-Test-->| Packets-Receiver | =0A= +------------------+ +------------------+ =0A= =0A= =0A= The activation of a measure by the control protocol or the test = protocol =0A= creates a measure in the IPPM-MIB Measure table. That table may be not = =0A= accessible by SNMP. In this case a list of the measures identifiers =0A= (owner,index) is handled by the measure software. =0A= =0A= Each timestamped result of the measure is logged on the fly in the = IPPM-=0A= MIB History table to permit read access to the NMSs and event handling. = =0A= =0A= On completion the measure results are managed according the measure =0A= setup: =0A= The results may be sent to a NMS entity using a SNMP Trap Pdu = or =0A= a SNMP Inform PDU. The NMS may be the sender entity or the control =0A= entity; =0A= They may be dropped from the IPPM-MIB History table. =0A= =0A= Stephan Informational - Expires August 2002 [Page 17] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= In this mode it is recommended to use a SNMPv2 Inform PDU to send the = =0A= result because it controls that the block of result is received. There = =0A= is no control using SNMP Trap PDU. =0A= =0A= In this mode it is recommended to implement the IPPM-MIB Measure table = =0A= in read only to permit NMS to read the status of their measures. =0A= =0A= 7.4. gateway architecture =0A= =0A= The gateway architecture combines the proxy mode and the reporting = mode. =0A= =0A= +-------+ +------+ =0A= | NMS1 | | NMS2 | =0A= +-------+ +------+ =0A= ^ ^ = =0A= | | =0A= SNMP SNMP =0A= | | =0A= | +----------------------------------------+ =0A= | | | =0A= +-------------+ +------------------+ =0A= | | | | | =0A= +----------------------------------------+ | =0A= | | | | | | =0A= | | v v | | =0A= | | +---------------------+ | | =0A= | | | IPPM-MIB scheduler | | | =0A= | | | entity | | | =0A= | | +---------------------+ | | =0A= | | | control server | | | =0A= | | +---------------------+ | | =0A= | | ^ ^ | | =0A= | | | | | | =0A= | | OWDP-Control protocol | | =0A= | | | | | | =0A= | | +-----+ +-------+ | | =0A= | | | | | | =0A= v v v v v v =0A= +---------+---------+ +----------+---------+ =0A= |IPPM-MIB | Packets | | Packets |IPPM-MIB | =0A= |reporting| Sender | | Receiver |reporting| =0A= | entity | |--OWDP-Test-->| | entity | =0A= +---------+---------+ +----------+---------+ =0A= =0A= =0A= The NMS measurement queries are registered in the IPPM-MIB scheduler = and =0A= performed by the control and the test protocol. NMS consult directly = the =0A= result in the corresponding points of measure. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 18] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= 7.5. Security =0A= =0A= The proxy mode provides flexibility and a fine control of the access = =0A= to the points of measure while permitting lightweight control =0A= protocol and test protocol implementations in the points of measure. = =0A= Different security rules may be applied to the NMS domain and to =0A= measurement system domain. =0A= =0A= The probe mode security relies on SNMP security. SNMP provides =0A= different levels of security according to the version used and to = the =0A= option chosen. SNMPv3 provides a high level of security. =0A= =0A= The reporting mode has 2 security domains. The control of the =0A= measures setup relies on the control and the test protocol security = =0A= mechanisms. The control of the access to the result depends on the = =0A= SNMP security mechanisms. =0A= =0A= The gateway mode security relies on the security of the proxy mode = =0A= and of the reporting mode. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 19] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= 8. Reporting mode integration with the control and test protocols =0A= =0A= The IPPM-MIB standardizes the parameters for configuring IPPM metrics = =0A= measures and for reporting the results. It introduces the concept of = =0A= owner namespace to permit fast configuration and reporting across =0A= multiple points of measures. =0A= =0A= A measure is a distributed object describing a task to be performed by = =0A= the control and the test protocols. An measure is identified by its =0A= owner and its owner index. This identifier is the same in all the = points =0A= of measure. As it is chosen by the owner there is no need for =0A= negotiation between the NMS and the points of measure before activating = =0A= the measure. =0A= =0A= A measure is mainly defined by its identifier, the metrics to measure, = =0A= the description of the end points addresses and the description of the = =0A= scheduling of the measure. =0A= =0A= The description of the measure is distributed to the points of measure = =0A= involved. The distribution may not be synchronized. =0A= =0A= 8.1. Integration =0A= =0A= Control protocol, test protocol and the IPPM-MIB share the same =0A= semantic. The parameters used are sibling. =0A= =0A= The integration of the IPPM-MIB, the test and control protocols relies = =0A= on the use of the conceptual programming interface described in the =0A= section 6. It consists basically in pushing the measure setup/teardown = =0A= parameters and the results values from the measure software to the = IPPM-=0A= MIB. =0A= =0A= 8.2. Setup of the measure =0A= =0A= The creation of the measure consists only in transferring the measure = =0A= description from the measurement software to the MIB. The management of = =0A= the measure is done using the ControlMeasure(). The protocol which =0A= provide the parameters of the measure to manage may be the control =0A= protocol of the test protocol. =0A= =0A= Different framework may be used to setup a measure. =0A= =0A= 8.2.1. synchronous setup =0A= =0A= The control protocol setups the measure both in the sender and the =0A= receiver before the measure. =0A= =0A= 8.2.2. asynchronous setup =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 20] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= The control protocol setups the measure only in the sender. In this = case =0A= the receiver has a service already activated (or pending )for the typeP = =0A= of the measure. =0A= =0A= As the first test packet includes the description of the measure it may = =0A= differ from regular test packets. If the first test packet is not =0A= consistent with the regular test packets is must not be used for =0A= performing metrics measures. =0A= =0A= 8.3. Setup of the report of a measure =0A= =0A= The report description is an extension to the definition of a measure. = =0A= It describes the event and the data to include in the report. A report = =0A= is read by a NMS in the ippmReportTable, or pushed to a NMS using a = SNMP =0A= Trap PDU, a SNMP Inform PDU, an email or a SMS. =0A= =0A= The control protocol or the test protocol includes the description of = =0A= the report in the setup of the measure. =0A= =0A= Different types of reports may be combined: =0A= =0A= + A trivial report defines the results to be saved in the =0A= ippmReportTable; =0A= + A basic report defines the host to which the results are =0A= pushed on completion of the measure; =0A= + An alarm report defines a threshold on the results of the =0A= measure. A message is sent to a host when the result raise or fall the = =0A= threshold; =0A= + An SLA report defines a threshold on the results of the =0A= measure. The events are filtered using a staircase method. The report = =0A= consists in the results of the measure (time and value) of the filtered = =0A= events. The reports is sent at each measure cycle or when the measure = =0A= completes. =0A= =0A= 8.4. writing the measure results in the IPPM-MIB =0A= =0A= Results have to be pushed from the measure task to the MIB. =0A= =0A= Adding result of a measure consists only in transferring the result = from =0A= the measurement software to the MIB. The protocol which provides the = =0A= result may be the control protocol or the test protocol. =0A= =0A= Writing a result is done using the CreateResult(). =0A= =0A= 8.5. report download and upload =0A= =0A= A report is read in the ippmReportTable using SNMP, or pushed by the = =0A= IPPM_MIB agent using a SNMP Trap PDU, a SNMP Inform PDU, an email or a = =0A= SMS. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 21] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= 8.6. Default value =0A= =0A= The default values correspond to Ipv4 best effort. =0A= =0A= 9. Definition =0A= =0A= IPPM-MIB DEFINITIONS ::=3D BEGIN =0A= =0A= IMPORTS =0A= MODULE-IDENTITY, =0A= NOTIFICATION-TYPE, =0A= OBJECT-TYPE, =0A= Integer32, =0A= Counter32, =0A= experimental =0A= FROM SNMPv2-SMI =0A= OwnerString =0A= FROM RMON-MIB =0A= protocolDir =0A= FROM RMON2-MIB =0A= DisplayString, =0A= TimeStamp, =0A= DateAndTime, =0A= TruthValue, =0A= RowStatus, =0A= StorageType, =0A= TEXTUAL-CONVENTION =0A= FROM SNMPv2-TC =0A= MODULE-COMPLIANCE, =0A= OBJECT-GROUP, =0A= NOTIFICATION-GROUP =0A= FROM SNMPv2-CONF; =0A= =0A= =0A= ippmMib MODULE-IDENTITY =0A= LAST-UPDATED "200202011200Z" -- Feb 1, 2002 =0A= ORGANIZATION "France Telecom - R&D" =0A= CONTACT-INFO =0A= "Postal : Emile Stephan =0A= France Telecom - R&D, Dpt. CPN =0A= 2, Avenue Pierre Marzin =0A= Technopole Anticipa =0A= 22307 Lannion Cedex =0A= FRANCE =0A= Tel: + 33 2 96 05 36 10 =0A= E-mail: emile.stephan@francetelecom.com" =0A= DESCRIPTION =0A= " This memo defines a portion of the Management Information Base =0A= (MIB) for use with network management protocols in TCP/IP-based =0A= internets. In particular, It defines a registry of the IPPM working = =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 22] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= group metrics and specifies the objects used for managing IPPM =0A= metrics measures, pushing alarms and reporting the measures results. = =0A= " =0A= REVISION "200107051500Z" -- July 2001 =0A= DESCRIPTION =0A= "The creation of the IPPM-MIB corresponds to the draft-=0A= stephan-ippm-mib-00.txt posted in July 2001. The IPPM-MIB was =0A= partially presented during the IPPM WG meeting of London. =0A= =0A= Two main issues were identified during the 52 th IETF meetings in = =0A= SLC: =0A= =0A= + There is a need for a common IPPM metric registry; =0A= + There is a short term need for the reporting part of the = IPPM-=0A= MIB; =0A= " =0A= REVISION "200201051500Z" -- Jan 2002 =0A= DESCRIPTION =0A= "This release corresponds to draft-stephan-ippm-mib-01.txt = =0A= posted in January 2002. This draft added sections which =0A= presents: =0A= =0A= + The different measurement architectures; =0A= + The integration of the IPPM-MIB in a measurement software; = =0A= + The use of the IPPM-MIB for reporting. =0A= =0A= The new items created in this release are: =0A= =0A= + Fields in the ippmOwnersTable to control the access of an = =0A= owner to the measures. =0A= + The table ippmResultSharingTable to manage the access of = an =0A= owner to the results of the measure. =0A= =0A= All the control tables are optional or read only in = reporting =0A= mode. =0A= " =0A= REVISION "200202011200Z" -- Feb 2002 =0A= DESCRIPTION =0A= "The current release corresponds to = draft-stephan-ippm-mib-=0A= 02.txt posted in February 2002. It added a section to present the = =0A= IPPM metrics registry. =0A= =0A= The new items created in this release are: =0A= =0A= + TC IppmReportDefinition and IppmStandardMetrics; =0A= + The registry of the IPPM metrics; =0A= + The ippmReportSetupTable and the ippmReportTable; =0A= + The notification tree. =0A= " =0A= =0A= -- =0A= =0A= Stephan Informational - Expires August 2002 [Page 23] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= -- to be assigned by IANA =0A= -- =0A= ::=3D { experimental 10000 } =0A= =0A= -- =0A= -- registry =0A= -- =0A= =0A= metrics OBJECT IDENTIFIER ::=3D { ippmMib 1 } =0A= =0A= rfc OBJECT IDENTIFIER ::=3D { metrics 1 } =0A= draft OBJECT IDENTIFIER ::=3D { metrics 2 } =0A= id OBJECT IDENTIFIER ::=3D { metrics 3 } =0A= =0A= -- =0A= -- metrics registry from RFC of the IPPM WG =0A= -- =0A= =0A= =0A= instantaneousUnidirectionalConnectivity OBJECT IDENTIFIER::=3D{rfc = 1} =0A= instantaneousBidirectionalConnectivity OBJECT IDENTIFIER ::=3D{rfc = 2} =0A= intervalUnidirectionalConnectivity OBJECT IDENTIFIER ::=3D { rfc 3 } = =0A= intervalBidirectionalConnectivity OBJECT IDENTIFIER ::=3D { rfc 4 } = =0A= intervalTemporalConnectivity OBJECT IDENTIFIER ::=3D { rfc 5 } = =0A= onewayDelay OBJECT IDENTIFIER ::=3D { rfc 6 } = =0A= onewayDelayPoissonStream OBJECT IDENTIFIER ::=3D { rfc 7 } = =0A= onewayDelayPercentile OBJECT IDENTIFIER ::=3D { rfc 8 } = =0A= onewayDelayMedian OBJECT IDENTIFIER ::=3D { rfc 9 } = =0A= onewayDelayMinimum OBJECT IDENTIFIER ::=3D { rfc 10 } = =0A= onewayDelayInversePercentile OBJECT IDENTIFIER ::=3D { rfc 11 } = =0A= onewayPacketLoss OBJECT IDENTIFIER ::=3D { rfc 12 } = =0A= onewayPacketLossPoissonStream OBJECT IDENTIFIER ::=3D { rfc 13 } = =0A= onewayPacketLossAverage OBJECT IDENTIFIER ::=3D { rfc 14 } = =0A= roundtripDelay OBJECT IDENTIFIER ::=3D { rfc 15 } = =0A= roundtripDelayPoissonStream OBJECT IDENTIFIER ::=3D { rfc 16 } = =0A= roundtripDelayPercentile OBJECT IDENTIFIER ::=3D { rfc 17 } = =0A= roundtripDelayMedian OBJECT IDENTIFIER ::=3D { rfc 18 } = =0A= roundtripDelayMinimum OBJECT IDENTIFIER ::=3D { rfc 19 } = =0A= roundtripDelayInversePercentile OBJECT IDENTIFIER ::=3D { rfc 20 } = =0A= =0A= -- =0A= -- metrics registry from draft of the IPPM WG =0A= -- =0A= =0A= -- =0A= -- metrics registry from individual draft =0A= -- =0A= =0A= -- =0A= -- TEXTUAL-CONVENTION =0A= -- =0A= =0A= Stephan Informational - Expires August 2002 [Page 24] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= =0A= TimeUnit ::=3D TEXTUAL-CONVENTION =0A= STATUS current =0A= DESCRIPTION =0A= "A list of time units." =0A= SYNTAX INTEGER { =0A= year(1), =0A= month(2), =0A= week(3), =0A= day(4), =0A= hour(5), =0A= second(6), =0A= ms(7), =0A= us(8), =0A= ns(9) =0A= } =0A= -- =0A= -- =0A= -- A absolute, GMT timer using UTC like convention. =0A= -- =0A= -- =0A= =0A= GMTDateAndTime ::=3D TEXTUAL-CONVENTION =0A= DISPLAY-HINT "1d-1d-1d,1d:1d:1d,2d" =0A= STATUS current =0A= DESCRIPTION =0A= "A date-time specification. =0A= =0A= field octets contents range =0A= ----- ------ -------- ----- =0A= 1 1 year* 0..255 =0A= 2 2 month 1..12 =0A= 3 3 day 1..31 =0A= 4 4 hour 0..23 =0A= 5 5 minutes 0..59 =0A= 6 6 seconds 0..59 =0A= 7 7-8 1/10 milliseconds 0..9999 =0A= =0A= *Notes: 0 stands for year 2000. =0A= =0A= For example, '0102192015100500' represent 8:15pm, 10 = =0A= seconds and 50 ms GMT on 19 February 2001 and is =0A= displayed as 01-02-19,20:15:10,0500" =0A= SYNTAX OCTET STRING (SIZE (8)) =0A= =0A= =0A= =0A= GmtTimeFilter ::=3D TEXTUAL-CONVENTION =0A= STATUS current =0A= DESCRIPTION =0A= =0A= Stephan Informational - Expires August 2002 [Page 25] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= "GmtTimeFilter TC is inspired by the TimeFilter defined = =0A= in the RMON2. The reference of the time of TimeFilter = is =0A= the local value of sysUptime while GmtTimeFilter uses a = =0A= absolute reference of time. =0A= =0A= GmtTimeFilter is intended to be used for the index of a = =0A= table. It allows an application to download only those = =0A= rows changed since a particular time. A row is =0A= considered changed if the value of any object in the = row =0A= changes or if the row is created or deleted. =0A= =0A= Each new conceptual row will be associated with the =0A= timeMark instance which was created at the value of =0A= ippmTimeSysTimer. =0A= =0A= It is intended to provide an absolute timestamp index = =0A= for the result of measures. Typically to each singleton = =0A= produced by an IPPM measure is associated the timemark = =0A= corresponding to the moment of the measure. =0A= =0A= illustrations: =0A= =0A= Consider the 2 tables measureTable and resultTable =0A= =0A= measureTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF MeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION '' =0A= ::=3D { fooMib 1 } =0A= INDEX { measureIndex } =0A= =0A= resultTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF ResultEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION '' =0A= ::=3D { fooMib 2 } =0A= INDEX { measureIndex, resultTimeMark } =0A= =0A= ResultEntry { =0A= resultTimeMark TimeFilter, =0A= resultCounts Counter =0A= } =0A= =0A= Should there be two measure rows in the measure table = =0A= (measureIndex =3D=3D 1, measureIndex =3D=3D 2) which = produced =0A= results asynchronously (e.g. made at Poisson intervals = =0A= or sibling) and log them in the result table. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 26] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= Measure 1 produced the result 34 at time =0A= 0102192015100500 GMT, while row 2 produced the value 54 = =0A= most recently (10ms later) at time 0102192015100600 = GMT, =0A= and both rows are updated on several later occasions = =0A= such that the current values are 37 and 53 = respectively. =0A= =0A= Then the following resultCounts instances would exist. = =0A= =0A= resultCounts.1.0102192015100500 34 =0A= resultCounts.2.0102192015100600 54 =0A= resultCounts.1.0102192015100950 65 =0A= resultCounts.1.0102192015100600 57 =0A= resultCounts.2.0102192015100800 48 =0A= resultCounts.2.0102192015100850 53 =0A= resultCounts.1.0102192015110050 49 =0A= resultCounts.1.0102192015110200 37 =0A= =0A= The following get-bulk explains how a NMS retrieves the = =0A= results of the measures. =0A= =0A= get-bulk(nonRptrs=3D1, maxReps=3D10, resultCounts.1); = =0A= returns: =0A= resultCounts.1.0102192015100500 =3D=3D 34 =0A= resultCounts.1.0102192015100950 =3D=3D 65 =0A= resultCounts.1.0102192015100600 =3D=3D 57 =0A= resultCounts.1.0102192015110050 =3D=3D 49 =0A= resultCounts.1.0102192015110200 =3D=3D 37 =0A= # return lexigraphically-next two MIB instances = =0A= =0A= get-bulk(nonRptrs=3D0, maxReps=3D2, =0A= resultCounts.1.0102192015100600, =0A= resultCounts.2.0102192015100600); =0A= returns: =0A= resultCounts.1.0102192015100950 =3D=3D 65 =0A= resultCounts.2.0102192015100800 =3D=3D 48 =0A= resultCounts.1.0102192015100600 =3D=3D 57 =0A= resultCounts.2.0102192015100850 =3D=3D 53 =0A= =0A= =0A= get-bulk(nonRptrs=3D0, maxReps=3D2, =0A= resultCounts.1.0102192015110200, =0A= resultCounts.2.0102192015110200); =0A= returns: =0A= return lexigraphically-next two MIB instances = =0A= no 'resultTable' counter values at all are =0A= returned because neither counter has been updated since = =0A= time 0102192015110200 =0A= " =0A= SYNTAX GMTDateAndTime =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 27] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= TypeP ::=3D TEXTUAL-CONVENTION =0A= DISPLAY-HINT "1d." =0A= STATUS current =0A= DESCRIPTION =0A= "This textual convention is used to describe the =0A= protocols encapsulation list of a packet, and is used = as =0A= the value of the SYNTAX clause for the type of the Src = =0A= and Dst of a IPPM measure. The RFC2895 specifies a = macro =0A= for the definition of protocols identifiers while its = =0A= companion document, the RFC2896 defines a set of =0A= protocols identifiers. =0A= =0A= Notes: An IPPM TypeP does not differ from RMON2 =0A= Protocols identifiers but TypeP usage in IPPM MIB =0A= differs from Protocol identifier usage in RMON2. A IPPM = =0A= measure is active so generally TypeP does not describe = =0A= the link layer (i.e. ether2...). Valid Internet packets = =0A= are sent from Src to Dst. Then the choice of the link = =0A= layer relies on the Internet stack. =0A= =0A= For example, the RFC2896 defines the protocol = identifier =0A= '16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' which =0A= represents ether2.ip.tcp.telnet and the protocol =0A= identifier 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 = =0A= which stands for ether2.ip.ipip4.udp. The corresponding = =0A= TypeP are '12.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' =0A= (ip.tcp.telnet) and 12.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0 = =0A= (ip.ipip4.udp)." =0A= SYNTAX OCTET STRING =0A= =0A= =0A= IppmReportDefinition ::=3D TEXTUAL-CONVENTION =0A= STATUS current =0A= DESCRIPTION =0A= "IppmReportDefinition is intended to be used for the = description =0A= of a report of results of a measure. =0A= =0A= By default all the results of a measure belong to the report of = =0A= this measure. =0A= =0A= The first step of the report elaboration set up triggers on the = =0A= value of the measure and on the distribution over time of the events = =0A= generated by these triggers. =0A= =0A= The measure results corresponding to an event are reported =0A= periodically or sent in alarms as soon as the event appears. =0A= =0A= The end of description describe housekeeping tasks. =0A= =0A= An action if performed if the corresponding bit is set to 1. = =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 28] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= onSingleton(1): =0A= The actions are performed each time a new result of the = =0A= measure occurs. =0A= =0A= onMeasureCycle(2): =0A= The actions are performed on the results of the measure = =0A= at the end of each cycle of measure. =0A= =0A= onMeasureCompletion(3): =0A= The actions are performed on the results of the measure = =0A= at the end of the measure. =0A= =0A= reportOnlyUptoDownMetricResults(4): =0A= Report the contiguous results which are on opposite = sides =0A= of the metric threshold. =0A= =0A= reportOnlyExceededEventsDuration(5): =0A= Report the current result of a serie of contiguous =0A= results which exceed the metric threshold when the =0A= duration of the serie is over the events duration =0A= threshold seconds. =0A= =0A= inIppmReportTable(6): =0A= store the report in the local ippmReportTable. =0A= =0A= inSNMPTrapPDU(7): =0A= Send the report using a SNMP-Trap-PDU. =0A= =0A= inSNMPv2TrapPDU(8): =0A= Send the report using a SNMPv2-Trap-PDU. =0A= =0A= inInformRequestPDU(9): =0A= Send the report using a SNMP InformRequest-PDU. =0A= =0A= inEmail(10): =0A= Send the report using an email. =0A= =0A= inSMS(11): =0A= Send the report using a SMS. =0A= =0A= clearHistory(12): =0A= Remove all the results corresponding to this measure =0A= from the ippmHistoryTable. =0A= =0A= clearReport(13): =0A= Remove all the results corresponding to this measure =0A= from the ippmReportTable. =0A= " =0A= =0A= SYNTAX BITS { =0A= none(0), -- reserved =0A= =0A= Stephan Informational - Expires August 2002 [Page 29] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= onSingleton(1), =0A= onMeasureCycle(2), =0A= onMeasureCompletion(3), =0A= reportOnlyUptoDownMetricResults(4), =0A= reportOnlyExceededEventsDuration(5), =0A= inIppmReportTable(6), =0A= inSNMPTrapPDU(7), =0A= inSNMPv2TrapPDU(8), =0A= inInformRequestPDU(9), =0A= inEmail(10), =0A= inSMS(11), =0A= clearHistory(12), =0A= clearReport(13) =0A= } =0A= =0A= =0A= =0A= IppmStandardMetrics ::=3D TEXTUAL-CONVENTION =0A= STATUS current =0A= DESCRIPTION =0A= "The definition of the standardized IPPM metrics. =0A= if the draftMetrics bit is set then the other bits describe a = WG =0A= draft metric identifiers. =0A= " =0A= SYNTAX BITS { =0A= draftMetrics(0), =0A= instantaneousUnidirectionalConnectivity(1), =0A= instantaneousBidirectionalConnectivity(2), =0A= intervalUnidirectionalConnectivity(3), =0A= intervalBidirectionalConnectivity(4), =0A= intervalTemporalConnectivity(5), =0A= onewayDelay(6), =0A= onewayDelayPoissonStream(7), =0A= onewayDelayPercentile(8), =0A= onewayDelayMedian(9), =0A= onewayDelayMinimum(10), =0A= onewayDelayInversePercentile(11), =0A= onewayPacketLoss(12), =0A= onewayPacketLossPoissonStream(13), =0A= onewayPacketLossAverage(14), =0A= roundtripDelay(15), =0A= roundtripDelayPoissonStream(16), =0A= roundtripDelayPercentile(17), =0A= roundtripDelayMedian(18), =0A= roundtripDelayMinimum(19), =0A= roundtripDelayInversePercentile(20) =0A= } =0A= -- IPPM Mib objects definitions =0A= =0A= ippmCompliances OBJECT IDENTIFIER ::=3D { ippmMib 2 } =0A= ippmOwnersGroup OBJECT IDENTIFIER ::=3D { ippmMib 3 } =0A= =0A= Stephan Informational - Expires August 2002 [Page 30] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmSystemGroup OBJECT IDENTIFIER ::=3D { ippmMib 4 } =0A= ippmMeasureGroup OBJECT IDENTIFIER ::=3D { ippmMib 5 } =0A= ippmHistoryGroup OBJECT IDENTIFIER ::=3D { ippmMib 6 } =0A= ippmNetworkMeasureGroup OBJECT IDENTIFIER ::=3D { ippmMib 7 } = =0A= ippmAggregatedMeasureGroup OBJECT IDENTIFIER ::=3D { ippmMib 8 } = =0A= ippmReportGroup OBJECT IDENTIFIER ::=3D { ippmMib 9 } = =0A= ippmNotifications OBJECT IDENTIFIER ::=3D { ippmMib 10 } = =0A= =0A= =0A= -- =0A= -- ippmOwnersGroup =0A= -- =0A= -- The ippmOwnersGroup objects are in charge of the management =0A= -- of the access of the owners to the measurements. =0A= -- =0A= -- =0A= ippmOwnersControlTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmOwnersControlEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "A NMS entity wishing to create and activate remote = Ippm =0A= measurements in an agent must previously be registered = =0A= in the ippmOwnersControlTable using the conceptual row = =0A= mechanism described in the RMON2. =0A= =0A= The control of the access to the results of the = measures =0A= is managed in the table ippmResultSharing. =0A= " =0A= ::=3D { ippmOwnersGroup 1 } =0A= =0A= ippmOwnersControlEntry OBJECT-TYPE =0A= SYNTAX IppmOwnersControlEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "The description of the resources the agent granted to = a =0A= SNMP application. =0A= =0A= For example, an instance of ippmOwnersControlOwner with = =0A= an OwnerString 'acme', which represents the 14th owner = =0A= created in ippmOwnersControlTable would be named =0A= ippmOwnersControlEntryOwner.14. =0A= =0A= Notes: =0A= =0A= The ippmOwnersControlIndex value is a local index =0A= managed directly by the agent. It is not used in anyway = =0A= in the other IPPM tables." =0A= =0A= INDEX { ippmOwnersControlIndex } =0A= =0A= Stephan Informational - Expires August 2002 [Page 31] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ::=3D { ippmOwnersControlTable 1 } =0A= =0A= IppmOwnersControlEntry ::=3D SEQUENCE { =0A= ippmOwnersControlOwner OwnerString, =0A= ippmOwnersControlIndex Integer32, =0A= ippmOwnersControlGrantedMetrics IppmStandardMetrics, =0A= ippmOwnersControlGrantedRules BITS, =0A= ippmOwnersControlIpAddress DisplayString, =0A= ippmOwnersControlEmail DisplayString, =0A= ippmOwnersControlSMS DisplayString, =0A= ippmOwnersControlStatus OwnerString =0A= } =0A= =0A= ippmOwnersControlIndex OBJECT-TYPE =0A= SYNTAX Integer32 (1.. 65535) =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "An arbitrary index that only identify an entry in this = =0A= table" =0A= ::=3D { ippmOwnersControlEntry 1 } =0A= =0A= ippmOwnersControlOwner OBJECT-TYPE =0A= SYNTAX OwnerString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The owner described by this entry." =0A= ::=3D { ippmOwnersControlEntry 2 } =0A= =0A= =0A= ippmOwnersControlGrantedMetrics OBJECT-TYPE =0A= SYNTAX IppmStandardMetrics =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= " Defines the metrics granted to an owner." =0A= ::=3D { ippmOwnersControlEntry 3 } =0A= =0A= ippmOwnersControlGrantedRules OBJECT-TYPE =0A= SYNTAX BITS { =0A= all(0), =0A= readonly(1), =0A= permanent(2), =0A= sender(2), =0A= receive(3), =0A= report(4), =0A= alarm(5) =0A= } =0A= MAX-ACCESS read-create =0A= STATUS current =0A= =0A= Stephan Informational - Expires August 2002 [Page 32] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= DESCRIPTION =0A= "Defines the rules this owner may act as in the current IPPM = MIB =0A= instance. =0A= all(0): =0A= The owner is granted with all the rules. =0A= readonly(1): =0A= The measures (not only the metrics) allowed to this =0A= owner are setup by the manager of the point of measure. The owner = can =0A= not add new measures for these metrics. The creation and the =0A= configuration of the measures corresponding to these metrics are =0A= managed by the manager of the point of measure. =0A= permanent(2): =0A= The measures (not only the metrics) allowed to this =0A= owner are determined by the manager of the point of measure. The =0A= owner can not add new measures for these metrics. The creation and = =0A= the first configuration of the measures corresponding to these =0A= metrics are managed by the manager of the point of measure. The = owner =0A= may modify the measures parameters of the entries of the =0A= corresponding ippmMeasureEntry which access is read-write. =0A= Typically that permits the owner to suspend the =0A= measures, to change the begin and end of the measures. =0A= =0A= sender(3): =0A= The owner may only activate measures for theses metrics = =0A= that send packets from the current point of measure. This flag is = =0A= only suitable for network measures. It shall be ignored for derived = =0A= metrics. =0A= receiver(2): =0A= The owner may only activate measures for theses metrics = =0A= that receive packets on the current point of measure. This flag is = =0A= only suitable for network measures. It shall be ignored for derived = =0A= metrics. Such control increases the security. The owner may not =0A= generate packets from the probe. =0A= =0A= report(4): =0A= The owner may setup aggregated metrics on the measures = =0A= corresponding to these metrics. =0A= =0A= alarm(5): =0A= The owner may setup alarms on the results of the =0A= measures metrics. =0A= =0A= =0A= e.g.: =0A= if the owner Acme is granted with the metric Instantaneous-=0A= Unidirectional-Connectivity as a Receiver in the current point of = =0A= measure, then Acme can not setup a Instantaneous-Unidirectional-=0A= Connectivity to another point of measure. =0A= " =0A= DEFVAL { 1 } =0A= ::=3D { ippmOwnersControlEntry 4 } =0A= =0A= Stephan Informational - Expires August 2002 [Page 33] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= ippmOwnersControlIpAddress OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The IP address of the NMS corresponding to this owner. = =0A= The address is human readable and is represented using the dot =0A= format." =0A= ::=3D { ippmOwnersControlEntry 5 } =0A= =0A= ippmOwnersControlEmail OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The email address of the NMS corresponding to this =0A= owner." =0A= ::=3D { ippmOwnersControlEntry 6 } =0A= =0A= ippmOwnersControlSMS OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The SMS phone number of the NMS corresponding to this = =0A= owner." =0A= ::=3D { ippmOwnersControlEntry 7 } =0A= =0A= ippmOwnersControlStatus OBJECT-TYPE =0A= SYNTAX RowStatus =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The status of this table entry." =0A= ::=3D { ippmOwnersControlEntry 8 } =0A= =0A= -- =0A= -- ippmResultSharingTable =0A= -- =0A= =0A= ippmResultSharingTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmResultSharingEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= " ippmResultSharingTable controls finely the access of = =0A= an owner to the measure results of other owners. An =0A= owner may grant another to read the result of its =0A= measure. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 34] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= Entries may exist in ippmResultSharingTable even is the = =0A= measures to be shared are not yet defined. Deleting a = =0A= measure entry in the ippmMeasureTable does not delete = =0A= the entries corresponding to this measure in the =0A= ippmResultSharingTable. =0A= =0A= IppmResultSharingTable is optional. If this table is = not =0A= implemented then the owner has only access to its =0A= measure results." =0A= =0A= ::=3D { ippmOwnersGroup 2 } =0A= =0A= ippmResultSharingEntry OBJECT-TYPE =0A= SYNTAX IppmResultSharingEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "An entry allows an owner to read the results of a =0A= measure owned by another owner. =0A= It permits 2 typical usages: =0A= creating derived measurements on these results; = =0A= reading the results from a remote NMS. =0A= =0A= Example: if acme.12 is a One-way-Delay(6) measure =0A= Acme may allows Peter to make derived metrics = =0A= On the results of this measure. =0A= " =0A= =0A= INDEX { ippmResultSharingOwner, ippmResultSharingIndex} =0A= ::=3D { ippmResultSharingTable 1 } =0A= =0A= =0A= IppmResultSharingEntry ::=3D SEQUENCE { =0A= ippmResultSharingOwner OwnerString, =0A= ippmResultSharingIndex Integer32, =0A= ippmResultSharingMeasureOwner OwnerString, =0A= ippmResultSharingMeasureIndex Integer32, =0A= ippmResultSharingGrantedOwner OwnerString, =0A= ippmResultSharingStatus RowStatus =0A= } =0A= ippmResultSharingOwner OBJECT-TYPE =0A= SYNTAX OwnerString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= " The owner of this result control entry. Typically the = =0A= owner which created this conceptual row." =0A= ::=3D { ippmResultSharingEntry 1 } =0A= =0A= =0A= ippmResultSharingIndex OBJECT-TYPE =0A= =0A= Stephan Informational - Expires August 2002 [Page 35] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= SYNTAX Integer32 (1.. 65535) =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= " The index of this result control entry. The value is = =0A= managed by the owner. On creation a SNMP error 'inconsistentValue' = is =0A= returned if this value is already in use by this owner." =0A= ::=3D { ippmResultSharingEntry 2 } =0A= =0A= =0A= ippmResultSharingMeasureOwner OBJECT-TYPE =0A= SYNTAX OwnerString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The owner of the measure to be shared. The couple =0A= ippmResultSharingMeasureOwner, ippmResultSharingMeasureIndex =0A= identifies absolutely a measure" =0A= ::=3D { ippmResultSharingEntry 3 } =0A= =0A= ippmResultSharingMeasureIndex OBJECT-TYPE =0A= SYNTAX Integer32 (1.. 65535) =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The index of the measure to be shared." =0A= ::=3D { ippmResultSharingEntry 4 } =0A= =0A= ippmResultSharingGrantedOwner OBJECT-TYPE =0A= SYNTAX OwnerString =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= =0A= "The owner which is granted to access to the result of = =0A= the measure described by the couple ippmResultSharingMeasureOwner, = =0A= ippmResultSharingMeasureIndex." =0A= ::=3D { ippmResultSharingEntry 5 } =0A= =0A= ippmResultSharingStatus OBJECT-TYPE =0A= SYNTAX RowStatus =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= " The status of this table entry. Once the entry status = =0A= is set to active." =0A= ::=3D { ippmResultSharingEntry 6 } =0A= =0A= =0A= -- =0A= -- ippmSystemGroup =0A= =0A= Stephan Informational - Expires August 2002 [Page 36] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= -- =0A= -- =0A= =0A= =0A= ippmSystemTimer OBJECT-TYPE =0A= SYNTAX GMTDateAndTime =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The current time of the system." =0A= ::=3D { ippmSystemGroup 1 } =0A= =0A= =0A= ippmSystemSynchonizationType OBJECT-TYPE =0A= SYNTAX INTEGER { =0A= other(0), =0A= ntp(1), =0A= gps(2), =0A= cdma(4) =0A= } =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "ippmSystemSynchonizationType describes the mechanism = =0A= used to synchronise the system. =0A= =0A= other =0A= The synchronisation process must be defined = =0A= extensively in the ippmSystemSynchonizationDescription. = =0A= =0A= ntp =0A= The system is synchronised using the network = =0A= time protocol. The NTP synchronisation must be = described =0A= finely in the ippmSystemSynchonizationDescription. =0A= =0A= gps =0A= The system is synchronised using the GPS clocks. = =0A= =0A= cdma =0A= The system is synchronised using the CDMA =0A= clocks. =0A= " =0A= ::=3D { ippmSystemGroup 2 } =0A= =0A= ippmSystemSynchonizationDescription OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The description of the synchronization process." =0A= ::=3D { ippmSystemGroup 3 } =0A= =0A= Stephan Informational - Expires August 2002 [Page 37] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= ippmSystemClockResolution OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "ippmSystemClockResolution provides the precision of = the =0A= clock used for the measures. The unit is 1/10 of =0A= millisecond. For example, the clock on an old Unix host = =0A= might advance only once every 10 msec, and thus have a = =0A= resolution of only 10 msec." =0A= =0A= ::=3D { ippmSystemGroup 4 } =0A= =0A= ippmSystemSynchronisationTime OBJECT-TYPE =0A= SYNTAX DateAndTime =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The time when occurs the last synchronisation of the = =0A= clock. The last synchronisation must be set even if the = =0A= synchronisation is not automatic." =0A= ::=3D { ippmSystemGroup 5 } =0A= =0A= ippmSystemClockAccuracy OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The most recent accuracy of the clock computed. The = =0A= accuracy must be compute even if the synchronisation is = =0A= not automatic." =0A= ::=3D { ippmSystemGroup 6 } =0A= =0A= ippmSystemClockSkew OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The most recent skew of the clock computed. The =0A= ippmSystemSkew must be compute even if the =0A= synchronisation is not automatic." =0A= ::=3D { ippmSystemGroup 7 } =0A= =0A= =0A= ippmSystemPrevClockAccuracy OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 38] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= "The previous accuracy of the clock measured. The =0A= ippmSystemPrevClockAccuracy must be computed even if = the =0A= synchronisation is not automatic." =0A= ::=3D { ippmSystemGroup 8 } =0A= =0A= ippmSystemPrevClockSkew OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The previous skew of the clock measured. The =0A= ippmSystemPrevClockSkew must be computed even if the = =0A= synchronisation is not automatic." =0A= ::=3D { ippmSystemGroup 9 } =0A= =0A= =0A= -- =0A= =0A= -- =0A= -- =0A= -- ippmMeasureGroup =0A= -- =0A= -- =0A= -- =0A= =0A= ippmMetricTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmMetricEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "This table describes the current implementation. This = =0A= table is mandatory. Each IPPM standardized metric must = =0A= be described in the table. =0A= In reporting mode the entries of this table may be not = =0A= accessible. It means that the table is handle = internally =0A= by the measure software. =0A= " =0A= ::=3D { ippmMeasureGroup 1 } =0A= =0A= ippmMetricEntry OBJECT-TYPE =0A= SYNTAX IppmMetricEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "An entry describes the static capabilities of a metric = =0A= implementation." =0A= INDEX { ippmMetricIndex } =0A= ::=3D { ippmMetricTable 1 } =0A= =0A= IppmMetricEntry ::=3D =0A= SEQUENCE { =0A= =0A= Stephan Informational - Expires August 2002 [Page 39] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmMetricIndex Integer32, =0A= ippmMetricCapabilities INTEGER, =0A= ippmMetricUnit INTEGER, =0A= ippmMetricDescription DisplayString, =0A= ippmMetricMaxHistorySize Integer32 =0A= } =0A= =0A= ippmMetricIndex OBJECT-TYPE =0A= SYNTAX Integer32 (1.. 65535) =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "ippmMetricIndex defines an unambiguous index for each =0A= standardized metric. Its value is the value of the node of the = =0A= metric in the IPPM-MIB metrics registry ippmMib.metrics.rfc. = =0A= Each metric registered in the standard registry must be present = =0A= in this table. =0A= This index is used to identify the metric performed among the = =0A= IPPM-MIB entities involved in the measure. =0A= Example: =0A= The index of the metric onewayPacketLossAverage which is =0A= registered as ippmMib.metrics.rfc.onewayPacketLossAverage will = =0A= always have the value 14." =0A= ::=3D { ippmMetricEntry 1 } =0A= =0A= =0A= ippmMetricCapabilities OBJECT-TYPE =0A= SYNTAX INTEGER { =0A= notImplemented(0), =0A= implemented(1) =0A= } =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "notImplemented =0A= the metric is not implemented. =0A= implemented =0A= the metric is implemented." =0A= DEFVAL { implemented } =0A= ::=3D { ippmMetricEntry 2 } =0A= =0A= ippmMetricUnit OBJECT-TYPE =0A= SYNTAX INTEGER { =0A= noUnit(0), =0A= second(1), =0A= ms(2), =0A= us(3), =0A= ns(4), =0A= percentage(5), =0A= packets(6), =0A= byte(6), =0A= =0A= Stephan Informational - Expires August 2002 [Page 40] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= kbyte(7), =0A= megabyte(8) =0A= } =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The unit used in the current entity for the results of = =0A= the measure of this metric." =0A= ::=3D { ippmMetricEntry 3 } =0A= =0A= ippmMetricDescription OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "A textual description of the metric implementation." = =0A= ::=3D { ippmMetricEntry 4 } =0A= =0A= ippmMetricMaxHistorySize OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the maximal number of results that a metric = =0A= measure can save in the ippmHistoryTable." =0A= ::=3D { ippmMetricEntry 5 } =0A= =0A= =0A= =0A= -- =0A= -- ippmMeasureTable =0A= -- =0A= -- =0A= =0A= ippmMeasureTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmMeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "The table of all the IPPM measures which are running = in =0A= the device. They may not be active. =0A= =0A= a measure consists in a subset of metrics to compute. = =0A= The results of the measure may be saved in the =0A= ippmHistoryTable. The configuration of the measure sets = =0A= the size of the history requested in =0A= ippmMeasureHystorySize. =0A= =0A= The maximal number of MIB objects to be collected in = the =0A= portion of ippmHistoryTable associated with this metric = =0A= depends the value of the ippmMetricMaxHistorySize. =0A= =0A= Stephan Informational - Expires August 2002 [Page 41] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= The value of each metric ippmMeasureHystorySize must = not =0A= be over the value of ippmMetricMaxHistorySize =0A= corresponding to this metric in ippmMetricTable. =0A= =0A= In reporting mode the entries of this table may be not = =0A= accessible. It means that the table is handle = internally =0A= by the measure software. =0A= " =0A= ::=3D { ippmMeasureGroup 2 } =0A= =0A= ippmMeasureEntry OBJECT-TYPE =0A= SYNTAX IppmMeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "A SNMP entity wishing to create and activate a =0A= measurement adds a new entry in the ippmMeasureTable. = =0A= =0A= Typically the configuration operation set the values of = =0A= the conceptual row parameters using an unused owner = =0A= index and sets the status of the row to createAndGo. = =0A= =0A= An SNMP error 'inconsistentValue' is returned if the = =0A= owner index is out of range." =0A= INDEX { ippmMeasureOwner, ippmMeasureIndex } =0A= ::=3D { ippmMeasureTable 1 } =0A= =0A= IppmMeasureEntry ::=3D =0A= SEQUENCE { =0A= ippmMeasureOwner OwnerString, =0A= ippmMeasureIndex Integer32, =0A= ippmMeasureName DisplayString, =0A= ippmMeasureMetrics IppmStandardMetrics, = =0A= ippmMeasureBeginTime GMTDateAndTime, =0A= ippmMeasureClockPeriodUnit TimeUnit, =0A= ippmMeasureClockPeriod Integer32, =0A= ippmMeasureDurationUnit TimeUnit, =0A= ippmMeasureDuration Integer32, =0A= ippmMeasureHystorySize Integer32, =0A= ippmMeasureStorageType StorageType, =0A= ippmMeasureStatus RowStatus =0A= } =0A= =0A= ippmMeasureOwner OBJECT-TYPE =0A= SYNTAX OwnerString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The owner who has configured this entry." =0A= DEFVAL { "acme" } =0A= =0A= Stephan Informational - Expires August 2002 [Page 42] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ::=3D { ippmMeasureEntry 1 } =0A= =0A= ippmMeasureIndex OBJECT-TYPE =0A= SYNTAX Integer32 (1.. 65535) =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The owner index of the measure. The value is managed = by =0A= the owner. An SNMP error 'inconsistentValue' is = returned =0A= if this value is already in use by this owner." =0A= ::=3D { ippmMeasureEntry 2 } =0A= =0A= ippmMeasureName OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The name of the instance of the metric. It illustrates = =0A= the specificity of the metric and includes the metric = =0A= and the typeP. =0A= =0A= example: IP-port-HTTP-connectivity" =0A= ::=3D { ippmMeasureEntry 3 } =0A= =0A= =0A= =0A= ippmMeasureMetrics OBJECT-TYPE =0A= SYNTAX IppmStandardMetrics =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Defines the metrics to compute within this measure. A = =0A= measure may be configured for the result of different = =0A= metrics singletons to be archive in the =0A= ippmHistoryTable. The ippmMetricIndex of the created = =0A= result has the value of the bit index of the =0A= corresponding ippmMeasureMetrics as explained above in = =0A= the ippmMetricIndex definition. =0A= =0A= Example: =0A= A measure asking for One-way-Delay(6) and One-way-=0A= Packet-Loss(12) generated a flow of singletons which = are =0A= logged in the ippmHistoryTable. The singletons created = =0A= for the One-way-Delay measure have a value of =0A= ippmMetricIndex of 6 while the created singletons for = =0A= the One-way-Packet-Loss measure have a value of =0A= ippmMetricIndex of 12." =0A= DEFVAL { { one-way-Delay, one-way-Packet-Loss } } =0A= ::=3D { ippmMeasureEntry 4 } =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 43] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmMeasureBeginTime OBJECT-TYPE =0A= SYNTAX GMTDateAndTime =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the time at which the measure starts." =0A= ::=3D { ippmMeasureEntry 5 } =0A= =0A= =0A= ippmMeasureClockPeriodUnit OBJECT-TYPE =0A= SYNTAX TimeUnit =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the unit of the measure period." =0A= DEFVAL { second } =0A= ::=3D { ippmMeasureEntry 6 } =0A= =0A= ippmMeasureClockPeriod OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the among of time between 2 sampling =0A= intervals. =0A= =0A= Notes: =0A= This interval generates a flow of periodical instants = =0A= which may be transformed as a flow of unpredictable =0A= instants of measure by the =0A= ippmNetworkMeasureClockPattern." =0A= DEFVAL { 60 } =0A= ::=3D { ippmMeasureEntry 7 } =0A= =0A= =0A= ippmMeasureDurationUnit OBJECT-TYPE =0A= SYNTAX TimeUnit =0A= =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the unit of the measure duration." =0A= DEFVAL { second } =0A= ::=3D { ippmMeasureEntry 8 } =0A= =0A= ippmMeasureDuration OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the duration of the measure." =0A= =0A= Stephan Informational - Expires August 2002 [Page 44] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= DEFVAL { 120 } =0A= ::=3D { ippmMeasureEntry 9 } =0A= =0A= ippmMeasureHystorySize OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the maximum number of results saved for each = =0A= metric of this measure. The history of each metric is = =0A= managed as a circular table. The newest result = overwrite =0A= the oldest one when the history granted to this metric = =0A= measure is full. =0A= =0A= The management of the results may be optimized if =0A= synchronized with the reports steps of this measure. = =0A= " =0A= DEFVAL { 120 } =0A= ::=3D { ippmMeasureEntry 10 } =0A= =0A= ippmMeasureStorageType OBJECT-TYPE =0A= SYNTAX StorageType =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "This object defines whether this row and the measure =0A= controlled by this row are kept in volatile storage and =0A= lost upon reboot or if this row is backed up by =0A= non-volatile or permanent storage. =0A= Possible values are: other(1), volatile(2), = nonVolatile(3), =0A= permanent(4), readOnly(5)" =0A= DEFVAL { nonVolatile } =0A= ::=3D { ippmMeasureEntry 11 } =0A= =0A= =0A= ippmMeasureStatus OBJECT-TYPE =0A= SYNTAX RowStatus =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The status of this table entry. Once the entry status = =0A= is set to active, the associate entry cannot be =0A= modified." =0A= DEFVAL { createAndGo } =0A= ::=3D { ippmMeasureEntry 12 } =0A= =0A= -- =0A= -- ippmHistoryGroup =0A= -- =0A= -- =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 45] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= -- =0A= -- ippmHistoryTable =0A= -- =0A= =0A= =0A= ippmHistoryTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmHistoryEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "The table of the results of the measures." =0A= =0A= ::=3D { ippmHistoryGroup 1 } =0A= =0A= =0A= =0A= ippmHistoryEntry OBJECT-TYPE =0A= SYNTAX IppmHistoryEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= =0A= "An ippmHistoryEntry entry is one of the result of an = =0A= measure identified by the index members = ippmMeasureOwner =0A= and ippmMeasureIndex. =0A= =0A= In the index : =0A= =0A= + ippmMeasureOwner and ippmMeasureIndex = identify =0A= the ippmMeasureEntry on whose behalf this entry was =0A= created; =0A= + ippmMetricIndex identifies the = ippmMetricEntry =0A= of the metric to measure; =0A= + ippmLogTimeMark value is the absolute time = =0A= when the result of the metric was measured. =0A= =0A= The ippmHistoryTimeMark value is the absolute time when = =0A= the ippmHistoryValue was performed. =0A= =0A= IppmHistoryValue is the value of the metric measured at = =0A= the time ippmHistoryTimeMark. =0A= =0A= Example: =0A= A one way delay measure is created by the entity 'acme' = =0A= using the owner index 1 and setting the 6th bit =0A= (corresponding to One-way-Delay) of ippmMeasureMetrics = =0A= to 1. =0A= Consider that the result of the one way delay measured = =0A= for acme on the day 15 of June at 8h20mn 10s 10ms is = 23. =0A= The result is identified as the singleton =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 46] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmHistoryValue.acme.1.6.0106150820100100 and stored = =0A= with value 23. =0A= =0A= Its value may be retrieved using a get-=0A= next(ippmHistoryValue.acme.1.6.0106150820100099) which = =0A= returns (ippmHistoryValue.acme.1.6.0106150820100100 = =3D=3D =0A= 23). The ippmMetricIndex value of '6' corresponds to = the =0A= 6th metric of ippmMetricTable which is = Type-P-One-way-=0A= Delay. =0A= " =0A= INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, = =0A= ippmHistoryTimeMark } =0A= ::=3D { ippmHistoryTable 1 } =0A= =0A= IppmHistoryEntry ::=3D =0A= SEQUENCE { =0A= ippmHistoryTimeMark GMTDateAndTime, =0A= ippmHistoryValue Integer32 =0A= } =0A= ippmHistoryTimeMark OBJECT-TYPE =0A= SYNTAX GMTDateAndTime =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The instant of the measure of the result." =0A= ::=3D { ippmHistoryEntry 1 } =0A= =0A= ippmHistoryValue OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= =0A= "The value of the measure." =0A= ::=3D { ippmHistoryEntry 2 } =0A= =0A= =0A= =0A= =0A= =0A= -- =0A= -- ippmNetworkMeasureGroup =0A= -- =0A= =0A= =0A= -- =0A= -- =0A= -- ippmNetworkMeasureTable =0A= -- =0A= -- =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 47] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmNetworkMeasureTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmNetworkMeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "A entry is a measure which performs network measures = =0A= and provides a flow of results. =0A= =0A= This table extends the ippmMeasureTable. A network =0A= measure is a specific measure. =0A= =0A= It performs several metrics measure per packet = exchange. =0A= Each step of a measure produces a singleton result per = =0A= metric. The time of the measure and the value of the = =0A= metric are saved in the ippmHistoryTable." =0A= ::=3D { ippmNetworkMeasureGroup 1 } =0A= =0A= ippmNetworkMeasureEntry OBJECT-TYPE =0A= SYNTAX IppmNetworkMeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "A SNMP entity wishing to create and activate a network = =0A= measure adds a new entry in the ippmMeasureTable and in = =0A= IppmNetworkMeasureTable. =0A= =0A= Typically the configuration operation set both the =0A= values of the new ippmMeasureEntry and of the new =0A= IppmNetworkMeasureEntry and sets the status of the row = =0A= to createAndGo. =0A= =0A= An SNMP error 'inconsistentValue' is returned if the = =0A= index is out of range. =0A= =0A= The ippmMeasureMetrics is set to a list of metrics to = be =0A= computed from the same raw packet exchange. Each step = of =0A= measure delivers a singleton per chosen metric. Results = =0A= are timestamped and saved in the ippmHistoryTable." =0A= INDEX { ippmMeasureOwner, ippmMeasureIndex } =0A= ::=3D { ippmNetworkMeasureTable 1 } =0A= =0A= IppmNetworkMeasureEntry ::=3D =0A= SEQUENCE { =0A= ippmNetworkMeasureSrcTypeP TypeP, =0A= ippmNetworkMeasureSrc OCTET STRING, = =0A= ippmNetworkMeasureDstTypeP TypeP, =0A= ippmNetworkMeasureDst OCTET STRING, = =0A= ippmNetworkMeasureClockPattern OCTET STRING, = =0A= ippmNetworkMeasureTimeoutDelay Integer32, =0A= ippmNetworkMeasureL3PacketSize Integer32, =0A= ippmNetworkMeasureDataPattern OCTET STRING = =0A= =0A= Stephan Informational - Expires August 2002 [Page 48] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= } =0A= =0A= ippmNetworkMeasureSrcTypeP OBJECT-TYPE =0A= SYNTAX TypeP =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Defines the type P of the source address of the = packets =0A= sent by the measure." =0A= DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 =0A= ::=3D { ippmNetworkMeasureEntry 1 } =0A= =0A= ippmNetworkMeasureSrc OBJECT-TYPE =0A= SYNTAX OCTET STRING =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the address of the source of the measure. = =0A= =0A= It is represented as an octet string with specific =0A= semantics and length as identified by the =0A= ippmNetworkMeasureSrcTypeP. =0A= =0A= For example, if the ippmNetworkMeasureSrcTypeP = indicates =0A= an encapsulation of 'ip', this object length is 4, =0A= followed by the 4 octets of the IP address, in network = =0A= byte order." =0A= DEFVAL { '04C0210415'H } -- -> ip: 192.33.4.21 =0A= ::=3D { ippmNetworkMeasureEntry 2} =0A= =0A= ippmNetworkMeasureDstTypeP OBJECT-TYPE =0A= SYNTAX TypeP =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Defines the type P of the destination address of the = =0A= packets sent by the measure." =0A= DEFVAL { '04000080001000'H } -- ->ip: 4.0.0.8.0.1.0 =0A= ::=3D { ippmNetworkMeasureEntry 3 } =0A= =0A= ippmNetworkMeasureDst OBJECT-TYPE =0A= SYNTAX OCTET STRING =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the address of the destination of the =0A= measure. =0A= =0A= It is represented as an octet string with specific =0A= semantics and length as identified by the =0A= ippmNetworkMeasureDstTypeP. =0A= =0A= Stephan Informational - Expires August 2002 [Page 49] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= For example, if the ippmNetworkMeasureDstTypeP = indicates =0A= an encapsulation of 'ip', this object length is 4, =0A= followed by the 4 octets of the IP address, in network = =0A= byte order." =0A= DEFVAL { '04C0220414'H } -- -> ip: 192.34.4.20 =0A= ::=3D { ippmNetworkMeasureEntry 4 } =0A= =0A= ippmNetworkMeasureClockPattern OBJECT-TYPE =0A= SYNTAX OCTET STRING =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "This cyclic clock shapes the profile of the instants = of =0A= measurement according to an arbitrary distribution law. = =0A= The clock resolution is ippmMeasureClockPeriod. The bits= =0A= of the clock set to the value 1 determine the valid =0A= instants of measurement. A measure is to be processed = if =0A= and only if the current bit value is 1. =0A= This pseudo-random clock pattern allows the =0A= configuration by the NMS of numerous kind of sampling = =0A= law such as periodic or Poisson." =0A= DEFVAL { 11111111} -- 100% periodic =0A= ::=3D { ippmNetworkMeasureEntry 5 } =0A= =0A= ippmNetworkMeasureTimeoutDelay OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= -- UNITS "Milliseconds" =0A= DESCRIPTION =0A= "Specifies the delay after which the packet is =0A= considered lost." =0A= DEFVAL { 1 } =0A= ::=3D { ippmNetworkMeasureEntry 6 } =0A= =0A= ippmNetworkMeasureL3PacketSize OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "Specifies the size of the packets send at the last =0A= network layer in the sense of the TypeP definition." = =0A= DEFVAL { 64 } =0A= ::=3D { ippmNetworkMeasureEntry 7 } =0A= =0A= ippmNetworkMeasureDataPattern OBJECT-TYPE =0A= SYNTAX OCTET STRING =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= =0A= Stephan Informational - Expires August 2002 [Page 50] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= "The current field defines the round robin pattern used = =0A= to fill the packet." =0A= DEFVAL { 'FF'H } =0A= ::=3D { ippmNetworkMeasureEntry 8 } =0A= =0A= =0A= =0A= -- =0A= -- =0A= -- ippmAggregatedMeasureGroup =0A= -- =0A= -- =0A= -- =0A= -- =0A= -- ippmAggregatedMeasureTable =0A= -- =0A= -- =0A= =0A= ippmAggregatedMeasureTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmAggregatedMeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= " This table extends the ippmMeasureTable. =0A= A aggregated measure summarizes the results of previous = =0A= network or aggregated measures. The results may saved = in =0A= the ippmHistoryTable. =0A= =0A= Each step of the measure computation produces a =0A= singleton result per metric." =0A= ::=3D { ippmAggregatedMeasureGroup 1 } =0A= =0A= ippmAggregatedMeasureEntry OBJECT-TYPE =0A= SYNTAX IppmAggregatedMeasureEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "A SNMP entity wishing to create and activate a statistic =0A= measure adds a new entry in the ippmMeasureTable and in =0A= ippmAggregatedMeasureTable. =0A= =0A= Typically the configuration operation sets both the values of = =0A= the new ippmMeasureEntry and of the new =0A= IppmAggregatedMeasureEntry and sets the status of the row to = =0A= createAndGo. =0A= =0A= The ippmMeasureMetrics defines the metric to compute. =0A= The results of the measure to summarize are identified by =0A= ippmAggregatedMeasureHistoryOwner, =0A= IppmAggregatedMeasureHistoryOwnerIndex and =0A= ippmAggregatedMeasureHistoryMetric =0A= =0A= Stephan Informational - Expires August 2002 [Page 51] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= The aggregated task starts at ippmMeasureBeginTime and end = after =0A= ippmMeasureDuration. A aggregated result is performed and saved = =0A= in the ippmHistoryTable for each ippmMeasureClockPeriod. =0A= " =0A= INDEX { ippmMeasureOwner, ippmMeasureIndex } =0A= ::=3D { ippmAggregatedMeasureTable 1 } =0A= =0A= =0A= IppmAggregatedMeasureEntry ::=3D =0A= SEQUENCE { =0A= ippmAggregatedMeasureHistoryOwner OwnerString, = =0A= ippmAggregatedMeasureHistoryOwnerIndex Integer32, =0A= ippmAggregatedMeasureHistoryMetric Integer32 =0A= } =0A= =0A= =0A= ippmAggregatedMeasureHistoryOwner OBJECT-TYPE =0A= SYNTAX OwnerString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The owner of the measure to summarize. " =0A= ::=3D { ippmAggregatedMeasureEntry 1 } =0A= =0A= ippmAggregatedMeasureHistoryOwnerIndex OBJECT-TYPE =0A= SYNTAX Integer32 (1.. 65535) =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The owner index of the measure to summarize. " =0A= ::=3D { ippmAggregatedMeasureEntry 2 } =0A= =0A= ippmAggregatedMeasureHistoryMetric OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The metric of the measure to summarize. " =0A= ::=3D { ippmAggregatedMeasureEntry 3 } =0A= =0A= =0A= -- =0A= -- ippmReportGroup =0A= -- =0A= =0A= -- =0A= -- =0A= -- ippmReportSetupTable =0A= -- =0A= -- =0A= =0A= Stephan Informational - Expires August 2002 [Page 52] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= ippmReportSetupTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmReportSetupEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "The ippmReportSetupTable is a list of definition of reports. It =0A= defines the results of a network or aggregated measures which are to = =0A= report. A report is saved in the ippmReportTable or sent to an =0A= application using a SNMP Trap, a SNMP inform PDU, an email or a SMS. = =0A= The reporting task is not a batch action processed at the end of the = =0A= measure. It is coupled with threshold detections and event filtering = =0A= to deliver application level events and data while preserving =0A= scalability. =0A= =0A= It extends the definition of a measure: the definition of an measure = =0A= may include the definition of a report." =0A= ::=3D { ippmReportGroup 1 } =0A= =0A= ippmReportSetupEntry OBJECT-TYPE =0A= SYNTAX IppmReportSetupEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "The report applies on the results of the measure which is extended = =0A= by the current report definition. =0A= =0A= Typically the creation or a report sets both the values of the new = =0A= measure and those of the new IppmReportSetupEntry. =0A= The ippmReportSetupDefinition describes the data and the events to = =0A= include in the report. The definition consists in a list of tasks to = =0A= perform on the results of the measure." =0A= INDEX { ippmMeasureOwner, ippmMeasureIndex } =0A= ::=3D { ippmReportSetupTable 1 } =0A= =0A= IppmReportSetupEntry ::=3D =0A= SEQUENCE { =0A= ippmReportSetupDefinition IppmReportDefinition, = =0A= ippmReportSetupMetricThreshold =0A= Integer32, =0A= ippmReportSetupEventsDurationThreshold Integer32, =0A= =0A= ippmReportSetupNMS DisplayString = =0A= } =0A= =0A= ippmReportSetupDefinition OBJECT-TYPE =0A= SYNTAX IppmReportDefinition =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 53] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= "The description of the events and actions which participate to = =0A= the elaboration of the report. =0A= Send the report using the type of message selected by the bits = 8 =0A= to 12. The report consists in the results of the measure which have = =0A= been saved in the ippmReportTable. If the onEventSendReport(7) bit = is =0A= unset the report is not saved. =0A= =0A= The message sent is a notification defined in the =0A= ippmNotifications node. The notification sent depends on the step of = =0A= the measure: =0A= =0A= + Singleton events are sent using the notification =0A= ippmSingletonAlarm; =0A= + Exceeded events duration are sent using the =0A= notification ippmEventsDurationExceededAlarm; =0A= + A report of a cycle of measure is sent using the =0A= notification ippmCycleOfMeasureReport; =0A= + A report of a complete measure is sent using the =0A= notification ippmCompletedMeasureReport; =0A= =0A= Example 1: =0A= The setup of an alarm to be sent to the owner in a SNMP Trap = =0A= each time the staircase crosses the metric threshold value of 5: =0A= =0A= ippmReportSetupMetricThreshold 5 =0A= ippmReportSetupDefinition { =0A= onSingleton(1), =0A= reportOnlyUptoDownMetricResults(4), =0A= inSNMPTrapPDU(8) =0A= } =0A= =0A= Example 2: =0A= The setup of a report to be sent to the owner in a SNMP =0A= informRequestPDU per measure cycle. It reports the staircase values = =0A= corresponding to a metric threshold of 5: =0A= =0A= ippmReportSetupMetricThreshold 5 =0A= ippmReportSetupDefinition { =0A= onMeasureCycle(2), =0A= reportOnlyUptoDownMetricResults(4), =0A= inInformRequestPDU(10), =0A= clearHistory(13) =0A= } =0A= =0A= Default report: =0A= The default report provides the control protocol with an =0A= implicit mechanism to forward the result of a cycle of measure to = the =0A= owner of the measure while deleting the results from the =0A= ippmHistoryTable on reception of the response to the = InformRequestPDU =0A= : =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 54] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmReportSetupDefinition { =0A= onMeasureCycle(2), =0A= inInformRequestPDU(10), =0A= clearHistory(13) =0A= } =0A= " =0A= DEFVAL { { onMeasureCycle, inInformRequestPDU, clearHistory } = }=0A= ::=3D { ippmReportSetupEntry 1 } =0A= =0A= ippmReportSetupMetricThreshold OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "An event is generated when the result of the measure exceeds = =0A= the value of ippmReportSetupMetricThreshold. =0A= The threshold has the same unit as the metric. The metric unit = =0A= is recorded in the object ippmMetricsUnit of this metric entry in = the =0A= ippmMetricTable. =0A= " =0A= ::=3D { ippmReportSetupEntry 2 } =0A= =0A= ippmReportSetupEventsDurationThreshold OBJECT-TYPE =0A= SYNTAX Integer32 =0A= UNITS "Seconds" =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "An event is generated when the duration of a serie of results = =0A= which are continuously over the metric threshold cross over the =0A= duration of the ippmReportSetupEventsDurationThreshold. =0A= " =0A= DEFVAL { 15 } =0A= ::=3D { ippmReportSetupEntry 3 } =0A= =0A= ippmReportSetupNMS OBJECT-TYPE =0A= SYNTAX DisplayString =0A= MAX-ACCESS read-create =0A= STATUS current =0A= DESCRIPTION =0A= "The recipient of the report may be provided in the setup. By = =0A= default the recipient of the report is the owner of the measure. Its = =0A= addresses are recorded in the ippmOwnersTable. =0A= " =0A= ::=3D { ippmReportSetupEntry 4 } =0A= =0A= =0A= -- =0A= -- ippmReportTable =0A= -- =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 55] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= ippmReportTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF IppmReportEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "The ippmReportTable logs the results of the reports. = =0A= The results consist in a subset of the results of a measure as =0A= described in the report definition. The activation of a up and down = =0A= filtering in the report definition limits the results logged to = those =0A= corresponding to major events. =0A= Excepted these points the ippmReportTable is identical = =0A= to the ippmHistoryTable. =0A= " =0A= =0A= ::=3D { ippmReportGroup 2 } =0A= =0A= =0A= ippmReportEntry OBJECT-TYPE =0A= SYNTAX IppmReportEntry =0A= MAX-ACCESS not-accessible =0A= STATUS current =0A= DESCRIPTION =0A= "A report is a list of results of a measure. This sample is =0A= associated with the ippmReportSetupEntry which has set up the = report. =0A= An ippmReportEntry entry is one of the results of an measure to =0A= report. The measure and the report definition are identified by the = =0A= index members ippmMeasureOwner and ippmMeasureIndex. =0A= =0A= in the index : =0A= =0A= + ippmMeasureOwner and ippmMeasureIndex identify the =0A= ippmMeasureEntry and the ippmReportSetupEntry on whose behalf this = =0A= report was created; =0A= + ippmMetricIndex identifies the ippmMetricEntry of the metric = =0A= measured; =0A= + ippmReportTimeMark value is the absolute time when the value = =0A= of the metric was measured. =0A= =0A= =0A= The ippmReportTimeMark value is the absolute time when the =0A= ippmHistoryValue was performed. =0A= IppmHistoryValue is the value of the metric measured at the = time =0A= ippmReportTimeMark. =0A= " =0A= INDEX { ippmMeasureOwner, ippmMeasureIndex, ippmMetricIndex, = =0A= ippmReportTimeMark } =0A= ::=3D { ippmReportTable 1 } =0A= =0A= IppmReportEntry ::=3D =0A= SEQUENCE { =0A= =0A= Stephan Informational - Expires August 2002 [Page 56] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmReportTimeMark GMTDateAndTime, =0A= ippmReportValue Integer32 =0A= } =0A= ippmReportTimeMark OBJECT-TYPE =0A= SYNTAX GMTDateAndTime =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= "The instant of the measure of the result." =0A= ::=3D { ippmReportEntry 1 } =0A= =0A= ippmReportValue OBJECT-TYPE =0A= SYNTAX Integer32 =0A= MAX-ACCESS read-only =0A= STATUS current =0A= DESCRIPTION =0A= =0A= "The value." =0A= ::=3D { ippmReportEntry 2 } =0A= =0A= =0A= -- =0A= -- ippmNotifications =0A= -- =0A= =0A= =0A= =0A= =0A= =0A= ippmSingletonAlarm NOTIFICATION-TYPE =0A= OBJECTS { =0A= ippmReportSetupDefinition, =0A= ippmReportSetupMetricThreshold, =0A= ippmMetricUnit, =0A= ippmHistoryValue =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "A notification sent because 2 contiguous results are = on =0A= opposite sides of the metric threshold value. =0A= The index of the included = ippmReportSetupMetricThreshold =0A= object identifies =0A= the ippmMeasureEntry and the ippmResultSetupEntry that = =0A= specified the threshold. =0A= =0A= The notification contains the instances of the =0A= ippmReportValue object which raised the threshold. The = =0A= ippmHistoryTimeMark of the index identifies the time = the =0A= event occurs. =0A= " =0A= ::=3D { ippmNotifications 1 } =0A= =0A= Stephan Informational - Expires August 2002 [Page 57] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= ippmEventsDurationExceededAlarm NOTIFICATION-TYPE =0A= OBJECTS { =0A= ippmReportSetupDefinition, =0A= ippmReportSetupEventsDurationThreshold, =0A= ippmMetricUnit, =0A= ippmHistoryValue =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "A notification sent when the duration of contiguous = =0A= raising ippmReportSetupMetricThreshold exceeds the =0A= ippmReportSetupEventsDurationThreshold value. The index = =0A= of the included ippmReportSetupDefinition object =0A= identifies =0A= the ippmMeasureEntry and the ippmResultSetupEntry that = =0A= specified the report. =0A= =0A= The notification contains the instances of the =0A= ippmReportValue objects saved in the ippmReportTable = for =0A= this report. The ippmHistoryTimeMark of the index =0A= identifies the time theses measures results where =0A= performed. =0A= " =0A= ::=3D { ippmNotifications 2 } =0A= =0A= =0A= ippmCycleOfMeasureReport NOTIFICATION-TYPE =0A= OBJECTS { =0A= ippmReportSetupDefinition, =0A= ippmMetricUnit, =0A= ippmHistoryValue =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "A notification sent when a measure cycle completes. = =0A= The index of the included ippmReportSetupDefinition =0A= object identifies =0A= the ippmMeasureEntry and the ippmResultSetupEntry that = =0A= specified the report. =0A= =0A= The notification contains the instances of the =0A= ippmReportValue objects saved in the ippmReportTable = for =0A= this measure cycle. The ippmHistoryTimeMark of the = index =0A= identifies the time the measures where performed. =0A= " =0A= ::=3D { ippmNotifications 3 } =0A= =0A= =0A= ippmCompletedMeasureReport NOTIFICATION-TYPE =0A= OBJECTS { =0A= =0A= Stephan Informational - Expires August 2002 [Page 58] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= ippmReportSetupDefinition, =0A= ippmMetricUnit, =0A= ippmHistoryValue =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "A notification sent when a measure completes. =0A= The index of the included ippmReportSetupDefinition =0A= object identifies =0A= the ippmMeasureEntry and the ippmResultSetupEntry that = =0A= specified the report. =0A= =0A= The notification contains the instances of the =0A= ippmReportValue objects saved in the ippmReportTable = for =0A= this measure cycle. The ippmHistoryTimeMark of the = index =0A= identifies the time the measures where performed. =0A= " =0A= ::=3D { ippmNotifications 4 } =0A= =0A= =0A= =0A= -- =0A= -- Compliance statements =0A= -- =0A= =0A= ippmCompliance MODULE-COMPLIANCE =0A= STATUS current =0A= DESCRIPTION =0A= "The compliance statement for SNMP entities which =0A= implement the IPPM MIB" =0A= MODULE -- this module =0A= MANDATORY-GROUPS { ippmSystemGroup, ippmMeasureGroup, =0A= ippmNetworkMeasureGroup, ippmHistoryGroup } =0A= ::=3D { ippmCompliances 1 } =0A= =0A= END =0A= =0A= =0A= =0A= 10. Security Considerations =0A= =0A= 10.1. Privacy =0A= =0A= The privacy concerns of network measurement are intrinsically = limited =0A= by the active measurements. Unlike passive measurements, there can = be =0A= no release of existing user data. =0A= =0A= =0A= 10.2. Measurement aspects =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 59] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= Conducting Internet measurements raises both security and privacy = =0A= concerns. This memo does not specify an implementation of the =0A= metrics, so it does not directly affect the security of the Internet = =0A= nor of applications which run on the Internet. However, =0A= implementations of these metrics must be mindful of security and =0A= privacy concerns. =0A= =0A= There are two types of security concerns: potential harm caused by = =0A= the measurements, and potential harm to the measurements. The =0A= measurements could cause harm because they are active, and inject = =0A= packets into the network. The measurement parameters MUST be =0A= carefully selected so that the measurements inject trivial amounts = of =0A= additional traffic into the networks they measure. If they inject = =0A= "too much" traffic, they can skew the results of the measurement, = and =0A= in extreme cases cause congestion and denial of service. =0A= =0A= The measurements themselves could be harmed by routers giving =0A= measurement traffic a different priority than "normal" traffic, or = by =0A= an attacker injecting artificial measurement traffic. If routers can = =0A= recognize measurement traffic and treat it separately, the =0A= measurements will not reflect actual user traffic. If an attacker = =0A= injects artificial traffic that is accepted as legitimate, the loss = =0A= rate will be artificially lowered. Therefore, the measurement =0A= methodologies SHOULD include appropriate techniques to reduce the = =0A= probability measurement traffic can be distinguished from "normal" = =0A= traffic. =0A= =0A= Authentication techniques, such as digital signatures, may be used = =0A= where appropriate to guard against injected traffic attacks. =0A= =0A= =0A= 10.3. Management aspects =0A= =0A= There are a number of management objects defined in this MIB that = =0A= have a MAX-ACCESS clause of read-write and/or read-create. Such =0A= objects may be considered sensitive or vulnerable in some network = =0A= environments. The support for SET operations in a non-secure =0A= environment without proper protection can have a negative effect on = =0A= network operations. =0A= =0A= SNMPv1 by itself is not a secure environment. Even if the network = =0A= itself is secure (for example by using IPSec), even then, there is = no =0A= control as to who on the secure network is allowed to access and =0A= GET/SET (read/change/create/delete) the objects in this MIB. =0A= =0A= It is recommended that the implementors consider the security =0A= features as provided by the SNMPv3 framework. Specifically, the use = =0A= of the User-based Security Model RFC 2574 [18] and the View-based = =0A= Access Control Model RFC 2575 [21] is recommended. =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 60] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= It is then a customer/user responsibility to ensure that the SNMP = =0A= entity giving access to an instance of this MIB, is properly =0A= configured to give access to the objects only to those principals = =0A= (users) that have legitimate rights to indeed GET or SET =0A= (change/create/delete) them. =0A= =0A= =0A= 11. References =0A= =0A= =0A= =0A= =0A= =0A= [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP = =0A= 9, RFC 2026, October 1996. =0A= =0A= [2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for = =0A= IP Performance Metrics", RFC 2330, May 1998. =0A= =0A= [3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring =0A= Connectivity", RFC 2678, September 1999. =0A= =0A= [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay = =0A= Metric for IPPM", RFC 2679, September 1999. =0A= =0A= [5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet = =0A= Loss Metric for IPPM", RFC 2680, September 1999. =0A= =0A= [6]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay = =0A= Metric for IPPM.", RFC 2681, September 1999. =0A= =0A= [7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for = =0A= Describing SNMP Management Frameworks", RFC 2571, April 1999. =0A= =0A= [8] Rose, M., and K. McCloghrie, "Structure and Identification of = =0A= Management Information for TCP/IP-based Internets", STD 16, RFC = =0A= 1155, May 1990. =0A= =0A= [9] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, = =0A= RFC 1212, March 1991. =0A= =0A= [10] M. Rose, "A Convention for Defining Traps for use with the =0A= SNMP", RFC 1215, March 1991. =0A= =0A= [11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, = =0A= M., and S. Waldbusser, "Structure of Management Information =0A= Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 61] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= [12] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, = =0A= M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, = =0A= RFC 2579, April 1999. =0A= =0A= [13] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, = =0A= M., and S. Waldbusser, "Conformance Statements for SMIv2", STD = 58, =0A= RFC 2580, April 1999. =0A= =0A= [14] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple =0A= Network Management Protocol", STD 15, RFC 1157, May 1990. =0A= =0A= [15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, =0A= "Introduction to Community-based SNMPv2", RFC 1901, January 1996. = =0A= =0A= [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, =0A= "Transport Mappings for Version 2 of the Simple Network = Management =0A= Protocol (SNMPv2)", RFC 1906, January 1996. =0A= =0A= [17]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message =0A= Processing and Dispatching for the Simple Network Management =0A= Protocol (SNMP)", RFC 2572, April 1999. =0A= =0A= [18] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) = =0A= for version 3 of the Simple Network Management Protocol = (SNMPv3)", =0A= RFC 2574, April 1999. =0A= =0A= [19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, = "Protocol =0A= Operations for Version 2 of the Simple Network Management = Protocol =0A= (SNMPv2)", RFC 1905, January 1996. =0A= =0A= [20] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC = =0A= 2573, April 1999. =0A= =0A= [21] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-basedAccess = =0A= Control Model (VACM) for the Simple Network Management Protocol = =0A= (SNMP)", RFC 2575, April 1999. =0A= =0A= [22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction = =0A= to Version 3 of the Internet-standard Network Management =0A= Framework", RFC 2570, April 1999. =0A= =0A= [23] Waldbusser, S., "Remote Network Monitoring MIB", STD 59, RFC = =0A= 2819, Lucent Technologies, May 2000 =0A= =0A= [24] Waldbusser, S., "Remote Network Monitoring Management =0A= Information Base Version 2 using SMIv2", RFC 2021, International = =0A= Network Services, January 1997. =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 62] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= [25] Remote Network Monitoring MIB Protocol Identifier Reference. A. = =0A= Bierman, C. Bucci, R. Iddon. RFC RFC2895 ,August 2000. =0A= =0A= [26] Remote Network Monitoring MIB Protocol Identifier Macros. A. = =0A= Bierman, C. Bucci, R. Iddon. RFC RFC2896, August 2000. =0A= =0A= [27] E. Stephan, "IPPM MIB", draft-stephan-ippm-mib-01.txt, January = =0A= 2002. =0A= =0A= 12. Acknowledgments =0A= =0A= A Kerbe. =0A= =0A= 13. Author's Addresses =0A= =0A= Emile STEPHAN =0A= France Telecom R & D =0A= 2 avenue Pierre Marzin =0A= F-22307 Lannion cedex =0A= Phone: (+ 33) 2 96 05 11 11 =0A= Email: emile.stephan@francetelecom.com =0A= =0A= =0A= Full Copyright Statement =0A= =0A= =0A= "Copyright (C) The Internet Society (2001). All Rights Reserved. =0A= =0A= This document and translations of it may be copied and furnished to = =0A= others, and derivative works that comment on or otherwise explain it = =0A= or assist its implementation may be prepared, copied, published and = =0A= distributed, in whole or in part, without restriction of any kind, = =0A= provided that the above copyright notice and this paragraph are =0A= included on all such copies and derivative works. However, this =0A= document itself may not be modified in any way, such as by removing = =0A= the copyright notice or references to the Internet Society or other = =0A= Internet organizations, except as needed for the purpose of =0A= developing Internet standards in which case the procedures for =0A= copyrights defined in the Internet Standards process must be =0A= followed, or as required to translate it into languages other than = =0A= English. =0A= =0A= The limited permissions granted above are perpetual and will not be = =0A= revoked by the Internet Society or its successors or assigns. =0A= =0A= This document and the information contained herein is provided on an = =0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING = =0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING = =0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION =0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF =0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 63] = =0A= =0A= =0C=0A= Internet Draft IPPM MIB February = 2002 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 64] = =0A= =0A= =0C ------_=_NextPart_000_01C1AD66.21B4C8D0-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 6 19:45:14 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05807 for ; Wed, 6 Feb 2002 19:45:14 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g170i3mQ003945; Wed, 6 Feb 2002 19:44:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g170h0mQ003062; Wed, 6 Feb 2002 19:43:00 -0500 From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , "Merike Kaeo" , "Allison Mankin" , "Scott Bradner" Date: Wed, 6 Feb 2002 19:43:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Revised IPPM charter nearing publication - final comments? Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The revised charter has been through an IESG review, and the current version is reproduced below. If you have any comments before it is officially published, send them to the chairs, the ADs, or the mailing list. I expect that the new charter should be official within two weeks. --Matt ======== draft 1.3 20020206 IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 06-Feb-02 Current Status: Active Working Group Chair(s): Merike Kaeo Matthew Zekauskas Transport Area Director(s): Scott Bradner Allison Mankin Transport Area Advisor: Allison Mankin Technical Advisor: Andy Bierman Mailing Lists: General Discussion:ippm@advanced.org To Subscribe: ippm-request@advanced.org Archive: http://www.advanced.org/IPPM/archive/ Description of Working Group Note: Andy Bierman serves as MIB advisor. The IPPM WG will develop a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics will be designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG will produce documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The metrics are: - connectivity - one-way delay and loss - round-trip delay and loss - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity This is the cumulative set, including the metrics already completed and published. The working group will closely review and then be guided by an IESG document on how metrics advance along the standards track within the IETF. This document will also be relevant to the work of the benchmarking working group (BMWG). The first draft of this document was discussed at IETF 51. Additionally, the WG will produce Proposed Standard applicability statement (AS) documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, or multimedia streams. It is specifically out of scope for this working group to actually characterize traffic, for example to characterize a voice-over-IP stream. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will produce a protocol to enable communication among test equipment that implements the one-way metrics. The intent is to create a protocol that provides a base level of functionality that will allow different manufacturer's equipment that implements the metrics according to a standard to interoperate. A protocol requirements document will guide the protocol design. The WG will also produce a MIB to retrieve the results of IPPM metrics, such as one-way delay and loss, to facilitate the communication of metrics to existing network management systems. Thus, the group will create a MIB that contains predominantly read only variables. If, after the protocol requirements document is finished, the group decides that it is appropriate to add variables that control the underlying measurements that the metrics report, such a control structure may be added as a separate document, subject to review by the IESG. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as T1A1.3, ITU-T SG 12 and SG 13) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. These include working groups such as BMWG, RMONMIB, and TEWG. Goals and Milestones: Done Submit drafts of standard metrics for connectivity and treno-bulk-throughput. Done Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for publication as an Informational RFC. Done Submit documents on delay and loss to IESG for publication as standards-track RFCs. Done Submit a document on connectivity to IESG for publication as a standards-track RFC. Done Submit framework for bulk transfer capacity to the IESG for publication as a Informational RFC. [Note to Secretariat: above milestones already exist and go to DONE] Done Create draft on requirements for a protocol to measure one-way delay and loss. Feb-02 Submit draft on loss pattern sample metrics to the IESG for publication as an Informational RFC. Feb-02 Submit draft on metrics for periodic streams to the IESG for publication as a Proposed Standard RFC. Feb-02 Submit draft on IP delay variation to the IESG for publication as a Proposed Standard RFC. Feb-02 Create initial draft on the definitions of link bandwidth capacity. Feb-02 First draft for AS on one-way delay and loss. Mar-02 Create initial draft on a sensitivity analysis of one-way delay and loss metric parameters (companion to the AS). Mar-02 Submit draft on One-Way Active Measurement Protocol Requirements to the IESG for consideration as an Informational RFC. Mar-02 Create initial draft on a MIB for reporting IPPM metrics. Apr-02 Create draft on a One-Way Active Measurement Protocol that satisfies the requirements document. Apr-02 Create initial draft on comparing ITU and IETF IP performance metrics. Apr-02 Create initial draft on a packet reordering metric. Jun-02 Submit link bandwidth capacity definitions draft to the IESG, for consideration as an Informational RFC. Jul-02 Submit draft on bulk transfer capacity metric based on the bulk transfer framework (CAP) to the IESG for Proposed Standard. Oct-02 Submit recommendation to the IESG on whether to advance, recycle, or deprecate RFCs 2678, 2679, 2680, and 2681 (connectivity, loss, & delay). Oct-02 Submit draft on a packet reordering metric to the IESG for Proposed Standard. Dec-02 Submit AS for one-way delay and loss to the IESG for PS. Dec-02 Submit sensitivity analysis of one-way delay and loss, for consideration as an Informational RFC. Feb-03 Submit draft on a MIB for reporting IPPM metrics to the IESG for Proposed Standard. Mar-03 Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS. Mar-03 Discuss rechartering or ending working group. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 8 03:09:18 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00818 for ; Fri, 8 Feb 2002 03:09:18 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g18873SE011593; Fri, 8 Feb 2002 03:07:03 -0500 Received: from cse.cuhk.edu.hk (cucs18.cse.cuhk.edu.hk [137.189.91.190]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g187dkSE010236 for ; Fri, 8 Feb 2002 02:39:48 -0500 Received: from daffodil (cslui@daffodil.cs.cuhk.hk [137.189.91.37]) by cse.cuhk.edu.hk with ESMTP id g187YUv19632; Fri, 8 Feb 2002 15:34:30 +0800 (HKT) Received: by daffodil (8.8.8+Sun/SMI-SVR4) id PAA12405; Fri, 8 Feb 2002 15:34:30 +0800 (HKT) From: cslui@cse.cuhk.edu.hk Message-Id: <200202080734.PAA12405@daffodil> To: ippm@advanced.org, diffserv@ietf.org, itc@i-teletraffic.org, cost279@coruja.lx.it.pt, WG@cs.ucf.edu, ppvpn@ppvpn.francetelecom.com, mmb@ira.uka.de, itg524@imst.de, itgfg523@comnets.rwth-aachen.de Date: Fri, 8 Feb 2002 15:34:30 +0800 (HKT) Cc: cslui@cse.cuhk.edu.hk (Dr. John Lui) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] favor Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit hi: This is a conference announcement. (*******We apologize that you may receive this email multiple times. *******) ======================================================================== Performance 2002 IFIP WG 7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation September 22 - 27, 2002 Rome, Italy Preliminary Call for Papers The 22nd IFIP WG 7.3 symposium will address state-of-the-art techniques and tools for performance evaluation with particular emphasis on new areas, such as, Internet and Web, active networks and content distribution networks. Topics of interest include, but are not limited to: Techniques and tools for analytic modeling, simulation, performance optimization, stochastic modeling, model checking, reliability analysis, system measurement and monitoring, workload characterization. Performance-oriented design and evaluation studies of communication networks, active networks, Web architectures, computer architectures, database systems, operating systems, multimedia systems, real-time systems, fault-tolerant systems. Program Paper/Poster Sessions: Full papers should not exceed 20 double-spaced pages including figures, tables and references. A limited number of submitted papers will be accepted for a poster session. Authors wishing to have their work considered for the poster session may submit a short paper not exceeding 5 double-spaced pages. Submissions must be made electronically as Postscript or Adobe PDF files through the Conference Web site (http://perf2002.uniroma2.it). In case of problems, send papers by email to papers@perf2002.uniroma2.it. Papers will be selected on the basis of their originality, relevance and clarity. Full papers will be published in a special issue of the Journal Performance Evaluation (Elsevier) available at the conference. Tutorial Sessions: Tutorial proposals, not exceeding 5 pages, have to include title, abstract, duration, intended audience, assumed background of attendees, name, affiliation and a biographical sketch of the instructors. Proposals should be sent to tutorials@perf2002.uniroma2.it. Evaluation of proposals will be based on instructor expertise, and on the relevance of the subject matter. A book of survey papers on the tutorial topics will be published. Publisher is under negotiation. Hot/Controversial Topic Sessions: Proposals are solicited for sessions in which a group of speakers will present and discuss ideas on recent results in a hot or controversial area. Send proposals for these sessions to proposals@perf2002.uniroma2.it, specifying the name, affiliation and a brief biography of organizer(s) of the session, the session title, and a list of possible speakers. The submission should also indicate whether any published material is required for the session. Awards: The Scientific Committee will assign the "Best Paper" and the "Best Student Paper" awards. Papers eligible for the student award must have a full-time student as the first author. IMPORTANT DATES: Submission of full papers and Proposals for special sessions: March 24, 2002 Notification of acceptance: May 25, 2002 Camera-Ready papers: June 20, 2002 For Further Information: info@perf2002.uniroma2.it http://perf2002.uniroma2.it _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 8 07:36:35 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04638 for ; Fri, 8 Feb 2002 07:36:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g18Ca2SE031353; Fri, 8 Feb 2002 07:36:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g18CZ6SE031156 for ; Fri, 8 Feb 2002 07:35:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04424; Fri, 8 Feb 2002 07:35:05 -0500 (EST) Message-Id: <200202081235.HAA04424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Feb 2002 07:35:04 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-npmps-06.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Network performance measurement for periodic streams Author(s) : V. Raisanen, G. Grotefeld, A. Morton Filename : draft-ietf-ippm-npmps-06.txt Pages : 19 Date : 07-Feb-02 This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances where analysis can be simplified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-npmps-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-npmps-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020207165746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-npmps-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-npmps-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020207165746.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 8 07:56:21 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04955 for ; Fri, 8 Feb 2002 07:56:21 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g18Cu2SE001762; Fri, 8 Feb 2002 07:56:02 -0500 Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g18CtZSE001615 for ; Fri, 8 Feb 2002 07:55:36 -0500 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4WXQNM>; Fri, 8 Feb 2002 13:55:27 +0100 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: ippm@advanced.org, rmonmib@ietf.org Date: Fri, 8 Feb 2002 13:55:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-961dd48f-1c69-11d6-ac1f-00508b692753" Subject: [ippm] IPPM MIB split proposal Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-961dd48f-1c69-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B09F.E13CA060" ------_=_NextPart_001_01C1B09F.E13CA060 Content-Type: text/plain; charset="iso-8859-1" hi, This a proposal to split the IPPM MIB to provide a MIB for reporting as request by the new charter. -1- Reporting MIB currently the IPPM-MIB tables are : ippmOwnersControlTable ippmResultSharingTable ippmMetricTable ippmMeasureTable ippmHistoryTable ippmNetworkMeasureTable ippmAggregatedMeasureTable ippmReportSetupTable ippmReportTable The tables needed for alarms and reports are : ippmOwnersControlTable ippmMetricTable ippmMeasureTable ippmHistoryTable ippmNetworkMeasureTable ippmAggregatedMeasureTable ippmReportSetupTable ippmReportTable The table ippmResultSharingTable may be removed. The table ippmOwnersControlTable become read only. Rows are added internally using the call CreateOwner(). The table is set at the installation and managed locally by the administrator of the device. The table ippmMetricTable is still read only. It describes the metric implemented and their implementation details. The tables of the measures become read only. Rows are added iternally using the call ControlMeasure(). They correspond to setup provided by the OWAP control protocol, by the installation software or by the internal management software : ippmMeasureTable ippmNetworkMeasureTable ippmAggregatedMeasureTable ippmReportSetupTable The tables of the results are still read only. Rows are added iternally using the call CreateResult(). There are feeded by the measure results provided by the OWAP test protocol and cleared according to the measure setup, the report setup and the available ressources: ippmHistoryTable ippmReportTable -2- Optional tables The table ippmOwnersControlTable is mandatory.There is at list one line corresponding to the owner 'monitor'. The table ippmMetricTable is mandatory. The tables ippmMeasureTable and ippmNetworkMeasureTable are mandatory. The need for the tables ippmAggregatedMeasureTable depends on to the point of measure capabilities. It is optional if the point of measures performs only network measures. The need for the tables ippmReportSetupTable and ippmReportTable depend on to the point of measure capabilities. They are optional if the point of measures has not thresholds and alarms capabilities. -3- lightweight IPPM-MIB So the lightweight IPPM-MIB implementation (without alarm and report) consists in 5 tables : ippmOwnersControlTable -- few change ippmMetricTable -- never change ippmMeasureTable -- set up by OWAP control protocol ippmNetworkMeasureTable -- set up by OWAP control protocol ippmHistoryTable -- set up by OWAP test protocol regards Emile ---------------------------------------------------------------------------- ---- E. Stephan Tel: (+ 33) 2 96 05 36 10 France Telecom R&D, Dpt. CPN Fax: (+ 33) 2 96 05 18 52 2 avenue Pierre Marzin F-22307 Lannion cedex mel: emile.stephan@francetelecom.com ---------------------------------------------------------------------------- ---- ------_=_NextPart_001_01C1B09F.E13CA060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPPM MIB split proposal

hi,

This a proposal to split the = IPPM MIB to provide a MIB for reporting as request by the new = charter.

-1- Reporting = MIB

    currently the = IPPM-MIB tables are :

      ippmOwnersControlTable
      ippmResultSharingTable
      ippmMetricTable =
      ippmMeasureTable =
      ippmHistoryTable =
      ippmNetworkMeasureTable
      ippmAggregatedMeasureTable
      ippmReportSetupTable
      ippmReportTable =

    The tables needed = for alarms and reports are :

      ippmOwnersControlTable
      ippmMetricTable =         =         =        
      ippmMeasureTable =        =         =        
      ippmHistoryTable =        =         =        
      ippmNetworkMeasureTable =         =        
      ippmAggregatedMeasureTable      =
      ippmReportSetupTable    =        
      ippmReportTable =         =         =        

    The table = ippmResultSharingTable may be removed.

    The table = ippmOwnersControlTable become read only. Rows are added internally = using the call CreateOwner(). The table is set at the installation and = managed locally by the administrator of the device.

    The table = ippmMetricTable is still read only. It describes the metric implemented = and their implementation details.

    The tables of the = measures become read only. Rows are added iternally using the call = ControlMeasure(). They correspond to setup provided by the OWAP control = protocol, by the installation software or by the internal management = software  :

      ippmMeasureTable =        =         =        
      ippmNetworkMeasureTable =         =        
      ippmAggregatedMeasureTable
      ippmReportSetupTable   


    The tables of the = results are still read only. Rows are added iternally using the call = CreateResult(). There are feeded by the measure results provided by the = OWAP test protocol and cleared according to the measure setup, the = report setup and the available ressources:

      ippmHistoryTable =        =         =        
      ippmReportTable =        

-2- Optional = tables

     The table = ippmOwnersControlTable is mandatory.There is at list one line = corresponding to the owner 'monitor'.

    The table = ippmMetricTable is mandatory.

    The tables = ippmMeasureTable and ippmNetworkMeasureTable are mandatory.

    The need for the = tables ippmAggregatedMeasureTable depends on to the point of measure = capabilities. It is optional if the point of measures performs only = network measures.

    The need for the = tables ippmReportSetupTable  and ippmReportTable  depend on = to the point of measure capabilities. They are optional if the point of = measures has not thresholds and alarms capabilities.

-3- lightweight = IPPM-MIB

    So the lightweight = IPPM-MIB implementation (without alarm and report) consists in 5 tables = :

      ippmOwnersControlTable  =         =         -- few change   =
      ippmMetricTable =         =         =         -- never change
      ippmMeasureTable =        =         =         =         -- set up by OWAP control = protocol
      ippmNetworkMeasureTable  =        =         =         -- set up by OWAP control = protocol
      ippmHistoryTable =        =         =         =         -- set up by OWAP test = protocol


    regards
    Emile   =

---------------------------------------------------------= -----------------------

        E. = Stephan           = ;            =        =         Tel: (+ 33) 2 96 05 36 = 10
        France = Telecom R&D, Dpt. CPN    Fax: (+ 33) 2 96 05 18 = 52
        2 avenue = Pierre = Marzin           =   
        F-22307 = Lannion cedex=20
          mel: = emile.stephan@francetelecom.com
---------------------------------------------------------= -----------------------


------_=_NextPart_001_01C1B09F.E13CA060-- ------=_NextPartTM-000-961dd48f-1c69-11d6-ac1f-00508b692753-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 12 08:24:45 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10466 for ; Tue, 12 Feb 2002 08:24:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1CDM3SE014407; Tue, 12 Feb 2002 08:22:03 -0500 Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1CDLISE014216 for ; Tue, 12 Feb 2002 08:21:18 -0500 Received: from RHOLLEYW2K (dhcp-64-102-43-132.cisco.com [64.102.43.132]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id IAA17719 for ; Tue, 12 Feb 2002 08:21:19 -0500 (EST) From: "Robert Holley" To: Date: Tue, 12 Feb 2002 08:21:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [ippm] ITU Y-Series Specs Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit ippm, I am having some difficulties in locating copies of the ITU draft Y-series recommendations Y.1530, Y.1540, and Y.1541. We have an ITU license, and access to several other Y-series docs, but still cannot locate the these specific recommendations. Our ITU admin beleives that they are not yet available for purchase. Since these documents are referenced in some IPPM specs, I thought this list may be able to help. Any suggestions would be appreciated. ============================================ Robert Holley Network Consulting Engineer Global Solutions Engineering Cisco Systems 7025 Kit Creek Road. Research Triangle Park, NC 27709 Phone: +1 919-392-2359 Pager: +1 800-796-7363 pin 100-9187 ============================================ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 12 09:18:23 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12513 for ; Tue, 12 Feb 2002 09:18:23 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1CEI3SE022272; Tue, 12 Feb 2002 09:18:03 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1CEHOSE022079 for ; Tue, 12 Feb 2002 09:17:24 -0500 Received: from hogpa.mt.att.com ([135.16.74.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g1CEHOW09058 for ; Tue, 12 Feb 2002 09:17:25 -0500 (EST) Received: from acmortonw.att.com by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id JAA00494; Tue, 12 Feb 2002 09:17:23 -0500 Message-Id: <5.1.0.14.0.20020212091647.00a52810@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Feb 2002 09:17:21 -0500 To: ippm@advanced.org From: Al Morton Subject: Re: [ippm] ITU Y-Series Specs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Robert, Y.1530 and Y.1541 are not yet published, so you'll need a TIES account to get them. Y.1540 is the (future) re-numbered version of I.380, and I.380 is published, etc. I'll send you some TD#'s for 1530/1541 if you want them. Al At 08:21 AM 02/12/2002 -0500, you wrote: >ippm, > >I am having some difficulties in locating copies of the ITU draft Y-series >recommendations Y.1530, Y.1540, and Y.1541. > >We have an ITU license, and access to several other Y-series docs, but still >cannot locate the these specific recommendations. > >Our ITU admin beleives that they are not yet available for purchase. > >Since these documents are referenced in some IPPM specs, I thought this list >may be able to help. > >Any suggestions would be appreciated. > >============================================ >Robert Holley >Network Consulting Engineer >Global Solutions Engineering > >Cisco Systems >7025 Kit Creek Road. >Research Triangle Park, NC 27709 >Phone: +1 919-392-2359 >Pager: +1 800-796-7363 pin 100-9187 >============================================ > >_______________________________________________ >ippm mailing list >ippm@advanced.org >http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 13 09:21:44 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03154 for ; Wed, 13 Feb 2002 09:21:44 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1DEL3SE024903; Wed, 13 Feb 2002 09:21:03 -0500 Received: from tid.tid.es (tidos.tid.es [193.145.240.2]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1DEJrSE024777 for ; Wed, 13 Feb 2002 09:19:54 -0500 Received: from holland.tid.es ([1.0.38.231]) by tid.tid.es (Netscape Messaging Server 4.15) with ESMTP id GRH6MS02.T3X for ; Wed, 13 Feb 2002 15:23:16 +0100 Message-Id: <5.1.0.14.2.20020213150307.00b54530@tid> X-Sender: holland@tid X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Feb 2002 15:20:38 +0100 To: ippm@advanced.org From: Henrik Holland In-Reply-To: <5.1.0.14.0.20020212091647.00a52810@hogpa.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] ippm mib Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Dear all, Are there yet any implemenatations of the IPPM mib? Regards, Henrik Holland. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 05:10:28 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14541 for ; Thu, 14 Feb 2002 05:10:27 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EAA3SE028617; Thu, 14 Feb 2002 05:10:03 -0500 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EA9LSE028508 for ; Thu, 14 Feb 2002 05:09:22 -0500 Received: from surfnet.nl (sluffy.heanet.ie [193.1.219.219]) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id KAA22686; Thu, 14 Feb 2002 10:09:21 GMT Message-ID: <3C6B8CED.72D8475D@surfnet.nl> Date: Thu, 14 Feb 2002 10:09:49 +0000 From: Victor Reijs Reply-To: victor.reijs@surfnet.nl Organization: SURFnet bv X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPPM Working Group , nicolas.simar@dante.org.uk, ht@surfnet.nl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] concatenation of QoS parameters Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello all of you, In IPPM, we are developing some great documents on definitions of parameters. When using them, I see one issue (perhaps already covered earlier in e-mail discussions), and I would like to hear your ideas about this. When measuring the parameters, I am sometimes not doing end-to-end measurements, but more concatenating measurement results gotten from several non overlapping domains. My question is now how is the concatenation done for all the defined IPPM parameters. Perhaps some parameters have only validity between the points measured? I assume it is also dependent how fine grained you are looking (in micro sec accuracy or milli second accuracy). So we have to keep that also in mind. In my below ideas I am looking at millisec accuracy. . OWD. I assume, I can just add figures in case of concatenation of domains. . IPDV. This is a difficult one. I would tend to say one can not just added the figures. I once heard a convolution is needed here. What are your ideas? . IP Packet Loss. This is not a simple addition. Because a lost packet in one domain can not be lost again in another domain, it can be calculated mathematically (I think). I will give this a shot in the coming time;-) . IP Loss patterns. This is really a parameter that can not be used in concatenation, in my opinion. . IP packet reordering: I would say the same as loss patterns... Would be great to hear your ideas on this (and possible solutions how to concatenate). The above was for the millisec range, perhaps other ideas are needed in microsec range. Thanks for your feedback. All the best, Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 09:59:12 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23532 for ; Thu, 14 Feb 2002 09:59:11 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EEw3SE029872; Thu, 14 Feb 2002 09:58:03 -0500 Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EEv2SE029679 for ; Thu, 14 Feb 2002 09:57:02 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g1EEurt53699; Thu, 14 Feb 2002 09:56:53 -0500 (EST) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g1EEuqC17434; Thu, 14 Feb 2002 09:56:53 -0500 (EST) Received: from malibu.torrentnet.com (chimento@localhost) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id g1EEupY16765; Thu, 14 Feb 2002 09:56:51 -0500 (EST) Message-Id: <200202141456.g1EEupY16765@malibu.torrentnet.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: victor.reijs@surfnet.nl cc: IPPM Working Group , nicolas.simar@dante.org.uk, ht@surfnet.nl, chimento@torrentnet.com Subject: Re: [ippm] concatenation of QoS parameters In-Reply-To: Message from Victor Reijs of "Thu, 14 Feb 2002 10:09:49 GMT." <3C6B8CED.72D8475D@surfnet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Feb 2002 09:56:51 -0500 From: Philip Chimento Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Victor: It depends on what you want to do mathematically. The short answer is that means and rates add, with very few restrictions and almost nothing else does. So, if you have the MEAN VALUES of OWD in two different domains, go ahead and add them (it doesn't even matter if the delays in the domains are somehow dependent on one another). The VARIANCES do NOT simply add if the random variables are dependent, you have to add in 2*covariance (measure of dependence), but if they are independent you can add them. Distributions, on the other hand must be convolved (and you can think of histograms as distributions, for example). So, what does all this mean from a practical point of view ? Go ahead and add AVERAGE OWD figures with a clear conscience. Oddly enough, (I believe) IPDV AVERAGEs can be added (even though they are dependent)[I would gladly hear from any statisticians out there if I am wrong about this]. The loss measures, on the other hand, I would simply add, because they are in fact measuring events on different probability spaces. What you have in successive domains are conditional average losses (or loss rates), where the losses are conditioned on the number of packets entering the domain (which is not necessarily the number of packets originally transmitted). Packet re-ordering is difficult, depending on how you define it; a domain may re-order packets to a permutation of the order in which it received them, but because of previous re-ordering, it may put some fraction of packets back into the original order as transmitted. If you define re-ordering conditional to the order received by a domain, I think that you can add the re-ordering rates. But what that means in terms of the original packet order, I am not sure. If you want to go further than averages, however, you run into a lot of mathematical issues, and so combining histograms from different domains means that you have to look at numerical convolutions.... My 2 cents anyway. (What are fractions of a Euro ;-) ? Regards, Phil -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 10:50:23 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25086 for ; Thu, 14 Feb 2002 10:50:23 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EFo3SE012222; Thu, 14 Feb 2002 10:50:03 -0500 Received: from bigglesworth.mail.be.easynet.net (bigglesworth.mail.be.easynet.net [212.100.160.67]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EFnlSE012106 for ; Thu, 14 Feb 2002 10:49:48 -0500 Received: from 212-100-179-83.adsl.easynet.be ([212.100.179.83] helo=there) by bigglesworth.mail.be.easynet.net with smtp (Exim 3.16 #1) id 16bO8p-00059C-00; Thu, 14 Feb 2002 16:49:47 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Steven Van den Berghe Organization: Ghent University To: Philip Chimento , victor.reijs@surfnet.nl Subject: Re: [ippm] concatenation of QoS parameters Date: Thu, 14 Feb 2002 16:49:47 +0100 X-Mailer: KMail [version 1.3.1] Cc: IPPM Working Group , nicolas.simar@dante.org.uk, ht@surfnet.nl, chimento@torrentnet.com References: <200202141456.g1EEupY16765@malibu.torrentnet.com> In-Reply-To: <200202141456.g1EEupY16765@malibu.torrentnet.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Hi Phil, Victor i'm certainly not a statistician, so what i'm about to say might be completely wrong. If the loss in successive domains is on the average n,n',n" (probabilty of packets being dropped), couldn't i say that if i sent x packets, i can expect x * n * n' * n" being dropped (so multiply instead of add the loss rates)? I agree on the delay part and must say i'm also afraid delay variations and re-ordering measurements are not very willing to be concatenated. so far for my two cents (the expression remains the same if you talk about fractions of a euro:) ) Regards, Steven On Thursday 14 February 2002 15:56, Philip Chimento wrote: > Hi Victor: > It depends on what you want to do mathematically. The short answer is that > means and rates add, with very few restrictions and almost nothing else > does. So, if you have the MEAN VALUES of OWD in two different domains, go > ahead and add them (it doesn't even matter if the delays in the domains are > somehow dependent on one another). The VARIANCES do NOT simply add if the > random variables are dependent, you have to add in 2*covariance (measure of > dependence), but if they are independent you can add them. > > Distributions, on the other hand must be convolved (and you can think of > histograms as distributions, for example). So, what does all this mean from > a practical point of view ? > > Go ahead and add AVERAGE OWD figures with a clear conscience. Oddly enough, > (I believe) IPDV AVERAGEs can be added (even though they are dependent)[I > would gladly hear from any statisticians out there if I am wrong about > this]. The loss measures, on the other hand, I would simply add, because > they are in fact measuring events on different probability spaces. What you > have in successive domains are conditional average losses (or loss rates), > where the losses are conditioned on the number of packets entering the > domain (which is not necessarily the number of packets originally > transmitted). Packet re-ordering is difficult, depending on how you define > it; a domain may re-order packets to a permutation of the order in which it > received them, but because of previous re-ordering, it may put some > fraction of packets back into the original order as transmitted. If you > define re-ordering conditional to the order received by a domain, I think > that you can add the re-ordering rates. But what that means in terms of the > original packet order, I am not sure. > > If you want to go further than averages, however, you run into a lot of > mathematical issues, and so combining histograms from different domains > means that you have to look at numerical convolutions.... > > My 2 cents anyway. (What are fractions of a Euro ;-) ? > > Regards, Phil -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband Communication Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1.5 tons. - Popular Mechanics, 1949 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 11:53:26 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27455 for ; Thu, 14 Feb 2002 11:53:26 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EGr2SE027578; Thu, 14 Feb 2002 11:53:02 -0500 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EGq3SE027380 for ; Thu, 14 Feb 2002 11:52:04 -0500 Received: from surfnet.nl (sluffy.heanet.ie [193.1.219.219]) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id QAA23499 for ; Thu, 14 Feb 2002 16:52:04 GMT Message-ID: <3C6BEB31.7FBF0601@surfnet.nl> Date: Thu, 14 Feb 2002 16:52:01 +0000 From: Victor Reijs Reply-To: victor.reijs@surfnet.nl Organization: SURFnet bv X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPPM Working Group Subject: [Fwd: [ippm] draft-ietf-ippm-owdp-reqs-01.txt: last comments before IETF52] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello Stanislav, Thanks for the phone call we had on my issues with regard to the OWAMP. I now much better understand where you are coming from in the OWAMP document. The thought I had was that I would be able to download test to the points that do the measurements. I now understand that the basic measurement done in OWAMP is time stamping of packets incoming and outgoing. These times stamps will sent to the host that provided the schedule of packets and then that host will evaluated the time stamping. The host can now do anything it likes (determine: OWD, IPDV, OWPL, etc.). So no intelligence is needed at the points that do the measurements. That makes any need of downloading code/script unnecessary. I was more thinking in having more intelligent points (like in Chariot). Downloading scripts/code would reduce the amount of data send as compared to a generic OWAMP point, but then indeed you have these issues of: security, no standard for coding, etc. I think that the proposed OWAMP can indeed work (together with the help of the evaluation in a host). I will now reread the paper in more detail with this new understanding. Thanks for the explanations gotten! All the best, Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 12:04:16 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27772 for ; Thu, 14 Feb 2002 12:04:16 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EH43SE000721; Thu, 14 Feb 2002 12:04:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EH3XSE000311 for ; Thu, 14 Feb 2002 12:03:33 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id C65A15EE47; Thu, 14 Feb 2002 12:03:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 96E0A5EE49; Thu, 14 Feb 2002 12:03:19 -0500 (EST) To: victor.reijs@surfnet.nl Cc: IPPM Working Group Subject: Re: [ippm] concatenation of QoS parameters References: <3C6B8CED.72D8475D@surfnet.nl> From: stanislav shalunov Date: 14 Feb 2002 12:03:54 -0500 In-Reply-To: <3C6B8CED.72D8475D@surfnet.nl> Message-ID: <87pu389erp.fsf@cain.internet2.edu> Lines: 49 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is probably outside of scope of IPPM WG activities (and in the realm of a statistics), but: Everything hinges on the assumption of independent distribution of the delay variables for different domains. On one hand, since the next domain doesn't explicitly know about treatment in the previous one you could say that the independence assumption should be true. On the other hand, if there exist global congestion oscillation phenomena (and why wouldn't they?) the assumption would be incorrect. Further, you do not specify your metrics. Averages, for example, would be much easier to analyze in this way than medians. Victor Reijs writes: > . OWD. I assume, I can just add figures in case of concatenation of > domains. Sum is correct for averages regardless of independence. > . IPDV. This is a difficult one. I would tend to say one can not just > added the figures. I once heard a convolution is needed here. What are > your ideas? Sum is correct for variances provided that there is independence. > . IP Packet Loss. Loss probability, assuming independence, is, of course, 1-\Pi(1-p_i). Accidentally, for small values of p_i the first order approximation of this quantity happens to be \Sigma p_i. > . IP Loss patterns. No numeric parameter. > . IP packet reordering: No defined metric and no defined model. > The above was for the millisec range, perhaps other ideas are needed > in microsec range. Scale doesn't matter. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "You wake me up early in the morning to tell me I am right? Please wait until I am wrong." -- John von Neumann, on being phoned at 10 a.m. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 12:15:21 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28493 for ; Thu, 14 Feb 2002 12:15:20 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EHF3SE002752; Thu, 14 Feb 2002 12:15:03 -0500 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EHEUSE002638 for ; Thu, 14 Feb 2002 12:14:31 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA26927 for ; Thu, 14 Feb 2002 10:14:31 -0700 (MST)] Received: [from il06exw10.corp.mot.com (il06exw10.corp.mot.com [199.5.78.81]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA20753 for ; Thu, 14 Feb 2002 10:14:31 -0700 (MST)] Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Feb 2002 11:14:30 -0600 Message-ID: From: Grotefeld Glenn-cecl03 To: "'stanislav shalunov'" , victor.reijs@surfnet.nl Cc: IPPM Working Group Subject: RE: [ippm] concatenation of QoS parameters Date: Thu, 14 Feb 2002 11:14:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List "On the other hand, if there exist global ~congestion oscillation phenomena (and why wouldn't they?) the ~assumption would be incorrect." Or, in another form, you can expect significant "tidal" effects such as time-of-day/day-of-week. While IP traffic may not have a "Mother's Day (US)" causing a huge spike in traffic like the phone system has, there may other equivalents in the IP that I just do not recognize. Glenn Grotefeld Motorola, Inc. g.grotefeld@motorola.com US 847 435-0730 847 632-6800 FAX ~-----Original Message----- ~From: stanislav shalunov [mailto:shalunov@internet2.edu] ~Sent: Thursday, February 14, 2002 11:04 AM ~To: victor.reijs@surfnet.nl ~Cc: IPPM Working Group ~Subject: Re: [ippm] concatenation of QoS parameters ~ ~ ~This is probably outside of scope of IPPM WG activities (and in the ~realm of a statistics), but: Everything hinges on the assumption of ~independent distribution of the delay variables for different domains. ~On one hand, since the next domain doesn't explicitly know about ~treatment in the previous one you could say that the independence ~assumption should be true. On the other hand, if there exist global ~congestion oscillation phenomena (and why wouldn't they?) the ~assumption would be incorrect. ~ ~Further, you do not specify your metrics. Averages, for example, ~would be much easier to analyze in this way than medians. ~ ~Victor Reijs writes: ~ ~> . OWD. I assume, I can just add figures in case of concatenation of ~> domains. ~ ~Sum is correct for averages regardless of independence. ~ ~> . IPDV. This is a difficult one. I would tend to say one can not just ~> added the figures. I once heard a convolution is needed ~here. What are ~> your ideas? ~ ~Sum is correct for variances provided that there is independence. ~ ~> . IP Packet Loss. ~ ~Loss probability, assuming independence, is, of course, 1-\Pi(1-p_i). ~Accidentally, for small values of p_i the first order approximation of ~this quantity happens to be \Sigma p_i. ~ ~> . IP Loss patterns. ~ ~No numeric parameter. ~ ~> . IP packet reordering: ~ ~No defined metric and no defined model. ~ ~> The above was for the millisec range, perhaps other ideas are needed ~> in microsec range. ~ ~Scale doesn't matter. ~ ~-- ~Stanislav Shalunov http://www.internet2.edu/~shalunov/ ~ ~"You wake me up early in the morning to tell me I am right? Please ~wait until I am wrong." -- John von Neumann, on being ~phoned at 10 a.m. ~_______________________________________________ ~ippm mailing list ~ippm@advanced.org ~http://mailhost.advanced.org/mailman/listinfo/ippm ~ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 14 12:58:33 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02445 for ; Thu, 14 Feb 2002 12:58:33 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EHv3SE013047; Thu, 14 Feb 2002 12:57:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EHuISE012935 for ; Thu, 14 Feb 2002 12:56:18 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id C08D15EE49 for ; Thu, 14 Feb 2002 12:56:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 1683A5EE47 for ; Thu, 14 Feb 2002 12:56:05 -0500 (EST) To: IPPM Working Group Subject: Re: [ippm] concatenation of QoS parameters References: From: stanislav shalunov Date: 14 Feb 2002 12:56:39 -0500 In-Reply-To: Message-ID: <87d6z89cbs.fsf@cain.internet2.edu> Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Grotefeld Glenn-cecl03 writes: > Or, in another form, you can expect significant "tidal" effects such > as time-of-day/day-of-week. While IP traffic may not have a > "Mother's Day (US)" causing a huge spike in traffic like the phone > system has, there may other equivalents in the IP that I just do not > recognize. Glenn, I believe the tidal effects with timescales much larger than the time of delivery of a single packet per se do not violate the independence assumption for the purposes of our argument. However, tidal effects with timescales similar to those required to deliver a packet would destroy the independence assumption completely. While I don't have evidence of their existence, I don't see why it would be obvious that they do not exist. The assumption of independence is not self-evident and should be spelled out when used. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Al your Qaeda are belong to US. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 15 01:31:29 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20611 for ; Fri, 15 Feb 2002 01:31:28 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1F6V2SE018899; Fri, 15 Feb 2002 01:31:02 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g1F6UxSE018717; Fri, 15 Feb 2002 01:30:59 -0500 From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , "Merike Kaeo" Date: Fri, 15 Feb 2002 01:29:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Working group last call: draft-ietf-ippm-npmps-06.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The latest draft of the Network Performance Measurement with Periodic Streams has all the fixes and changes suggested on this list as well as previous IETF meetings. Since there have been no substantive changes suggested to this document since the last version, the co-chairs propose a Working Group last-call for this document, draft-ietf-ippm-npmps-06.txt. Assuming no major objections or changes, we will submit this document to the IESG for consideration as an Proposed Standard RFC. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). Because multiple last-calls are outstanding, the Working Group last-call period for this document will be extended (slightly), and will end on Monday, March 4, 2002 at 5pm EST. One pointer for the document is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-06.txt --Matt Zekauskas & Merike Kaeo _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 18 04:49:04 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29287 for ; Mon, 18 Feb 2002 04:49:04 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1I9m2SE030940; Mon, 18 Feb 2002 04:48:02 -0500 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1I9lwSE030752 for ; Mon, 18 Feb 2002 04:47:58 -0500 Received: from [193.203.132.2] (helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 16ckOs-00077A-00; Mon, 18 Feb 2002 10:47:58 +0100 Message-ID: <3C70CDCA.F7D951D3@surfnet.nl> Date: Mon, 18 Feb 2002 09:47:54 +0000 From: Victor Reijs Organization: SURFnet bv X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: stanislav shalunov CC: IPPM Working Group Subject: Re: [ippm] concatenation of QoS parameters References: <3C6B8CED.72D8475D@surfnet.nl> <87pu389erp.fsf@cain.internet2.edu> Content-Type: multipart/mixed; boundary="------------1E8D8F116D7547D4C3EBAF84" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. --------------1E8D8F116D7547D4C3EBAF84 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Stanislav, stanislav shalunov wrote: > Further, you do not specify your metrics. Averages, for example, > would be much easier to analyze in this way than medians. I would say: averages. I then avergae over two different time periods: say over 10 micro sec (for micro sec range) and say over 1 msec (for milli sec range). All the best, Victor --------------1E8D8F116D7547D4C3EBAF84 Content-Type: text/x-vcard; charset=us-ascii; name="victor.reijs.vcf" Content-Description: Card for Victor Reijs Content-Disposition: attachment; filename="victor.reijs.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Reijs;Victor tel;fax:+ 353 1 8105121 tel;work:+ 31 30 2305305 x-mozilla-html:FALSE url:http://www.surfnet.nl/ org:SURFnet bv;Networkmanagement adr:;;;Utrecht;;;The Netherlands version:2.1 email;internet:Victor.Reijs@SURFnet.nl title:Network Engineer fn:Victor Reijs end:vcard --------------1E8D8F116D7547D4C3EBAF84-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 18 11:53:29 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08452 for ; Mon, 18 Feb 2002 11:53:29 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1IGq3SE010609; Mon, 18 Feb 2002 11:52:03 -0500 Received: from hotmail.com ([64.4.17.113]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EDZLSE015202 for ; Thu, 14 Feb 2002 08:35:21 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Feb 2002 05:35:22 -0800 Received: from 168.172.1.253 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 14 Feb 2002 13:35:22 GMT X-Originating-IP: [168.172.1.253] From: "sello stanley africa moloi" To: ippm@advanced.org Date: Thu, 14 Feb 2002 15:35:22 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Feb 2002 13:35:22.0298 (UTC) FILETIME=[7387C1A0:01C1B55C] Subject: [ippm] video streaming Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi. i am a student at Pretoria Technikon at SA and i am ivolved in the Storage Area Network project,now my task is to perform video streaming experiments on the SAN that we have hear at the Technikon and now i am stuck with calculation like for example the calculation of determining how may clients can a server handle for different bit rates,how much of the bandwidth is used and the amount of memory. Basically i need any help that i can get to correctly monitor the performance of my server and storage system. thank you. Stanley moloi 204 Vergesig Building 106 Vermeulen Street Pretoria 0002 Cell Number:0833159458 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 18 11:53:34 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08466 for ; Mon, 18 Feb 2002 11:53:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1IGqFSE010895; Mon, 18 Feb 2002 11:52:15 -0500 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EGU7SE022488 for ; Thu, 14 Feb 2002 11:30:11 -0500 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1EGT3B20805; Thu, 14 Feb 2002 17:29:03 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA20410; Thu, 14 Feb 2002 17:28:59 +0100 (MET) Message-ID: <3C6BE581.30E6823C@eth.ericsson.se> Date: Thu, 14 Feb 2002 17:27:45 +0100 From: Attila =?iso-8859-1?Q?P=E1sztor?= Organization: ETH/RG X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steven Van den Berghe CC: Philip Chimento , victor.reijs@surfnet.nl, IPPM Working Group , nicolas.simar@dante.org.uk, ht@surfnet.nl Subject: Re: [ippm] concatenation of QoS parameters References: <200202141456.g1EEupY16765@malibu.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi All, in my understanding if independent losses are assumed, then one can expect (1-n'), (1-n'') 'no-loss' rate, what gives: x*(1-(1-n')*(1-n'')*..) as the number of packets, one could expect to transmit successfully. Regards, Attila Steven Van den Berghe wrote: > Hi Phil, Victor > > i'm certainly not a statistician, so what i'm about to say might be > completely wrong. If the loss in successive domains is on the average n,n',n" > (probabilty of packets being dropped), couldn't i say that if i sent x > packets, i can expect x * n * n' * n" being dropped (so multiply instead of > add the loss rates)? > > I agree on the delay part and must say i'm also afraid delay variations and > re-ordering measurements are not very willing to be concatenated. > > so far for my two cents (the expression remains the same if you talk about > fractions of a euro:) ) > > Regards, > Steven > > On Thursday 14 February 2002 15:56, Philip Chimento wrote: > > Hi Victor: > > It depends on what you want to do mathematically. The short answer is that > > means and rates add, with very few restrictions and almost nothing else > > does. So, if you have the MEAN VALUES of OWD in two different domains, go > > ahead and add them (it doesn't even matter if the delays in the domains are > > somehow dependent on one another). The VARIANCES do NOT simply add if the > > random variables are dependent, you have to add in 2*covariance (measure of > > dependence), but if they are independent you can add them. > > > > Distributions, on the other hand must be convolved (and you can think of > > histograms as distributions, for example). So, what does all this mean from > > a practical point of view ? > > > > Go ahead and add AVERAGE OWD figures with a clear conscience. Oddly enough, > > (I believe) IPDV AVERAGEs can be added (even though they are dependent)[I > > would gladly hear from any statisticians out there if I am wrong about > > this]. The loss measures, on the other hand, I would simply add, because > > they are in fact measuring events on different probability spaces. What you > > have in successive domains are conditional average losses (or loss rates), > > where the losses are conditioned on the number of packets entering the > > domain (which is not necessarily the number of packets originally > > transmitted). Packet re-ordering is difficult, depending on how you define > > it; a domain may re-order packets to a permutation of the order in which it > > received them, but because of previous re-ordering, it may put some > > fraction of packets back into the original order as transmitted. If you > > define re-ordering conditional to the order received by a domain, I think > > that you can add the re-ordering rates. But what that means in terms of the > > original packet order, I am not sure. > > > > If you want to go further than averages, however, you run into a lot of > > mathematical issues, and so combining histograms from different domains > > means that you have to look at numerical convolutions.... > > > > My 2 cents anyway. (What are fractions of a Euro ;-) ? > > > > Regards, Phil > > -- > Steven Van den Berghe > steven.vandenberghe@intec.rug.ac.be > Workgroup Broadband Communication Networks > Department Information Technology > Ghent University - Belgium > Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Where a calculator on the ENIAC is equipped with 18,000 > vacuum tubes and weighs 30 tons, computers in the future > may have only 1,000 vacuum tubes and weigh only 1.5 tons. > - Popular Mechanics, 1949 > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 18 11:53:38 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08480 for ; Mon, 18 Feb 2002 11:53:38 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1IGq7SE010706; Mon, 18 Feb 2002 11:52:07 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1EI2TSE014821 for ; Thu, 14 Feb 2002 13:02:29 -0500 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id C5CF34CE72; Thu, 14 Feb 2002 13:02:29 -0500 (EST) Received: from research.att.com (roughan@wombat.research.att.com [135.207.26.100]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id NAA22890; Thu, 14 Feb 2002 13:02:29 -0500 (EST) Message-ID: <3C6BFBF2.4010101@research.att.com> Date: Thu, 14 Feb 2002 13:03:30 -0500 From: Matthew Roughan Organization: AT&T Research Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steven Van den Berghe Cc: Philip Chimento , victor.reijs@surfnet.nl, IPPM Working Group , nicolas.simar@dante.org.uk, ht@surfnet.nl Subject: Re: [ippm] concatenation of QoS parameters References: <200202141456.g1EEupY16765@malibu.torrentnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi, addition of the loss probabilities is a reasonable approximation for low loss (assuming losses in different domains are independent). If the loss probabilities in each domain are high then you run into obvious problems such as the sum being larger than 1. The correct way to compute the loss (assuming independence) is p_{loss} = 1 - product_{i} (1 - p_{i}) where p_{i} is the probability of being lost in domain i. This computes 1 - the probability that the packet is not lost in any of the domains. The summation formula is the first order approximation. The assumption of independence might not always hold. If the losses occurred because of an overload in traffic, then this could be correlated between domains (conceivably) and therefore cause correlated losses. Syncronization could also cause correlated losses. I don't personally think these will be a big issue, but one should be quite careful when considering general data. Matt Steven Van den Berghe wrote: > Hi Phil, Victor > > i'm certainly not a statistician, so what i'm about to say might be > completely wrong. If the loss in successive domains is on the average n,n',n" > (probabilty of packets being dropped), couldn't i say that if i sent x > packets, i can expect x * n * n' * n" being dropped (so multiply instead of > add the loss rates)? > > I agree on the delay part and must say i'm also afraid delay variations and > re-ordering measurements are not very willing to be concatenated. > > so far for my two cents (the expression remains the same if you talk about > fractions of a euro:) ) > > Regards, > Steven > > > On Thursday 14 February 2002 15:56, Philip Chimento wrote: > >>Hi Victor: >>It depends on what you want to do mathematically. The short answer is that >>means and rates add, with very few restrictions and almost nothing else >>does. So, if you have the MEAN VALUES of OWD in two different domains, go >>ahead and add them (it doesn't even matter if the delays in the domains are >>somehow dependent on one another). The VARIANCES do NOT simply add if the >>random variables are dependent, you have to add in 2*covariance (measure of >>dependence), but if they are independent you can add them. >> >>Distributions, on the other hand must be convolved (and you can think of >>histograms as distributions, for example). So, what does all this mean from >>a practical point of view ? >> >>Go ahead and add AVERAGE OWD figures with a clear conscience. Oddly enough, >>(I believe) IPDV AVERAGEs can be added (even though they are dependent)[I >>would gladly hear from any statisticians out there if I am wrong about >>this]. The loss measures, on the other hand, I would simply add, because >>they are in fact measuring events on different probability spaces. What you >>have in successive domains are conditional average losses (or loss rates), >>where the losses are conditioned on the number of packets entering the >>domain (which is not necessarily the number of packets originally >>transmitted). Packet re-ordering is difficult, depending on how you define >>it; a domain may re-order packets to a permutation of the order in which it >>received them, but because of previous re-ordering, it may put some >>fraction of packets back into the original order as transmitted. If you >>define re-ordering conditional to the order received by a domain, I think >>that you can add the re-ordering rates. But what that means in terms of the >>original packet order, I am not sure. >> >>If you want to go further than averages, however, you run into a lot of >>mathematical issues, and so combining histograms from different domains >>means that you have to look at numerical convolutions.... >> >>My 2 cents anyway. (What are fractions of a Euro ;-) ? >> >>Regards, Phil >> > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 18 11:53:47 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08494 for ; Mon, 18 Feb 2002 11:53:47 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1IGqBSE010807; Mon, 18 Feb 2002 11:52:11 -0500 Received: from sspws010.sp.edu.sg (sspws011.sp.edu.sg [164.78.252.34]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1I9FPSE029529 for ; Mon, 18 Feb 2002 04:15:26 -0500 From: icon2002@sp.edu.sg To: icon00-01i%SP_SF@sp.edu.sg X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 18 Feb 2002 17:16:01 +0800 X-MIMETrack: Serialize by Router on SSPWS010/SP/SP_SF(Release 5.0.2b (Intl)|16 December 1999) at 18/02/2002 05:15:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g1I9FPSE029529 Subject: [ippm] 10th IEEE International Conference on Networks (ICON2002) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit ********************************************************************** Our apologies if you receive multiple copies of this message. We highly appreciate your help to publicize the CFP locally. ********************************************************************** This is an invitation to ICON2002: IEEE International Conference on Networks (Singapore, August 27-30, 2002). For detailed information of the conference, please visit our web site: http://icon2002.calendarone.com Though the deadline for submission of the full papers for ICON2002 is March 1, 2002, we will consider any request for an extension of the deadline should you require one. We hope you will consider ICON2002 for presenting your research work. Please note that we are also encouraging the presentation of work-in- progress. Sincerely, ICON2002 Organising Committee ********************************************************************** IEEE INTERNATIONAL CONFERENCE ON NETWORKS (ICON 2002) http://icon2002.calendarone.com CALL FOR PAPERS IEEE INTERNATIONAL CONFERENCE ON NETWORKS Tues, August 27 - Fri, August 30, 2002, Singapore Organised by Computer Chapter, IEEE Singapore School of EEE, Singapore Polytechnic In Cooperation with National University of Singapore Nanyang Technological University Laboratories for Information Technology Supported by Singapore Exhibition & Convention Bureau Conference Theme: Towards Network Superiority The IEEE International Conference on Networks (ICON2002) will be held in Singapore. Two days of tutorials and two days of technical presentations are planned for the conference. The conference will also include invited speakers, poster presentations and an exhibition. ICON2002 will provide a forum to discuss the recent advances in computer networks and communications. Contributions describing original research, surveys and applications are solicited. Topics of interest include, but are not limited to, the following areas: Active / Intelligent Networks Ad-hoc Networks BISDN and ATM Congestion / Admission Control Converged Data and Telecom Networks Data Traffic Engineering and Management High Speed Network Protocols Internet Services / Applications Label Switching Protocol Mobile Communication Multicast / Broadcast Protocols Multimedia Protocols and Networking Multimedia over Internet Multiple Access Technology Network Architecture and Protocol Performance Network Management and Control Network Monitoring Network Security and Privacy Network Signalling and Connection Management Optical Communication Networks MPLS in WDM Networks IP over WDM Networks Personal Communication Services Pervasive Networks Quality of Service Routing and Routing Protocols Storage Area Networks Test-beds and Measurements Virtual Private Networks Voice over Internet Wireless/Mobile/Satellite/ Networks and Protocols Wireless Internet Submissions of original, unpublished papers on various aspects of mobility in computer networks are particularly encouraged. All submitted papers will be internationally reviewed and accepted papers will be published. PAPER SUBMISSION INSTRUCTIONS The paper should present original, unpublished research and be no longer than 5000 words. The submission should include a cover page containing the title, author name(s), complete address (telephone, fax, email) for all authors, indication of the corresponding author, and an abstract (100-150 words), followed by keywords and one or more areas of interest from the list above. Electronic submission in PDF is preferred. Instructions on the submission of papers can be found on the conference web page. Submission of paper(s) implies the authors' willingness to register at the conference and present the paper(s). An accepted paper will be published in the proceedings only if the final version is accompanied by the registration form and fee for at least one of the authors. One author registration will guarantee publication of up to only two accepted papers. SPECIAL SESSION / PLENARY SESSION PROPOSALS Proposals for Special Sessions/Plenary Sessions are also solicited. Proposals may be submitted to the Conference Co-Chair, Lee-Yee LAU via email at icon2002@sp.edu.sg by January 1, 2002. TUTORIAL PROPOSALS Proposals for full- or half-day tutorial topics including but not restricted to these areas are solicited: high-speed networks, mobile and wireless networks, optical networks, network security and advanced internet. Each proposal should be about 1000 words long and should include a synopsis, tutorial outline and brief biography of the speaker. Please submit your proposals to the Tutorial Chair, Yew-Chiong LOH via email at icon2002@sp.edu.sg by March 1, 2002. IMPORTANT DATES Proposal for Special/ Plenary Sessions due: Jan 1, 2002 Proposal for Tutorials due: March 1, 2002 Full paper due: March 1, 2002 Notification of acceptance: May 1, 2002 Camera-ready paper due: June 15, 2002 Tutorial: Aug 27-28, 2002 Conference: Aug 29-30, 2002 ORGANISING COMMITTEE Conference Co-Chairs: Lawrence WONG (NUS, Singapore) Lee-Yee LAU (SP, Singapore) Technical Program Co-Chairs: Liren ZHANG (NTU, Singapore) Lek-Heng NGOH (LIT, Singapore) Finance Chair: Sudhir K JHAJHARIA (SP, Singapore) Publicity Chair: Weng-Yew WONG (SP, Singapore) Tutorial Chair: Yew-Chiong LOH (SP, Singapore) Local Arrangements Chair: Teck-Bee TAN (SP, Singapore) Conference Secretary: Siti Marina Masduki (SP, Singapore) Webmaster: Cindy LAI (SP, Singapore) IMPORTANT DATES Proposal for Special/ Plenary Sessions due: Jan 1, 2002 Proposal for Tutorials due: March 1, 2002 Full paper due: March 1, 2002 Notification of acceptance: May 1, 2002 Camera-ready paper due: June 15, 2002 Tutorial: Aug 27-28, 2002 Conference: Aug 29-30, 2002 INTERNATIONAL TECHNICAL PROGRAM COMMITTEE A L Ananda (National University of Singapore, Singapore) Andrew Campbell (Columbia University, USA) Aruna Seneviratne (University of New South Wales, Australia) Brahim Bensaou (Hong Kong University of Science and Technology, Hong Kong) Chai-Keong Toh (Georgia Institute of Technology, USA) Chen-Khong Tham (National University of Singapore, Singapore) Francis Lee (Nanyang Technological University, Singapore) Gee-Swee Poo (National University of Singapore, Singapore) HT Kung (Harvard University, USA) Hung-Keng Pung (National University of Singapore, Singapore) Jadwiga Indulska (University of Queensland, Australia) Javier A. Barria (Imperial College of Science Technology and Medicine, UK) K R Subramanian (Nanyang Technological University, Singapore) Kevin Tsai (UC Irvine, USA) Kwok-Yan Lam (National University of Singapore, Singapore) Lindsay Jackson (Australia) Nick Maxemchuk (AT&T Research Labs, USA) Peter Beadle (Motorola Australia Research Centre, Australia) Peter Steenkiste (Carnegie Mellon University, USA) Radhakrishna Pillai (Laboratories for Information Technology, Singapore) Raj Jain (Nayna Networks, USA) S Venkatesan (University of Texas-Dallas, USA) S V Raghavan (IIT Madras, India) Whay-Chiou Lee (Motorola, USA) Yew-Hock Ang (Nanyang Technological University, Singapore) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Feb 20 13:13:35 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12538 for ; Wed, 20 Feb 2002 13:13:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1KIB2rk014528; Wed, 20 Feb 2002 13:11:02 -0500 Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1KIA3rk013905 for ; Wed, 20 Feb 2002 13:10:03 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g1KGE5o27265; Wed, 20 Feb 2002 11:14:05 -0500 (EST) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g1KGE4Q96886; Wed, 20 Feb 2002 11:14:04 -0500 (EST) Received: from malibu.torrentnet.com (chimento@localhost) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id g1KGDl820551; Wed, 20 Feb 2002 11:13:47 -0500 (EST) Message-Id: <200202201613.g1KGDl820551@malibu.torrentnet.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Reinhard Sojka cc: ippm@advanced.org, chimento@torrentnet.com In-Reply-To: Message from Reinhard Sojka of "Wed, 20 Feb 2002 10:32:12 +0100." <200202200932.g1K9WCn04375@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Feb 2002 11:13:47 -0500 From: Philip Chimento Subject: [ippm] Re: - typo? Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hello Reinhard: > Good morning Phil, > > I want to draw your attention to the following two sentences in the ipdv draft: > > Clock offset if then also a function of time and the error evolves as e(t) = > K*t + O, where K is a constant and O is the offset at time 0. In this case, > the error added to the subtraction two different time stamps (t2 > t1) is > e(t2)-e(t1) = K*(t2 - t1) which will be added to the time difference (t2 - t1). > > I have the impression that there is one (or more?) typo(s). > > These two sentences can be found in paragraph "4.7.1. Errors/Uncertainties > related to Clocks" , nearly on top of page 11. > > Regards, > Reinhard > Thanks for catching those. There are indeed typos in that paragraph. It should read: > Clock offset _is_ then also a function of time and the error evolves as > e(t) = K*t + O, where K is a constant and O is the offset at time 0. > In this case, the error added to the subtraction _of_ two different time > stamps (t2 _-_ t1) is e(t2)-e(t1) = K*(t2 - t1) which will be added to > the time difference (t2 - t1). Underscored items are the corrections. Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 21 03:34:36 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10890 for ; Thu, 21 Feb 2002 03:34:36 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1L8Y2rk028072; Thu, 21 Feb 2002 03:34:03 -0500 Received: from mainserver.surfnetusa.com (mainserver.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1L8XXrk027886; Thu, 21 Feb 2002 03:33:34 -0500 Received: from SEABREEZE (SEABREEZE [208.232.125.89]) by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id fbzexbaa for ippm@advanced.org; Thu, 21 Feb 2002 00:34:32 -0800 Message-Id: <5.1.0.14.2.20020221002042.00bc5008@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 00:33:13 -0800 To: ippm@advanced.org From: Merike Kaeo Cc: matthew J Zekauskas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] working group last calls Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Just a reminder that there are currently 3 working-group last call items in progress. 1. The latest drafts of the IP Packet Delay Variation Metric: http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-08.txt 2. The latest draft of the One-way Loss Pattern Sample Metrics: http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-pattern-06.txt These two will end on Monday, February 25, 2002 at noon EST. [we had a typo on the email sent out regarding last call for One-way Loss Pattern Sample Metrics which initially said Monday Feb 28th] 3. The latest draft of Network Performance Measurement with Periodic Streams: http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-06.txt This last call will end on Monday, March 4, 2002 at 5pm EST. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). - Merike Kaeo & Matt Zekauskas _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 22 06:25:07 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27510 for ; Fri, 22 Feb 2002 06:25:07 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1MBM3rk001703; Fri, 22 Feb 2002 06:22:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1MBLbrk001510 for ; Fri, 22 Feb 2002 06:21:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27264; Fri, 22 Feb 2002 06:21:34 -0500 (EST) Message-Id: <200202221121.GAA27264@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 22 Feb 2002 06:21:34 -0500 Subject: [ippm] I-D ACTION:draft-morton-ippm-nonrev-reordering-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reordering Metric for IPPM using Non-Reversing Sequence Author(s) : A. Morton et al. Filename : draft-morton-ippm-nonrev-reordering-00.txt Pages : 10 Date : 21-Feb-02 This memo proposes a simple metric to determine if a network has maintained packet sequence. It provides motivations for the new metric, suggests a metric definition, and discusses the issues associated with measuring packet sequence. The memo includes secondary metrics to quantify the extent of reordering in several useful dimensions. Some examples of evaluation using the non- reversing sequence criterion are included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morton-ippm-nonrev-reordering-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-morton-ippm-nonrev-reordering-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-morton-ippm-nonrev-reordering-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221154921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-morton-ippm-nonrev-reordering-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-morton-ippm-nonrev-reordering-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221154921.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Feb 22 15:10:14 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20295 for ; Fri, 22 Feb 2002 15:10:13 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1MK83rk003430; Fri, 22 Feb 2002 15:08:04 -0500 Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g1MGuHrk030063; Fri, 22 Feb 2002 11:56:17 -0500 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4W8DWN>; Fri, 22 Feb 2002 17:40:11 +0100 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: internet-drafts@ietf.org Cc: Matt Zekauskas , Merike Kaeo , ippm@advanced.org, rmonmib@ietf.org Date: Fri, 22 Feb 2002 17:39:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BBBF.7416BF40" Subject: [ippm] I-D submission of the draft-stephan-ippm-multicast-metrics-00.t xt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BBBF.7416BF40 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBBF.7416BF40" ------_=_NextPart_001_01C1BBBF.7416BF40 Content-Type: text/plain; charset="ISO-8859-1" Hello, This is a submission of a draft. It concerns the IPPM WG, the RMON WG and the Multicast WGs. Abstract: This memo defines a set of spatial metrics for measuring the performance of multicast networks and a set of multicast metrics for measuring the performance of multicast services. It introduces a framework to perform operational multicast metrics measurements coupling SNMP and the IPPM-MIB. best regards. Emile <> ---------------------------------------------------------------------------- ---- E. Stephan Tel: (+ 33) 2 96 05 36 10 France Telecom R&D, Dpt. CPN Fax: (+ 33) 2 96 05 18 52 2 avenue Pierre Marzin F-22307 Lannion cedex mel: emile.stephan@francetelecom.com ---------------------------------------------------------------------------- ---- ------_=_NextPart_001_01C1BBBF.7416BF40 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I-D submission of the = draft-stephan-ippm-multicast-metrics-00.txt

        Hello,

        This is a submission of a = draft. It concerns the IPPM = WG, the RMON WG and the Multicast WGs.

        Abstract:
          This memo = defines a set of spatial metrics for measuring the
          performance = of multicast networks and a set of multicast metrics for
          measuring = the performance of multicast services. It introduces a
          framework to = perform operational multicast metrics measurements
          coupling = SNMP and the IPPM-MIB.
           =20
        best regards.
        Emile

= <<draft-stephan-ippm-multicast-metrics-00.txt>>


---------------------------------------------------------= -----------------------

        E. = Stephan           = ;            =        =         Tel: (+ 33) 2 96 05 36 = 10
        France = Telecom R&D, Dpt. CPN    Fax: (+ 33) 2 96 05 18 = 52
        2 avenue = Pierre = Marzin           =   
        F-22307 = Lannion cedex=20
          mel: = emile.stephan@francetelecom.com
---------------------------------------------------------= -----------------------


------_=_NextPart_001_01C1BBBF.7416BF40-- ------_=_NextPart_000_01C1BBBF.7416BF40 Content-Type: text/plain; name="draft-stephan-ippm-multicast-metrics-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-stephan-ippm-multicast-metrics-00.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= Network Working Group E. = Stephan =0A= =0A= Internet Draft France Telecom = R&D =0A= =0A= Document: draft-stephan-ippm-multicast-metrics-00.txt February 20, = 2002 =0A= =0A= Category: Informational = =0A= =0A= =0A= IPPM Multicast metrics measurement =0A= =0A= =0A= Status of this Memo =0A= =0A= This document is an Internet-Draft and is in full conformance with = =0A= all provisions of Section 10 of RFC2026 [1] except that the right to = =0A= produce derivative works is not granted. =0A= =0A= =0A= Internet-Drafts are working documents of the Internet Engineering = =0A= Task Force (IETF), its areas, and its working groups. Note that = other =0A= groups may also distribute working documents as Internet-Drafts. =0A= Internet-Drafts are draft documents valid for a maximum of six = months =0A= and may be updated, replaced, or obsoleted by other documents at any = =0A= time. It is inappropriate to use Internet- Drafts as reference =0A= material or to cite them other than as "work in progress." =0A= =0A= The list of current Internet-Drafts can be accessed at =0A= http://www.ietf.org/ietf/1id-abstracts.txt. =0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at =0A= http://www.ietf.org/shadow.html. =0A= =0A= =0A= Abstract =0A= =0A= This memo defines a set of spatial metrics for measuring the =0A= performance of multicast networks and a set of multicast metrics for = =0A= measuring the performance of multicast services. It introduces a =0A= framework to perform operational multicast metrics measurements =0A= coupling SNMP and the IPPM-MIB. =0A= =0A= Table of Contents =0A= =0A= 1. = Introduction................................................3 =0A= 2. = Motivation..................................................3 =0A= 3. The IPPM = Framework..........................................3 =0A= 4. Spatial hop one way delay = metric............................4 =0A= 4.1. Metric = Name.................................................4 =0A= 4.2. Metric = Parameters...........................................4 =0A= 4.3. Metric = Units................................................4 =0A= 4.4. = Definition..................................................5 =0A= 5. Spatial One way delay stream = metric.........................5 =0A= 5.1. Metric = Name.................................................5 =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 1] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= 5.2. Metric = Parameters...........................................5 =0A= 5.3. Metric = Units................................................5 =0A= 5.4. = Definition..................................................5 =0A= 6. Spatial One way delay = metric................................6 =0A= 6.1. Metric = Name.................................................6 =0A= 6.2. Metric = Parameters...........................................6 =0A= 6.3. Metric = Units................................................6 =0A= 6.4. = Definition..................................................6 =0A= 7. Multicast Instantaneous One-way Delay = Stream................6 =0A= 7.1. Metric = Name.................................................6 =0A= 7.2. Metric = Parameters...........................................6 =0A= 7.3. Metric = Units................................................7 =0A= 7.4. = Definition..................................................7 =0A= 8. Statistics definitions for Multicast instantaneous One =0A= way = Delay.................................................7 =0A= 8.1. = Type-P-Multicast-Instantaneous-Hop-One-way-Delay............7 =0A= 8.2. = Type-P-Multicast-Instantaneous-One-way-Delay-Percentile.....7 =0A= 8.3. = Type-P-Multicast-Instantaneous-One-way-Delay-Median.........8 =0A= 8.4. Type-P-Multicast-Instantaneous-One-way-Delay-Inverse =0A= Percentile................................................8= =0A= 9. Multicast Instantaneous Packet Loss = Stream..................8 =0A= 9.1. Metric = Name.................................................8 =0A= 9.2. Metric = Parameters...........................................8 =0A= 9.3. Metric = Units................................................8 =0A= 9.4. = Definition..................................................8 =0A= 10. Statistics definitions for Multicast instantaneous =0A= Packet = Loss...............................................8 =0A= 10.1. = Type-P-Multicast-Instantaneous-Packet-Loss-Percentile........9 =0A= 10.2. = Type-P-Multicast-Instantaneous-Packet-Loss-Median............9 =0A= 10.3. Type-P-Multicast-Instantaneous-Packet-Loss-Inverse =0A= = Percentile................................................9 =0A= 11. Multicast Instantaneous = Connectivity........................9 =0A= 11.1. Metric = Name..................................................9 =0A= 11.2. Metric = Parameters............................................9 =0A= 11.3. Metric = Units.................................................9 =0A= 11.4. = Definition...................................................9 =0A= 12. Measurement = framework......................................10 =0A= 12.1. = Security....................................................12 =0A= 12.2. Setup of a multicast instantaneous = measure..................12 =0A= 12.3. Definition of a multicast instantaneous = report..............12 =0A= 12.4. Upload of the multicast instantaneous measure = result........12 =0A= 12.5. Multicast and Spatial metrics = computation...................13 =0A= 13. IPPM-CONTROL-MIB = Definition................................13 =0A= 14. Security = Considerations....................................17 =0A= 14.1. = Privacy.....................................................17 =0A= 14.2. Measurement = aspects.........................................17 =0A= 14.3. Management = aspects..........................................18 =0A= 15. = References.................................................18 =0A= 16. = Acknowledgments............................................19 =0A= 17. Author's = Addresses.........................................19 =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 2] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= =0A= 1. Introduction =0A= =0A= The structure of the memo is as follows: =0A= =0A= + It defines a set of metrics for measuring the performance of = =0A= multicast networks. The metrics defined rely on the instantaneous = =0A= metrics specified in the IPPM WG. The next releases of this memo = will =0A= specify multicast metrics relying on the existing aggregated = metrics. =0A= The metrics definition are directly inspired by the WG RFC. =0A= =0A= =0A= + It makes a proposal to perform operational multicast =0A= measurements using the IPPM-MIB and SNMP messages to control =0A= both the setup and the reporting. The SNMP messages are =0A= specified using the SMIv2 NOTIFICATION-TYPE. =0A= =0A= the metrics specified derivate from those standardized by IPPM =0A= Working Group. There are built on notions introduced and discussed = in =0A= the IPPM Framework document, RFC 2330 [2]. =0A= =0A= There are companion documents to the IPPM MIB both in the Transport = =0A= Area and in the Operations and Management Area. The reader should be = =0A= familiar with these documents. =0A= =0A= 2. Motivation =0A= =0A= The network performance required for a multicast application depends = =0A= on its semantics. The main differences with unicast applications is = =0A= the asymmetrical connectivity and the variable number of sources and = =0A= receivers. =0A= =0A= The IPPM WG has designed metrics for measuring the performance of = =0A= unicast networks. The IPPM framework is applicable for multicast =0A= services. =0A= =0A= Multicast performance metrics are needed for several reasons: =0A= =0A= + for designing and engineering the multicast trees of the networks; = =0A= =0A= + for accounting multicast services; =0A= =0A= + for controlling the quality of the multicast services; =0A= =0A= + for controlling the performance of the inter domain multicast =0A= services. =0A= =0A= =0A= 3. The IPPM Framework =0A= =0A= The IPPM Framework consists in 3 major components: =0A= =0A= Stephan Informational - Expires August 2002 [Page 3] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= =0A= A general framework for defining performance metrics, described = =0A= in the Framework for IP Performance Metrics, RFC 2330 [2]; =0A= =0A= A set of standardized metrics which conform to this framework. = =0A= The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]. The = One-=0A= way Delay Metric for IPPM, RFC 2679 [4]. The One-way Packet Loss =0A= Metric for IPPM, RFC 2680 [5]. The Round-trip Delay Metric for IPPM, = =0A= RFC 2681 [6]; =0A= =0A= Emerging metrics which are being specified in respect of this =0A= framework; =0A= =0A= 4. Spatial hop one way delay metric =0A= =0A= The recommendation of the RFC2330 regarding spatial composition of = =0A= metric are applicable to the definition of a spatial one way delay = =0A= over a list of clouds. Such a metric is very useful for the =0A= computation of inter domain Type-P-One-way-Delay. =0A= =0A= =0A= 4.1. Metric Name =0A= =0A= Type-P-spatial-hop-one-way-delay =0A= =0A= 4.2. Metric Parameters =0A= =0A= + H0, the address of the sender. =0A= =0A= + Hn, the address of the receiver. =0A= =0A= + I, An integer which ordered the hosts in the path. =0A= =0A= + Hi, exchange points of the path digest. =0A= =0A= + T0, a time. =0A= =0A= + T1,..., Tn a list of time. =0A= =0A= + dT1,..., dTn a list of time. =0A= =0A= + P, the specification of the packet type. =0A= =0A= + a path digest. =0A= =0A= =0A= 4.3. Metric Units =0A= =0A= The unit is the same as the singleton Type-P-One-way-Delay defined in = =0A= [4]. The value of a Type-P-spatial-hop-One-way-Delay is either a real = =0A= number, or an undefined (informally, infinite) number of seconds. =0A= =0A= Stephan Informational - Expires August 2002 [Page 4] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= =0A= 4.4. Definition =0A= =0A= Given a Type P packet sent by the source H0 at T0 to Hn in the path = =0A= , given the sequence of time = =0A= of arrival of the packets in , a = Type-P-spatial-hop-one-=0A= way-delay metric is defined for a hop of the path as flowing: =0A= =0A= =0A= For a real number dTi, the Type-P-spatial-hop-One-way-Delay from Hi = =0A= to Hi+1 at Ti is dTi means that Hi sent the first bit of a Type-P = =0A= packet to Hi+1 at wire-time Ti and that Hi+1 received the last bit = of =0A= that packet at wire-time Ti+dTi. =0A= =0A= 5. Spatial One way delay stream metric =0A= =0A= 5.1. Metric Name =0A= =0A= Type-P-spatial-one-way-delay-stream =0A= =0A= 5.2. Metric Parameters =0A= =0A= + H0, the address of the sender. =0A= =0A= + Hn, the address of the receiver. =0A= =0A= + I, An integer which ordered the hosts in the path. =0A= =0A= + Hi, exchange points of the path digest. =0A= =0A= + T0, a time. =0A= =0A= + T1,..., Tn a list of time. =0A= =0A= + dT1,..., dTn a list of time. =0A= =0A= + P, the specification of the packet type. =0A= =0A= + a path digest. =0A= =0A= =0A= 5.3. Metric Units =0A= =0A= A sequence time. =0A= =0A= 5.4. Definition =0A= =0A= Given a Type P packet sent by the source H0 at T0 to Hn in the path = =0A= , given the sequence of time = =0A= of arrival of the packets in , a = Type-P-spatial-one-=0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 5] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= way-delay-stream metric is defined as the sequence of the Type-P-=0A= spatial-hop-one-way-delay values =0A= =0A= =0A= 6. Spatial One way delay metric =0A= =0A= 6.1. Metric Name =0A= =0A= Type-P-spatial-one-way-delay =0A= =0A= 6.2. Metric Parameters =0A= =0A= + H0, the address of the sender. =0A= =0A= + Hn, the address of the receiver. =0A= =0A= + I, An integer which ordered the hosts in the path. =0A= =0A= + Hi, exchange points of the path digest. =0A= =0A= + T0, a time. =0A= =0A= + T1,..., Tn a list of time. =0A= =0A= + dT1,..., dTn a list of time. =0A= =0A= + P, the specification of the packet type. =0A= =0A= + a path digest. =0A= =0A= =0A= 6.3. Metric Units =0A= =0A= A time. =0A= =0A= 6.4. Definition =0A= =0A= Given a Type P packet sent by the source H0 at T0 to Hn in the path = =0A= , given a Type-P-spatial-one-way-delay-stream = metric =0A= value, a Type-P-spatial-one-way-delay metric is = defined =0A= as the sum of each term of the Type-P-spatial-one-way-delay-stream. = =0A= =0A= 7. Multicast Instantaneous One-way Delay Stream =0A= =0A= 7.1. Metric Name =0A= =0A= Type-P-Multicast-Instantaneous-One-way-Delay-Stream =0A= =0A= 7.2. Metric Parameters =0A= =0A= + Src, the IP address of a host acting as the source. =0A= =0A= Stephan Informational - Expires August 2002 [Page 6] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= =0A= + Recv1,..., RecvN, the IP addresses of the N hosts acting as = =0A= receivers. =0A= =0A= + T0, a time. =0A= =0A= + dT1,...,dTn a list of time. =0A= =0A= + P, the specification of the packet type. =0A= =0A= + D0, a distance (e.g.: the number of hop). =0A= =0A= + dD1,...,dDn a list of distance. =0A= =0A= 7.3. Metric Units =0A= =0A= The value of a Type-P-Multicast-Instantaneous-One-way-Delay-Stream = is =0A= a set of singletons metrics Type-P-One-way-Delay [4]. =0A= =0A= 7.4. Definition =0A= =0A= Given a Type P packet sent by the source Src at T0, given the N = hosts =0A= { Recv1,...,RecvN } which are located at the distance { D0-=0A= dD1,...,D0-dDn } from Src and receive the packet at the time { =0A= T0+dT1,...,T0+dTn }, a = Type-P-Multicast-Instantaneous-One-way-Delay-=0A= Stream is defined as the set of the Type-P-One-way-Delay singleton = =0A= between Src and each receiver { dT1, dT2,...,dTn }. =0A= =0A= 8. Statistics definitions for Multicast instantaneous One-way Delay = =0A= =0A= This section was largely written by copying material from section = "5. =0A= Some Statistics Definitions for One-way Delay" of the RFC2679. =0A= =0A= Statistics among the set (or a subset) of the receivers are useful = =0A= when the delay is crucial for the multicast application. =0A= =0A= 8.1. Type-P-Multicast-Instantaneous-Hop-One-way-Delay =0A= =0A= Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream, the = =0A= Type-P-Multicast-Instantaneous-Hop-One-way-Delay metric is defined = as =0A= the average of all the delay per hop values (dDi/dTi) in the stream. = =0A= =0A= 8.2. Type-P-Multicast-Instantaneous-One-way-Delay-Percentile =0A= =0A= Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream and a = =0A= percent X between 0% and 100%, the = Type-P-Multicast-Instantaneous-=0A= One-way-Delay-Percentile metric is defined as the Xth percentile of = =0A= all the dT values in the stream. =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 7] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= 8.3. Type-P-Multicast-Instantaneous-One-way-Delay-Median =0A= =0A= Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream, the = =0A= Type-P-Multicast-Instantaneous-One-way-Delay-Median metric is = defined =0A= as the median of all the dT values in the Stream. =0A= =0A= =0A= 8.4. Type-P-Multicast-Instantaneous-One-way-Delay-Inverse-Percentile = =0A= =0A= Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream and a = =0A= time duration threshold, the = Type-P-Multicast-Instantaneous-One-way-=0A= Delay-Inverse-Percentile metric is defined as the fraction of all = the =0A= dT values in the stream less than or equal to the threshold. =0A= =0A= 9. Multicast Instantaneous Packet Loss Stream =0A= =0A= =0A= 9.1. Metric Name =0A= =0A= Type-P-Multicast-Instantaneous-Packet-Loss-Stream =0A= =0A= 9.2. Metric Parameters =0A= =0A= + Src, the IP address of a host acting as the source. =0A= =0A= + Recv1,..., RecvN, the IP addresses of the N hosts acting as =0A= receivers. =0A= =0A= + T0, a time. =0A= =0A= + T1,...,Tn =0A= =0A= + P, the specification of the packet type. =0A= =0A= 9.3. Metric Units =0A= =0A= The value of a Type-P-Multicast-Instantaneous-Packet-Loss-Stream is = a =0A= set of singletons metrics Type-P-One-way-Packet-Loss [6]. =0A= =0A= 9.4. Definition =0A= =0A= Given a Type P packet sent by the source Src at T0 and =0A= Recv1,...,RecvN the N hosts which should receive the packet at =0A= T1,...,Tn a Type-P-Multicast-Instantaneous-Packet-Loss-Stream is =0A= defined as the set of the Type-P-One-way-Packet-Loss singleton =0A= between Src and each of the receivers =0A= {,,...,}. =0A= =0A= 10. Statistics definitions for Multicast instantaneous Packet Loss =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 8] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= This section was largely written by copying material from the = section =0A= "4. Some Statistics Definitions for One-way Packet Loss" of the =0A= RFC2680. =0A= =0A= 10.1. Type-P-Multicast-Instantaneous-Packet-Loss-Percentile =0A= =0A= Given a Type-P-Multicast-Instantaneous-Packet-Loss-Stream and a = =0A= percent X between 0% and 100%, the = Type-P-Multicast-Instantaneous-=0A= Packet-Loss-Percentile metric is defined as the Xth percentile of = all =0A= the singleton values in the stream. =0A= =0A= =0A= 10.2. Type-P-Multicast-Instantaneous-Packet-Loss-Median =0A= =0A= Given a Type-P-Multicast-Instantaneous-Packet-Loss-Stream, the = =0A= Type-P-Multicast-Instantaneous-Packet-Loss-Median metric is defined = =0A= as the median of all the singleton values in the Stream. =0A= =0A= =0A= 10.3. Type-P-Multicast-Instantaneous-Packet-Loss-Inverse-Percentile =0A= =0A= Given a Type-P-Multicast-Instantaneous-Packet-Loss-Stream and a = =0A= time duration threshold, the = Type-P-Multicast-Instantaneous-Packet-=0A= Loss-Inverse-Percentile metric is defined as the fraction of all the = =0A= singleton values in the stream less than or equal to the threshold. = =0A= =0A= 11. Multicast Instantaneous Connectivity =0A= =0A= 11.1. Metric Name =0A= =0A= Type-P-Multicast-Instantaneous-Connectivity =0A= =0A= 11.2. Metric Parameters =0A= =0A= + Src, the address of a host acting as the source. =0A= =0A= + Node, the address of a router acting as a multicast repeater. =0A= =0A= + P, the specification of the packet type. =0A= =0A= 11.3. Metric Units =0A= =0A= An integer. =0A= =0A= 11.4. Definition =0A= =0A= Given a Type P packet sent by the multicast source Src at T0 and = Node =0A= a router acting as a multicast repeater, a Type-P-Multicast-=0A= Instantaneous-Node-Connectivity is defined as the number of time the = =0A= packet P is repeated by this node. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 9] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= This metric is useful to consolidate inter domain spatial metrics. = It =0A= determines the number of branches a node have. =0A= =0A= 12. Measurement framework =0A= =0A= Using unicast to establish a multicast measure among a source and a = =0A= huge number of receivers is not scalable mainly because of the =0A= bandwidth consumption of the setup, the duration of the setup and = the =0A= bandwidth needed to polling the result. =0A= =0A= To scale with the number of receivers the setup of the measure is = =0A= done using a message which is sent by the 'multicast' source to the = =0A= multicast receivers in the multicast flow. =0A= =0A= The message is specify using the SMIv2 NOTIFICATION-TYPE. It is send = =0A= by the source in the data flow. The message is a SNMP Trap which is = =0A= sent to the standard UDP port (162). =0A= =0A= The framework is usable to get the number of active receivers per = =0A= branch of the multicast tree. The routers (or sibling) have 'just' = to =0A= detect the setup messages and to send the current number of = multicast =0A= branches (existing somewhere in a MIB) and the time of the measure. = =0A= =0A= The consolidation is intrinsic because the setup packet is of the = =0A= same typeP as the other packets of the stream. It acts as the test = =0A= packet and use the same path as the multicast packets. =0A= =0A= The multicast channel may be a group specialized for the measures. = =0A= Then the number of active branches reported are those corresponding = =0A= to the source address of the setup. =0A= =0A= The IPPM-MIB implementation in the receivers and in the intermediary = =0A= systems may be very very light. The implementation of the IPPM-MIB = =0A= tables may be virtual. There in no need to record the results. The = =0A= identification of the measure relies on the owner namespace defined = =0A= in the IPPM-MIB. It consists only in two tasks: =0A= =0A= + Capturing the setup and its arrival time; =0A= =0A= + Sending the results in a SNMP Inform PDU to the NMS described = =0A= in the setup or to the default one of its the configuration. = =0A= =0A= =0A= Partial spatial metrics are computed in each provider IPPM-MIB proxy = =0A= entity. The broadcaster consults these values to complete the =0A= computation of the spatial metrics results. =0A= =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 10] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= 6.1. Inter domain architecture =0A= =0A= =0A= =0A= =0A= +----------------+ +----------------+ +----------------+ =0A= | NMS | | NMS | | NMS | = =0A= | Provider Foo | |Broadcaster Acme| | Provider Bar | = =0A= +----------------+ +----------------+ +----------------+ =0A= ^ ^ ^ ^ ^ = =0A= | | | | | =0A= | | | | | =0A= | | | | | =0A= SNMP or Sibling SNMP or Sibling SNMP or Sibling = =0A= | | | | | =0A= | | | | | =0A= | | | | | =0A= | +------------------+ | +-------------+ | =0A= | | | | | =0A= | | | | | =0A= v v v v v =0A= +----------------+ +----------------+ +----------------+ = =0A= |IPPM-MIB proxy | | mcast-Source | |IPPM-MIB proxy | = =0A= | Provider Foo | |Broadcaster Acme| | Provider Bar | = =0A= +----------------+ +----------------+ +----------------+ =0A= ^^^ ^ | ^ ^^^ =0A= ||| | | | ||| =0A= ||| | | | ||| =0A= SNMP inform PDU SNMP Trap SNMP inform PDU =0A= result mcast-setup result =0A= ||| | | | ||| =0A= ||| | | | ||| =0A= ||| | | | ||| =0A= ||| | +------------------+ | ||| =0A= ||| +----| mcast-Repeater | | ||| =0A= ||| |IPPM-MIB reporting|+ | ||| =0A= ||| +------------------+|+ | ||| = =0A= ||| +------------------+|-----+ ||| =0A= ||| +------------------+ ||| =0A= ||| | | ||| =0A= ||| | | ||| =0A= ||| +--------+ +------------+ ||| =0A= ||| | | ||| =0A= ||| v v ||| =0A= +------------------+ +------------------+ =0A= | mcast-Receiver | | mcast-Receiver | =0A= |IPPM-MIB reporting|+ |IPPM-MIB reporting|+ = =0A= +------------------+|+ +------------------+|+ = =0A= +------------------+| +------------------+| = =0A= +------------------+ +------------------+ = =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 11] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= In this architecture the Broadcaster send measure setups in the = =0A= multicast channel and access its providers IPPM-MIB proxies to get = =0A= the spatial metrics results per domain and to perform results =0A= concatenations. It means that the broadcaster have been previously = =0A= granted to setup a measure and to access to the results of the =0A= measure. =0A= =0A= =0A= 12.1. Security =0A= =0A= The proxy mode provides flexibility and a fine control of the access to = =0A= the points of measure while permitting lightweight implementations in = =0A= the points of measure. Different security rules may be applied to the = =0A= NMS domain and to measurement system domain. =0A= =0A= SNMP provides different levels of security according to the version = used =0A= and to the option chosen. SNMPv3 provides a high level of security. =0A= =0A= A public key may be added both in the =0A= ippmMulticastInstantaneousMeasureSetup and in the =0A= ippmMulticastInstantaneousMeasureSetup messages to clearly identify the = =0A= measure. =0A= =0A= 12.2. Setup of a multicast instantaneous measure =0A= =0A= The creation of the measure consists in sending the =0A= ippmMulticastInstantaneousMeasureSetup message in the multicast channel = =0A= using a SNMP trap. =0A= =0A= The NOTIFICATION-TYPE ippmMulticastInstantaneousMeasureSetup is defined = =0A= in the IPPM-CONTROL-MIB. =0A= =0A= It setups the measurement of the following singletons directly on the = =0A= message setup: =0A= =0A= Type-P-One-way-Delay, =0A= Type-P-One-way-Packet-Loss, =0A= Type-P-Multicast-Instantaneous-Connectivity, (*) =0A= Type-P-spatial-hop-one-way-delay (*) =0A= =0A= * only applicable for routers. =0A= =0A= 12.3. Definition of a multicast instantaneous report =0A= =0A= The definition of the report is included of the definition of the =0A= ippmMulticastInstantaneousMeasureSetup. =0A= =0A= 12.4. Upload of the multicast instantaneous measure result =0A= =0A= The results of the measure are pushed on the fly by each points of =0A= measure to the NMS choosen using the =0A= =0A= Stephan Informational - Expires August 2002 [Page 12] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= ippmMulticastInstantaneousMeasureReport message sentin a SNMP Inform = =0A= PDU. The NOTIFICATION-TYPE ippmMulticastInstantaneousMeasureReport is = =0A= defined in the IPPM-CONTROL-MIB. =0A= =0A= Note: The results are not pushed in the multicast channel. =0A= =0A= 12.5. Multicast and Spatial metrics computation =0A= =0A= The results are pushed to the IPPM-MIB proxy of provider and are =0A= usable to compute multicast metric measure and spatial metrics =0A= measure defined above. =0A= =0A= =0A= 13. IPPM-CONTROL-MIB Definition =0A= =0A= IPPM-CONTROL-MIB DEFINITIONS ::=3D BEGIN =0A= =0A= IMPORTS =0A= IppmMib, =0A= InstantaneousUnidirectionalConnectivity, =0A= InstantaneousBidirectionalConnectivity, =0A= intervalUnidirectionalConnectivity , =0A= intervalBidirectionalConnectivity, =0A= intervalTemporalConnectivity, =0A= onewayDelay, =0A= onewayDelayPoissonStream, =0A= onewayDelayPercentile, =0A= onewayDelayMedian, =0A= onewayDelayMinimum, =0A= onewayDelayInversePercentile, =0A= onewayPacketLoss, =0A= onewayPacketLossPoissonStream, =0A= onewayPacketLossAverage, =0A= roundtripDelay, =0A= roundtripDelayPoissonStream, =0A= roundtripDelayPercentile, =0A= roundtripDelayMedian, =0A= roundtripDelayMinimum, =0A= roundtripDelayInversePercentile =0A= FROM IPPM-MIB =0A= MODULE-IDENTITY, =0A= NOTIFICATION-TYPE, =0A= OBJECT-TYPE, =0A= Integer32, =0A= Counter32, =0A= experimental =0A= FROM SNMPv2-SMI =0A= OwnerString =0A= FROM RMON-MIB =0A= protocolDir =0A= FROM RMON2-MIB =0A= =0A= Stephan Informational - Expires August 2002 [Page 13] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= DisplayString, =0A= TimeStamp, =0A= DateAndTime, =0A= TruthValue, =0A= RowStatus, =0A= StorageType, =0A= TEXTUAL-CONVENTION =0A= FROM SNMPv2-TC =0A= MODULE-COMPLIANCE, =0A= OBJECT-GROUP, =0A= NOTIFICATION-GROUP =0A= FROM SNMPv2-CONF; =0A= =0A= =0A= ippmControlMib MODULE-IDENTITY =0A= LAST-UPDATED "200202111200Z" -- Feb 21, 2002 =0A= ORGANIZATION "France Telecom - R&D" =0A= CONTACT-INFO =0A= "Postal : Emile Stephan =0A= France Telecom - R&D, Dpt. CPN =0A= 2, Avenue Pierre Marzin =0A= Technopole Anticipa =0A= 22307 Lannion Cedex =0A= FRANCE =0A= Tel: + 33 2 96 05 36 10 =0A= E-mail: emile.stephan@francetelecom.com" =0A= DESCRIPTION =0A= " This memo defines a portion of the Management Information Base =0A= (MIB) for use with network management protocols in TCP/IP-based =0A= internets. In particular, It defines a set of NOTIFICATION-TYPE used = =0A= to control IPPM metrics measures, pushing alarms and reporting the = =0A= measures results. =0A= =0A= -- =0A= -- to be assigned by IANA =0A= -- =0A= ::=3D { experimental 10001 } =0A= =0A= -- =0A= -- IPPM multicast messages for the setup of the measure =0A= -- and the reporting of the result. =0A= -- =0A= =0A= ippmMulticastInstantaneousMeasureSetup NOTIFICATION-TYPE =0A= OBJECTS { =0A= -- measure setup =0A= ippmMeasureOwner, =0A= ippmMeasureIndex, =0A= =0A= -- Network measure setup =0A= ippmNetworkMeasureSrcTypeP, =0A= =0A= Stephan Informational - Expires August 2002 [Page 14] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= ippmNetworkMeasureSrc, =0A= ippmNetworkMeasureDstTypeP, =0A= ippmNetworkMeasureDst, =0A= ippmNetworkMeasureTimeoutDelay, =0A= =0A= -- report setup =0A= ippmReportSetupNMS, =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "The definition of the setup of an instantaneous multicast =0A= measure is sent by the broadcasting application or the probe in = =0A= the multicast channel using a SNMP trap defined in this =0A= NOTIFICATION-TYPE. =0A= =0A= On reception of the ippmMulticastInstantaneousMeasureSetup = =0A= setup the receiver or the router: =0A= =0A= + timestamp the arrival time of the setup; =0A= + considers the following defaults values; =0A= + prepare the ippmMulticastInstantaneousMeasureReport =0A= notification; =0A= + send the report using a SNMP Inform PDU. =0A= =0A= Defaults values: =0A= =0A= IppmMeasureEntry default values: =0A= =0A= ippmMeasureName: =0A= ippmMulticastInstantaneousMeasure; =0A= =0A= ippmMeasureMetrics: { =0A= Type-P-One-way-Delay, =0A= Type-P-One-way-Packet-Loss, =0A= Type-P-Multicast-Instantaneous-Connectivity, (*) =0A= Type-P-spatial-hop-one-way-delay (*) =0A= } =0A= =0A= ippmMeasureBeginTime: 0 =0A= =0A= ippmMeasureClockPeriodUnit: 0 =0A= ippmMeasureClockPeriod: 0 =0A= ippmMeasureDurationUnit: 0 =0A= ippmMeasureDuration: 0 =0A= ippmMeasureHystorySize: 0 =0A= ippmMeasureStorageType: other =0A= ippmMeasureStatus: createAndGo =0A= =0A= IppmNetworkMeasureEntry default values: =0A= =0A= IppmNetworkMeasureClockPattern: 0 =0A= =0A= Stephan Informational - Expires August 2002 [Page 15] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= IppmNetworkMeasureTimeoutDelay: 0 =0A= ippmNetworkMeasureL3PacketSize: 0 =0A= ippmNetworkMeasureDataPattern: 0 =0A= =0A= IppmippmReportSetupEntry default values: =0A= =0A= IppmReportSetupDefinition: { =0A= onSingleton, =0A= inInformRequestPDU, =0A= clearHistory =0A= =0A= } =0A= =0A= ippmReportSetupMetricThreshold: 0 =0A= ippmReportSetupEventsDurationThreshold: 0 =0A= =0A= (*) only considered by routers. =0A= " =0A= ::=3D { ippmControlMib 1 } =0A= =0A= ippmMulticastInstantaneousMeasureReport NOTIFICATION-TYPE =0A= -- measure setup =0A= ippmMeasureOwner, =0A= ippmMeasureIndex, =0A= =0A= -- Network measure setup =0A= ippmNetworkMeasureSrcTypeP, =0A= ippmNetworkMeasureSrc, =0A= ippmNetworkMeasureDstTypeP, =0A= ippmNetworkMeasureDst, =0A= =0A= -- report of the measure =0A= =0A= -- timestamp =0A= ippmHistoryTimeMark, =0A= =0A= -- value of the Type-P-One-way-Delay =0A= ippmHistoryValue, =0A= =0A= -- value of the Type-P-One-way-Packet-Loss =0A= ippmHistoryValue, =0A= =0A= -- value of the =0A= -- Type-P-Multicast-Instantaneous-Connectivity (*) =0A= ippmHistoryValue, =0A= =0A= -- value of the Type-P-spatial-hop-one-way-delay (*) = =0A= ippmHistoryValue =0A= =0A= } =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 16] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= STATUS current =0A= DESCRIPTION =0A= "This NOTIFICATION-TYPE is used by the receiver or the = =0A= router to push the result of the measure performed =0A= according the ippmMulticastInstantaneousMeasureSetup = =0A= setup. =0A= =0A= (*) is only applicable for router. =0A= { comment: =0A= This report definition has to be split to get one for = =0A= receiver and one for router.} =0A= =0A= Note: =0A= An ippmHistoryValue is indexed using the owner, the =0A= owner index, the metric index and the timestamp (e.g.: = =0A= acme.1.6.0106150820100100). So the metric index =0A= identifies which metric result (One-way-Delay, = Packet-=0A= Loss, Connectivity) the ippmHistoryValue carries." =0A= ::=3D { ippmControlMib 2 } =0A= =0A= =0A= END =0A= =0A= =0A= =0A= 14. Security Considerations =0A= =0A= Since this draft proposes sample metrics based on the One-way Delay = =0A= singleton metric defined in RFC2679 and RFC2680 it inherits the =0A= security considerations mentioned in this RFC. =0A= =0A= 14.1. Privacy =0A= =0A= The privacy concerns of network measurement are intrinsically = limited =0A= by the active measurements. Unlike passive measurements, there can = be =0A= no release of existing user data. =0A= =0A= =0A= 14.2. Measurement aspects =0A= =0A= Conducting Internet measurements raises both security and privacy = =0A= concerns. This memo does not specify an implementation of the =0A= metrics, so it does not directly affect the security of the Internet = =0A= nor of applications which run on the Internet. However, =0A= implementations of these metrics must be mindful of security and =0A= privacy concerns. =0A= =0A= There are two types of security concerns: potential harm caused by = =0A= the measurements, and potential harm to the measurements. The =0A= measurements could cause harm because they are active, and inject = =0A= packets into the network. The measurement parameters MUST be =0A= =0A= Stephan Informational - Expires August 2002 [Page 17] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= carefully selected so that the measurements inject trivial amounts = of =0A= additional traffic into the networks they measure. If they inject = =0A= "too much" traffic, they can skew the results of the measurement, = and =0A= in extreme cases cause congestion and denial of service. =0A= =0A= The measurements themselves could be harmed by routers giving =0A= measurement traffic a different priority than "normal" traffic, or = by =0A= an attacker injecting artificial measurement traffic. If routers can = =0A= recognize measurement traffic and treat it separately, the =0A= measurements will not reflect actual user traffic. If an attacker = =0A= injects artificial traffic that is accepted as legitimate, the loss = =0A= rate will be artificially lowered. Therefore, the measurement =0A= methodologies SHOULD include appropriate techniques to reduce the = =0A= probability measurement traffic can be distinguished from "normal" = =0A= traffic. =0A= =0A= Authentication techniques, such as digital signatures, may be used = =0A= where appropriate to guard against injected traffic attacks. =0A= =0A= =0A= 14.3. Management aspects =0A= =0A= There are a number of management objects defined in this MIB that = =0A= have a MAX-ACCESS clause of read-write and/or read-create. Such =0A= objects may be considered sensitive or vulnerable in some network = =0A= environments. The support for SET operations in a non-secure =0A= environment without proper protection can have a negative effect on = =0A= network operations. =0A= =0A= SNMPv1 by itself is not a secure environment. Even if the network = =0A= itself is secure (for example by using IPSec), even then, there is = no =0A= control as to who on the secure network is allowed to access and =0A= GET/SET (read/change/create/delete) the objects in this MIB. =0A= =0A= It is recommended that the implementors consider the security =0A= features as provided by the SNMPv3 framework. Specifically, the use = =0A= of the User-based Security Model RFC 2574 [18] and the View-based = =0A= Access Control Model RFC 2575 [21] is recommended. =0A= =0A= It is then a customer/user responsibility to ensure that the SNMP = =0A= entity giving access to an instance of this MIB, is properly =0A= configured to give access to the objects only to those principals = =0A= (users) that have legitimate rights to indeed GET or SET =0A= (change/create/delete) them. =0A= =0A= =0A= 15. References =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 18] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= =0A= [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP = =0A= 9, RFC 2026, October 1996. =0A= =0A= [2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for = =0A= IP Performance Metrics", RFC 2330, May 1998. =0A= =0A= [3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring =0A= Connectivity", RFC 2678, September 1999. =0A= =0A= [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay = =0A= Metric for IPPM", RFC 2679, September 1999. =0A= =0A= [5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet = =0A= Loss Metric for IPPM", RFC 2680, September 1999. =0A= =0A= [6]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay = =0A= Metric for IPPM.", RFC 2681, September 1999. =0A= =0A= =0A= 16. Acknowledgments =0A= =0A= A Kerbe. =0A= =0A= 17. Author's Addresses =0A= =0A= Emile STEPHAN =0A= France Telecom R & D =0A= 2 avenue Pierre Marzin =0A= F-22307 Lannion cedex =0A= Phone: (+ 33) 2 96 05 11 11 =0A= Email: emile.stephan@francetelecom.com =0A= =0A= =0A= Full Copyright Statement =0A= =0A= =0A= "Copyright (C) The Internet Society (2001). All Rights Reserved. =0A= =0A= This document and translations of it may be copied and furnished to = =0A= others, and derivative works that comment on or otherwise explain it = =0A= or assist its implementation may be prepared, copied, published and = =0A= distributed, in whole or in part, without restriction of any kind, = =0A= provided that the above copyright notice and this paragraph are =0A= included on all such copies and derivative works. However, this =0A= document itself may not be modified in any way, such as by removing = =0A= the copyright notice or references to the Internet Society or other = =0A= Internet organizations, except as needed for the purpose of =0A= developing Internet standards in which case the procedures for =0A= copyrights defined in the Internet Standards process must be =0A= followed, or as required to translate it into languages other than = =0A= English. =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 19] = =0A= =0A= =0C=0A= Internet Draft multicast metrics February 2002 = =0A= =0A= =0A= =0A= The limited permissions granted above are perpetual and will not be = =0A= revoked by the Internet Society or its successors or assigns. =0A= =0A= This document and the information contained herein is provided on an = =0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING = =0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING = =0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION =0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF =0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Stephan Informational - Expires August 2002 [Page 20] = =0A= =0A= =0C ------_=_NextPart_000_01C1BBBF.7416BF40-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sun Feb 24 20:52:34 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18505 for ; Sun, 24 Feb 2002 20:52:34 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1P1p3rk032495; Sun, 24 Feb 2002 20:51:03 -0500 Received: from mail.cad.zju.edu.cn (cad.zju.edu.cn [210.32.131.2]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g1P1oprk032354 for ; Sun, 24 Feb 2002 20:50:55 -0500 Received: (qmail 17932 invoked from network); 25 Feb 2002 01:55:04 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 25 Feb 2002 01:55:04 -0000 Message-ID: <3C799878.30A3D26E@cad.zju.edu.cn> Date: Mon, 25 Feb 2002 09:50:48 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Content-Type: multipart/alternative; boundary="------------A3DF5BE3B4DA8A158BE3C561" Subject: [ippm] seeking for Mukherjee's Paper on internet load Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --------------A3DF5BE3B4DA8A158BE3C561 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I'm trying to find a online copy of A. Mukherjee's paper "On the Dynamics and Significance of Low Frequency Components of Internet Load" published in the December 1994 edition of Internetworking:Research and Experience. I've read about message on the following address http://LINC2.CIS.UPENN.EDU/~techreports/abstracts92.html , but I can't access it. I don't know whether the server is down or other reason cause it. Is there anybody can do me a favor on giving some help? -- Jing Shen State Key Lab of CAD&CG ZheJiang University (YuQuan) HangZhou, ZheJiang Province 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** --------------A3DF5BE3B4DA8A158BE3C561 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hi,

I'm trying to find a online copy of  A. Mukherjee's paper  "On  the Dynamics and Significance of Low
Frequency Components of Internet  Load"
published in the December 1994 edition of Internetworking:Research and Experience.

I've read about message on the following address
http://LINC2.CIS.UPENN.EDU/~techreports/abstracts92.html , but I can't
access it. I don't know whether the server is down or other reason cause it.  Is there anybody can do
me a favor on giving some help?
  

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University (YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************
  --------------A3DF5BE3B4DA8A158BE3C561-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 05:07:58 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03758 for ; Mon, 25 Feb 2002 05:07:58 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PA73rk027447; Mon, 25 Feb 2002 05:07:03 -0500 Received: from skybar.pilsnet.sunet.se (skybar.pilsnet.sunet.se [192.36.125.99]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PA6erk027347 for ; Mon, 25 Feb 2002 05:06:40 -0500 Received: from nada.kth.se (IDENT:adrian@corvette.pilsnet.sunet.se [192.36.125.112]) by skybar.pilsnet.sunet.se (8.9.3/8.9.3) with ESMTP id LAA40916 for ; Mon, 25 Feb 2002 11:06:39 +0100 (CET) Message-ID: <3C7A17DE.81AB8B50@nada.kth.se> Date: Mon, 25 Feb 2002 11:54:22 +0100 From: Adrian Popescu Organization: Royal Institute of Technology, Stockholm X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] correlated queues Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hi, I am trying to do analysis on delay in correlated queue(s) in a communication system, to also capture Long-Range Dependence properties in network traffic. The analysis can be done either at a packet or at a message level and Kleinrock's independency assumption seems to quite limited in this case. I would be very thankful if I can get information regarding this type of questions. Thanking you in advance, Adrian Popescu -------------------------------------------------------------------- Adrian Popescu Phone + 46 8 7906560 Facsimile + 46 8 241179 Dept. of Numerical Analysis Email adrian@nada.kth.se & Computer Science adr@acm.org Royal Inst. of Technology URL http://www.nada.kth.se/~adrian S-100 44 Stockholm, Sweden _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 06:23:55 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05122 for ; Mon, 25 Feb 2002 06:23:55 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PBN2rk031767; Mon, 25 Feb 2002 06:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PBMurk031574 for ; Mon, 25 Feb 2002 06:22:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04855; Mon, 25 Feb 2002 06:22:55 -0500 (EST) Message-Id: <200202251122.GAA04855@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Feb 2002 06:22:55 -0500 Subject: [ippm] I-D ACTION:draft-jeong-1way-delay-ipv6-source-routing-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : One-way Delay Measurement using IPv6 Source Routing Author(s) : J. Jeong et al. Filename : draft-jeong-1way-delay-ipv6-source-routing-00.txt Pages : 9 Date : 22-Feb-02 This document specifies a methodology for measurement of the IETF IPPM WG's one-way IP performance metrics such as one-way delay and jitter of subpaths consisting of a specific end-to-end path in IPv6 network as well as end-to-end one-way IP performance metrics. The methodology measures one-way IP performance metrics in use of IPv6 source routing through IPv6 extension headers. Because the methodology can contribute to the finding of congested link or underutilized link, it can provide important information to configure and manage IPv6 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-1way-delay-ipv6-source-routing-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jeong-1way-delay-ipv6-source-routing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-1way-delay-ipv6-source-routing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020222110553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-1way-delay-ipv6-source-routing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-1way-delay-ipv6-source-routing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020222110553.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 06:26:52 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05386 for ; Mon, 25 Feb 2002 06:26:51 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PBP4rk000549; Mon, 25 Feb 2002 06:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PBOwrk032758 for ; Mon, 25 Feb 2002 06:24:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05352; Mon, 25 Feb 2002 06:24:57 -0500 (EST) Message-Id: <200202251124.GAA05352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Feb 2002 06:24:57 -0500 Subject: [ippm] I-D ACTION:draft-mcgregor-ipmp-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Measurement Protocol (IPMP) Author(s) : A. McGregor Filename : draft-mcgregor-ipmp-00.txt Pages : 15 Date : 22-Feb-02 The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. IPMP is tightly constrained and easy to implement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcgregor-ipmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mcgregor-ipmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020222122603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcgregor-ipmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcgregor-ipmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020222122603.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 10:32:00 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13943 for ; Mon, 25 Feb 2002 10:32:00 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PFT2rk006514; Mon, 25 Feb 2002 10:29:02 -0500 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PFSBrk006112 for ; Mon, 25 Feb 2002 10:28:12 -0500 Received: from surfnet.nl (sluffy.heanet.ie [193.1.219.219]) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id PAA23862 for ; Mon, 25 Feb 2002 15:28:11 GMT Message-ID: <3C7A57DF.55088019@surfnet.nl> Date: Mon, 25 Feb 2002 15:27:27 +0000 From: Victor Reijs Reply-To: victor.reijs@surfnet.nl Organization: SURFnet bv X-Sender: "Victor Reijs" <@mail.heanet.ie> X-Mailer: Mozilla 4.77 [en]C-CCK-MCD SURFKITV4 (Windows NT 5.0; U) X-Accept-Language: nl,en MIME-Version: 1.0 To: IPPM Working Group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] RE: Management requirements. Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello Emile, Thanks for your draft document (nov. 2001). Just a few points: . I think OWDP is the old name; I assume it should mow be OWAMP. . Please also have a look at the basic specification I foresee for a measurement infrastructure: http://www.dante.net/tf-ngn/D9.4v2.pdf (section 3.3) Most of them are covered by your proposal, but I think a few still need some more though, like: + explicitly mention that it is supporting passive and active measurements. Or do you think it only should support one of the two? + resource control; I think this is something the Management plane has to control. Not only for 'accuracy' reasons but also for load reasons (and perhaps also 'oscillation' reason, see next point). . is 'the sampling law' something that only the management requirements needs to define? Is that also not something for the individual measurements to take into account? So this is a shared issue. . is a reference to NIMI also not helpful? Hope you can use the above comments. All the best, Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 11:34:20 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16852 for ; Mon, 25 Feb 2002 11:34:19 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PGX2rk020955; Mon, 25 Feb 2002 11:33:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PGWqrk020861 for ; Mon, 25 Feb 2002 11:32:52 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id D9C1C5EE33 for ; Mon, 25 Feb 2002 11:32:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 30A775EE07 for ; Mon, 25 Feb 2002 11:32:40 -0500 (EST) To: ippm@advanced.org Subject: [ippm] draft-jeong-1way-delay-ipv6-source-routing-00.txt References: <200202251122.GAA04855@ietf.org> From: stanislav shalunov Date: 25 Feb 2002 11:33:20 -0500 In-Reply-To: <200202251122.GAA04855@ietf.org> Message-ID: <87pu2t4j3j.fsf@cain.internet2.edu> Lines: 9 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This draft appears to define a new IPv6 option to record timestamps as a packet goes past IPv6 routers. Is this method better than IPMP or is this just another way of doing the same thing that IPMP does? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ But we must show them that they cannot terrorize the greatest nation on the face of the Earth. And we won't. -- George W. Bush, 20011017 _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 11:54:00 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18182 for ; Mon, 25 Feb 2002 11:53:59 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PGr3rk025361; Mon, 25 Feb 2002 11:53:03 -0500 Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g1PGqdrk025217 for ; Mon, 25 Feb 2002 11:52:40 -0500 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 17:52:25 +0100 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: IPPM Working Group Cc: victor.reijs@surfnet.nl Subject: RE: [ippm] RE: Management requirements. Date: Mon, 25 Feb 2002 17:52:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6e41cf26-29fb-11d6-b1e5-00508b69ab48" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-6e41cf26-29fb-11d6-b1e5-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE1C.D186AAF0" ------_=_NextPart_001_01C1BE1C.D186AAF0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Victor, you got the point this release of the draft-stephan-ippm-mgmt-reqs.txt = has to be upgraded.=20 At the time I started to write it(September 2001) the official name of = the control protocol was still OWDP. Passive measures are out of the scope = of the IPPM WG (please verify). I plan to upgrade it in April. I have a couple of points to add in it regarding the needs for the management of inter domain spatial metrics result (see draft-stephan-ippm-multicast-metrics-00.txt).=20 Could you be more specific about "Is that also not something for the individual measurements to take into account? "=20 regards emile =20 -----Message d'origine----- De : Victor Reijs [mailto:victor.reijs@surfnet.nl] Envoy=E9 : lundi 25 f=E9vrier 2002 16:27 =C0 : IPPM Working Group Objet : [ippm] RE: Management requirements. Hello Emile,=20 Thanks for your draft document (nov. 2001). Just a few points:=20 . I think OWDP is the old name; I assume it should mow be OWAMP. . Please also have a look at the basic specification I foresee for a=20 measurement infrastructure:=20 http://www.dante.net/tf-ngn/D9.4v2.pdf (section 3.3)=20 Most of them are covered by your proposal, but I think a few still need = some more though, like: + explicitly mention that it is supporting passive and active=20 measurements. Or do you think it only should support one of the two? + resource control; I think this is something the Management plane = has to=20 control. Not only for 'accuracy' reasons but also for load reasons (and = perhaps also 'oscillation' reason, see next point). . is 'the sampling law' something that only the management = requirements needs to=20 define? Is that also not something for the individual measurements to take into account?=20 So this is a shared issue. . is a reference to NIMI also not helpful?=20 Hope you can use the above comments.=20 All the best,=20 Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm ------_=_NextPart_001_01C1BE1C.D186AAF0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ippm] RE: Management requirements.

Hi Victor,

you got the point this release of the = draft-stephan-ippm-mgmt-reqs.txt has to be upgraded.

At the time I started to write it(September 2001) the = official name of the control protocol was still OWDP. Passive measures = are out of the scope of the IPPM WG (please verify).

I plan to upgrade it in April. I have a couple of = points to add in it regarding the needs for the management of inter = domain spatial metrics result (see = draft-stephan-ippm-multicast-metrics-00.txt).

Could you be more specific about "Is that also = not something for the individual measurements to take into account? = "

regards
emile


 
-----Message d'origine-----
De : Victor Reijs [mailto:victor.reijs@surfnet.nl]
Envoy=E9 : lundi 25 f=E9vrier 2002 16:27
=C0 : IPPM Working Group
Objet : [ippm] RE: Management requirements.


Hello Emile,

Thanks for your draft document (nov. 2001). Just a = few points:
. I think OWDP is the old name; I assume it should = mow be OWAMP.
. Please also have a look at the basic specification = I foresee for a
measurement infrastructure:
http://www.dante.net/tf-ngn/D9.4v2.pdf (section = 3.3)
Most of them are covered by your proposal, but I = think a few still need
some more though, like:
  + explicitly mention that it is supporting = passive and active
measurements. Or do you think it only should support = one of the two?
  + resource control; I think this is something = the Management plane has
to
control. Not only for 'accuracy' reasons but also = for load reasons (and
perhaps also 'oscillation' reason, see next = point).
. is 'the sampling law' something that only the = management requirements
needs to
define? Is that also not something for the = individual measurements to
take into account?
So this is a shared issue.
. is a reference to NIMI also not helpful?


Hope you can use the above comments.


All the best,


Victor
_______________________________________________
ippm mailing list
ippm@advanced.org
http://mailhost.advanced.org/mailman/listinfo/ippm=

------_=_NextPart_001_01C1BE1C.D186AAF0-- ------=_NextPartTM-000-6e41cf26-29fb-11d6-b1e5-00508b69ab48-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 12:06:56 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18982 for ; Mon, 25 Feb 2002 12:06:56 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PH42rk030291; Mon, 25 Feb 2002 12:04:02 -0500 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PH3Hrk029090 for ; Mon, 25 Feb 2002 12:03:18 -0500 Received: from surfnet.nl (sluffy.heanet.ie [193.1.219.219]) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id RAA32005; Mon, 25 Feb 2002 17:03:17 GMT Message-ID: <3C7A6E29.AD913E96@surfnet.nl> Date: Mon, 25 Feb 2002 17:02:33 +0000 From: Victor Reijs Reply-To: victor.reijs@surfnet.nl Organization: SURFnet bv X-Sender: "Victor Reijs" <@mail.heanet.ie> X-Mailer: Mozilla 4.77 [en]C-CCK-MCD SURFKITV4 (Windows NT 5.0; U) X-Accept-Language: nl,en MIME-Version: 1.0 To: STEPHAN Emile FTRD/DAC/LAN CC: IPPM Working Group Subject: Re: [ippm] RE: Management requirements. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello Emile, > STEPHAN Emile FTRD/DAC/LAN wrote: > > Hi Victor, > > you got the point this release of the draft-stephan-ippm-mgmt-reqs.txt > has to be upgraded. > > At the time I started to write it(September 2001) the official name of > the control protocol was still OWDP. Passive measures are out of the > scope of the IPPM WG (please verify). Is it in principle possible to provide both with your frame work set up, or is it only not possible because it is outside the scope of IPPM? If it is a princple (technology) issue in your frame-work, can you point me out what that principle issue is? All the best, Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 12:16:01 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19324 for ; Mon, 25 Feb 2002 12:16:01 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PH92rk031571; Mon, 25 Feb 2002 12:09:02 -0500 Received: from byerley.cs.waikato.ac.nz (byerley.cs.waikato.ac.nz [130.217.250.10]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1P3QFrk005520 for ; Sun, 24 Feb 2002 22:26:16 -0500 Received: from tonym (helo=localhost) by byerley.cs.waikato.ac.nz with local-esmtp (Exim 3.12 #1 (Debian)) id 16fBmI-00063n-00 for ; Mon, 25 Feb 2002 16:26:14 +1300 Date: Mon, 25 Feb 2002 16:26:14 +1300 (NZDT) From: Tony McGregor To: ippm@advanced.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] ID draft-ietf-mcgregor-ippm-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List A New Internet-Draft is available from the on-line Internet-Drafts directories. This is a personal draft that may be of interest to members of IPPM. Title : IP Measurement protocol Author(s) : A McGregor Filename : draft-mcgregor-ipmp-00.txt Pages : 15 Date : 22-Feb-02 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-00.txt The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. IPMP is tightly constrained and easy to implement. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcgregor-ipmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft--mcgregor-ipmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011121140825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcgregor-ipmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcgregor-ipmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121140825.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Feb 25 15:16:52 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28181 for ; Mon, 25 Feb 2002 15:16:51 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PKG2rk007912; Mon, 25 Feb 2002 15:16:02 -0500 Received: from mave.nlanr.net (mave.nlanr.net [198.202.74.38]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1PKFarl007722 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 25 Feb 2002 15:15:38 -0500 Received: from localhost (mjl@localhost) by mave.nlanr.net (8.11.1/8.11.1) with ESMTP id g1PKFZo45470; Mon, 25 Feb 2002 12:15:35 -0800 (PST) (envelope-from mjl@nlanr.net) X-Authentication-Warning: mave.nlanr.net: mjl owned process doing -bs Date: Mon, 25 Feb 2002 12:15:35 -0800 (PST) From: Matthew Luckie To: stanislav shalunov cc: ippm@advanced.org Subject: Re: [ippm] draft-jeong-1way-delay-ipv6-source-routing-00.txt In-Reply-To: <87pu2t4j3j.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List > This draft appears to define a new IPv6 option to record timestamps as > a packet goes past IPv6 routers. Is this method better than IPMP or > is this just another way of doing the same thing that IPMP does? it is an interesting approach given that it uses the IPv6 routing header. there are likely to be other IPv6 hacks useful for measurement. a limitation of this approach is that you need to know a forward path in advance to use a routing header, which is a somewhat contrived way of doing an IPMP-style measurement, and probably won't help you detect route changes. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 26 06:00:07 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22882 for ; Tue, 26 Feb 2002 06:00:07 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1QAv3rk005514; Tue, 26 Feb 2002 05:57:03 -0500 Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with SMTP id g1QAu7rk005365 for ; Tue, 26 Feb 2002 05:56:08 -0500 Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 11:55:56 +0100 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: IPPM Working Group Subject: RE: [ippm] RE: Management requirements. Date: Tue, 26 Feb 2002 11:56:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-73e511c6-29f3-11d6-ac1f-00508b692753" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-73e511c6-29f3-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEB4.309A16C0" ------_=_NextPart_001_01C1BEB4.309A16C0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi victor, Do you mean that the IPPM MIB has to manage passive measure too ? regards Emile -----Message d'origine----- De : Victor Reijs [mailto:victor.reijs@surfnet.nl] Envoy=E9 : lundi 25 f=E9vrier 2002 18:03 =C0 : STEPHAN Emile FTRD/DAC/LAN Cc : IPPM Working Group Objet : Re: [ippm] RE: Management requirements. Hello Emile, > STEPHAN Emile FTRD/DAC/LAN wrote: >=20 > Hi Victor, >=20 > you got the point this release of the = draft-stephan-ippm-mgmt-reqs.txt > has to be upgraded. >=20 > At the time I started to write it(September 2001) the official name = of > the control protocol was still OWDP. Passive measures are out of the > scope of the IPPM WG (please verify). Is it in principle possible to provide both with your frame work set = up, or is it only not possible because it is outside the scope of IPPM? If it is a princple (technology) issue in your frame-work, can you = point me out what that principle issue is? All the best, Victor ------_=_NextPart_001_01C1BEB4.309A16C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ippm] RE: Management requirements.

Hi victor,

Do you mean that the IPPM MIB has to manage passive = measure too ?

regards
Emile



-----Message d'origine-----
De : Victor Reijs [mailto:victor.reijs@surfnet.nl]
Envoy=E9 : lundi 25 f=E9vrier 2002 18:03
=C0 : STEPHAN Emile FTRD/DAC/LAN
Cc : IPPM Working Group
Objet : Re: [ippm] RE: Management = requirements.


Hello Emile,

> STEPHAN Emile FTRD/DAC/LAN wrote:
>
> Hi Victor,
>
> you got the point this release of the = draft-stephan-ippm-mgmt-reqs.txt
> has to be upgraded.
>
> At the time I started to write it(September = 2001) the official name of
> the control protocol was still OWDP. Passive = measures are out of the
> scope of the IPPM WG (please verify).

Is it in principle possible to provide both with your = frame work set up,
or is it only not possible because it is outside the = scope of IPPM?
If it is a princple (technology) issue in your = frame-work, can you point
me out what that principle issue is?


All the best,


Victor

------_=_NextPart_001_01C1BEB4.309A16C0-- ------=_NextPartTM-000-73e511c6-29f3-11d6-ac1f-00508b692753-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 26 08:45:17 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29041 for ; Tue, 26 Feb 2002 08:45:17 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1QDi3rk024774; Tue, 26 Feb 2002 08:44:03 -0500 Received: from urda.heanet.ie (urda.heanet.ie [193.1.219.124]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1QDhPrk024675 for ; Tue, 26 Feb 2002 08:43:26 -0500 Received: from surfnet.nl (vreijs.heanet.ie [193.1.219.219] (may be forged)) by urda.heanet.ie (8.9.3/8.9.3) with ESMTP id NAA12331; Tue, 26 Feb 2002 13:43:24 GMT Message-ID: <3C7B90D0.FD441B13@surfnet.nl> Date: Tue, 26 Feb 2002 13:42:40 +0000 From: Victor Reijs Reply-To: victor.reijs@surfnet.nl Organization: SURFnet bv X-Sender: "Victor Reijs" <@mail.heanet.ie> X-Mailer: Mozilla 4.77 [en]C-CCK-MCD SURFKITV4 (Windows NT 5.0; U) X-Accept-Language: nl,en MIME-Version: 1.0 To: STEPHAN Emile FTRD/DAC/LAN CC: IPPM Working Group Subject: Re: [ippm] RE: Management requirements. References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g1QDhPrk024675 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 8bit Hello Emile, > STEPHAN Emile FTRD/DAC/LAN wrote: > > Hi victor, > > Do you mean that the IPPM MIB has to manage passive measure too ? Most MIB hold passive measurements (like counters of bytes, errors, etc.), so I don't think that IPPM MIB has to cover the passive ones. But I am not referring to IPPM MIB. I am only looking at the potential capabilities of your protocol/implementation (mgmt-reqs.txt), so is it really confined to only active or not? I would prefer solution that can handle both for active or passive, certainly if there are so potential boardly usable as yours (or NIMI's). All the best, Victor > > regards > Emile > > -----Message d'origine----- > De : Victor Reijs [mailto:victor.reijs@surfnet.nl] > Envoyé : lundi 25 février 2002 18:03 > À : STEPHAN Emile FTRD/DAC/LAN > Cc : IPPM Working Group > Objet : Re: [ippm] RE: Management requirements. > > Hello Emile, > > > STEPHAN Emile FTRD/DAC/LAN wrote: > > > > Hi Victor, > > > > you got the point this release of the > draft-stephan-ippm-mgmt-reqs.txt > > has to be upgraded. > > > > At the time I started to write it(September 2001) the official name > of > > the control protocol was still OWDP. Passive measures are out of the > > > scope of the IPPM WG (please verify). > > Is it in principle possible to provide both with your frame work set > up, > or is it only not possible because it is outside the scope of IPPM? > If it is a princple (technology) issue in your frame-work, can you > point > me out what that principle issue is? > > All the best, > > Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Feb 26 20:10:06 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26878 for ; Tue, 26 Feb 2002 20:10:06 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1R172rk020335; Tue, 26 Feb 2002 20:07:02 -0500 Received: from tripod-int.labs.agilent.com (tripod-ext.labs.agilent.com [192.25.140.133]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1QDahrk022977 for ; Tue, 26 Feb 2002 08:36:43 -0500 Received: from unicorn.labs.agilent.com (root@unicorn.labs.agilent.com [130.29.252.5]) by tripod-int.labs.agilent.com (8.11.4/8.11.4/Agilent Labs Bastion Host v 01.01 2001/01/08) with ESMTP id g1QDWjp28771; Tue, 26 Feb 2002 05:32:45 -0800 Received: from alex2.labs.agilent.com (alex2.labs.agilent.com [130.29.252.56]) by unicorn.labs.agilent.com (8.11.2/8.11.2/Agilent Labs Mail Hub v 01.01 2001/01/05) with SMTP id g1QDVhb20929; Tue, 26 Feb 2002 05:31:43 -0800 (PST) Received: from 130.29.252.56 by alex2.labs.agilent.com (InterScan E-Mail VirusWall NT); Tue, 26 Feb 2002 05:31:43 -0800 Received: by ALEX2 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 05:31:43 -0800 Message-ID: From: rick_whitner@agilent.com To: pam2002@labs.agilent.com Date: Tue, 26 Feb 2002 05:31:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ippm] PAM2002 Registration is Open (please forward) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List [Our apologies if you receive multiple copies of this announcement.] Passive & Active Measurement: PAM 2002 A workshop on passive and active measurement and analysis techniques for high speed computer networks and the Internet Fort Collins, Colorado, USA March 25-26, 2002 To register, go to http://www.labs.agilent.com/hosted/conferences/pam2002/registration/ PAM 2002 is a two-day event focusing on research and practical applications of passive and active measurement and analysis techniques for high speed computer networks and the Internet. Registration for this workshop is now. The cost of the workshop is $300 (US). Attendance will be limited. The preliminary program is available on the website. Contact information: * PAM 2002 c/o Agilent Laboratories 4800 Wheaton Dr Fort Collins, CO 80525 USA * Phone: +1-970-288-3821 * Fax: +1-970-288-4234 * Email: pam2002@labs.agilent.com * Webpage: http://www.labs.agilent.com/pam2002 _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Feb 28 09:44:40 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25551 for ; Thu, 28 Feb 2002 09:44:40 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1SEh2rk020993; Thu, 28 Feb 2002 09:43:02 -0500 Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by mailhost.advanced.org (8.12.1/8.12.1/Debian -2) with ESMTP id g1S1pBrk006949 for ; Wed, 27 Feb 2002 20:51:12 -0500 Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g1S1pCgB019469 for ; Wed, 27 Feb 2002 18:51:12 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.10.2+Sun/8.10.2) id g1S1pCD29825 for ippm@advanced.org; Wed, 27 Feb 2002 18:51:12 -0700 (MST) Date: Wed, 27 Feb 2002 18:51:12 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200202280151.g1S1pCD29825@ece2.ece.arizona.edu> To: ippm@advanced.org Subject: [ippm] Mobicom 2002 - Final CFP Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List *************************************************************** [Appologies if you receive duplicates of this message] Please note the following changes in this CFP: - Paper submission details have been revised. - A Student Poster Session has been added. - Student travel grants are now available. See below for details. *************************************************************** F I N A L C A L L F O R P A P E R S *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Paper Submission Deadline (EXTENDED): March 8, 2002 ******** No further extensions will be given ********* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: ------- Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: ------------------ Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. **REVISED SUBMISSION INSTRUCTIONS**: ------------------------------------ All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. No other format will be accepted. Papers must meet the following restrictions: - The paper must be original material that has not been previously published nor is currently under review by another conference or journal. - Full papers should be no longer than *15 pages*, in font no smaller than 10 points. (Note that accepted papers, when formatted for the proceedings, may not exceed 12 pages in font no smaller than 9 points). - Challenges papers should be no longer than 8 pages, in font no smaller than 10 points. - All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names *must not* appear in the paper. - The paper should fit properly on US Letter-sized paper (8.5x11 inches) - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file - The paper must be formatted for b/w printers and not color printers. Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ TUTORIALS: ---------- Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: ------- Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: --------------- Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). ** STUDENT POSTER SESSION **: --------------------------- The conference solicits student posters that highlight recent and on-going research by students on mobile computing topics. Proposals should be a maximum of two pages in length. While it does not need to describe completed work, the poster paper should report on research that is beyond the initial stages. The first author of a poster submission must be a student. Poster abstracts will not be published in the proceedings but will instead be published on the web before the conference. Poster submissions will be reviewed. Authors of accepted papers must not submit a poster of the work they present in the conference. For more information about student poster applications contact the Student Poster Co-chairs (ebelding@cs.ucsb.edu or sjlee@hpl.hp.com). **STUDENT TRAVEL AWARDS**: -------------------------- MobiCom will offer a limited number of travel grants to support students. Please contact Student Travel Awards Co-Chairs for application details (fang@ece.ufl.edu or syrotiuk@utdallas.edu). BEST STUDENT PAPER AWARD: ------------------------- Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: ---------------- * Paper submissions due: March 8, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 * Tutorial proposals: May 1, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu EXECUTIVE COMMITTEE: -------------------- * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Mercury Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Co-Chairs: - Suresh Singh, Portland State University - Robin Kravets, University of Illinois, Urbana-Champaign * Student Poster Co-Chairs: - Elizabeth M. Belding-Royer, University of California, Santa Barbara - Sung-Ju Lee, HP Laboratories * Student Travel Award Co-Chairs: - Yuguang Fang, University of Florida - Violet R. Syrotiuk, University of Texas at Dallas * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Webmaster: Michael E. Kounavis, Columbia University PROGRAM COMMITTEE: -------------------- Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University Program Committee: - Arup Acharya, IBM Research - Prathima Agrawal, Telcordia - B. R. Badrinath, Rutgers University - Victor Bahl, Microsoft Research - Stefano Basagni, Northeastern University - Roberto Battiti, University of Trento - Pravin Bhagwat, ReefEdge - Chatschik Bisdikian, IBM Research - Scott Corson, Flarion - Sajal Das, University Texas at Arlington - Nigel Davies, Lancaster University - Dan Duchamp, Stevens Institute of Technology - Maria Ebling, IBM Research - Magda El-Zarki, University of California, Irvine - Anthony Ephremides, University of Maryland - Deborah Estrin, University of California, Los Angeles - J.J. Garcia-Luna-Aceves, University of California at Santa Cruz - Mario Gerla, University of California, Los Angeles - Ramesh Govindan, USC/ISI - Ravi Jain, Telcordia - David B. Johnson, Rice University - Anthony Joseph, University of California, Berkeley - Edward Knightly, Rice University - Tom LaPorta, Lucent Technologies - Songwu Lu, University of California, Los Angeles - Robert Morris, MIT - S. Muthukrishnan, AT&T Research - Brian Noble, University of Michigan - Venkat Padmanabhan, Microsoft Research - Charles Perkins, Nokia - Chiara Petrioli, University "La Sapienza" - George Polyzos, Athens University of Economics and Business - Parmesh Ramanathan, University of Wisconsin - Madison - Ram Ramanathan, BBN Technologies - Ramachandran Ramjee, Lucent Technologies - Daniela Rus, Dartmouth College - Srinivasan Seshan, Carnegie Mellon University - Kang G. Shin, University of Michigan - Suresh Singh, Portland State University - Mani Srivastava, University of California, Los Angeles - Frank Stajano, AT&T Laboratories Cambridge - Martha Steenstrup, Stow Research - Violet R. Syrotiuk, University of Texas at Dallas - Leandros Tassiulas, University of Maryland - Nitin H. Vaidya, University of Illinois at Urbana-Champaign - Andras Valko, Ericsson Research - Adam Wolisz, Technical University of Berlin - Michele Zorzi, Universita di Ferrara _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm