doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc3705.txt b/doc/rfc/rfc3705.txt
new file mode 100644
index 0000000..6a22d1c
--- /dev/null
+++ b/doc/rfc/rfc3705.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                             B. Ray
+Request for Comments: 3705                        PESA Switching Systems
+Category: Standards Track                                        R. Abbi
+                                                                 Alcatel
+                                                           February 2004
+
+
+        High Capacity Textual Conventions for MIB Modules Using
+            Performance History Based on 15 Minute Intervals
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document presents a set of High Capacity Textual Conventions for
+   use in MIB modules which require performance history based upon 15
+   minute intervals.  The Textual Conventions defined in this document
+   extend the conventions presented in RFC 3593 to 64 bit resolution
+   using the conventions presented in RFC 2856.
+
+Table of Contents
+
+   1.  The Internet-Standard Management Framework . . . . . . . . . .  2
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Intellectual Property Statement. . . . . . . . . . . . . . . .  8
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       5.1.  Normative References . . . . . . . . . . . . . . . . . .  8
+       5.2.  Informative References . . . . . . . . . . . . . . . . .  9
+   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 10
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+Ray & Abbi                  Standards Track                     [Page 1]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+1. The Internet-Standard Management Framework
+
+   For a detailed overview of the documents that describe the current
+   Internet-Standard Management Framework, please refer to section 7 of
+   RFC 3410 [RFC3410].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  MIB objects are generally
+   accessed through the Simple Network Management Protocol (SNMP).
+   Objects in the MIB are defined using the mechanisms defined in the
+   Structure of Management Information (SMI).  This memo specifies a MIB
+   module that is compliant to the SMIv2, which is described in STD 58,
+   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+   [RFC2580].
+
+   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 [RFC2119].
+
+2.  Overview
+
+   In cases where a manager must obtain performance history data about
+   the behavior of equipment it manages, several strategies can be
+   followed in the design of a MIB module that represents the managed
+   equipment, including:
+
+   -  The agent counts events on a continuous basis and, whenever
+      desired, the manager obtains the value of the event counter and
+      adjusts its understanding of the history of events at the agent.
+
+   -  The agent allocates events to 'buckets' where each bucket
+      represents an interval of time.
+
+   Telecommunications equipment often makes use of the latter strategy.
+   For such equipment the standard practice is that history data is
+   maintained by the agent in terms of 15-minute intervals [T1.231].
+
+   MIB modules for collecting performance history based on 15-minute
+   intervals have been defined for the DS1/E1 [RFC2495], DS3/E3
+   [RFC2496], SONET/SDH [RFC3592], ADSL [RFC2662], HDLS2 and SHDSL
+   [RFC3276] interface types.  These MIB modules use a common set of
+   textual conventions defined in [RFC3593].
+
+   A need has arisen to define 64-bit versions of the textual
+   conventions in [RFC3593].  Ideally, these high-capacity textual
+   conventions would be based on a Gauge64 or Unsigned64 data type, but
+   unfortunately no such types exist in SMIv2.  The next best choice
+   would be to base them on the CounterBasedGauge64 textual convention
+
+
+
+Ray & Abbi                  Standards Track                     [Page 2]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+   presented in [RFC2856], but that is not possible either since SMIv2
+   allows only base types to be used in defining textual conventions.
+   Therefore, the textual conventions presented in this memo are based
+   directly on the Counter64 type, like those in [RFC2856].  They are
+   subject to the following limitations:
+
+   -  The MAX-ACCESS of objects defined using these textual conventions
+      must be read-only, because the MAX-ACCESS of the underlying
+      Counter64 type is read-only.
+
+   -  No sub-range can be specified in object definitions using these
+      textual conventions, because sub-ranges are not allowed on
+      Counter64 objects.
+
+   -  No DEFVAL clause can be specified in object definitions using
+      these textual conventions, because DEFVALs are not allowed on
+      Counter64 objects.
+
+   -  Objects defined using these textual conventions cannot be used in
+      an INDEX clause, because there is no INDEX clause mapping defined
+      for objects of type Counter64.
+
+   Use of the textual conventions presented in this memo assumes the
+   following:
+
+   -  The agent supports 15 minute based history counters.
+
+   -  The agent is capable of keeping a history of 96 intervals of 15
+      minute performance data.
+
+   -  The agent may optionally support performance data aggregating the
+      history intervals.
+
+   -  The agent will keep separate tables for the current interval, the
+      history intervals, and the total aggregates.
+
+3.  Definitions
+
+   HC-PerfHist-TC-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       MODULE-IDENTITY,
+       Counter64,
+       Unsigned32,
+       Integer32,
+       mib-2                FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION   FROM SNMPv2-TC;
+
+
+
+
+Ray & Abbi                  Standards Track                     [Page 3]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+   hcPerfHistTCMIB MODULE-IDENTITY
+      LAST-UPDATED "200402030000Z" -- February 3, 2004
+      ORGANIZATION "ADSLMIB Working Group"
+      CONTACT-INFO "WG-email:  adslmib@ietf.org
+           Info:      https://www1.ietf.org/mailman/listinfo/adslmib
+
+           Chair:     Mike Sneed
+                      Sand Channel Systems
+           Postal:    P.O.  Box 37324
+                      Raleigh NC 27627-7324
+                      USA
+           Email:     sneedmike@hotmail.com
+           Phone:     +1 206 600 7022
+
+           Co-editor: Bob Ray
+                      PESA Switching Systems, Inc.
+           Postal:    330-A Wynn Drive
+                      Huntsville, AL 35805
+                      USA
+           Email:     rray@pesa.com
+           Phone:     +1 256 726 9200 ext.  142
+
+           Co-editor: Rajesh Abbi
+                      Alcatel USA
+           Postal:    2301 Sugar Bush Road
+                      Raleigh, NC 27612-3339
+                      USA
+           Email:     Rajesh.Abbi@alcatel.com
+           Phone:     +1 919 850 6194
+           "
+       DESCRIPTION
+           "This MIB Module provides Textual Conventions to be
+            used by systems supporting 15 minute based performance
+            history counts that require high-capacity counts.
+
+            Copyright (C) The Internet Society (2004).  This version
+            of this MIB module is part of RFC 3705: see the RFC
+            itself for full legal notices."
+
+           REVISION "200402030000Z" -- February 3, 2004
+           DESCRIPTION "Initial version, published as RFC 3705."
+
+           ::= { mib-2 107 }
+
+   HCPerfValidIntervals ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+          "The number of near end intervals for which data was
+
+
+
+Ray & Abbi                  Standards Track                     [Page 4]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+          collected.  The value of an object with an
+          HCPerfValidIntervals syntax will be 96 unless the
+          measurement was (re-)started within the last 1440 minutes,
+          in which case the value will be the number of complete 15
+          minute intervals for which the agent has at least some data.
+          In certain cases (e.g., in the case where the agent is a
+          proxy) it is possible that some intervals are unavailable.
+          In this case, this interval is the maximum interval number
+          for which data is available."
+       SYNTAX   Integer32 (0..96)
+
+   HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+          "The number of near end intervals for which no data is
+          available.  The value of an object with an
+          HCPerfInvalidIntervals syntax will typically be zero except
+          in cases where the data for some intervals are not available
+          (e.g., in proxy situations)."
+       SYNTAX   Integer32 (0..96)
+
+   HCPerfTimeElapsed ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+          "The number of seconds that have elapsed since the beginning
+          of the current measurement period.  If, for some reason,
+          such as an adjustment in the system's time-of-day clock or
+          the addition of a leap second, the duration of the current
+          interval exceeds the maximum value, the agent will return
+          the maximum value.
+
+          For 15 minute intervals, the range is limited to (0..899).
+          For 24 hour intervals, the range is limited to (0..86399)."
+       SYNTAX   Integer32 (0..86399)
+
+   HCPerfIntervalThreshold ::= TEXTUAL-CONVENTION
+       STATUS   current
+       DESCRIPTION
+           "This convention defines a range of values that may be set
+           in a fault threshold alarm control.  As the number of
+           seconds in a 15-minute interval numbers at most 900,
+           objects of this type may have a range of 0...900, where the
+           value of 0 disables the alarm."
+       SYNTAX   Unsigned32 (0..900)
+
+   HCPerfCurrentCount ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+
+
+
+Ray & Abbi                  Standards Track                     [Page 5]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+           "A gauge associated with a performance measurement in a
+            current 15 minute measurement interval.  The value of an
+            object with an HCPerfCurrentCount syntax starts from zero
+            and is increased when associated events occur, until the
+            end of the 15 minute interval.  At that time the value of
+            the gauge is stored in the first 15 minute history
+            interval, and the gauge is restarted at zero.  In the case
+            where the agent has no valid data available for the
+            current interval, the corresponding object instance is not
+            available and upon a retrieval request a corresponding
+            error message shall be returned to indicate that this
+            instance does not exist.
+
+            This count represents a non-negative integer, which
+            may increase or decrease, but shall never exceed 2^64-1
+            (18446744073709551615 decimal), nor fall below 0.  The
+            value of an object with HCPerfCurrentCount syntax
+            assumes its maximum value whenever the underlying count
+            exceeds 2^64-1.  If the underlying count subsequently
+            decreases below 2^64-1 (due, e.g., to a retroactive
+            adjustment as a result of entering or exiting unavailable
+            time), then the object's value also decreases.
+
+            Note that this TC is not strictly supported in SMIv2,
+            because the 'always increasing' and 'counter wrap'
+            semantics associated with the Counter64 base type are not
+            preserved.  It is possible that management applications
+            which rely solely upon the (Counter64) ASN.1 tag to
+            determine object semantics will mistakenly operate upon
+            objects of this type as they would for Counter64 objects.
+
+            This textual convention represents a limited and short-
+            term solution, and may be deprecated as a long term
+            solution is defined and deployed to replace it."
+       SYNTAX  Counter64
+
+   HCPerfIntervalCount ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+           "A gauge associated with a performance measurement in
+            a previous 15 minute measurement interval.  In the case
+            where the agent has no valid data available for a
+            particular interval, the corresponding object instance is
+            not available and upon a retrieval request a corresponding
+            error message shall be returned to indicate that this
+            instance does not exist.
+
+            Let X be an object with HCPerfIntervalCount syntax.
+
+
+
+Ray & Abbi                  Standards Track                     [Page 6]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+            Let Y be an object with HCPerfCurrentCount syntax.
+            Let Z be an object with HCPerfTotalCount syntax.
+            Then, in a system supporting a history of n intervals with
+            X(1) and X(n) the most and least recent intervals
+            respectively, the following applies at the end of a 15
+            minute interval:
+
+               - discard the value of X(n)
+               - the value of X(i) becomes that of X(i-1)
+                 for n >= i > 1
+               - the value of X(1) becomes that of Y.
+               - the value of Z, if supported, is adjusted.
+
+            This count represents a non-negative integer, which
+            may increase or decrease, but shall never exceed 2^64-1
+            (18446744073709551615 decimal), nor fall below 0.  The
+            value of an object with HCPerfIntervalCount syntax
+            assumes its maximum value whenever the underlying count
+            exceeds 2^64-1.  If the underlying count subsequently
+            decreases below 2^64-1 (due, e.g., to a retroactive
+            adjustment as a result of entering or exiting unavailable
+            time), then the value of the object also decreases.
+
+            Note that this TC is not strictly supported in SMIv2,
+            because the 'always increasing' and 'counter wrap'
+            semantics associated with the Counter64 base type are not
+            preserved.  It is possible that management applications
+            which rely solely upon the (Counter64) ASN.1 tag to
+            determine object semantics will mistakenly operate upon
+            objects of this type as they would for Counter64 objects.
+
+            This textual convention represents a limited and short-
+            term solution, and may be deprecated as a long term
+            solution is defined and deployed to replace it."
+       SYNTAX  Counter64
+
+   HCPerfTotalCount ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+           "A gauge representing the aggregate of previous valid 15
+            minute measurement intervals.  Intervals for which no
+            valid data was available are not counted.
+
+            This count represents a non-negative integer, which
+            may increase or decrease, but shall never exceed 2^64-1
+            (18446744073709551615 decimal), nor fall below 0.  The
+            value of an object with HCPerfTotalCount syntax
+            assumes its maximum value whenever the underlying count
+
+
+
+Ray & Abbi                  Standards Track                     [Page 7]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+            exceeds 2^64-1.  If the underlying count subsequently
+            decreases below 2^64-1 (due, e.g., to a retroactive
+            adjustment as a result of entering or exiting unavailable
+            time), then the object's value also decreases.
+
+            Note that this TC is not strictly supported in SMIv2,
+            because the 'always increasing' and 'counter wrap'
+            semantics associated with the Counter64 base type are not
+            preserved.  It is possible that management applications
+            which rely solely upon the (Counter64) ASN.1 tag to
+            determine object semantics will mistakenly operate upon
+            objects of this type as they would for Counter64 objects.
+
+            This textual convention represents a limited and short-
+            term solution, and may be deprecated as a long term
+            solution is defined and deployed to replace it."
+       SYNTAX  Counter64
+   END
+
+4. Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available;  neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Ray & Abbi                  Standards Track                     [Page 8]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+   [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+             Rose, M. and S. Waldbusser, "Structure of Management
+             Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+             1999.
+
+   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+             Rose, M. and S. Waldbusser, "Textual Conventions for
+             SMIv2", STD 58, RFC 2579, April 1999.
+
+   [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+             Rose, M. and S. Waldbusser, "Conformance Statements for
+             SMIv2", STD 58, RFC 2580, April 1999.
+
+5.2.  Informative References
+
+   [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
+             "Introduction and Applicability Statements for Internet-
+             Standard Management Framework", RFC 3410, December 2002.
+
+   [T1.231]  American National Standard for Telecommunications - Digital
+             Hierarchy - Layer 1 In-Service Digital Transmission
+             Performance Monitoring, ANSI T1.231-1997, September 1997.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+             3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1,
+             E1, DS2 and E2 Interface Types", RFC 2495, January 1999.
+
+   [RFC2496] Fowler, D., "Definitions of Managed Objects for the DS3/E3
+             Interface Type", RFC 2496, January 1999.
+
+   [RFC3592] Tesink, K., "Definitions of Managed Objects for the
+             Synchronous Optical Network/Synchronous Digital Hierarchy
+             (SONET/SDH) Interface Type", RFC 3592, November 2003.
+
+   [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for
+             the ADSL Lines",  RFC 2662, August 1999.
+
+   [RFC2856] Bierman, A., McCloghrie, K.  and R. Presuhn, "Textual
+             Conventions for Additional High Capacity Data Types", RFC
+             2856, June 2000.
+
+   [RFC3276] Ray, B. and R. Abbi, "Definitions of Managed Objects for
+             High Bit-rate DSL - 2nd Generation (HDSL2) and Single-Pair
+             High-Speed Digital Subscriber Line (SHDSL) Lines", RFC
+             3276, May 2002.
+
+
+
+
+Ray & Abbi                  Standards Track                     [Page 9]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+   [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using
+             Performance History Based on 15 Minute Intervals", RFC
+             3593,  November 2003.
+
+6. Security Considerations
+
+   This module does not define any management objects.  Instead, it
+   defines a set of textual conventions which may be used by other MIB
+   modules to define management objects.
+
+   Meaningful security considerations can only be written in the MIB
+   modules that define management objects.  This document has therefore
+   no impact on the security of the Internet.
+
+7. Acknowledgements
+
+   This document borrows tremendously from [RFC3593] and [RFC2856].  As
+   such, any credit for the text found within should be fully attributed
+   to the authors of those documents.
+
+8. Authors' Addresses
+
+   Bob Ray
+   PESA Switching Systems, Inc.
+   330-A Wynn Drive
+   Huntsville, AL 35805
+   USA
+
+   Phone: +1 256 726 9200 ext. 142
+   Fax:   +1 256 726 9271
+   EMail: rray@pesa.com
+
+
+   Rajesh Abbi
+   Alcatel USA
+   2301 Sugar Bush Road
+   Raleigh, NC 27612-3339
+   USA
+
+   Phone: +1 919 850 6194
+   EMail: Rajesh.Abbi@alcatel.com
+
+
+
+
+
+
+
+
+
+
+Ray & Abbi                  Standards Track                    [Page 10]
+
+RFC 3705             High Capacity Perfhist TC MIB         February 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 in 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 assignees.
+
+   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
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ray & Abbi                  Standards Track                    [Page 11]
+