summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1449.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1449.txt')
-rw-r--r--doc/rfc/rfc1449.txt1475
1 files changed, 1475 insertions, 0 deletions
diff --git a/doc/rfc/rfc1449.txt b/doc/rfc/rfc1449.txt
new file mode 100644
index 0000000..d8c43b4
--- /dev/null
+++ b/doc/rfc/rfc1449.txt
@@ -0,0 +1,1475 @@
+
+
+
+ Network Working Group J. Case
+ Request for Comments: 1449 SNMP Research, Inc.
+ K. McCloghrie
+ Hughes LAN Systems
+ M. Rose
+ Dover Beach Consulting, Inc.
+ S. Waldbusser
+ Carnegie Mellon University
+ April 1993
+
+
+ Transport Mappings
+ for version 2 of the
+ Simple Network Management Protocol (SNMPv2)
+
+
+ Status of this Memo
+
+ This RFC specifes an IAB standards track protocol for the
+ Internet community, and requests discussion and suggestions
+ for improvements. Please refer to the current edition of the
+ "IAB Official Protocol Standards" for the standardization
+ state and status of this protocol. Distribution of this memo
+ is unlimited.
+
+
+ Table of Contents
+
+
+ 1 Introduction .......................................... 2
+ 1.1 A Note on Terminology ............................... 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 ......... 11
+ 5.3.3 How to Turn NBP names into DDP addresses .......... 11
+ 5.3.4 What if NBP is broken ............................. 12
+ 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
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page i]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 8 Serialization using the Basic Encoding Rules .......... 16
+ 8.1 Usage Example ....................................... 17
+ 9 Acknowledgements ...................................... 18
+ 10 References ........................................... 22
+ 11 Security Considerations .............................. 24
+ 12 Authors' Addresses ................................... 24
+ 13 Security Considerations .............................. 25
+ 14 Authors' Addresses ................................... 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 1]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 1. Introduction
+
+ A network 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 both authentication and
+ authorization policies.
+
+ Network management stations execute management applications
+ which monitor and control network elements. Network elements
+ are devices such as hosts, routers, terminal servers, etc.,
+ which are monitored and controlled through 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 2]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 3]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ -- 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))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 4]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ -- 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))
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 5]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ -- 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 6]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 3. SNMPv2 over UDP
+
+ This is the preferred transport mapping.
+
+
+ 3.1. Serialization
+
+ Each instance of a message is serialized 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 7]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 8]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 9]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ frequently).
+
+ 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.
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 10]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 11]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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,
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 12]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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 Packet).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 13]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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 relationship identifies a proxy destination party
+ which has rfc1157Domain as its transport domain:
+
+ (1) the proxy source party (contextSrcPartyIndex) and proxy
+ context (contextProxyContext) components of the proxy
+ relationship 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,
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 14]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ (2) the party's private authentication key
+ (partySecretsAuthPrivate) 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.)
+
+ Note that when setting the party's private authentication key,
+ the exclusive-OR semantics specified in [10] still apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 15]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 16]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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.)
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 17]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 9. Acknowledgements
+
+ The UDP-based mapping is based, in part, on RFC 1157.
+
+ The OSI-based mapping is based, in part, on RFC 1283.
+
+ The DDP-based mapping is based, in part, on earlier work by
+ Greg Minshall of Novell, Inc., and Mike Ritter of Apple
+ Computer, Inc.
+
+ The IPX-based mapping is based, in part, on RFC 1298.
+
+ The section on proxy to community-based SNMP is based on
+ earlier work that was based in part on a suggestion by
+ Jonathan Biggar of Netlabs, Inc.
+
+ Finally, the comments of the SNMP version 2 working group are
+ gratefully acknowledged:
+
+ Beth Adams, Network Management Forum
+ Steve Alexander, INTERACTIVE Systems Corporation
+ David Arneson, Cabletron Systems
+ Toshiya Asaba
+ Fred Baker, ACC
+ Jim Barnes, Xylogics, Inc.
+ Brian Bataille
+ Andy Bierman, SynOptics Communications, Inc.
+ Uri Blumenthal, IBM Corporation
+ Fred Bohle, Interlink
+ Jack Brown
+ Theodore Brunner, Bellcore
+ Stephen F. Bush, GE Information Services
+ Jeffrey D. Case, University of Tennessee, Knoxville
+ John Chang, IBM Corporation
+ Szusin Chen, Sun Microsystems
+ Robert Ching
+ Chris Chiotasso, Ungermann-Bass
+ Bobby A. Clay, NASA/Boeing
+ John Cooke, Chipcom
+ Tracy Cox, Bellcore
+ Juan Cruz, Datability, Inc.
+ David Cullerot, Cabletron Systems
+ Cathy Cunningham, Microcom
+ James R. (Chuck) Davin, Bellcore
+ Michael Davis, Clearpoint
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 18]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ Mike Davison, FiberCom
+ Cynthia DellaTorre, MITRE
+ Taso N. Devetzis, Bellcore
+ Manual Diaz, DAVID Systems, Inc.
+ Jon Dreyer, Sun Microsystems
+ David Engel, Optical Data Systems
+ Mike Erlinger, Lexcel
+ Roger Fajman, NIH
+ Daniel Fauvarque, Sun Microsystems
+ Karen Frisa, CMU
+ Shari Galitzer, MITRE
+ Shawn Gallagher, Digital Equipment Corporation
+ Richard Graveman, Bellcore
+ Maria Greene, Xyplex, Inc.
+ Michel Guittet, Apple
+ Robert Gutierrez, NASA
+ Bill Hagerty, Cabletron Systems
+ Gary W. Haney, Martin Marietta Energy Systems
+ Patrick Hanil, Nokia Telecommunications
+ Matt Hecht, SNMP Research, Inc.
+ Edward A. Heiner, Jr., Synernetics Inc.
+ Susan E. Hicks, Martin Marietta Energy Systems
+ Geral Holzhauer, Apple
+ John Hopprich, DAVID Systems, Inc.
+ Jeff Hughes, Hewlett-Packard
+ Robin Iddon, Axon Networks, Inc.
+ David Itusak
+ Kevin M. Jackson, Concord Communications, Inc.
+ Ole J. Jacobsen, Interop Company
+ Ronald Jacoby, Silicon Graphics, Inc.
+ Satish Joshi, SynOptics Communications, Inc.
+ Frank Kastenholz, FTP Software
+ Mark Kepke, Hewlett-Packard
+ Ken Key, SNMP Research, Inc.
+ Zbiginew Kielczewski, Eicon
+ Jongyeoi Kim
+ Andrew Knutsen, The Santa Cruz Operation
+ Michael L. Kornegay, VisiSoft
+ Deirdre C. Kostik, Bellcore
+ Cheryl Krupczak, Georgia Tech
+ Mark S. Lewis, Telebit
+ David Lin
+ David Lindemulder, AT&T/NCR
+ Ben Lisowski, Sprint
+ David Liu, Bell-Northern Research
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 19]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ John Lunny, The Wollongong Group
+ Robert C. Lushbaugh Martin, Marietta Energy Systems
+ Michael Luufer, BBN
+ Carl Madison, Star-Tek, Inc.
+ Keith McCloghrie, Hughes LAN Systems
+ Evan McGinnis, 3Com Corporation
+ Bill McKenzie, IBM Corporation
+ Donna McMaster, SynOptics Communications, Inc.
+ John Medicke, IBM Corporation
+ Doug Miller, Telebit
+ Dave Minnich, FiberCom
+ Mohammad Mirhakkak, MITRE
+ Rohit Mital, Protools
+ George Mouradian, AT&T Bell Labs
+ Patrick Mullaney, Cabletron Systems
+ Dan Myers, 3Com Corporation
+ Rina Nathaniel, Rad Network Devices Ltd.
+ Hien V. Nguyen, Sprint
+ Mo Nikain
+ Tom Nisbet
+ William B. Norton, MERIT
+ Steve Onishi, Wellfleet Communications, Inc.
+ David T. Perkins, SynOptics Communications, Inc.
+ Carl Powell, BBN
+ Ilan Raab, SynOptics Communications, Inc.
+ Richard Ramons, AT&T
+ Venkat D. Rangan, Metric Network Systems, Inc.
+ Louise Reingold, Sprint
+ Sam Roberts, Farallon Computing, Inc.
+ Kary Robertson, Concord Communications, Inc.
+ Dan Romascanu, Lannet Data Communications Ltd.
+ Marshall T. Rose, Dover Beach Consulting, Inc.
+ Shawn A. Routhier, Epilogue Technology Corporation
+ Chris Rozman
+ Asaf Rubissa, Fibronics
+ Jon Saperia, Digital Equipment Corporation
+ Michael Sapich
+ Mike Scanlon, Interlan
+ Sam Schaen, MITRE
+ John Seligson, Ultra Network Technologies
+ Paul A. Serice, Corporation for Open Systems
+ Chris Shaw, Banyan Systems
+ Timon Sloane
+ Robert Snyder, Cisco Systems
+ Joo Young Song
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 20]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ Roy Spitier, Sprint
+ Einar Stefferud, Network Management Associates
+ John Stephens, Cayman Systems, Inc.
+ Robert L. Stewart, Xyplex, Inc. (chair)
+ Kaj Tesink, Bellcore
+ Dean Throop, Data General
+ Ahmet Tuncay, France Telecom-CNET
+ Maurice Turcotte, Racal Datacom
+ Warren Vik, INTERACTIVE Systems Corporation
+ Yannis Viniotis
+ Steven L. Waldbusser, Carnegie Mellon Universitty
+ Timothy M. Walden, ACC
+ Alice Wang, Sun Microsystems
+ James Watt, Newbridge
+ Luanne Waul, Timeplex
+ Donald E. Westlake III, Digital Equipment Corporation
+ Gerry White
+ Bert Wijnen, IBM Corporation
+ Peter Wilson, 3Com Corporation
+ Steven Wong, Digital Equipment Corporation
+ Randy Worzella, IBM Corporation
+ Daniel Woycke, MITRE
+ Honda Wu
+ Jeff Yarnell, Protools
+ Chris Young, Cabletron
+ Kiho Yum, 3Com Corporation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 21]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 10. References
+
+ [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Protocol Operations for version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
+ Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
+ Carnegie Mellon University, April 1993.
+
+ [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", RFC
+ 1452, SNMP Research, Inc., Hughes LAN Systems, Dover
+ Beach Consulting, Inc., Carnegie Mellon University, April
+ 1993.
+
+ [10] McCloghrie, K., and Galvin, J., "Party MIB for version 2
+ of the Simple Network Management Protocol (SNMPv2)", RFC
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 22]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 1447, Hughes LAN Systems, Trusted Information Systems,
+ April 1993.
+
+ [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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 23]
+
+
+
+
+
+ RFC 1449 Transport Mappings for SNMPv2 April 1993
+
+
+ 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
+ Hughes LAN Systems
+ 1225 Charleston Road
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 415 966 7934
+ Email: kzm@hls.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
+ 4910 Forbes Ave
+ Pittsburgh, PA 15213
+ US
+
+ Phone: +1 412 268 6628
+ Email: waldbusser@cmu.edu
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 24]
+