As per Relevance of the word mappings, we have this rfc below:
Network Working Group SNMPv2 Working
Request for Comments: 1906 J.
Obsoletes: 1449 SNMP Research, Inc
Category: Standards Track K.
Cisco Systems, Inc
M.
Dover Beach Consulting, Inc
S.
International Network
January 1996
Transport Mappings for Version 2 of
Simple Network Management Protocol (SNMPv2)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
1. Introduction ................................................ 2
1.1 A Note on Terminology ...................................... 2
2. Definitions ................................................. 3
3. SNMPv2 over UDP ............................................. 5
3.1 Serialization .............................................. 5
3.2 Well-known Values .......................................... 5
4. SNMPv2 over OSI ............................................. 6
4.1 Serialization .............................................. 6
4.2 Well-known Values .......................................... 6
5. SNMPv2 over DDP ............................................. 6
5.1 Serialization .............................................. 6
5.2 Well-known Values .......................................... 6
5.3 Discussion of AppleTalk Addressing ......................... 7
5.3.1 How to Acquire NBP names ................................. 8
5.3.2 When to Turn NBP names into DDP addresses ................ 8
5.3.3 How to Turn NBP names into DDP addresses ................. 8
5.3.4 What if NBP is broken .................................... 9
6. SNMPv2 over IPX ............................................. 9
6.1 Serialization .............................................. 9
6.2 Well-known Values .......................................... 9
7. Proxy to SNMPv1 ............................................. 10
8. Serialization using the Basic Encoding Rules ................ 10
8.1 Usage Example .............................................. 11
SNMPv2 Working Group Standards Track [Page 1]
RFC 1906 Transport Mappings for SNMPv2 January 1996
9. Security Considerations ..................................... 11
10. Editor's Address ........................................... 12
11. Acknowledgements ........................................... 12
12. References ................................................. 13
1.
A management system contains: several (potentially many) nodes,
with a processing entity, termed an agent, which has access
management instrumentation; at least one management station; and,
management protocol, used to convey management information
the agents and management stations. Operations of the protocol
carried out under an administrative framework which
authentication, authorization, access control, and privacy policies
Management stations execute management applications which monitor
control managed elements. Managed elements are devices such
hosts, routers, terminal servers, etc., which are monitored
controlled via access to their management information
The management protocol, version 2 of the Simple Network
Protocol [1], may be used over a variety of protocol suites. It
the purpose of this document to define how the SNMPv2 maps onto
initial set of transport domains. Other mappings may be defined
the future
Although several mappings are defined, the mapping onto UDP is
preferred mapping. As such, to provide for the greatest level
interoperability, systems which choose to deploy other
should also provide for proxy service to the UDP mapping
1.1. A Note on
For the purpose of exposition, the original Internet-standard
Management Framework, as described in RFCs 1155 (STD 16), 1157 (
15), and 1212 (STD 16), is termed the SNMP version 1
(SNMPv1). The current framework is termed the SNMP version 2
framework (SNMPv2).
SNMPv2 Working Group Standards Track [Page 2]
RFC 1906 Transport Mappings for SNMPv2 January 1996
2.
SNMPv2-TM DEFINITIONS ::=
OBJECT-IDENTITY, snmpDomains,
FROM SNMPv2-
TEXTUAL-
FROM SNMPv2-TC
-- SNMPv2 over UDP over IPv
snmpUDPDomain OBJECT-
STATUS
"The SNMPv2 over UDP transport domain. The
transport address is of type SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-
DISPLAY-HINT "1d.1d.1d.1d/2d
STATUS
"Represents a UDP address
octets contents
1-4 IP-address network-byte
5-6 UDP-port network-byte
"
SYNTAX OCTET STRING (SIZE (6))
-- SNMPv2 over
snmpCLNSDomain OBJECT-
STATUS
"The SNMPv2 over CLNS transport domain. The
transport address is of type SnmpOSIAddress."
::= { snmpDomains 2 }
snmpCONSDomain OBJECT-
STATUS
"The SNMPv2 over CONS transport domain. The
transport address is of type SnmpOSIAddress."
::= { snmpDomains 3 }
SNMPv2 Working Group Standards Track [Page 3]
RFC 1906 Transport Mappings for SNMPv2 January 1996
SnmpOSIAddress ::= TEXTUAL-
DISPLAY-HINT "*1x:/1x:"
STATUS
"Represents an OSI transport-address
octets contents
1 length of NSAP 'n' as an unsigned-
(either 0 or from 3 to 20)
2..(n+1) NSAP concrete binary
(n+2)..m TSEL string of (up to 64)
"
SYNTAX OCTET STRING (SIZE (1 | 4..85))
-- SNMPv2 over
snmpDDPDomain OBJECT-
STATUS
"The SNMPv2 over DDP transport domain. The
transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 }
SnmpNBPAddress ::= TEXTUAL-
STATUS
"Represents an NBP name
octets contents
1 length of object 'n' as an unsigned
2..(n+1) object string of (up to 32)
n+2 length of type 'p' as an unsigned
(n+3)..(n+2+p) type string of (up to 32)
n+3+p length of zone 'q' as an unsigned
(n+4+p)..(n+3+p+q) zone string of (up to 32)
For comparison purposes, strings are case-insensitive
strings may contain any octet other than 255 (hex ff)."
SYNTAX OCTET STRING (SIZE (3..99))
-- SNMPv2 over
snmpIPXDomain OBJECT-
STATUS
"The SNMPv2 over IPX transport domain. The
SNMPv2 Working Group Standards Track [Page 4]
RFC 1906 Transport Mappings for SNMPv2 January 1996
transport address is of type SnmpIPXAddress."
::= { snmpDomains 5 }
SnmpIPXAddress ::= TEXTUAL-
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d
STATUS
"Represents an IPX address
octets contents
1-4 network-number network-byte
5-10 physical-address network-byte
11-12 socket-number network-byte
"
SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-
STATUS
"The transport domain for SNMPv1 over UDP.
corresponding transport address is of type SnmpUDPAddress."
::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is
3. SNMPv2 over
This is the preferred transport mapping
3.1.
Each instance of a message is serialized (i.e., encoded according
the convention of [1]) onto a single UDP[2] datagram, using
algorithm specified in Section 8.
3.2. Well-known
It is suggested that administrators configure their SNMPv2
acting in an agent role to listen on UDP port 161. Further, it
suggested that notification sinks be configured to listen on UDP
SNMPv2 Working Group Standards Track [Page 5]
RFC 1906 Transport Mappings for SNMPv2 January 1996
162.
When an SNMPv2 entity uses this transport mapping, it must be
of accepting messages that are at least 484 octets in size
Implementation of larger values is encouraged whenever possible
4. SNMPv2 over
This is an optional transport mapping
4.1.
Each instance of a message is serialized onto a single TSDU [3,4]
the OSI Connectionless-mode Transport Service (CLTS), using
algorithm specified in Section 8.
4.2. Well-known
It is suggested that administrators configure their SNMPv2
acting in an agent role to listen on transport selector "snmp-l
(which consists of six ASCII characters), when using a CL-
network service to realize the CLTS. Further, it is suggested
notification sinks be configured to listen on transport
"snmpt-l" (which consists of seven ASCII characters, six letters
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",
agent and notification sink, respectively
When an SNMPv2 entity uses this transport mapping, it must be
of accepting messages that are at least 484 octets in size
Implementation of larger values is encouraged whenever possible
5. SNMPv2 over
This is an optional transport mapping
5.1.
Each instance of a message is serialized onto a single DDP
[5], using the algorithm specified in Section 8.
5.2. Well-known
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2
acting in an agent role listens on DDP socket number 8,
notification sinks listen on DDP socket number 9.
SNMPv2 Working Group Standards Track [Page 6]
RFC 1906 Transport Mappings for SNMPv2 January 1996
Administrators must configure their SNMPv2 entities acting in
agent role to use NBP type "SNMP Agent" (which consists of ten
characters), whilst notification sinks must be configured to use
type "SNMP Trap Handler" (which consists of seventeen
characters).
The NBP name for agents and notification sinks should be stable -
names should not change any more often than the IP address of
typical TCP/IP node. It is suggested that the NBP name be stored
some form of stable storage
When an SNMPv2 entity uses this transport mapping, it must be
of accepting messages that are at least 484 octets in size
Implementation of larger values is encouraged whenever possible
5.3. Discussion of AppleTalk
The AppleTalk protocol suite has certain features not manifest in
TCP/IP suite. AppleTalk's naming strategy and the dynamic nature
address assignment can cause problems for SNMPv2 entities that
to manage AppleTalk networks. TCP/IP nodes have an associated
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
reboot (or more frequently).
Thus, when SNMPv2 is mapped over DDP, nodes are identified by
"name", rather than by an "address". Hence, all AppleTalk nodes
implement this mapping are required to respond to NBP lookups
confirms (e.g., implement the NBP protocol stub), which
that a mapping from NBP name to DDP address will be possible
In determining the SNMP identity to register for an SNMPv2 entity,
is suggested that the SNMP identity be a name which is
with other network services offered by the machine
NBP lookups, which are used to map NBP names into DDP addresses,
cause large amounts of network traffic as well as consume
resources. It is also the case that the ability to perform an
lookup is sensitive to certain network disruptions (such as
table inconsistencies) which would not prevent direct
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.
cached mappings should then be used for any further SNMP traffic.
is recommended that SNMPv2 entities acting in a manager role
maintain this cache between reboots. This caching can help
SNMPv2 Working Group Standards Track [Page 7]
RFC 1906 Transport Mappings for SNMPv2 January 1996
network traffic, reduce CPU load on the network, and allow for (
amount of) network trouble shooting when the basic name-to-
translation mechanism is broken
5.3.1. How to Acquire NBP
An SNMPv2 entity acting in a manager role may have a pre-
list of names of "known" SNMPv2 entities acting in an agent role
Similarly, an SNMPv2 entity acting in a manager role might
with an operator. Finally, an SNMPv2 entity acting in a manager
might communicate with all SNMPv2 entities acting in an agent role
a set of zones or networks
5.3.2. When to Turn NBP names into DDP
When an SNMPv2 entity uses a cache entry to address an SNMP packet
it should attempt to confirm the validity mapping, if the
hasn't been confirmed within the last T1 seconds. This cache
lifetime, T1, has a minimum, default value of 60 seconds, and
be configurable
An SNMPv2 entity acting in a manager role may decide to prime
cache of names prior to actually communicating with another SNMPv
entity. In general, it is expected that such an entity may want
keep certain mappings "more current" than other mappings, e.g.,
nodes which represent the network infrastructure (e.g., routers)
be deemed "more important".
Note that an SNMPv2 entity acting in a manager role should not
its entire cache upon initialization - rather, it should
resolutions over an extended period of time (perhaps in some pre
determined or configured priority order). Each of these
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
to send an SNMP trap. When generating a response, such an
does not need to confirm a cache entry
5.3.3. How to Turn NBP names into DDP
If the only piece of information available is the NBP name, then
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
a hint to perform an NBP confirm (which sends a unicast to
network address which is presumed to be the target of the
lookup) to see if the stale information is, in fact, still valid
SNMPv2 Working Group Standards Track [Page 8]
RFC 1906 Transport Mappings for SNMPv2 January 1996
An NBP name to DDP address mapping can also be confirmed
using only SNMP transactions. For example, an SNMPv2 entity
in a manager role issuing a retrieval operation could also
the relevant objects from the NBP group [6] for the SNMPv2
acting in an agent role. This information can then be
with the source DDP address of the response
5.3.4. What if NBP is
Under some circumstances, there may be connectivity between
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'
network; or
o the NBP BrRq (NBP broadcast request) mechanism might be
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
AppleTalk management might choose to alleviate some of these
by directly implementing the router portion of NBP. For example
such an entity might already know all the zones on the
internet and the networks on which each zone appears. Given an
lookup which fails, the entity could send an NBP FwdReq to
network in which the agent was last located. If that failed,
station could then send an NBP LkUp (NBP lookup packet) as a
(DDP) multicast to each network number on that network. Of the
(single) failures, this combined approach will solve the case
either the local router's BrRq-to-FwdReq mechanism is broken or
remote router's FwdReq-to-LkUp mechanism is broken
6. SNMPv2 over
This is an optional transport mapping
6.1.
Each instance of a message is serialized onto a single IPX
[7], using the algorithm specified in Section 8.
6.2. Well-known
SNMPv2 messages are sent using IPX packet type 4 (i.e.,
Exchange Protocol).
SNMPv2 Working Group Standards Track [Page 9]
RFC 1906 Transport Mappings for SNMPv2 January 1996
It is suggested that administrators configure their SNMPv2
acting in an agent role to listen on IPX socket 36879 (900
hexadecimal). Further, it is suggested that notification sinks
configured to listen on IPX socket 36880 (9010 hexadecimal
When an SNMPv2 entity uses this transport mapping, it must be
of accepting messages that are at least 546 octets in size
Implementation of larger values is encouraged whenever possible
7. Proxy to SNMPv
In order to provide proxy to SNMPv1 [8], it may be useful to define
transport domain, rfc1157Domain, which indicates the
mapping for SNMP messages as defined in RFC 1157. Section 3.1 of [9]
specifies the behavior of the proxy agent
8. Serialization using the Basic Encoding
When the Basic Encoding Rules [10] are used for serialization
(1) When encoding the length field, only the definite form is used;
of the indefinite form encoding is prohibited. Note that
using the definite-long form, it is permissible to use more
the minimum number of length octets necessary to encode the
field
(2) When encoding the value field, the primitive form shall be used
all simple types, i.e., INTEGER, OCTET STRING, and
IDENTIFIER (either IMPLICIT or explicit). The constructed form
encoding shall be used only for structured types, i.e., a
or an IMPLICIT SEQUENCE
(3) When encoding an object whose syntax is described using the
construct, the value is encoded as an OCTET STRING, in which
the named bits in (the definition of) the bitstring,
with the first bit and proceeding to the last bit, are placed
bits 8 to 1 of the first octet, followed by bits 8 to 1 of
subsequent octet in turn, followed by as many bits as are needed
the final subsequent octet, commencing with bit 8. Remaining bits
if any, of the final octet are set to zero on generation
ignored on receipt
These restrictions apply to all aspects of ASN.1 encoding,
the message wrappers, protocol data units, and the data objects
contain
SNMPv2 Working Group Standards Track [Page 10]
RFC 1906 Transport Mappings for SNMPv2 January 1996
8.1. Usage
As an example of applying the Basic Encoding Rules, suppose
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 2
SEQUENCE 30 0
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
NULL 05 00
SEQUENCE 30 0
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
NULL 05 00
SEQUENCE 30 0
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
number of length octets. (The first octet of the length, 82,
indicates that the length of the content is encoded in the next
octets.)
9. Security
Security issues are not discussed in this memo
SNMPv2 Working Group Standards Track [Page 11]
RFC 1906 Transport Mappings for SNMPv2 January 1996
10. Editor's
Keith
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 526 5260
EMail: kzm@cisco.
11.
This document is the result of significant work by the four
contributors
Jeffrey D. Case (SNMP Research, case@snmp.com
Keith McCloghrie (Cisco Systems, kzm@cisco.com
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us
Steven Waldbusser (International Network Services, stevew@uni.ins.com
In addition, the contributions of the SNMPv2 Working Group
acknowledged. In particular, a special thanks is extended for
contributions of
Alexander I. Alten (Novell
Dave Arneson (Cabletron
Uri Blumenthal (IBM
Doug Book (Chipcom
Kim Curran (Bell-Northern Research
Jim Galvin (Trusted Information Systems
Maria Greene (Ascom Timeplex
Iain Hanson (Digital
Dave Harrington (Cabletron
Nguyen Hien (IBM
Jeff Johnson (Cisco Systems
Michael Kornegay (Object Quest
Deirdre Kostick (AT&T Bell Labs
David Levi (SNMP Research
Daniel Mahoney (Cabletron
Bob Natale (ACE*COMM
Brian O'Keefe (Hewlett Packard
Andrew Pearson (SNMP Research
Dave Perkins (Peer Networks
Randy Presuhn (Peer Networks
Aleksey Romanov (Quality Quorum
Shawn Routhier (Epilogue
Jon Saperia (BGS Systems
SNMPv2 Working Group Standards Track [Page 12]
RFC 1906 Transport Mappings for SNMPv2 January 1996
Bob Stewart (Cisco Systems, bstewart@cisco.com),
Kaj Tesink (Bellcore
Glenn Waters (Bell-Northern Research
Bert Wijnen (IBM
12.
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Protocol Operations for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[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
Standardization. International Standard 8072, (June, 1986).
[4] Information processing systems - Open Systems Interconnection -
Transport Service Definition - Addendum 1: Connectionless-
Transmission, International Organization for Standardization
International Standard 8072/AD 1, (December, 1986).
[5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (
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., and J. Davin, "Simple
Management Protocol", STD 15, RFC 1157, SNMP Research,
Systems International, MIT Laboratory for Computer Science,
1990.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Coexistence between Version 1 and Version 2 of
Internet-standard Network Management Framework", RFC 1908,
January 1996.
[10] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax
One (ASN.1), International Organization for Standardization
International Standard 8825, December 1987.
SNMPv2 Working Group Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
