Network Working Group E. Stephan Internet Draft France Telecom R&D Document: draft-stephan-ippm-mgmt-reqs-00.txt Nov 12, 2001 Category: Informational IPPM Management Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The IPPM Working group has specified metrics for measuring the performance of an IP network. They are implemented in measurement platform. Processing widespread end to end measurement requires a common interface for the management of the measurement of the IPPM metrics. This memo specifies a set of requirements of a management service for the IPPM measurements. Table of Contents 1. Motivations and goals.......................................2 2. Convention..................................................3 3. Architecture................................................3 4. Functional Requirements.....................................3 4.1. Management of the access to the points of measures..........4 4.1.1. Control of the access.......................................4 4.1.2. naming of the measure.......................................4 4.2. Interoperability issues.....................................5 Stephan Informational - Expires [Page 1] Internet Draft IPPM Management Requirements Sept 2001 4.2.1. time zone...................................................5 4.2.2. unit........................................................5 4.2.3. Packets of Type P...........................................6 4.2.4. Sampling law................................................6 4.3. trustworthiness of the results..............................6 4.3.1. Results definition..........................................6 4.3.2. Issues related to time......................................6 4.3.3. Sampling law................................................7 4.4. End to end troubleshooting..................................7 4.5. Evolution...................................................7 5. Example using SNMP, the IPPM-MIB............................7 6. Security Considerations.....................................8 7. References..................................................8 8. Acknowledgments.............................................8 9. Author's Addresses..........................................8 1. Motivations and goals Although the IPPM WG has specified more than 20 metrics and that they are now implemented, there is not currently a standard for managing them. This memo lists a collection of requirements for managing widespread end to end measures using the IP performance metrics specified by the IPPM Working Group. It refers to notions introduced and discussed in the IPPM Framework document, RFC 2330 [1]. This memo is intended to be parallel in structure to the memo draft-ietf-ippm-owdp-reqs-00.txt [2]. The reader is assumed to be familiar with these documents. Sharing points of measure across administrative areas increases both the number of points of measures and the value-add of the results. It increases dramatically the number of feasible end to end measures while providing reliable pieces of information for management of SLA, provisioning, troubleshooting, bandwidth managementà The difficulties in managing a system of end to end points of measures are more administrative than technical. The main issues to address are (1) to provide an efficient management of the different steps of the measure, (2) to guaranty the unambiguousness of the measure, (3) to guaranty the trustworthiness of results,(4) to permit efficient troubleshooting and (5) to be flexible enough to accept new measure definitions. Managing distributed measures requires 3 levels of functionality: + The test plane timestamps the event, sends and receives the packets. + The control plane manages the network measures. It controls the activation, the deletion and the retrieval of the result of the measure. Stephan Informational - Expires [Page 2] Internet Draft IPPM Management Requirements Sept 2001 + The management plane is in charge of the administrative aspects and of all the issues which are not covered by the 2 previous planes. 2. Convention A peer is an identified NMS entity from a trusted administrative area. The control plane uses a protocol to exchange information. The draft- ietf-ippm-owdp-reqs-00.txt [2] introduces the requirement for such a protocol, and defines a generic name, OWDP-Control. The test plane uses a protocol to perform the measures. The draft- ietf-ippm-owdp-reqs-00.txt [2] introduces the requirement for such a protocol, and defines a generic name, OWDP-Test. A consolidation measure is a aggregated measure or a statistical measure performed on the result of a network measure or on another consolidation measure. 3. Architecture One of the conclusion of the draft-ietf-ippm-owdp-reqs-00.txt [2] is that the control plane may be implemented using different protocols and that the test plane has to be lightweight and easy to implement. The management plane provides a common interface for a system of points of measures using heterogeneous control protocols while preserving the complexity of the points of measures. The control plane manages the network measures, and the test plane produces singleton results. The control plane provides the management plane with the primitives to control the network measures. The management plane directly controls the measure of aggregated and statistical metrics. 4. Functional Requirements (1) The whole service should provide ability to control, measure, record, and distribute the results of measurements of the metrics defined in the IPPM Working Group. End to end measurements are widespread, involve different administrative areas and third parties. In a way to achieve end to end measures, the control plane should be accessed by peers under the control of the management plan. It controls both the access to the OWDP-Control and to the OWDP-Test. The granularity of the management distinguishes the control of a measurement instance from the access to the produced results. It provide the peer Stephan Informational - Expires [Page 3] Internet Draft IPPM Management Requirements Sept 2001 with a hierarchical grant mechanism to allow the share of the result. (2) The specification should focus on the design of a high level of interoperability and evolubility. It should comport sections that develop these aspects while detailing case studies. (3) The specification of the management of the IPPM metrics should be respectful of the RFC2330 framework to provide trusted results. (4) The management information exchange should be efficient enough and permit end to end troubleshooting. (5) The design should guaranty the integration of future IPPM metrics definitions. 4.1. Management of the access to the points of measures Internet flows are widespread. The management plane must permit end to end measures across administrative areas: peering management. 4.1.1. Control of the access Sharing points of measures across administrative areas squares the number of feasible measures while providing value-added information to the management of high level services. The management plane must provide a hierarchical grant mechanism to control the access to the points of measures by peers: + An administrator of an area allows peers to manage a set of network or consolidation measures on a point of measure. + A peer allows other peers to perform consolidation measures on the results produced by its measures. + A peer may be only granted to consult fully identified results. { Comment: Sharing network measures inside a point of measure reduces the test plane bandwidth consuming while providing intrinsically consistent results.} 4.1.2. naming of the measure In a point of measure, a measure instance belongs to a peer. On the network a measure involved several points of measures. The naming of the measure instances must be designed to permit an efficient management. Stephan Informational - Expires [Page 4] Internet Draft IPPM Management Requirements Sept 2001 Currently each point of measure is in charge of the naming of the instance. It results in having different names for one measure instance: + It is not acceptable, especially for interoperability purpose, because it introduces ambiguity at the beginning of the measure process. + It does not provide the managers of each point with a unambiguous identifier of a measure instance. Such kind of confusion increase dramatically the risk of misunderstanding during troubleshooting. + It is not efficient for troubleshooting because the whole measure setup duration may increase due to longer negotiation duration exchange with one point of measure while getting an instance name. The management framework must provide a peer with a naming space where is identified its measure instances: + It permits the peer to use the same identifier in all the points of measures involved by a measure. + The results of a measure are numbered in this naming space. + It provides an efficient share framework to the grant mechanism. 4.2. Interoperability issues Peering management permits interoperable access to points of measures. Measure must interoperate too. The configuration of the measure must be unambiguous to permit a high level of interoperability. 4.2.1. time zone The time zone parameter may be different at each point of the measure. The timestamp representation should be unique to avoid zone errors during the consolidation. 4.2.2. unit The comparison of 2 remote instants needs absolute time. As the measures are typically distributed over Internet there is a need to have an unambiguous and absolute time representation to have more aggregated metrics to be computed automatically. Stephan Informational - Expires [Page 5] Internet Draft IPPM Management Requirements Sept 2001 The section "6.1. Metrics" of the RFC2330 says that " When a time is given, it will be expressed in UTC". The timestamp representation should be in UTC. 4.2.3. Packets of Type P The section " 13. Packets of Type P" of the RFC2330, introduces "the generic notion of a 'packet of type'" because "the value of the metric depends on the type of IP packet(s) used to make the measurement." The definition part of the measure in the management plane which represent the source or the destination of the packet needs to accept any combination of existing Internet protocols suites. Its design should accept the future Internet protocol combination suites. 4.2.4. Sampling law The section "11.1. Methods of Collecting Samples" of the RFC2330 presents the different sampling laws. The definition part of the measure which represent the sampling law needs to accept the different sampling laws discussed in the RFC2330. 4.3. trustworthiness of the results The management plane must define the result format and the rules to qualify the result. 4.3.1. Results definition The management plane must specify exhaustively the results of the different measure definitions. It includes the format, the unit and the unusable value transfer rule. 4.3.2. Issues related to time The RFC2330 considers that the quality of a result relative to time depends on the clock characteristics which are its accuracy, its skew, its drift and its type of synchronization. Result values which represent more the instantaneous variation of the clock than the network behavior are unusable and must be marked as discarded. Each result of a measure must be validated against the clock variation. A result may not display values more accurate than it was Stephan Informational - Expires [Page 6] Internet Draft IPPM Management Requirements Sept 2001 possible at the time of the measure. The result value must be consistent with the accuracy of the clock at the time of the measure. The instantaneous characteristics of the clock are part of the measure result. So they must be accessible from the management plan. As the result gathering is delayed the history of the instantaneous characteristics of the clock must be available to the management plan. 4.3.3. Sampling law To avoid network oscillations introduced by network measures the management plane must be able to tune finely the sampling law parameters of a measure configuration. Meshed measures which use periodic or pseudo random sampling law may introduce network oscillation. The management plane must avoid meshed measures to be synchronized. 4.4. End to end troubleshooting The management plane performance must be compatible with troubleshooting across administrative areas: + A measure setup must use a limited number of message exchanges. + As troubleshooting must work during network congestion, the management plane should support UDP as transport protocol. + As troubleshooting must work during network congestion a measure setup may be done using a single message. 4.5. Evolution The design of the management plane must accept new network and consolidation measures specified in the IPPM WG. The Type P must accept the future Internet protocol combination suites. 5. Example using SNMP, the IPPM-MIB The requirements listed in this memo are partially respected in the IPPM-MIB draft [3]. This memo was presented briefly during the IPPM meeting at London. The presentation is available on line in the proceeding of the 51th IETF meeting [4]. Stephan Informational - Expires [Page 7] Internet Draft IPPM Management Requirements Sept 2001 6. Security Considerations The management plane should provide the interface to manage both the information related to the authentication of the access of the peers to the OWDP-Control and the information related to the OWDP-Control defined in [2]. 7. References 8. Acknowledgments 9. Author's Addresses Emile STEPHAN France Telecom R & D 2 avenue Pierre Marzin F-22307 Lannion cedex Phone: (+ 33) 2 96 05 11 11 Email: emile.stephan@francetelecom.com Full Copyright Statement "Copyright (C) The Internet Society ). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Stephan Informational - Expires [Page 8] Internet Draft IPPM Management Requirements Sept 2001 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. [1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [2] S. Shalunov, B. Teitelbaum, " A One-way Active Measurement Protocol Requirements", draft-ietf-ippm-owdp-reqs-00.txt, july 2001. [3] E. Stephan, " IPPM measurement MIB", draft-stephan-ippm-mib- 00.txt, June 29, 2001. [4] E. Stephan, "Presentation of the IPPM-MIB at the 51th IETF Meeting" http://search.ietf.org/proceedings/01aug/slides/ippm- 6.pdf, August 5, 2001. Stephan Informational - Expires [Page 9]