draft-ietf-snmpv2-tm-ds-03.txt   draft-ietf-snmpv2-tm-ds-04.txt 
Transport Mappings for Version 2 of the Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2) Simple Network Management Protocol (SNMPv2)
20 September 1995 | 25 September 1995 |
draft-ietf-snmpv2-tm-ds-03.txt | draft-ietf-snmpv2-tm-ds-04.txt |
Keith McCloghrie Keith McCloghrie
Editor + Editor +
Cisco Systems, Inc. Cisco Systems, Inc.
kzm@cisco.com kzm@cisco.com
Status of this Memo - Status of this Memo -
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
skipping to change at page 2, line 34 skipping to change at page 2, line 34
Although several mappings are defined, the mapping onto UDP is the Although several mappings are defined, the mapping onto UDP is the
preferred mapping. As such, to provide for the greatest level of preferred mapping. As such, to provide for the greatest level of
interoperability, systems which choose to deploy other mappings should interoperability, systems which choose to deploy other mappings should
also provide for proxy service to the UDP mapping. also provide for proxy service to the UDP mapping.
1.1. A Note on Terminology 1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is 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 1 framework (SNMPv1). The current framework is |
termed the SNMP version 2 framework (SNMPv2). termed the SNMP version 2 framework (SNMPv2), as described in [11]. |
2. Definitions 2. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
OBJECT-IDENTITY, snmpDomains, snmpProxys OBJECT-IDENTITY, snmpDomains, snmpProxys
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
skipping to change at page 6, line 27 skipping to change at page 6, line 27
DESCRIPTION DESCRIPTION
"Represents an IPX address: "Represents an IPX address:
octets contents encoding octets contents encoding
1-4 network-number network-byte order 1-4 network-number network-byte order
5-10 physical-address network-byte order 5-10 physical-address network-byte order
11-12 socket-number network-byte order 11-12 socket-number network-byte order
" "
SYNTAX OCTET STRING (SIZE (12)) SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY rfc1157Domain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The transport domain for SNMPv1 over UDP. The "The transport domain for SNMPv1 over UDP. The
corresponding transport address is of type SnmpUDPAddress." corresponding transport address is of type SnmpUDPAddress."
::= { rfc1157Proxy 1 } ::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete
END - END
3. SNMPv2 over UDP 3. SNMPv2 over UDP
This is the preferred transport mapping. This is the preferred transport mapping.
3.1. Serialization 3.1. Serialization
Each instance of a message is serialized (i.e., encoded according to the 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 convention of [1]) onto a single UDP[2] datagram, using the algorithm
specified in Section 8. specified in Section 8.
3.2. Well-known Values 3.2. Well-known Values
It is suggested that administrators configure their SNMPv2 entities | It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on UDP port 161. Further, it is 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 suggested that notification sinks be configured to listen on UDP port
162. 162.
When an SNMPv2 entity uses this transport mapping, it must be capable of | When an SNMPv2 entity uses this transport mapping, it must be capable of
accepting messages that are at least 484 octets in size. | accepting messages that are at least 484 octets in size. Implementation
Implementation of larger values is encouraged whenever possible. of larger values is encouraged whenever possible.
4. SNMPv2 over OSI 4. SNMPv2 over OSI
This is an optional transport mapping. This is an optional transport mapping.
4.1. Serialization 4.1. Serialization
Each instance of a message is serialized onto a single TSDU [3,4] for Each instance of a message is serialized onto a single TSDU [3,4] for
the OSI Connectionless-mode Transport Service (CLTS), using the the OSI Connectionless-mode Transport Service (CLTS), using the
algorithm specified in Section 8. algorithm specified in Section 8.
4.2. Well-known Values 4.2. Well-known Values
It is suggested that administrators configure their SNMPv2 entities | It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on transport selector "snmp-l" (which 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 consists of six ASCII characters), when using a CL-mode network service
to realize the CLTS. Further, it is suggested that notification sinks to realize the CLTS. Further, it is suggested that notification sinks
be configured to listen on transport selector "snmpt-l" (which consists be configured to listen on transport selector "snmpt-l" (which consists
of seven ASCII characters, six letters and a hyphen) when using a CL- 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. Similarly, when using a CO-
mode network service to realize the CLTS, the suggested transport mode network service to realize the CLTS, the suggested transport
selectors are "snmp-o" and "snmpt-o", for agent and notification sink, selectors are "snmp-o" and "snmpt-o", for agent and notification sink,
respectively. respectively.
When an SNMPv2 entity uses this transport mapping, it must be capable of | When an SNMPv2 entity uses this transport mapping, it must be capable of
accepting messages that are at least 484 octets in size. | accepting messages that are at least 484 octets in size. Implementation
Implementation of larger values is encouraged whenever possible. of larger values is encouraged whenever possible.
5. SNMPv2 over DDP 5. SNMPv2 over DDP
This is an optional transport mapping. This is an optional transport mapping.
5.1. Serialization 5.1. Serialization
Each instance of a message is serialized onto a single DDP datagram [5], Each instance of a message is serialized onto a single DDP datagram [5],
using the algorithm specified in Section 8. using the algorithm specified in Section 8.
5.2. Well-known Values 5.2. Well-known Values
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities
acting in an agent role listens on DDP socket number 8, whilst acting in an agent role listens on DDP socket number 8, whilst
notification sinks listen on DDP socket number 9. notification sinks listen on DDP socket number 9.
Administrators must configure their SNMPv2 entities | Administrators must configure their SNMPv2 entities acting in an agent
acting in an agent role to use NBP type "SNMP Agent" (which consists of role to use NBP type "SNMP Agent" (which consists of ten ASCII
ten ASCII characters), whilst notification sinks must be configured to characters), whilst notification sinks must be configured to use NBP
use NBP type "SNMP Trap Handler" (which consists of seventeen ASCII type "SNMP Trap Handler" (which consists of seventeen ASCII characters).
characters).
The NBP name for agents and notification sinks should be stable - NBP 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 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 TCP/IP node. It is suggested that the NBP name be stored in some form
of stable storage. of stable storage.
When an SNMPv2 entity uses this transport mapping, it must be capable of | When an SNMPv2 entity uses this transport mapping, it must be capable of
accepting messages that are at least 484 octets in size. | accepting messages that are at least 484 octets in size. Implementation
Implementation of larger values is encouraged whenever possible. of larger values is encouraged whenever possible.
5.3. Discussion of AppleTalk Addressing 5.3. Discussion of AppleTalk Addressing
The AppleTalk protocol suite has certain features not manifest in the The AppleTalk protocol suite has certain features not manifest in the
TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of
address assignment can cause problems for SNMPv2 entities that wish to address assignment can cause problems for SNMPv2 entities that wish to
manage AppleTalk networks. TCP/IP nodes have an associated IP address manage AppleTalk networks. TCP/IP nodes have an associated IP address
which distinguishes each from the other. In contrast, AppleTalk nodes which distinguishes each from the other. In contrast, AppleTalk nodes
generally have no such characteristic. The network-level address, while generally have no such characteristic. The network-level address, while
often relatively stable, can change at every reboot (or more often relatively stable, can change at every reboot (or more
skipping to change at page 13, line 19 skipping to change at page 13, line 19
6.1. Serialization 6.1. Serialization
Each instance of a message is serialized onto a single IPX datagram [7], Each instance of a message is serialized onto a single IPX datagram [7],
using the algorithm specified in Section 8. using the algorithm specified in Section 8.
6.2. Well-known Values 6.2. Well-known Values
SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange
Protocol). Protocol).
It is suggested that administrators configure their SNMPv2 entities | It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on IPX socket 36879 (900f acting in an agent role to listen on IPX socket 36879 (900f
hexadecimal). Further, it is suggested that notification sinks be hexadecimal). Further, it is suggested that notification sinks be
configured to listen on IPX socket 36880 (9010 hexadecimal) configured to listen on IPX socket 36880 (9010 hexadecimal)
When an SNMPv2 entity uses this transport mapping, it must be capable of | When an SNMPv2 entity uses this transport mapping, it must be capable of
accepting messages that are at least 546 octets in size. | accepting messages that are at least 546 octets in size. Implementation
Implementation of larger values is encouraged whenever possible. of larger values is encouraged whenever possible.
7. Proxy to SNMPv1 + 7. Proxy to SNMPv1
In order to provide proxy to SNMPv1 [8], it may be useful to define a | In order to provide proxy to SNMPv1 [8], it may be useful to define a
transport domain, rfc1157Domain, which indicates the transport mapping | transport domain, rfc1157Domain, which indicates the transport mapping
for SNMP messages as defined in RFC 1157. | for SNMP messages as defined in RFC 1157. Section 3.1 of [9] specifies
Section 3.1 of [9] specifies the behavior of the proxy agent. the behavior of the proxy agent.
8. Serialization using the Basic Encoding Rules - 8. Serialization using the Basic Encoding Rules
When the Basic Encoding Rules [10] are used for serialization: | When the Basic Encoding Rules [10] are used for serialization:
(1) When encoding the length field, only the definite form is used; use (1) When encoding the length field, only the definite form is used; use
of the indefinite form encoding is prohibited. Note that when of the indefinite form encoding is prohibited. Note that when
using the definite-long form, it is permissible to use more than using the definite-long form, it is permissible to use more than
the minimum number of length octets necessary to encode the length the minimum number of length octets necessary to encode the length
field. field.
(2) When encoding the value field, the primitive form shall be used for (2) When encoding the value field, the primitive form shall be used for
all simple types, i.e., INTEGER, OCTET STRING, and OBJECT all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
IDENTIFIER (either IMPLICIT or explicit). The constructed form of IDENTIFIER (either IMPLICIT or explicit). The constructed form of
skipping to change at page 18, line 42 skipping to change at page 18, line 42
[8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network [8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May Systems International, MIT Laboratory for Computer Science, May
1990. 1990.
[9] McCloghrie, K., Editor, | [9] McCloghrie, K., Editor, |
"Coexistence between Version 1 and Version 2 of the Internet- "Coexistence between Version 1 and Version 2 of the Internet-
standard Network Management Framework", Internet Draft, Cisco | standard Network Management Framework", Internet Draft, Cisco |
Systems, September 1995. | Systems, September 1995. |
[10] - [10] Information processing systems - Open Systems Interconnection -
Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1), International Organization for Standardization. One (ASN.1), International Organization for Standardization.
International Standard 8825, December 1987. International Standard 8825, December 1987.
[11] McCloghrie, K., Editor, "Introduction to Version 2 of the +
Internet-standard Network Management Framework", Internet Draft, +
Cisco Systems, September 1995. +
11. Security Considerations 11. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
12. Editor's Address 12. Editor's Address
Keith McCloghrie - Keith McCloghrie -
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive | 170 West Tasman Drive
San Jose, CA 95134-1706 | San Jose, CA 95134-1706
US | US
Phone: +1 408 526 5260 Phone: +1 408 526 5260
Email: kzm@cisco.com Email: kzm@cisco.com
Table of Contents - Table of Contents -
1 Introduction .................................................... 2 1 Introduction .................................................... 2
1.1 A Note on Terminology ......................................... 2 1.1 A Note on Terminology ......................................... 2
2 Definitions ..................................................... 3 2 Definitions ..................................................... 3
3 SNMPv2 over UDP ................................................. 7 3 SNMPv2 over UDP ................................................. 7
 End of changes. 21 change blocks. 
37 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/