rfc1906.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页
TXT
732 行
Network Working Group SNMPv2 Working Group
Request for Comments: 1906 J. Case
Obsoletes: 1449 SNMP Research, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
January 1996
Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) 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 ............................................. 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. 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 (STD 16), 1157 (STD
15), and 1212 (STD 16), is termed the SNMP version 1 framework
(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. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-IDENTITY, snmpDomains, snmpProxys
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
-- SNMPv2 over UDP over IPv4
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over UDP transport domain. The corresponding
transport address is of type SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
octets contents encoding
1-4 IP-address network-byte order
5-6 UDP-port network-byte order
"
SYNTAX OCTET STRING (SIZE (6))
-- SNMPv2 over OSI
snmpCLNSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over CLNS transport domain. The corresponding
transport address is of type SnmpOSIAddress."
::= { snmpDomains 2 }
snmpCONSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over CONS transport domain. The corresponding
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-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
"Represents an OSI transport-address:
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
"
SYNTAX OCTET STRING (SIZE (1 | 4..85))
-- SNMPv2 over DDP
snmpDDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over DDP transport domain. The corresponding
transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 }
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an NBP name:
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)..(n+3+p+q) 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)."
SYNTAX OCTET STRING (SIZE (3..99))
-- SNMPv2 over IPX
snmpIPXDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over IPX transport domain. The corresponding
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-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
"Represents an IPX address:
octets contents encoding
1-4 network-number network-byte order
5-10 physical-address network-byte order
11-12 socket-number network-byte order
"
SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The transport domain for SNMPv1 over UDP. The
corresponding transport address is of type SnmpUDPAddress."
::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete
END
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
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
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 capable
of accepting messages that are at least 484 octets in size.
Implementation of larger values is encouraged whenever possible.
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
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.
When an SNMPv2 entity uses this transport mapping, it must be capable
of accepting messages that are at least 484 octets in size.
Implementation of larger values is encouraged whenever possible.
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.
SNMPv2 Working Group Standards Track [Page 6]
RFC 1906 Transport Mappings for SNMPv2 January 1996
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.
When an SNMPv2 entity uses this transport mapping, it must be capable
of accepting messages that are at least 484 octets in size.
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?