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