Internet Draft       Transport Mappings for SNMPv2         November 1994


                Transport Mappings for Version 2 of the
              Simple Network Management Protocol (SNMPv2)

                            1 November 1994


                            Jeffrey D. Case
                          SNMP Research, Inc.
                             case@snmp.com

                            Keith McCloghrie
                          Cisco Systems, Inc.
                             kzm@cisco.com

                            Marshall T. Rose
                      Dover Beach Consulting, Inc.
                         mrose@dbc.mtview.ca.us

                           Steven Waldbusser
                       Carnegie Mellon University
                           waldbusser@cmu.edu


                    <draft-ietf-snmpv2-tm-ds-00.txt>



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
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.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).







Expires May 1994                                                [Page 1]


Internet Draft       Transport Mappings for SNMPv2         November 1994


1.  Introduction

A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations.  Operations of the protocol are carried
out under an administrative framework which defines authentication,
authorization, access control, and privacy policies.

Management stations execute management applications which monitor and
control managed elements.  Managed elements are devices such as hosts,
routers, terminal servers, etc., which are monitored and controlled via
access to their management information.

The management protocol, version 2 of the Simple Network Management
Protocol [1], may be used over a variety of protocol suites.  It is the
purpose of this document to define how the SNMPv2 maps onto an initial
set of transport domains.  Other mappings may be defined in the future.

Although several mappings are defined, the mapping onto UDP is the
preferred mapping.  As such, to provide for the greatest level of
interoperability, systems which choose to deploy other mappings should
also provide for proxy service to the UDP mapping.


1.1.  A Note on Terminology

For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1).  The current framework is
termed the SNMP version 2 framework (SNMPv2).


1.2.  Change Log

For the 1 November version:

-    recast RFC 1449 into an Internet-Draft,

-    fixed typos,

-    clarified the description of the use of rfc1157Domain as the
     transport domain of a proxy destination party.






Expires May 1994                                                [Page 2]


Internet Draft       Transport Mappings for SNMPv2         November 1994


2.  Definitions

SNMPv2-TM DEFINITIONS ::= BEGIN

IMPORTS
    snmpDomains, snmpProxys
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION
        FROM SNMPv2-TC;

-- SNMPv2 over UDP

snmpUDPDomain  OBJECT IDENTIFIER ::= { snmpDomains 1 }
-- for a SnmpUDPAddress of length 6:
--
-- octets   contents        encoding
--  1-4     IP-address      network-byte order
--  5-6     UDP-port        network-byte order
--
SnmpUDPAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d/2d"
    STATUS       current
    DESCRIPTION
            "Represents a UDP address."
    SYNTAX       OCTET STRING (SIZE (6))

























Expires May 1994                                                [Page 3]


Internet Draft       Transport Mappings for SNMPv2         November 1994


-- SNMPv2 over OSI

snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 }
snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 }
-- for a SnmpOSIAddress of length m:
--
-- octets   contents            encoding
--    1     length of NSAP      "n" as an unsigned-integer
--                                (either 0 or from 3 to 20)
-- 2..(n+1) NSAP                concrete binary representation
-- (n+2)..m TSEL                string of (up to 64) octets
--
SnmpOSIAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "*1x:/1x:"
    STATUS       current
    DESCRIPTION
            "Represents an OSI transport-address."
    SYNTAX       OCTET STRING (SIZE (1 | 4..85))
































Expires May 1994                                                [Page 4]


Internet Draft       Transport Mappings for SNMPv2         November 1994


-- SNMPv2 over DDP

snmpDDPDomain  OBJECT IDENTIFIER ::= { snmpDomains 4 }
-- for a SnmpNBPAddress of length m:
--
--    octets      contents          encoding
--       1        length of object  "n" as an unsigned integer
--     2..(n+1)   object            string of (up to 32) octets
--      n+2       length of type    "p" as an unsigned integer
-- (n+3)..(n+2+p) type              string of (up to 32) octets
--     n+3+p      length of zone    "q" as an unsigned integer
-- (n+4+p)..m     zone              string of (up to 32) octets
--
-- for comparison purposes, strings are case-insensitive
--
-- all strings may contain any octet other than 255 (hex ff)
--
SnmpNBPAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Represents an NBP name."
    SYNTAX       OCTET STRING (SIZE (3..99))


-- SNMPv2 over IPX

snmpIPXDomain  OBJECT IDENTIFIER ::= { snmpDomains 5 }
-- for a SnmpIPXAddress of length 12:
--
-- octets   contents            encoding
--  1-4     network-number      network-byte order
--  5-10    physical-address    network-byte order
-- 11-12    socket-number       network-byte order
--
SnmpIPXAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
    STATUS       current
    DESCRIPTION
            "Represents an IPX address."
    SYNTAX       OCTET STRING (SIZE (12))










Expires May 1994                                                [Page 5]


Internet Draft       Transport Mappings for SNMPv2         November 1994


-- for proxy to community-based SNMPv1 (RFC 1157)

rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }

-- uses SnmpUDPAddress
rfc1157Domain  OBJECT IDENTIFIER ::= { rfc1157Proxy 1 }

-- the community-based noAuth
rfc1157noAuth  OBJECT IDENTIFIER ::= { rfc1157Proxy 2 }


END






































Expires May 1994                                                [Page 6]


Internet Draft       Transport Mappings for SNMPv2         November 1994


3.  SNMPv2 over UDP

This is the preferred transport mapping.


3.1.  Serialization

Each instance of a message is serialized (i.e., encoded according to the
convention of [1]) onto a single UDP[2] datagram, using the algorithm
specified in Section 8.


3.2.  Well-known Values

Although the partyTable gives transport addressing information for an
SNMPv2 party, it is suggested that administrators configure their SNMPv2
entities acting in an agent role to listen on UDP port 161.  Further, it
is suggested that notification sinks be configured to listen on UDP port
162.

The partyTable also lists the maximum message size which a SNMPv2 party
is willing to accept.  This value must be at least 484 octets.
Implementation of larger values is encouraged whenever possible.



























Expires May 1994                                                [Page 7]


Internet Draft       Transport Mappings for SNMPv2         November 1994


4.  SNMPv2 over OSI

This is an optional transport mapping.


4.1.  Serialization

Each instance of a message is serialized onto a single TSDU [3,4] for
the OSI Connectionless-mode Transport Service (CLTS), using the
algorithm specified in Section 8.


4.2.  Well-known Values

Although the partyTable gives transport addressing information for an
SNMPv2 party, it is suggested that administrators configure their SNMPv2
entities acting in an agent role to listen on transport selector "snmp-
l" (which consists of six ASCII characters), when using a CL-mode
network service to realize the CLTS.  Further, it is suggested that
notification sinks be configured to listen on transport selector
"snmpt-l" (which consists of seven ASCII characters, six letters and a
hyphen) when using a CL-mode network service to realize the CLTS.
Similarly, when using a CO-mode network service to realize the CLTS, the
suggested transport selectors are "snmp-o"  and "snmpt-o", for agent and
notification sink, respectively.

The partyTable also lists the maximum message size which a SNMPv2 party
is willing to accept.  This value must be at least 484 octets.
Implementation of larger values is encouraged whenever possible.





















Expires May 1994                                                [Page 8]


Internet Draft       Transport Mappings for SNMPv2         November 1994


5.  SNMPv2 over DDP

This is an optional transport mapping.


5.1.  Serialization

Each instance of a message is serialized onto a single DDP datagram [5],
using the algorithm specified in Section 8.


5.2.  Well-known Values

SNMPv2 messages are sent using DDP protocol type 8.  SNMPv2 entities
acting in an agent role listens on DDP socket number 8, whilst
notification sinks listen on DDP socket number 9.

Although the partyTable gives transport addressing information for an
SNMPv2 party, administrators must configure their SNMPv2 entities acting
in an agent role to use NBP type "SNMP Agent" (which consists of ten
ASCII characters), whilst notification sinks must be configured to use
NBP type "SNMP Trap Handler" (which consists of seventeen ASCII
characters).

The NBP name for agents and notification sinks should be stable - NBP
names should not change any more often than the IP address of a typical
TCP/IP node.  It is suggested that the NBP name be stored in some form
of stable storage.

The partyTable also lists the maximum message size which a SNMPv2 party
is willing to accept.  This value must be at least 484 octets.
Implementation of larger values is encouraged whenever possible.


5.3.  Discussion of AppleTalk Addressing

The AppleTalk protocol suite has certain features not manifest in the
TCP/IP suite.  AppleTalk's naming strategy and the dynamic nature of
address assignment can cause problems for SNMPv2 entities that wish to
manage AppleTalk networks.  TCP/IP nodes have an associated IP address
which distinguishes each from the other.  In contrast, AppleTalk nodes
generally have no such characteristic.  The network-level address, while
often relatively stable, can change at every reboot (or more
frequently).






Expires May 1994                                                [Page 9]


Internet Draft       Transport Mappings for SNMPv2         November 1994


Thus, when SNMPv2 is mapped over DDP, nodes are identified by a "name",
rather than by an "address".  Hence, all AppleTalk nodes that implement
this mapping are required to respond to NBP lookups and confirms (e.g.,
implement the NBP protocol stub), which guarantees that a mapping from
NBP name to DDP address will be possible.

In determining the SNMP identity to register for an SNMPv2 entity, it is
suggested that the SNMP identity be a name which is associated with
other network services offered by the machine.

NBP lookups, which are used to map NBP names into DDP addresses, can
cause large amounts of network traffic as well as consume CPU resources.
It is also the case that the ability to perform an NBP lookup is
sensitive to certain network disruptions (such as zone table
inconsistencies) which would not prevent direct AppleTalk communications
between two SNMPv2 entities.

Thus, it is recommended that NBP lookups be used infrequently, primarily
to create a cache of name-to-address mappings.  These cached mappings
should then be used for any further SNMP traffic.  It is recommended
that SNMPv2 entities acting in a manager role should maintain this cache
between reboots.  This caching can help minimize network traffic, reduce
CPU load on the network, and allow for (some amount of) network trouble
shooting when the basic name-to-address translation mechanism is broken.


5.3.1.  How to Acquire NBP names

An SNMPv2 entity acting in a manager role may have a pre-configured list
of names of "known" SNMPv2 entities acting in an agent role.  Similarly,
an SNMPv2 entity acting in a manager role might interact with an
operator.  Finally, an SNMPv2 entity acting in a manager role might
communicate with all SNMPv2 entities acting in an agent role in a set of
zones or networks.


5.3.2.  When to Turn NBP names into DDP addresses

When an SNMPv2 entity uses a cache entry to address an SNMP packet, it
should attempt to confirm the validity mapping, if the mapping hasn't
been confirmed within the last T1 seconds.  This cache entry lifetime,
T1, has a minimum, default value of 60 seconds, and should be
configurable.







Expires May 1994                                               [Page 10]


Internet Draft       Transport Mappings for SNMPv2         November 1994


An SNMPv2 entity acting in a manager role may decide to prime its cache
of names prior to actually communicating with another SNMPv2 entity.  In
general, it is expected that such an entity may want to keep certain
mappings "more current" than other mappings, e.g., those nodes which
represent the network infrastructure (e.g., routers) may be deemed "more
important".

Note that an SNMPv2 entity acting in a manager role should not prime its
entire cache upon initialization - rather, it should attempt resolutions
over an extended period of time (perhaps in some pre-determined or
configured priority order).  Each of these resolutions might, in fact,
be a wildcard lookup in a given zone.

An SNMPv2 entity acting in an agent role must never prime its cache.
Such an entity should do NBP lookups (or confirms) only when it needs to
send an SNMP trap.  When generating a response, such an entity does not
need to confirm a cache entry.


5.3.3.  How to Turn NBP names into DDP addresses

If the only piece of information available is the NBP name, then an NBP
lookup should be performed to turn that name into a DDP address.
However, if there is a piece of stale information, it can be used as a
hint to perform an NBP confirm (which sends a unicast to the network
address which is presumed to be the target of the name lookup) to see if
the stale information is, in fact, still valid.

An NBP name to DDP address mapping can also be confirmed implicitly
using only SNMP transactions.  For example, an SNMPv2 entity acting in a
manager role issuing a retrieval operation could also retrieve the
relevant objects from the NBP group [6] for the SNMPv2 entity acting in
an agent role.  This information can then be correlated with the source
DDP address of the response.


5.3.4.  What if NBP is broken

Under some circumstances, there may be connectivity between two SNMPv2
entities, but the NBP mapping machinery may be broken, e.g.,

o    the NBP FwdReq (forward NBP lookup onto local attached network)
     mechanism might be broken at a router on the other entity's
     network; or,






Expires May 1994                                               [Page 11]


Internet Draft       Transport Mappings for SNMPv2         November 1994


o    the NBP BrRq (NBP broadcast request) mechanism might be broken at a
     router on the entity's own network; or,

o    NBP might be broken on the other entity's node.

An SNMPv2 entity acting in a manager role which is dedicated to
AppleTalk management might choose to alleviate some of these failures by
directly implementing the router portion of NBP.  For example, such an
entity might already know all the zones on the AppleTalk internet and
the networks on which each zone appears.  Given an NBP lookup which
fails, the entity could send an NBP FwdReq to the network in which the
agent was last located.  If that failed, the station could then send an
NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each
network number on that network.  Of the above (single) failures, this
combined approach will solve the case where either the local router's
BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp
mechanism is broken.

































Expires May 1994                                               [Page 12]


Internet Draft       Transport Mappings for SNMPv2         November 1994


6.  SNMPv2 over IPX

This is an optional transport mapping.


6.1.  Serialization

Each instance of a message is serialized onto a single IPX datagram [7],
using the algorithm specified in Section 8.


6.2.  Well-known Values

SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange
Protocol).

Although the partyTable gives transport addressing information for an
SNMPv2 party, it is suggested that administrators configure their SNMPv2
entities acting in an agent role to listen on IPX socket 36879 (900f
hexadecimal).  Further, it is suggested that notification sinks be
configured to listen on IPX socket 36880 (9010 hexadecimal)

The partyTable also lists the maximum message size which a SNMPv2 party
is willing to accept.  This value must be at least 546 octets.
Implementation of larger values is encouraged whenever possible.

























Expires May 1994                                               [Page 13]


Internet Draft       Transport Mappings for SNMPv2         November 1994


7.  Proxy to SNMPv1

In order to provide proxy to community-based SNMP [8], some definitions
are necessary for both transport domains and authentication protocols.


7.1.  Transport Domain: rfc1157Domain

The transport domain, rfc1157Domain, indicates the transport mapping for
community-based SNMP messages defined in RFC 1157.  When a party's
transport domain (partyTDomain) is rfc1157Domain:

(1)  the party's transport address (partyTAddress) shall be 6 octets
     long, the initial 4 octets containing the IP-address in network-
     byte order, and the last two octets containing the UDP port in
     network-byte order; and,

(2)  the party's authentication protocol (partyAuthProtocol) shall be
     rfc1157noAuth.

When a proxy context specifies a proxy destination party which has
rfc1157Domain as its transport domain:

(1)  the proxy source party (contextSrcPartyIndex) and proxied context
     (contextProxyContext) components of the proxy context are
     irrelevant; and,

(2)  Section 3.1 of [9] specifies the behavior of the proxy agent.


7.2.  Authentication Algorithm: rfc1157noAuth

A party's authentication protocol (partyAuthProtocol) specifies the
protocol and mechanism by which the party authenticates the integrity
and origin of the SNMPv1 or SNMPv2 PDUs it generates.  When a party's
authentication protocol is rfc1157noAuth:

(1)  the party's public authentication key (partyAuthPublic), clock
     (partyAuthClock), and lifetime (partyAuthLifetime) are irrelevant;
     and,

(2)  the party's private authentication key (partyAuthPrivate) shall be
     used as the 1157 community for the proxy destination, and shall be
     at least one octet in length.  (No maximum length is specified.)






Expires May 1994                                               [Page 14]


Internet Draft       Transport Mappings for SNMPv2         November 1994


Note that when setting the party's private authentication key, the
exclusive-OR semantics specified in [10] still apply.
















































Expires May 1994                                               [Page 15]


Internet Draft       Transport Mappings for SNMPv2         November 1994


8.  Serialization using the Basic Encoding Rules

When the Basic Encoding Rules [11] are used for serialization:

(1)  When encoding the length field, only the definite form is used; use
     of the indefinite form encoding is prohibited.  Note that when
     using the definite-long form, it is permissible to use more than
     the minimum number of length octets necessary to encode the length
     field.

(2)  When encoding the value field, the primitive form shall be used for
     all simple types, i.e., INTEGER, OCTET STRING, OBJECT IDENTIFIER,
     and BIT STRING (either IMPLICIT or explicit).  The constructed form
     of encoding shall be used only for structured types, i.e., a
     SEQUENCE or an IMPLICIT SEQUENCE.

(3)  When a BIT STRING is serialized, all named-bits are transferred
     regardless of their truth-value.  Further, if the number of named-
     bits is not an integral multiple of eight, then the fewest number
     of additional zero-valued bits are transferred so that an integral
     multiple of eight bits is transferred.

These restrictions apply to all aspects of ASN.1 encoding, including the
message wrappers, protocol data units, and the data objects they
contain.

























Expires May 1994                                               [Page 16]


Internet Draft       Transport Mappings for SNMPv2         November 1994


8.1.  Usage Example

As an example of applying the Basic Encoding Rules, suppose one wanted
to encode an instance of the GetBulkRequest-PDU [1]:

     [5] IMPLICIT SEQUENCE {
             request-id      1414684022,
             non-repeaters   1,
             max-repetitions 2,
             variable-bindings {
                 { name sysUpTime,
                   value { unspecified NULL } },
                 { name ipNetToMediaPhysAddress,
                   value { unspecified NULL } },
                 { name ipNetToMediaType,
                   value { unspecified NULL } }
             }
         }

Applying the BER, this would be encoded (in hexadecimal) as:

[5] IMPLICIT SEQUENCE          a5 82 00 39
    INTEGER                    02 04 52 54 5d 76
    INTEGER                    02 01 01
    INTEGER                    02 01 02
    SEQUENCE                   30 2b
        SEQUENCE               30 0b
            OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
            NULL               05 00
        SEQUENCE               30 0d
            OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
            NULL               05 00
        SEQUENCE               30 0d
            OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04
            NULL               05 00

Note that the initial SEQUENCE is not encoded using the minimum number
of length octets.  (The first octet of the length, 82, indicates that
the length of the content is encoded in the next two octets.)











Expires May 1994                                               [Page 17]


Internet Draft       Transport Mappings for SNMPv2         November 1994


9.  Acknowledgements

This document is a modified version of RFC 1449.


10.  References

[1]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
     Operations for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
     Dover Beach Consulting, Inc., Carnegie Mellon University, November
     1994.

[2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
     USC/Information Sciences Institute, August 1980.

[3]  Information processing systems - Open Systems Interconnection -
     Transport Service Definition, International Organization for
     Standardization.  International Standard 8072, (June, 1986).

[4]  Information processing systems - Open Systems Interconnection -
     Transport Service Definition - Addendum 1: Connectionless-mode
     Transmission, International Organization for Standardization.
     International Standard 8072/AD 1, (December, 1986).

[5]  G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
     edition).  Addison-Wesley, 1990.

[6]  Waldbusser, S., "AppleTalk Management Information Base", RFC 1243,
     Carnegie Mellon University, July 1991.

[7]  Network System Technical Interface Overview.  Novell, Inc, (June,
     1989).

[8]  Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
     Systems International, MIT Laboratory for Computer Science, May
     1990.

[9]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
     "Coexistence between Version 1 and Version 2 of the Internet-
     standard Network Management Framework", Internet Draft, SNMP
     Research, Inc., Cisco Systems, Dover Beach Consulting, Inc.,
     Carnegie Mellon University, November 1994.






Expires May 1994                                               [Page 18]


Internet Draft       Transport Mappings for SNMPv2         November 1994


[10] McCloghrie, K., and Galvin, J., "Party MIB for Version 2 of the
     Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco
     Systems, Trusted Information Systems, November 1994.

[11] Information processing systems - Open Systems Interconnection -
     Specification of Basic Encoding Rules for Abstract Syntax Notation
     One (ASN.1), International Organization for Standardization.
     International Standard 8825, (December, 1987).










































Expires May 1994                                               [Page 19]


Internet Draft       Transport Mappings for SNMPv2         November 1994


11.  Security Considerations

Security issues are not discussed in this memo.


12.  Authors' Addresses

     Jeffrey D. Case
     SNMP Research, Inc.
     3001 Kimberlin Heights Rd.
     Knoxville, TN  37920-9716
     US

     Phone: +1 615 573 1434
     Email: case@snmp.com


     Keith McCloghrie
     Cisco Systems, Inc.
     170 West Tasman Drive,
     San Jose CA 95134-1706.

     Phone: +1 408 526 5260
     Email: kzm@cisco.com


     Marshall T. Rose
     Dover Beach Consulting, Inc.
     420 Whisman Court
     Mountain View, CA  94043-2186
     US

     Phone: +1 415 968 1052
     Email: mrose@dbc.mtview.ca.us

     Steven Waldbusser
     Carnegie Mellon University
     5000 Forbes Ave
     Pittsburgh, PA  15213
     US

     Phone: +1 412 268 6628
     Email: waldbusser@cmu.edu







Expires May 1994                                               [Page 20]


Internet Draft       Transport Mappings for SNMPv2         November 1994


Table of Contents


1 Introduction ....................................................    2
1.1 A Note on Terminology .........................................    2
1.2 Change Log ....................................................    2
2 Definitions .....................................................    3
3 SNMPv2 over UDP .................................................    7
3.1 Serialization .................................................    7
3.2 Well-known Values .............................................    7
4 SNMPv2 over OSI .................................................    8
4.1 Serialization .................................................    8
4.2 Well-known Values .............................................    8
5 SNMPv2 over DDP .................................................    9
5.1 Serialization .................................................    9
5.2 Well-known Values .............................................    9
5.3 Discussion of AppleTalk Addressing ............................    9
5.3.1 How to Acquire NBP names ....................................   10
5.3.2 When to Turn NBP names into DDP addresses ...................   10
5.3.3 How to Turn NBP names into DDP addresses ....................   11
5.3.4 What if NBP is broken .......................................   11
6 SNMPv2 over IPX .................................................   13
6.1 Serialization .................................................   13
6.2 Well-known Values .............................................   13
7 Proxy to SNMPv1 .................................................   14
7.1 Transport Domain: rfc1157Domain ...............................   14
7.2 Authentication Algorithm: rfc1157noAuth .......................   14
8 Serialization using the Basic Encoding Rules ....................   16
8.1 Usage Example .................................................   17
9 Acknowledgements ................................................   18
10 References .....................................................   18
11 Security Considerations ........................................   20
12 Authors' Addresses .............................................   20

















Expires May 1994                                               [Page 21]