Internet DRAFT - draft-perkins-sums

draft-perkins-sums



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 10:49:06 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 07 Jun 1996 22:00:00 GMT
ETag: "361e60-38dd-31b8a660"
Accept-Ranges: bytes
Content-Length: 14557
Connection: close
Content-Type: text/plain


INTERNET-DRAFT          Expires November 1996             INTERNET-DRAFT

Draft                        SUM Pseudotype                 May 27, 1996


                           The SUM Pseudotype
                             for SNMPv2 SMI

                        <draft-perkins-sum-00.txt>

                              May 27, 1996

                            David T. Perkins
                         dperkins@scruznet.com



1.  Status of this Memo

   This document is an Internet Draft.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the internet-drafts Shadow
   Directories on:

         ftp.is.co.za (Africa)
         nic.nordu.net (Europe)
         ds.internic.net (US East Coast)
         ftp.isi.edu (US West Coast)
         munnari.oz.au (Pacific Rim)

















Expires 11/27/96                                                [Page 1]

Draft                        SUM Pseudotype                 May 27, 1996


2.  Introduction

This memo is experimental.  It specifies a pseudotype for the SNMPv2
SMI[1][2][3] to ease the development and improve the understanding of
SNMP MIBs.  This pseudotype is called "SUM" and has the look, and
function of an ASN.1 type in the following constructs, allowed in SNMPv2
MIB modules: OBJECT-TYPE, SEQUENCE, MODULE-COMPLIANCE, AGENT-
CAPABILITIES, TEXTUAL-CONVENTION, and type assignments.  This pseudotype
is meant to replace the current construct for specifying bit strings
encoded as integers in SNMP MIBs.  Existing MIBs can be easily converted
to use this new construct, and MIBs that use the new construct can be
converted to MIBs that are valid under the rules of the SMNPv2 SMI (and
SNMPv1 SMI[4][5].) (An example of an object definition using a bit
string encoded as an integer is "sysServices" found in RFCs 1213[6] and
1907[7].)

This memo proposes that the SUM pseudotype be integrated into a future
version of the SNMPv2 SMI.  A definition of the pseudotype is given
using the ASN.1 macro notation.  Also included in this memo is the
extended BNF notation describing the syntax for this construct, and the
guidelines for conversion between MIB modules in the SMIv2 format and
those using this new pseudotype.

This memo does not specify a standard for the Internet community.





























Expires 11/27/96                                                [Page 2]

Draft                        SUM Pseudotype                 May 27, 1996


3.  The ASN.1 Macro for the SUM Pseudotype

SUM MACRO ::=
BEGIN
    -- Note: ASN.1 macro notation is too limiting to specify all the
    -- rules for usage. Additional rules are specified as comments.

    TYPE NOTATION ::=
        -- in SEQUENCES, cannot name any bits
        -- (i.e. SEQUENCE { o1 SUM, o2 Integer32 })
        empty
        -- in SYNTAX clause, must specify the bits
        | "{" NamedBits "}"

    -- The following is just to specify the syntax for values,
    -- but does not "deliver" a useful value. (The identifier
    -- must be a name of one of the named bits.)
    VALUE NOTATION ::=
        "{" NamedBitVal "}"
        <VALUE INTEGER(0..2147483647) ::= 0>

    -- the names of bits in a value
    NamedBitVal ::=
          identifier
        | NamedBitVal "," identifier

    -- the names of bits in the type definition
    NamedBits ::=
          NamedBit
        | NamedBits "," NamedBit

    -- The bits are named and identified by their position in the
    -- integer. Bit zero is the low order (or right-most)
    -- bit in the integer. Bit 30 is the highest order allowed bit
    -- in the integer.  For an instance of a SUM macro, all named
    -- bits for that instance must be unique and the names must start
    -- with a lowercase letter. Also, all the positions for that
    -- instance must be unique and range from zero to the last one
    -- specified, which can be at most 30.  The bits do not need to
    -- be named in any order; however, all positions for bits must
    -- be specified.  The identifier must consist of one or more
    -- letters or digits (no hyphens), up to a maximum of 64
    -- characters, and the initial character must be a lower-case
    -- letter.
    NamedBit ::= identifier "(" number ")"
END







Expires 11/27/96                                                [Page 3]

Draft                        SUM Pseudotype                 May 27, 1996


4.  The extended BNF for the SUM Pseudotype

When used as a type, the SUM pseudotype is defined by production
<sumTypeRef>.  When used as a value, the SUM pseudotype is defined by
production <sumValueRef>.

    <sumTypeRef> =
            "SUM"   -- in a sequence
          | "SUM" "{" <namedBit> [ "," <namedBit> ]... "}"

    <namedBit> = identifier "(" number ")"

    <sumValueRef> = "{" [ identifier ["," identifier]... ] "}"


Where:
     identifier must consist of one or more letters or digits
       (no hyphens), up to a maximum of 64 characters, and the
       initial character must be a lower-case letter.

     number is an unsigned integer less than or equal to 30.


5.  Mapping of the SUM Pseudotype

The SUM pseudotype represents an enumeration of named bits encoded in an
integer. (The pseudotype looks like the ASN.1 type BIT STRING, but maps
to type INTEGER(0..2147483647).)  Each collection of named bits is
assigned non-negative, contiguous values, starting at zero.  However,
the bits do not need to be named in any order in the definition of the
collection as long as the resulting collection names all bits
contiguously.  The maximum number of bits in a collection is 31 (i.e.,
the highest identifiable bit is 30).

Finally, the identifier (also called a label) for a named bit must
consist of one or more letters or digits (no hyphens), up to a maximum
of 64 characters, and the initial character must be a lower-case letter.
(However, labels longer than 32 characters are not recommended.)

Values for the SUM pseudotype are encoded as values for the ASN.1
INTEGER type, with the bits (up to 31) packed into the value.  Bits
are numbered by their position, starting at zero, in the integer.
Bit zero is the low order (or right-most) bit in the integer. Bit 30
is the highest order allowed bit in the integer.  When a value is
encoded, unspecified bits, if any, must be set to zero.








Expires 11/27/96                                                [Page 4]

Draft                        SUM Pseudotype                 May 27, 1996


6.  Example usage

The SUM pseudotype can be used in the follow situations in MIB modules:

In an OBJECT-TYPE construct, for example:

     o1 OBJECT-TYPE
          SYNTAX         SUM { blue(0), red(1), green(2) }
          MAX-ACCESS     read-create
          STATUS         current
          DESCRIPTION    "Example object"
          DEFVAL         { { blue, green } }
     ::= { a1 1 }


  In a TEXTUAL-CONVENTION construct, for example:

     T1 TEXTUAL-CONVENTION
          STATUS         current
          DESCRIPTION    "Example textual convention"
          SYNTAX         SUM { fire(0), wind(1), rain(2) }


  In a type assignment, for example:

     T1 ::= SUM { smooth(0), flexible(1), warm(2) }


  In a SEQUENCE definition, for example:

     S1Entry ::= SEQUENCE {
          o1 SUM,
          o2 Integer32 }


  In a MODULE-COMPLIANCE construct, for example:

     mc1 MODULE-COMPLIANCE
          STATUS         current
          DESCRIPTION    "Example module compliance"
          MODULE
            MANDATORY-GROUPS { g1 }
            OBJECT o1
              SYNTAX          SUM { fire(0), wind(1) }
              WRITE-SYNTAX    SUM { fire(0) }
              DESCRIPTION     "Example variation"
     ::= { mc 1 }






Expires 11/27/96                                                [Page 5]

Draft                        SUM Pseudotype                 May 27, 1996


  In an AGENT-CAPABILITIES construct, for example:

     ac1 AGENT-CAPABILITIES
          PRODUCT-RELEASE     "Example product"
          STATUS              current
          DESCRIPTION         "Example agent capabilities"
          SUPPORTS       M1
            INCLUDES { g1 }
            VARIATION o1
              SYNTAX          SUM { fire(0), wind(1) }
              WRITE-SYNTAX    SUM { fire(0) }
              DEFVAL          { { wind } }
     ::= { ac 1 }



7.  Conversion Between Current Usage and the SUM Pseudotype

In both SMIv1 and SMv2 MIB modules, the type notation for a bit string
encoded in an integer value is written as  "INTEGER(0..n)" (or
"Integer32(0..n)"), where the value of "n" is 2 raised to the number of
bits in the bit string, minus 1.  For example, if there are 3 bits in
the bit string, then the value of "n" is (2^3)-1, or 7.  Conversion from
SNMPv2 or SNMPv1 MIB modules first requires a careful review of the
OBJECT-TYPE, SEQUENCE, MODULE-COMPLIANCE, AGENT-CAPABILITIES, TEXTUAL-
CONVENTION, and type assignment constructs to determine which are using
a bit string encoded as an integer.  For each identified usage, all the
bits in the string must be assigned a label.  Finally, the text of the
DESCRIPTION clause may need to be updated, typically to simplify.

The example below shows the definition of sysServices from RFC 1907, and
a modified version using the SUM pseudotype.


  From RFC 1907:

    sysServices OBJECT-TYPE
        SYNTAX      INTEGER (0..127)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "A value which indicates the set of services that this
            entity may potentially offers.  The value is a sum.  This
            sum initially takes the value zero, Then, for each layer, L,
            in the range 1 through 7, that this node performs
            transactions for, 2 raised to (L - 1) is added to the sum.
            For example, a node which performs only routing functions
            would have a value of 4 (2^(3-1)).  In contrast, a node
            which is a host offering application services would have a
            value of 72 (2^(4-1) + 2^(7-1)).  Note that in the context
            of the Internet suite of protocols, values should be


Expires 11/27/96                                                [Page 6]

Draft                        SUM Pseudotype                 May 27, 1996


            calculated accordingly:

                 layer      functionality
                   1        physical (e.g., repeaters)
                   2        datalink/subnetwork (e.g., bridges)
                   3        internet (e.g., supports the IP)
                   4        end-to-end  (e.g., supports the TCP)
                   7        applications (e.g., supports the SMTP)

            For systems including OSI protocols, layers 5 and 6 may also
            be counted."
        ::= { system 7 }

  Modified version using the SUM pseudotype:

    sysServices OBJECT-TYPE
        SYNTAX      SUM { physical(0), datalinkOrSubnetwork(1),
                          internet(2), endToEnd(3), session(4),
                          presentation(5), applications(6) }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The set of services that this entity may potentially
            offer.  The members of this set are the protocol 'layers'
            for which this node performs transactions.  For example,
            a node which performs only routing functions would have
            a value of { internet }.  In contrast, a node which is
            a host offering application services would have a value
            of { endToEnd, applications }.  Note that in the
            context of the Internet suite of protocols, the
            bits should be interpreted accordingly:

                 layer      functionality
                   1        physical(0) (e.g., repeaters)
                   2        datalinkOrSubnetwork(1) (e.g., bridges)
                   3        internet(2) (e.g., supports the IP)
                   4        endToEnd(3)  (e.g., supports the TCP)
                   7        applications(6) (e.g., supports the SMTP)

            For systems including OSI protocols, layers 5 and 6
            should be interpreted normally."
        ::= { system 7 }

Conversion of the SUM pseudotype back to an INTEGER (or Integer32) is
quite trivial.








Expires 11/27/96                                                [Page 7]

Draft                        SUM Pseudotype                 May 27, 1996


8.  Allowed Updates

An instance of an SUM pseudotype may not be changed.  A modification
requires that a new instance of the construct in which it is used be
created.  (Note that requirement is consistent with that specified in
section 10.2 of SMIv2.)


9.  Acknowledgments

Thanks go to Bancroff Scott for his assistance on the BITS macro on
which the SUM macro is modeled.


10.  References


[1]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of
     Management Information for Version 2 of the Simple Network
     Management Protocol (SNMPv2)", RFC 1902, 01/22/1996.

[2]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual
     Conventions for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", RFC 1903, 01/22/1996.

[3]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance
     Statements for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", RFC 1904, 01/22/1996.

[4]  K. McCloghrie, M. Rose, "Structure and Identification of Management
     Information for TCP/IP-based Internets", RFC 1155, 05/10/1990.

[5]  K. McCloghrie, M. Rose, "Concise MIB Definitions", RFC 1212,
     03/26/1991.

[6]  K. McCloghrie, M. Rose, "Management Information Base for Network
     Management of TCP/IP-based internets: MIB-II", 03/26/1991.

[7]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Management
     Information Base for Version 2 of the Simple Network Management
     Protocol (SNMPv2)", 01/22/1996












Expires 11/27/96                                                [Page 8]