home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1200s / rfc1283.txt < prev    next >
Text File  |  1991-12-04  |  17KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           M. Rose
  8. Request for Comments: 1283                 Dover Beach Consulting, Inc.
  9. Obsoletes: RFC 1161                                       December 1991
  10.  
  11.  
  12.                              SNMP over OSI
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  Discussion and suggestions for improvement are requested.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Table of Contents
  23.  
  24.       1. Background ............................................    1
  25.       1.1 A Digression on User Interfaces ......................    2
  26.       1.1.1 Addressing Conventions for UDP-based service .......    3
  27.       1.2 A Digression of Layering .............................    3
  28.       2. Mapping onto CLTS .....................................    3
  29.       2.1 Addressing Conventions ...............................    4
  30.       2.1.1 Conventions for CLNP-based service .................    4
  31.       3. Mapping onto COTS .....................................    4
  32.       3.1 Addressing Conventions ...............................    5
  33.       3.1.1 Conventions for TP4/CLNP-based service .............    5
  34.       3.1.2 Conventions for TP0/X.25-based service .............    6
  35.       4. Trap PDU ..............................................    6
  36.       5. Acknowledgements ......................................    7
  37.       6. References ............................................    7
  38.       7. Security Considerations................................    8
  39.       8. Author's Address.......................................    8
  40.  
  41. 1.  Background
  42.  
  43.    The Simple Network Management Protocol (SNMP) as defined in [1] is
  44.    now used as an integral part of the network management framework for
  45.    TCP/IP-based internets.  Together, with its companions standards,
  46.    which define the Structure of Management Information (SMI) [2], and
  47.    the Management Information Base (MIB) [3], the SNMP has received
  48.    widespread deployment in many operational networks running the
  49.    Internet suite of protocols.
  50.  
  51.    It should not be surprising that many of these sites might acquire
  52.    OSI capabilities and may wish to leverage their investment in SNMP
  53.    technology towards managing those OSI components.  This memo
  54.    addresses these concerns by defining a framework for running the SNMP
  55.  
  56.  
  57.  
  58. Rose                                                            [Page 1]
  59.  
  60. RFC 1283                     SNMP over OSI                 December 1991
  61.  
  62.  
  63.    in an environment which supports the OSI transport services.
  64.  
  65.    In OSI, there are two such services, a connection-oriented transport
  66.    services (COTS) as defined in [4], and a connectionless-mode
  67.    transport service (CLTS) as defined in [5].  Although the primary
  68.    deployment of the SNMP is over the connectionless-mode transport
  69.    service provided by the Internet suite of protocols (i.e., the User
  70.    Datagram Protocol or UDP [6]), a design goal of the SNMP was to be
  71.    able to use either a CO-mode or CL-mode transport service.  As such,
  72.    this memo describes mappings from the SNMP onto both the COTS and the
  73.    CLTS.
  74.  
  75. 1.1.  A Digression on User Interfaces
  76.  
  77.    It is likely that user-interfaces to the SNMP will be developed that
  78.    support multiple transport backings.  In an environment such as this,
  79.    it is often important to maintain a consistent addressing scheme for
  80.    users.  Since the mappings described in this memo are onto the OSI
  81.    transport services, use of the textual scheme described in [7], which
  82.    describes a string encoding for OSI presentation addresses, is
  83.    recommended.  The syntax defined in [7] is equally applicable towards
  84.    transport addresses.
  85.  
  86.    In this context, a string encoding usually appears as:
  87.  
  88.       [<t-selector>/]<n-provider><n-address>[+<n-info>]
  89.  
  90.       where:
  91.  
  92.       (1)  <t-selector> is usually either an ASCII string enclosed
  93.            in double-quotes (e.g., "snmp"), or a hexadecimal number
  94.            (e.g., '736e6d70'H);
  95.  
  96.       (2)  <n-provider> is one of several well-known providers of a
  97.            connectivity-service, one of: "Internet=" for a
  98.            transport-service from the Internet suite of protocols,
  99.            "Int-X25=" for the 1980 CCITT X.25 recommendation, or
  100.            "NS+" for the OSI network service;
  101.  
  102.       (3)  <n-address> is an address in a format specific to the
  103.            <n-provider>; and,
  104.  
  105.       (4)  <n-info> is any additional addressing information in a
  106.            format specific to the <n-provider>.
  107.  
  108.    It is not the purpose of this memo to provide an exhaustive
  109.    description of string encodings such as these.  Readers should
  110.    consult [7] for detailed information on the syntax.  However, this
  111.  
  112.  
  113.  
  114. Rose                                                            [Page 2]
  115.  
  116. RFC 1283                     SNMP over OSI                 December 1991
  117.  
  118.  
  119.    memo recommends that, as an implementation option, user-interfaces to
  120.    the SNMP that support multiple transport backings SHOULD implement
  121.    this syntax.
  122.  
  123. 1.1.1.  Addressing Conventions for UDP-based service
  124.  
  125.    In the context of a UDP-based transport backing, addresses would be
  126.    encoded as:
  127.  
  128.                            Internet=<host>+161+2
  129.  
  130.    which says that the transport service is from the Internet suite of
  131.    protocols, residing at <host>, on port 161, using the UDP (2).  The
  132.    token <host> may be either a domain name or a dotted-quad, e.g., both
  133.  
  134.                      Internet=cheetah.nyser.net+161+2
  135.  
  136.    and
  137.  
  138.                         Internet=192.52.180.1+161+2
  139.  
  140.    are both valid.  Note however that if domain name "cheetah.nyser.net"
  141.    maps to multiple IP addresses, then this implies multiple transport
  142.    addresses.  The number of addresses examined by the application (and
  143.    the order of examination) are specific to each application.
  144.  
  145.    Of course, this memo does not require that other interface schemes
  146.    not be used.  Clearly, use of a simple hostname is preferable to the
  147.    string encoding above.  However, for the sake of uniformity, for
  148.    those user-interfaces to the SNMP that support multiple transport
  149.    backings, it is strongly RECOMMENDED that the syntax in [7] be
  150.    adopted and even the mapping for UDP-based transport be valid.
  151.  
  152. 1.2.  A Digression of Layering
  153.  
  154.    Although other frameworks view network management as an application,
  155.    extensive experience with the SNMP suggests otherwise.  In essense,
  156.    network management is a function unlike any other user of a transport
  157.    service.  The citation [8] develops this argument in full.  As such,
  158.    it is inappropriate to map the SNMP onto the OSI application layer.
  159.    Rather, it is mapped to OSI transport services, in order to build on
  160.    the proven success of the Internet network management framework.
  161.  
  162. 2.  Mapping onto CLTS
  163.  
  164.    Mapping the SNMP onto the CLTS is straight-forward.  The elements of
  165.    procedure are identical to that of using the UDP, with one exception:
  166.    a slightly different Trap PDU is used.  Further, note that the CLTS
  167.  
  168.  
  169.  
  170. Rose                                                            [Page 3]
  171.  
  172. RFC 1283                     SNMP over OSI                 December 1991
  173.  
  174.  
  175.    and the service offered by the UDP both transmit packets of
  176.    information which contain full addressing information.  Thus, mapping
  177.    the SNMP onto the CLTS, a "transport address" in the context of [1],
  178.    is simply a transport-selector and network address.
  179.  
  180. 2.1.  Addressing Conventions
  181.  
  182.    Unlike the Internet suite of protocols, OSI does not use well-known
  183.    ports.  Rather demultiplexing occurs on the basis of "selectors",
  184.    which are opaque strings of octets, which have meaning only at the
  185.    destination.  In order to foster interoperable implementations of the
  186.    SNMP over the CLTS, it is necessary define a selector for this
  187.    purpose.
  188.  
  189. 2.1.1.  Conventions for CLNP-based service
  190.  
  191.    When the CLTS is used to provide the transport backing for the SNMP,
  192.    demultiplexing will occur on the basis of transport selector.  The
  193.    transport selector used shall be the four ASCII characters
  194.  
  195.                                    snmp
  196.  
  197.    Thus, using the string encoding of [7], such addresses may be
  198.    textual, described as:
  199.  
  200.                              "snmp"/NS+<nsap>
  201.  
  202.    where:
  203.  
  204.    (1)  <nsap> is a hex string defining the nsap, e.g.,
  205.  
  206.                      "snmp"/NS+4900590800200038bafe00
  207.  
  208.    Similarly, SNMP traps are, by convention, sent to a manager listening
  209.    on the transport selector
  210.  
  211.                                  snmp-trap
  212.  
  213.    which consists of nine ASCII characters.
  214.  
  215. 3.  Mapping onto COTS
  216.  
  217.    Mapping the SNMP onto the COTS is more difficult as the SNMP does not
  218.    specifically require an existing connection.  Thus, the mapping
  219.    consists of establishing a transport connection, sending one or more
  220.    SNMP messages on that connection, and then releasing the transport
  221.    connection.  Further, a slightly different Trap PDU is used.
  222.  
  223.  
  224.  
  225.  
  226. Rose                                                            [Page 4]
  227.  
  228. RFC 1283                     SNMP over OSI                 December 1991
  229.  
  230.  
  231.    Consistent with the SNMP model, the initiator of a connection should
  232.    not require that responses to a request be returned on that
  233.    connection.  However, if a responder to a connection sends SNMP
  234.    messages on a connection, then these MUST be in response to requests
  235.    received on that connection.
  236.  
  237.    Ideally, the transport connection SHOULD be released by the
  238.    initiator, however, note that the responder may release the
  239.    connection due to resource limitations.  Further note, that the
  240.    amount of time a connection remains established is implementation-
  241.    specific.  Implementors should take care to choose an appropriate
  242.    dynamic algorithm.
  243.  
  244.    Also consistent with the SNMP model, the initiator should not
  245.    associate any reliability characteristics with the use of a
  246.    connection.  Issues such as retransmission of SNMP messages, etc.,
  247.    always remain with the SNMP application, not with the transport
  248.    service.
  249.  
  250. 3.1.  Addressing Conventions
  251.  
  252.    Unlike the Internet suite of protocols, OSI does not use well-known
  253.    ports.  Rather demultiplexing occurs on the basis of "selectors",
  254.    which are opaque strings of octets, which have meaning only at the
  255.    destination.  In order to foster interoperable implementations of the
  256.    SNMP over the COTS, it is necessary define a selector for this
  257.    purpose.  However, to be consistent with the various connectivity-
  258.    services, different conventions, based on the actual underlying
  259.    service, will be used.
  260.  
  261. 3.1.1.  Conventions for TP4/CLNP-based service
  262.  
  263.    When a COTS based on the TP4/CLNP is used to provide the transport
  264.    backing for the SNMP, demultiplexing will occur on the basis of
  265.    transport selector.  The transport selector used shall be the four
  266.    ASCII characters
  267.  
  268.                                    snmp
  269.  
  270.    Thus, using the string encoding of [7], such addresses may be
  271.    textual, described as:
  272.  
  273.                              "snmp"/NS+<nsap>
  274.    where:
  275.  
  276.    (1)  <nsap> is a hex string defining the nsap, e.g.,
  277.  
  278.                      "snmp"/NS+4900590800200038bafe00
  279.  
  280.  
  281.  
  282. Rose                                                            [Page 5]
  283.  
  284. RFC 1283                     SNMP over OSI                 December 1991
  285.  
  286.  
  287.    Similarly, SNMP traps are, by convention, sent to a manager listening
  288.    on the transport selector
  289.  
  290.                                  snmp-trap
  291.  
  292.    which consists of nine ASCII characters.
  293.  
  294. 3.1.2.  Conventions for TP0/X.25-based service
  295.  
  296.    When a COTS based on the TP0/X.25 is used to provide the transport
  297.    backing for the SNMP, demultiplexing will occur on the basis of X.25
  298.    protocol-ID.  The protocol-ID used shall be the four octets
  299.  
  300.                                  03018200
  301.  
  302.    This is the X.25 protocol-ID assigned for local management purposes.
  303.    Thus, using the string encoding of [7], such addresses may be textual
  304.    described as:
  305.  
  306.                         Int-X25=<dte>+PID+03018200
  307.  
  308.    where:
  309.  
  310.    (1)  <dte> is the X.121 DTE, e.g.,
  311.  
  312.                     Int-X25=23421920030013+PID+03018200
  313.  
  314.    Similarly, SNMP traps are, by convention, sent to a manager listening
  315.    on the protocol-ID
  316.  
  317.                                  03019000
  318.  
  319.    This is an X.25 protocol-ID assigned for local purposes.
  320.  
  321. 4. Trap PDU
  322.  
  323.    The Trap-PDU defined in [1] is designed to represent traps generated
  324.    on IP networks.  As such, a slightly different PDU must be used when
  325.    representing traps generated on OSI networks.
  326.  
  327.    RFC1283 DEFINTIONS ::= BEGIN
  328.  
  329.    IMPORTS
  330.         TimeTicks
  331.             FROM RFC1155-SMI  -- [2] --
  332.         VarBindList
  333.             FROM RFC1157-SNMP -- [1] --
  334.         ClnpAddress
  335.  
  336.  
  337.  
  338. Rose                                                            [Page 6]
  339.  
  340. RFC 1283                     SNMP over OSI                 December 1991
  341.  
  342.  
  343.             FROM CLNS-MIB     -- [9] --;
  344.  
  345.    Trap-PDU ::=
  346.         [4]
  347.             IMPLICT SEQUENCE {
  348.                 enterprise              -- type of object generating
  349.                     OBJECT IDENTIFIER,  -- trap, see sysObjectID
  350.  
  351.                 agent-addr              -- address of object generating
  352.                     ClnpAddress,        -- trap
  353.  
  354.                 generic-trap            -- generic trap type
  355.                     INTEGER {
  356.                         coldStart(0),
  357.                         warmStart(1),
  358.                         linkDown(2),
  359.                         linkUp(3),
  360.                         authenticationFailure(4),
  361.                         egpNeighborLoss(5),
  362.                         enterpriseSpecific(6)
  363.                     },
  364.  
  365.                 specific-trap           -- specific code, present even
  366.                     INTEGER,            -- if generic-trap is not
  367.                                         -- enterpriseSpecific
  368.  
  369.                 time-stamp              -- time elapsed between the last
  370.                     TimeTicks,          -- (re)initialization of the
  371.                                         -- network entity and the
  372.                                         -- generation of the trap
  373.  
  374.                 variable-bindings       -- "interesting" information
  375.                     VarBindList
  376.         }
  377.  
  378.    END
  379.  
  380. 5.  Acknowledgements
  381.  
  382.    The predecessor of this document (RFC 1161) was produced by the SNMP
  383.    Working Group, and subsequently modified by the editor to reflect
  384.    operational experience gained since the original publication.
  385.  
  386. 6.  References
  387.  
  388.    [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
  389.        Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
  390.        Performance Systems International, Performance Systems
  391.  
  392.  
  393.  
  394. Rose                                                            [Page 7]
  395.  
  396. RFC 1283                     SNMP over OSI                 December 1991
  397.  
  398.  
  399.        International, and MIT Laboratory for Computer Science, May 1990.
  400.  
  401.    [2] Rose M., and K. McCloghrie, "Structure and Identification of
  402.        Management Information for TCP/IP-based internets", RFC 1155,
  403.        Performance Systems International, Hughes LAN Systems, May 1990.
  404.  
  405.    [3] McCloghrie K., and M. Rose, Editors, "Management Information Base
  406.        for Network Management of TCP/IP-based internets", RFC 1213,
  407.        Hughes LAN Systems, Performance Systems International, March
  408.        1991.
  409.  
  410.    [4] Information Processing Systems - Open Systems Interconnection,
  411.        "Transport Service Definition", International Organization for
  412.        Standardization, International Standard 8072, June 1986.
  413.  
  414.    [5] Information Processing Systems - Open Systems Interconnection,
  415.        "Transport Service Definition - Addendum 1: Connectionless-mode
  416.        Transmission", International Organization for Standardization,
  417.        International Standard 8072/AD 1, December 1986.
  418.  
  419.    [6] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
  420.        Sciences Institute, November 1980.
  421.  
  422.    [7] Kille, S., "A String Encoding of Presentation Address", RFC 1278,
  423.        Department of Computer Science, University College London,
  424.        November 1991.
  425.  
  426.    [8] Case, J., Davin, J., Fedor, M., and M. Schoffstall, "Network
  427.        Management and the Design of SNMP", ConneXions (ISSN 0894-5926),
  428.        Volume 3, Number 3, March 1989.
  429.  
  430.    [9] Satz, G., "CLNS MIB for use with CLNP and ES-IS", RFC 1238, cisco
  431.        Systems, June 1991.
  432.  
  433. 7.  Security Considerations
  434.  
  435.    Security issues are not discussed in this memo.
  436.  
  437. 8.  Author's Address
  438.  
  439.    Marshall T. Rose
  440.    Dover Beach Consulting, Inc.
  441.    420 Whisman Court
  442.    Mountain View, CA 94043-2112
  443.  
  444.    Phone: (415) 968-1052
  445.    Email: mrose@dbc.mtview.ca.us
  446.    X.500: mrose, dbc, us
  447.  
  448.  
  449.  
  450. Rose                                                            [Page 8]
  451.  
  452.