[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]