draft-ietf-snmpv2-tm-ds-00.txt   draft-ietf-snmpv2-tm-ds-01.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)
1 November 1994 19 March 1995 |
draft-ietf-snmpv2-tm-ds-01.txt |
Jeffrey D. Case Jeffrey D. Case
SNMP Research, Inc. SNMP Research, Inc.
case@snmp.com case@snmp.com
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
kzm@cisco.com kzm@cisco.com
Marshall T. Rose Marshall T. Rose
Dover Beach Consulting, Inc. Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us mrose@dbc.mtview.ca.us
Steven Waldbusser Steven Waldbusser
Carnegie Mellon University Carnegie Mellon University
waldbusser@cmu.edu waldbusser@cmu.edu
<draft-ietf-snmpv2-tm-ds-00.txt>
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
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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).
1.2. Change Log 1.2. Change Log
For the 19 March version: +
- The changes adopted by the SNMPv2 Working Group. +
For the 1 November version: For the 1 November version:
- recast RFC 1449 into an Internet-Draft, - recast RFC 1449 into an Internet-Draft,
- fixed typos, - fixed typos,
- clarified the description of the use of rfc1157Domain as the - clarified the description of the use of rfc1157Domain as the
transport domain of a proxy destination party. transport domain of a proxy destination party.
2. Definitions 2. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
snmpDomains, snmpProxys snmpDomains, snmpProxys
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; 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 } |
snmpUDPDomain OBJECT IDENTIFIER ::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d" DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a UDP address." "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)) SYNTAX OCTET STRING (SIZE (6))
-- SNMPv2 over OSI -- SNMPv2 over OSI
snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 } snmpCLNSDomain OBJECT-IDENTITY |
snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 } 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 } |
SnmpOSIAddress ::= TEXTUAL-CONVENTION SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:" DISPLAY-HINT "*1x:/1x:"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents an OSI transport-address." "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)) SYNTAX OCTET STRING (SIZE (1 | 4..85))
-- SNMPv2 over DDP -- SNMPv2 over DDP
snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 } 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 SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents an NBP name." "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)..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)." |
SYNTAX OCTET STRING (SIZE (3..99)) SYNTAX OCTET STRING (SIZE (3..99))
-- SNMPv2 over IPX -- SNMPv2 over IPX
snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 } snmpIPXDomain OBJECT-IDENTITY |
STATUS current |
DESCRIPTION |
"The SNMPv2 over IPX transport domain. The corresponding |
transport address is of type SnmpIPXAddress." |
::= { snmpDomains 5 } |
SnmpIPXAddress ::= TEXTUAL-CONVENTION SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents an IPX address." "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)) SYNTAX OCTET STRING (SIZE (12))
-- for proxy to community-based SNMPv1 (RFC 1157) -- for proxy to community-based SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } -
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } rfc1157Domain OBJECT-IDENTITY |
STATUS current |
rfc1157Domain OBJECT IDENTIFIER ::= { rfc1157Proxy 1 } DESCRIPTION |
"The transport domain for SNMPv1 over UDP. The |
corresponding transport address is of type SnmpUDPAddress." |
::= { rfc1157Proxy 1 } |
rfc1157noAuth OBJECT IDENTIFIER ::= { rfc1157Proxy 2 } rfc1157noAuth OBJECT-IDENTITY +
STATUS current +
DESCRIPTION +
"The SNMPv1 community-based (non-) authentication protocol." +
::= { rfc1157Proxy 2 } +
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
Although the partyTable gives transport addressing information for an Although the partyTable gives transport addressing information for an
SNMPv2 party, it is suggested that administrators configure their SNMPv2 SNMPv2 party, it is suggested that administrators configure their SNMPv2
entities acting in an agent role to listen on UDP port 161. Further, it 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 is suggested that notification sinks be configured to listen on UDP port
162. 162.
The partyTable also lists the maximum message size which a SNMPv2 party The partyTable also lists the maximum message size which a SNMPv2 party
is willing to accept. This value must be at least 484 octets. is willing to accept. This value must be at least 1472 octets. |
Implementation of larger values is encouraged whenever possible. Implementation 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
skipping to change at page 8, line 30 skipping to change at page 9, line 30
l" (which consists of six ASCII characters), when using a CL-mode l" (which consists of six ASCII characters), when using a CL-mode
network service to realize the CLTS. Further, it is suggested that network service to realize the CLTS. Further, it is suggested that
notification sinks be configured to listen on transport selector notification sinks be configured to listen on transport selector
"snmpt-l" (which consists of seven ASCII characters, six letters and a "snmpt-l" (which consists of seven ASCII characters, six letters and a
hyphen) when using a CL-mode network service to realize the CLTS. 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 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 suggested transport selectors are "snmp-o" and "snmpt-o", for agent and
notification sink, respectively. notification sink, respectively.
The partyTable also lists the maximum message size which a SNMPv2 party The partyTable also lists the maximum message size which a SNMPv2 party
is willing to accept. This value must be at least 484 octets. is willing to accept. This value must be at least 1472 octets. |
Implementation of larger values is encouraged whenever possible. Implementation 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.
skipping to change at page 14, line 27 skipping to change at page 15, line 27
long, the initial 4 octets containing the IP-address in network- long, the initial 4 octets containing the IP-address in network-
byte order, and the last two octets containing the UDP port in byte order, and the last two octets containing the UDP port in
network-byte order; and, network-byte order; and,
(2) the party's authentication protocol (partyAuthProtocol) shall be (2) the party's authentication protocol (partyAuthProtocol) shall be
rfc1157noAuth. rfc1157noAuth.
When a proxy context specifies a proxy destination party which has When a proxy context specifies a proxy destination party which has
rfc1157Domain as its transport domain: rfc1157Domain as its transport domain:
(1) the proxy source party (contextSrcPartyIndex) and proxied context (1) the proxy source party (contextProxySrcParty) |
(contextProxyContext) components of the proxy context are and proxied context (contextProxyContext) components of the proxy
irrelevant; and, context are irrelevant; and,
(2) Section 3.1 of [9] specifies the behavior of the proxy agent. (2) Section 3.1 of [9] specifies the behavior of the proxy agent.
7.2. Authentication Algorithm: rfc1157noAuth 7.2. Authentication Algorithm: rfc1157noAuth
A party's authentication protocol (partyAuthProtocol) specifies the A party's authentication protocol (partyAuthProtocol) specifies the
protocol and mechanism by which the party authenticates the integrity protocol and mechanism by which the party authenticates the integrity
and origin of the SNMPv1 or SNMPv2 PDUs it generates. When a party's and origin of the SNMPv1 or SNMPv2 PDUs it generates. When a party's
authentication protocol is rfc1157noAuth: authentication protocol is rfc1157noAuth:
skipping to change at page 16, line 16 skipping to change at page 17, line 16
When the Basic Encoding Rules [11] are used for serialization: When the Basic Encoding Rules [11] 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, OBJECT IDENTIFIER, all simple types, i.e., INTEGER, OCTET STRING, and OBJECT |
and BIT STRING (either IMPLICIT or explicit). The constructed form IDENTIFIER |
of encoding shall be used only for structured types, i.e., a (either IMPLICIT or explicit). The constructed form of encoding
SEQUENCE or an IMPLICIT SEQUENCE. 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 (3) When encoding an object whose syntax is described using the BITS |
regardless of their truth-value. Further, if the number of named- construct, the value is encoded as an OCTET STRING, in which all |
bits is not an integral multiple of eight, then the fewest number the named bits in the bitstring, commencing with the first bit and |
of additional zero-valued bits are transferred so that an integral proceeding to the last bit, are placed in bits 8 to 1 of the first |
multiple of eight bits is transferred. octet, followed by bits 8 to 1 of each subsequent octet in turn, |
followed by as many bits as are needed of the final subsequent |
octet, commencing with bit 8. |
These restrictions apply to all aspects of ASN.1 encoding, including the These restrictions apply to all aspects of ASN.1 encoding, including the
message wrappers, protocol data units, and the data objects they message wrappers, protocol data units, and the data objects they
contain. contain.
8.1. Usage Example 8.1. Usage Example
As an example of applying the Basic Encoding Rules, suppose one wanted As an example of applying the Basic Encoding Rules, suppose one wanted
to encode an instance of the GetBulkRequest-PDU [1]: to encode an instance of the GetBulkRequest-PDU [1]:
skipping to change at page 18, line 7 skipping to change at page 19, line 7
SEQUENCE 30 0d SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00 NULL 05 00
Note that the initial SEQUENCE is not encoded using the minimum number Note that the initial SEQUENCE is not encoded using the minimum number
of length octets. (The first octet of the length, 82, indicates that of length octets. (The first octet of the length, 82, indicates that
the length of the content is encoded in the next two octets.) the length of the content is encoded in the next two octets.)
9. Acknowledgements 9. Acknowledgements
This document is a modified version of RFC 1449. The authors wish to acknowledge the contributions of the SNMPv2 Working
Group in general. In particular, the following individuals
Dave Arneson (Cabletron),
Uri Blumenthal (IBM),
Doug Book (Chipcom),
Maria Greene (Ascom Timeplex),
Deirdre Kostik (Bellcore),
Dave Harrington (Cabletron),
Jeff Johnson (Cisco Systems),
Brian O'Keefe (Hewlett Packard),
Dave Perkins (Bay Networks),
Randy Presuhn (Peer Networks),
Shawn Routhier (Epilogue),
Bob Stewart (Cisco Systems),
Kaj Tesink (Bellcore).
deserve special thanks for their contributions.
10. References 10. References
[1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
Operations for Version 2 of the Simple Network Management Protocol Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
Dover Beach Consulting, Inc., Carnegie Mellon University, November Dover Beach Consulting, Inc., Carnegie Mellon University, November
1994. 1994.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
skipping to change at page 19, line 5 skipping to change at page 20, line 22
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] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., [9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"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, SNMP standard Network Management Framework", Internet Draft, SNMP
Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Research, Inc., Cisco Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, November 1994. Carnegie Mellon University, November 1994.
[10] McCloghrie, K., and Galvin, J., "Party MIB for Version 2 of the [10] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., |
Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco "Party MIB for Version 2 of the Simple Network Management Protocol
Systems, Trusted Information Systems, November 1994. (SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted Information |
Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie |
Mellon University, |
November 1994.
[11] Information processing systems - Open Systems Interconnection - [11] 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. Security Considerations 11. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
12. Authors' Addresses 12. Authors' Addresses
Jeffrey D. Case Jeffrey D. Case
SNMP Research, Inc. SNMP Research, Inc.
3001 Kimberlin Heights Rd. 3001 Kimberlin Heights Rd.
skipping to change at page 21, line 10 skipping to change at page 22, line 10
US US
Phone: +1 412 268 6628 Phone: +1 412 268 6628
Email: waldbusser@cmu.edu Email: waldbusser@cmu.edu
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
1.2 Change Log .................................................... 2 1.2 Change Log .................................................... 2
2 Definitions ..................................................... 3 2 Definitions ..................................................... 4
3 SNMPv2 over UDP ................................................. 7 3 SNMPv2 over UDP ................................................. 8
3.1 Serialization ................................................. 7 3.1 Serialization ................................................. 8
3.2 Well-known Values ............................................. 7 3.2 Well-known Values ............................................. 8
4 SNMPv2 over OSI ................................................. 8 4 SNMPv2 over OSI ................................................. 9
4.1 Serialization ................................................. 8 4.1 Serialization ................................................. 9
4.2 Well-known Values ............................................. 8 4.2 Well-known Values ............................................. 9
5 SNMPv2 over DDP ................................................. 9 5 SNMPv2 over DDP ................................................. 10
5.1 Serialization ................................................. 9 5.1 Serialization ................................................. 10
5.2 Well-known Values ............................................. 9 5.2 Well-known Values ............................................. 10
5.3 Discussion of AppleTalk Addressing ............................ 9 5.3 Discussion of AppleTalk Addressing ............................ 10
5.3.1 How to Acquire NBP names .................................... 10 5.3.1 How to Acquire NBP names .................................... 11
5.3.2 When to Turn NBP names into DDP addresses ................... 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.3 How to Turn NBP names into DDP addresses .................... 12
5.3.4 What if NBP is broken ....................................... 11 5.3.4 What if NBP is broken ....................................... 12
6 SNMPv2 over IPX ................................................. 13 6 SNMPv2 over IPX ................................................. 14
6.1 Serialization ................................................. 13 6.1 Serialization ................................................. 14
6.2 Well-known Values ............................................. 13 6.2 Well-known Values ............................................. 14
7 Proxy to SNMPv1 ................................................. 14 7 Proxy to SNMPv1 ................................................. 15
7.1 Transport Domain: rfc1157Domain ............................... 14 7.1 Transport Domain: rfc1157Domain ............................... 15
7.2 Authentication Algorithm: rfc1157noAuth ....................... 14 7.2 Authentication Algorithm: rfc1157noAuth ....................... 15
8 Serialization using the Basic Encoding Rules .................... 16 8 Serialization using the Basic Encoding Rules .................... 17
8.1 Usage Example ................................................. 17 8.1 Usage Example ................................................. 18
9 Acknowledgements ................................................ 18 9 Acknowledgements ................................................ 19
10 References ..................................................... 18 10 References ..................................................... 19
11 Security Considerations ........................................ 20 11 Security Considerations ........................................ 21
12 Authors' Addresses ............................................. 20 12 Authors' Addresses ............................................. 21
 End of changes. 25 change blocks. 
36 lines changed or deleted 136 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/