Network Working Group E. Stephan Internet-Draft France Telecom Orange Intended status: Standards Track july 1, 2010 Expires: January 2, 2011 IPPM Metrics Registry Extension draft-stephan-ippm-registry-ext-00 Abstract The current IANA IPPM Metrics Registry [RFC4148] only assigns an identifier to each IP Performance Metrics (IPPM) defined in the IETF. This document extends this registry for enabling the registration of fine-grained information on each metric. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Stephan Expires January 2, 2011 [Page 1] Internet-Draft IPPM Metrics Registry Extension july 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Stephan Expires January 2, 2011 [Page 2] Internet-Draft IPPM Metrics Registry Extension july 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPPM Registry Extension Framework . . . . . . . . . . . . . . . 4 3.1. Leg1, existing registry . . . . . . . . . . . . . . . . . . 4 3.2. Leg2, metrics parameters and options . . . . . . . . . . . 5 4. Discussion and Open issues . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5.1. New Registry Management rules . . . . . . . . . . . . . . . 6 5.1.1. ianaIppmMetrics subtree (SMI leg) . . . . . . . . . . . 7 5.1.2. Leg2 . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Stephan Expires January 2, 2011 [Page 3] Internet-Draft IPPM Metrics Registry Extension july 2010 1. Introduction The current IANA IPPM Metrics Registry [RFC4148] assigns an identifier to each IP Performance Metrics (IPPM) defined in the IETF. This document extends this registry for enabling the registration of fine-grained information on each metric. 2. Overview To facilitate the understanding of the changes this document reuse mostly the structure of [RFC4148]. The current version assumes that IESG will request backward compatibility with the existing registry. This memo suggest to extend the current registry for the following reasons: o The current registry is designed as a MIB extension which may be used by other MIB modules to identify specific IP Performance Metrics. This precludes the usage of the registry by other management frameworks like those based on XML. The new registry should be easely parsable by other management frameworks. o parameters: It should capture information to distinguish flavors of a metric when a metric have optional parameters. o results: It should register parameters for easing the comparison of metrics. As a example an ouput parameter should be registered with clear units (time, number of packet, bytes...) or default value (e.g. milliseconds, kbytes...); 3. IPPM Registry Extension Framework The new registry should preserve the compatibilty with the existing one because MIB compilers already import this as a MIB module. Nevertheless the extension part does not inherit of this constraint. In brief the new registry is made of 2 legs the existing one and a new one which should be readable by non SMI network management frameworks. 3.1. Leg1, existing registry Leg1 corresponds the the current SMIv2 module. Its behavior is unchanged. New metrics are still identified in 'ianaIppmMetrics' subtree. Stephan Expires January 2, 2011 [Page 4] Internet-Draft IPPM Metrics Registry Extension july 2010 Furthermore the number assigned to a metric is copied in the table of the metrics of the Leg2. 3.2. Leg2, metrics parameters and options To capture the characterization of each metric the Leg2 has the following structure : o One table of metric names and identifiers given by the Leg1; o A list of metrics flavors The table of metric names copies the metric names, id and reference from the 'ianaIppmMetrics' subtree of the Leg1 (pratically this is done by IANA): +-----------------------------------+----------+ | MetricName | MetricId | +-----------------------------------+----------+ | ietfInstantUnidirConnectivity | 1 | | ietfInstantBidirConnectivity | 2 | | ... | ... | | ietfOneToGroupRangeDelayVariation | 70 | +-----------------------------------+----------+ Metrics Table Then metrics flavors are defined separatly after this table. Each metric flavor is introduced with its name and fields like the MetricName it is based on and a brief description. Then the parameters of the metric flavor are listed in a dedicaced table described below. +-----------+---------+-----------------+------------------+--------+ | Name | Unit | Cardinality | Description | Type | +-----------+---------+-----------------+------------------+--------+ | the name | The | The parameter | Text precising | Input | | of the | default | is mandatory or | the meaning of | or | | metric | unit | optional | the parameter | output | +-----------+---------+-----------------+------------------+--------+ Metric flavor table Stephan Expires January 2, 2011 [Page 5] Internet-Draft IPPM Metrics Registry Extension july 2010 4. Discussion and Open issues Complexity: The new registry will probably have 2 legs, a SMI leg and the extension leg. Is this too complex ? Duplication of works: Having 2 legs means duplicating the metric identifier to provide natural access to SMI and non SMI frameworks. It is the price to have the metric identifiers to be shared amongs SMI and non SMI management frameworks. Security considerations: Diff with v1 of the registry: Security considerations differ from the initial registry because the new registry exposes detailed information on the metrics. Do we keep the retro compatibily with the initial registry ? IESG will probably say 'Yes', I made this asumption and may be wrong. Initial content: Do we initiate the extension of the registry with content ? Reporting metrics: This document does not specify a management interface. Nevertheless it may be somewhat tied with the work on the reporting of metrics the IPPM WG is currently addressing. How to benefit from that ? 5. IANA Considerations This section describes the rules for the management of the registry by IANA. The management of the ianaIppmMetrics subtree (existing registry) is inchanged. The rules below include these rules . Several are common to the 2 legs. 5.1. New Registry Management rules Registrations are done sequentially by IANA on the bases of 'Specification Required' as defined in [RFC2434]. The number and the name identifying a metric is the same in the 2 legs. The reference of the specification must point to a stable document including a title, a revision and a date. The name always starts with the name of the organization and must respect the SMIv2 rules for descriptors defined in the section 3.1 of [RFC2578]; Stephan Expires January 2, 2011 [Page 6] Internet-Draft IPPM Metrics Registry Extension july 2010 A document that creates new metrics would have an IANA considerations section in which it would describe new metrics to register. Additional documents may add new metric flavors in the registry on the bases of 'Specification Required' as defined in [RFC2434]. 5.1.1. ianaIppmMetrics subtree (SMI leg) Registrations are done sequentially by IANA in the ianaIppmMetrics subtree. The number and the name identifying the metric is reused i the leg2. An OBJECT IDENTITY assigned to a metric is definitive and cannot be reused. If a new version of a metric is produced then it is assigned with a new name and a new identifier. 5.1.2. Leg2 see section 3.2 6. Security Considerations FIXME: Security considerations differ from the initial registry. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005. Stephan Expires January 2, 2011 [Page 7] Internet-Draft IPPM Metrics Registry Extension july 2010 8.2. Informative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. Appendix A. An Appendix Author's Address Stephan Emile France Telecom Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange-ftgroup.com Stephan Expires January 2, 2011 [Page 8]