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]