Internet DRAFT - draft-vaughn-cnmp-pdu
draft-vaughn-cnmp-pdu
INTERNET-DRAFT K. Vaughn
Intended Status: Standards Track Trevilon LLC
Expires: May 24, 2014 A. Triglia
OSS Nokalva, Inc.
R. Rausch
Transcore, LP
November 20, 2013
Protocol Operations for Condensed Network Management Protocol (CNMP)
draft-vaughn-cnmp-pdu-00
Abstract
This document specifies the protocol operations for Condensed Network
Management Protocol (CNMP) messages. It defines the syntax and
element of procedures for sending, receiving, and processing CNMP
PDUs.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
K. Vaughn Expires May 24, 2014 [Page 1]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Management Information Base Definitions . . . . . . . . . . . 4
5. CNMP PDU Format . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Type Definitions . . . . . . . . . . . . . . . . . . . . 16
5.2.1. ObjectName . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2. ObjectSyntax . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. PDU Structure . . . . . . . . . . . . . . . . . . . . 18
5.2.4. DynamicObject-PDU . . . . . . . . . . . . . . . . . . 18
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
6.1.1. GetRequest-PDU . . . . . . . . . . . . . . . . . . . . 19
6.1.2. SetRequest-PDU and SetNoReply-PDU . . . . . . . . . . 20
6.1.3. GetNextRequest-PDU . . . . . . . . . . . . . . . . . . 21
6.1.1. GetResponse-PDU, SetResponse-PDU,
InformResponse-PDU, and ErrorResponse-PDU . . . . . . 22
6.1.1. GetBulkRequest-PDU . . . . . . . . . . . . . . . . . . 22
6.1.1. Trap-PDU . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. InformRequest-PDU . . . . . . . . . . . . . . . . . . 23
6.1.1. GetDynObjX . . . . . . . . . . . . . . . . . . . . . . 23
6.1.2. SetDynObjX and SetNoReplyDynObjX . . . . . . . . . . . 24
6.1.3. GetNextDynObjX . . . . . . . . . . . . . . . . . . . . 26
6.1.4. GetRespDynObjX, SetRespDynObjX, and ErrorRespDynObjX . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1 Normative References . . . . . . . . . . . . . . . . . . . 29
10.2 Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
K. Vaughn Expires May 24, 2014 [Page 2]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
1. Introduction
The management framework used by CNMP consists of:
1) An architecture that conforms to that described in in STD 62
[RFC3411], [RFC5343], and [RFC5590],
2) Mechanisms for describing and naming objects and events for the
purposes of management, as defined in STD 58
[RFC2578][RFC2579][RFC2580],
3) Message protocols for transferring management information, as
defined in [Msg],
4) Protocol operations for accessing management information, as
defined in this document, and
5) A set of fundamental applications and the view-based access
control mechanism described in STD 62 [RFC3413][RFC3415].
A more complete introduction to CNMP can be found in [Intro].
This document, Protocol Operations for the Condensed Network
Management Protocol, defines the operations of the protocol with
respect to the sending and receiving of PDUs to be carried by the
message protocol. Applications make use of the services of these
subsystems.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Within this INTERNET-DRAFT and all referenced documents, CNMP is to
be considered another version of SNMP. It is only given a different
name because the protocol encoding does not follow the same message
format as SNMP messages and the protocol will use a different binding
with the transport layer. When referencing other RFCs, the any
reference to SNMP in those RFCs shall be interpreted to reference
CNMP, unless specifically stated otherwise within this document.
3. Overview
CNMP Protocol Operations are nearly identical to those supported by
SNMPv3, as defined in [RFC3416]. Readers of this document should
become familiar with the content of that document.
K. Vaughn Expires May 24, 2014 [Page 3]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
An overview of the exceptions to SNMPv3 Protocol Operations include:
* CNMP defines a SetNoReply-PDU. This request type does not result
in a response message. This request type can be useful for
broadcasting commands that should be implemented by numerous
devices near simultaneously. A manager can later verify the
proper receipt of the command by issuing individual GetRequest-
PDUs to each agent.
* CNMP uses a separate ErrorResponse-PDU to report errors,
eliminating the need to report no error in most messages.
* CNMP defines a number of dynamic object PDUs that are placed
directly over the transport without the normal
CNMPVersionedMessage message wrapper. These PDUs offer the most
condensed form of communication, but do not offer any real
security features.
* CNMP allows the use of RELATIVE-OIDs. In addition to providing
more efficient encodings, this allows the GetNextRequest-PDU and
GetBulkRequest-PDU to walk a defined range of the ISO naming tree.
* CNMP makes a number of other refinements to decrease the size of a
message without compromising key functionality of the protocol.
* The Transport mappings for CNMP are defined in [Trans].
* CNMP uses SMIv2 as defined in [RFC2578].
4. Management Information Base Definitions
CNMP-PO-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
mgmt, MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI;
cnmp OBJECT IDENTIFIER ::= { TBD1 }
cnmpModules OBJECT IDENTIFIER ::= { cnmp 1 }
cnmpPOMIB MODULE-IDENTITY
LAST-UPDATED "201310170000Z"
ORGANIZATION "Trevilon LLC"
CONTACT-INFO "name: Kenneth Vaughn
phone: +1-571-331-5670
email: kvaughn@trevilon.com
postal: 6606 FM 1488 RD
STE 148-503
K. Vaughn Expires May 24, 2014 [Page 4]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
Magnolia, TX 77354
USA
"
DESCRIPTION "The MIB for CNMP Protocol Operations."
::= { cnmpModules 2 }
-- Administrative assignments ***************************************
cnmpPOAdmin OBJECT IDENTIFIER ::= { cnmpPOMIB 1 }
cnmpPOMIBObjects OBJECT IDENTIFIER ::= { cnmpPOMIB 2 }
cnmpPOMIBConformance OBJECT IDENTIFIER ::= { cnmpPOMIB 3 }
-- Statistics for CNMP Messages *************************************
dynObjectConfig OBJECT IDENTIFIER ::= { cnmpPOMIBObjects 1 }
dynObjectMaxRows OBJECT-TYPE
SYNTAX INTEGER (0..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum number of dynamic objects supported by
the entity. The first 13 dynamic objects can be
retrieved with the most compact encodings of CNMP."
::= { dynObjectConfig 1 }
dynObjectMaxVariables OBJECT-TYPE
SYNTAX INTEGER (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum number of variables that can be
referenced by a single dynamic object. This SHALL
be equal to the number of conceptual rows that exist
in the dynObjectVarTable for each dynObjectNumber
and provides the maximum allowed value for
dynObjectVarIndex. All dynamic objects within an
implementation SHALL support the same maximum number
of variable references. The actual number of
variables contained within a dynamic object are
defined by the rules in Clause X.X.X."
::= { dynObjectConfig 2 }
dynObjectTable OBJECT-TYPE
SYNTAX SEQUENCE OF DynObjectEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table that defines the owner and status for each
dynamic object and allows its retrieval.
K. Vaughn Expires May 24, 2014 [Page 5]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
Agents that implement the Simple Transportation
Management Protocol (STMP), as defined in NTCIP
1103, SHALL always synchronize the values of the
objects in this table with the objects contained
in the dynObjConfigTable."
::= { dynObjectConfig 3 }
dynObjectEntry OBJECT-TYPE
SYNTAX DynObjectEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the dynObjTable. The table is indexed
by the dynamic object number."
INDEX { dynObjectNumber }
::= { dynObjectTable 1 }
DynObjectEntry ::= SEQUENCE {
dynObjectNumber INTEGER,
dynObjectOwner DisplayString,
dynObjectReset INTEGER,
dynObjectValue OCTET STRING,
dynObjectStatus RowStatus
}
dynObjectNumber OBJECT-TYPE
SYNTAX INTEGER (1..dynObjectMaxRows)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The dynamic object number used as the index to the
dynObjectTable and the primary index to the
dynObjectVarTable."
::= { dynObjectEntry 1 }
dynObjectOwner OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The name of the owner of this dynamic object. This
object cannot be set when the value of dynObjStatus
is 'active'."
::= { dynObjectEntry 2 }
dynObjectReset OBJECT-TYPE
SYNTAX INTEGER { normal (1),
clear (2) } (1..2)
MAX-ACCESS read-write
STATUS current
DESCRIPTION "A control that allows a manager to easily reset all
K. Vaughn Expires May 24, 2014 [Page 6]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
of the variable references for this dynamic object
to null. A set to 'normal' SHALL have no effect. A
set to 'clear' shall automatically set all
dynObjVariable objects associated with this
dynObjNumber to the value 'null' (i.e., 0.0). Once
all of the dynObjVariable objects have been updated,
the value of this object shall automatically
transition to 'normal'. This object cannot be set
when the value of dynObjStatus is 'active'."
::= { dynObjectEntry 3 }
dynObjectValue OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The current value of the dynamic object. This is
the Octet Encoding Rules [OER] encoding of the ASN.1
SEQUENCE of the referenced dynObjectVariable objects
for this dynObjectNumber. This object shall only
be accessible when dynObjectStatus for this dynamic
object has a value of 'active'; at all other times,
this object SHALL act as if its STATUS is
'not-accessible'."
::= { dynObjectEntry 4 }
dynObjectStatus OBJECT-TYPE
SYNTAX RowStatus (1..3)
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The status column used for modifying and validating
instances of dynamic objects. The range of this
object SAHLL be limited to 'active', 'notInService',
and 'notReady'. Under no circumstances SHALL the
values 'createAndGo', 'createAndWait', or 'destroy'
be assigned to this object (i.e., 'wrongValue'
error). An attempt to set this object to 'active'
SHALL initiate consistency checks, which may cause
an 'inconsistentValue' error.
The value of this object SHALL NOT be 'active' when
attempting to set any other column of this table
(i.e., 'inconsistentValue' error)."
::= { dynObjectEntry 6 }
dynObjectVarTable OBJECT-TYPE
SYNTAX SEQUENCE OF DynObjectVarEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table that indicates the ordered list of
K. Vaughn Expires May 24, 2014 [Page 7]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
variables contained in the dynamic object.
Agents that implement the Simple Transportation
Management Protocol (STMP), as defined in NTCIP
1103, SHALL always synchronize the values of the
objects in this table with the objects contained
in the dynObjDef table."
::= { dynObjectConfig 4 }
dynObjectVarEntry OBJECT-TYPE
SYNTAX DynObjectVarEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the dynObjVarTable. The table is
indexed by the dynamic object number (from the
dynObjTable) and the dynObjVarIndex."
INDEX { dynObjectNumber, dynObjectVarIndex }
::= { dynObjectVarTable 1 }
DynObjectVarEntry ::= SEQUENCE {
dynObjectVarIndex INTEGER,
dynObjectVariable OBJECT IDENTIFIER
}
dynObjectVarIndex OBJECT-TYPE
SYNTAX INTEGER (1..dynObjectMaxVariables)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The index position of the referenced variable within
the dynamic object. This is the secondary index to
the dynObjectVarTable."
::= { dynObjectVarEntry 1 }
dynObjectVariable OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The instance of an object type to be included within
the dynamic object. If this value is 'null' (0.0),
the value of all dynObjectVariable objects for this
dynObjectNumber with larger dynObjectVarIndexes
shall be ignored. See Clause X.X.X. for a complete
definition."
::= { dynObjectVarEntry 2 }
defaultNodeConfig OBJECT IDENTIFIER ::= { cnmpPOMIBObjects 2 }
K. Vaughn Expires May 24, 2014 [Page 8]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
defaultNodeMaxRows OBJECT-TYPE
SYNTAX INTEGER (0..15)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum number of defaultNode options supported
by the entity within the ObjectName construct of
CNMP."
::= { defaultNodeConfig 1 }
defaultNodeTable OBJECT-TYPE
SYNTAX SEQUENCE OF DefaultNodeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table that defines the base nodes on the naming
tree from which to identify objects when using one
of the defaultNode (RELATIVE OID) options of the
ObjectName format. See Clause X.X.X. for a
complete definition."
::= { defaultNodeConfig 2 }
defaultNodeEntry OBJECT-TYPE
SYNTAX DefaultNodeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the DefaultNodeTable. The table is
indexed by the defaultNodeIndex."
INDEX { defaultNodeIndex }
::= { defaultNodeTable 1 }
defaultNodeEntry ::= SEQUENCE {
defaultNodeIndex INTEGER,
defaultNodeOid OBJECT IDENTIFIER
}
defaultNodeIndex OBJECT-TYPE
SYNTAX INTEGER (1..defaultNodeMaxRows)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The default node number. Row 1 corresponds with the
defaultNode1 option of the ObjectName construct."
::= { defaultNodeEntry 1 }
defaultNodeOid OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
K. Vaughn Expires May 24, 2014 [Page 9]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
DESCRIPTION "The node on the naming tree from which the
ObjectName is encoded. For example, if the value of
the referenced defaultNodeOid is 'mib-2'
(1.3.6.1.2.1), the ObjectName field would only need
to encode '1.5' in order to reference the object
'sysName'."
::= { defaultNodeEntry 2 }
-- Conformance information ******************************************
cnmpPOMIBCompliances OBJECT IDENTIFIER ::= {cnmpPOMIBConformance 1}
cnmpPOMIBGroups OBJECT IDENTIFIER ::= {cnmpPOMIBConformance 2}
-- Compliance statements
cnmpPOCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for CNMP entities which
implement the CNMP-PO-MIB."
MODULE -- this module
MANDATORY-GROUPS { cnmpCapabilitiesGroup }
GROUP dynObjectGroup
DESCRIPTION "The dynObjectGroup is mandatory if the value of
dynObjectMaxRows is greater than zero (0)."
GROUP defaultNode
DESCRIPTION "The defaultNodeGroup is mandatory if the value of
defaultNodeMaxRows is greater than zero (0)."
::= { cnmpPOMIBCompliances 1 }
cnmpCapabilitiesGroup OBJECT-GROUP
OBJECTS {
dynObjectMaxRows,
defaultNodeMaxRows
}
STATUS current
DESCRIPTION "A collection of objects that indicate basic
capabilities supported (or not supported) by the
CNMP entity."
::= { cnmpPOMIBGroups 1 }
dynObjectGroup OBJECT-GROUP
OBJECTS {
K. Vaughn Expires May 24, 2014 [Page 10]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
dynObjectMaxVariables,
dynObjectOwner,
dynObjectReset,
dynObjectValue,
dynObjectStatus,
dynObjectVariable
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
and retrieval of dynamic objects."
::= { cnmpPOMIBGroups 1 }
defaultNodeGroup OBJECT-GROUP
OBJECTS {
defaultNodeOid
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
and retrieval of dynamic objects."
::= { cnmpPOMIBGroups 1 }
END
5. CNMP PDU Format
5.1. Definition
CNMP-PDU DEFINITIONS ::= BEGIN
IMPORTS
IpAddress, Counter32, Unsigned32, Gauge32, TimeTicks,
Opaque, Counter64
FROM SNMPv2-PDU;
ObjectName ::= CHOICE {
fullOid [0] OBJECT IDENTIFIER,
-- OID is formed by the base and extension pair
pair [1] OidPair,
-- OID is relative to most recently used base
extension [2] RELATIVE-OID,
-- dynObject is relative to dynObjectValue,
dynObject [3] RELATIVE-OID,
-- defaultNodeX is relative to defaultNodeOid.X
defaultNode1 [PRIVATE 1] RELATIVE-OID,
K. Vaughn Expires May 24, 2014 [Page 11]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
defaultNode2 [PRIVATE 2] RELATIVE-OID,
defaultNode3 [PRIVATE 3] RELATIVE-OID,
defaultNode4 [PRIVATE 4] RELATIVE-OID,
defaultNode5 [PRIVATE 5] RELATIVE-OID,
defaultNode6 [PRIVATE 6] RELATIVE-OID,
defaultNode7 [PRIVATE 7] RELATIVE-OID,
defaultNode8 [PRIVATE 8] RELATIVE-OID,
defaultNode9 [PRIVATE 9] RELATIVE-OID,
defaultNode10 [PRIVATE 10] RELATIVE-OID,
defaultNode11 [PRIVATE 11] RELATIVE-OID,
defaultNode12 [PRIVATE 12] RELATIVE-OID,
defaultNode13 [PRIVATE 13] RELATIVE-OID,
defaultNode14 [PRIVATE 14] RELATIVE-OID,
defaultNode15 [PRIVATE 15] RELATIVE-OID
}
OidPair ::= SEQUENCE {
base OBJECT IDENTIFIER,
extension RELATIVE-OID
}
ObjectSyntax ::= CHOICE {
long Signed32,
string-value OCTET STRING (SIZE (0..65535)),
objectID-value OBJECT IDENTIFIER,
ipAddress-value IpAddress,
counter-value Counter32,
ulong Unsigned32,
timeticks-value TimeTicks,
arbitrary-value Opaque,
big-counter-value Counter64,
byte Signed8,
short Signed16,
ubyte Unsigned8,
ushort Unsigned16
}
Signed8 ::= [APPLICATION 7] INTEGER (-128..127)
Signed16 ::= [APPLICATION 8] INTEGER (-32768..32767)
Signed32 ::= INTEGER (-2147483648..2147483647)
Unsigned8 ::= [APPLICATION 9] INTEGER (0..255)
Unsigned16 ::= [APPLICATION 10] INTEGER (0..65535)
VarBind ::= SEQUENCE {
name ObjectName,
value CHOICE {
value ObjectSyntax,
noSuchObject [0] NULL,
K. Vaughn Expires May 24, 2014 [Page 12]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
noSuchInstance [1] NULL,
endOfMibView [2] NULL,
endOfRange [3] NULL,
processTimeout [4] NULL
}
}
VarBinds ::= SEQUENCE (SIZE (0..255)) OF VarBind
VarNames ::= SEQUENCE (SIZE (0..255)) OF ObjectName
GetBulkRequest ::= SEQUENCE {
non-repeaters Unsigned8,
max-repetitions Unsigned8,
variables VarNames
}
ErrorStatus ::= INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18),
invalidName(19),
processTimeout(20)
} (0..255)
ErrorResponse ::= SEQUENCE {
errorStatus ErrorStatus,
errorIndex INTEGER (0..255),
errorVariable OBJECT IDENTIFIER
}
CNMP-PDUs ::= CHOICE {
getRequest GetRequest-PDU,
K. Vaughn Expires May 24, 2014 [Page 13]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
setRequest SetRequest-PDU,
setNoReply SetNoReply-PDU,
getNextRequest GetNextRequest-PDU,
getResponse GetResponse-PDU,
setResponse SetResponse-PDU,
errorResponse ErrorResponse-PDU,
getBulkRequest GetBulkRequest-PDU,
trap Trap-PDU,
inform InformRequest-PDU,
informResponse InformResponse-PDU
}
GetRequest-PDU ::= [0] VarNames
SetRequest-PDU ::= [16] VarBinds
SetNoReply-PDU ::= [32] VarBinds
GetNextRequest-PDU ::= [48] VarNames
GetResponse-PDU ::= [PRIVATE 0] VarBinds
SetResponse-PDU ::= [PRIVATE 16] NULL
ErrorResponse-PDU ::= [PRIVATE 32] ErrorResponse
GetBulkRequest-PDU ::= [PRIVATE 48] GetBulkRequest
Trap-PDU ::= [PRIVATE 49] VarBinds
InformRequest-PDU ::= [PRIVATE 50] VarBinds
InformResponse-PDU ::= [PRIVATE 51] NULL
-- The following definitions provide for the most compact encoding
-- but do not offer built-in security. They should only be used
-- over networks that are either physically secure or secured by
-- other means (e.g., VPN).
GetDynObj1 ::= [1] NULL
GetDynObj2 ::= [2] NULL
GetDynObj3 ::= [3] NULL
GetDynObj4 ::= [4] NULL
GetDynObj5 ::= [5] NULL
GetDynObj6 ::= [6] NULL
GetDynObj7 ::= [7] NULL
GetDynObj8 ::= [8] NULL
GetDynObj9 ::= [9] NULL
GetDynObj10 ::= [10] NULL
GetDynObj11 ::= [11] NULL
GetDynObj12 ::= [12] NULL
GetDynObj13 ::= [13] NULL
SetDynObj1 ::= [17] DynamicObject-PDU
SetDynObj2 ::= [18] DynamicObject-PDU
SetDynObj3 ::= [19] DynamicObject-PDU
SetDynObj4 ::= [20] DynamicObject-PDU
SetDynObj5 ::= [21] DynamicObject-PDU
K. Vaughn Expires May 24, 2014 [Page 14]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
SetDynObj6 ::= [22] DynamicObject-PDU
SetDynObj7 ::= [23] DynamicObject-PDU
SetDynObj8 ::= [24] DynamicObject-PDU
SetDynObj9 ::= [25] DynamicObject-PDU
SetDynObj10 ::= [26] DynamicObject-PDU
SetDynObj11 ::= [27] DynamicObject-PDU
SetDynObj12 ::= [28] DynamicObject-PDU
SetDynObj13 ::= [29] DynamicObject-PDU
SetNoReplyDynObj1 ::= [33] DynamicObject-PDU
SetNoReplyDynObj2 ::= [34] DynamicObject-PDU
SetNoReplyDynObj3 ::= [35] DynamicObject-PDU
SetNoReplyDynObj4 ::= [36] DynamicObject-PDU
SetNoReplyDynObj5 ::= [37] DynamicObject-PDU
SetNoReplyDynObj6 ::= [38] DynamicObject-PDU
SetNoReplyDynObj7 ::= [39] DynamicObject-PDU
SetNoReplyDynObj8 ::= [40] DynamicObject-PDU
SetNoReplyDynObj9 ::= [41] DynamicObject-PDU
SetNoReplyDynObj10 ::= [42] DynamicObject-PDU
SetNoReplyDynObj11 ::= [43] DynamicObject-PDU
SetNoReplyDynObj12 ::= [44] DynamicObject-PDU
SetNoReplyDynObj13 ::= [45] DynamicObject-PDU
GetNextDynObj1 ::= [49] NULL
GetNextDynObj2 ::= [50] NULL
GetNextDynObj3 ::= [51] NULL
GetNextDynObj4 ::= [52] NULL
GetNextDynObj5 ::= [53] NULL
GetNextDynObj6 ::= [54] NULL
GetNextDynObj7 ::= [55] NULL
GetNextDynObj8 ::= [56] NULL
GetNextDynObj9 ::= [57] NULL
GetNextDynObj10 ::= [58] NULL
GetNextDynObj11 ::= [59] NULL
GetNextDynObj12 ::= [60] NULL
GetNextDynObj13 ::= [61] NULL
GetRespDynObj1 ::= [PRIVATE 1] DynamicObject-PDU
GetRespDynObj2 ::= [PRIVATE 2] DynamicObject-PDU
GetRespDynObj3 ::= [PRIVATE 3] DynamicObject-PDU
GetRespDynObj4 ::= [PRIVATE 4] DynamicObject-PDU
GetRespDynObj5 ::= [PRIVATE 5] DynamicObject-PDU
GetRespDynObj6 ::= [PRIVATE 6] DynamicObject-PDU
GetRespDynObj7 ::= [PRIVATE 7] DynamicObject-PDU
GetRespDynObj8 ::= [PRIVATE 8] DynamicObject-PDU
GetRespDynObj9 ::= [PRIVATE 9] DynamicObject-PDU
GetRespDynObj10 ::= [PRIVATE 10] DynamicObject-PDU
GetRespDynObj11 ::= [PRIVATE 11] DynamicObject-PDU
K. Vaughn Expires May 24, 2014 [Page 15]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
GetRespDynObj12 ::= [PRIVATE 12] DynamicObject-PDU
GetRespDynObj13 ::= [PRIVATE 13] DynamicObject-PDU
SetRespDynObj1 ::= [PRIVATE 17] NULL
SetRespDynObj2 ::= [PRIVATE 18] NULL
SetRespDynObj3 ::= [PRIVATE 19] NULL
SetRespDynObj4 ::= [PRIVATE 20] NULL
SetRespDynObj5 ::= [PRIVATE 21] NULL
SetRespDynObj6 ::= [PRIVATE 22] NULL
SetRespDynObj7 ::= [PRIVATE 23] NULL
SetRespDynObj8 ::= [PRIVATE 24] NULL
SetRespDynObj9 ::= [PRIVATE 25] NULL
SetRespDynObj10 ::= [PRIVATE 26] NULL
SetRespDynObj11 ::= [PRIVATE 27] NULL
SetRespDynObj12 ::= [PRIVATE 28] NULL
SetRespDynObj13 ::= [PRIVATE 29] NULL
ErrorRespDynObj1 ::= [PRIVATE 33] ErrorInformation-PDU
ErrorRespDynObj2 ::= [PRIVATE 34] ErrorInformation-PDU
ErrorRespDynObj3 ::= [PRIVATE 35] ErrorInformation-PDU
ErrorRespDynObj4 ::= [PRIVATE 36] ErrorInformation-PDU
ErrorRespDynObj5 ::= [PRIVATE 37] ErrorInformation-PDU
ErrorRespDynObj6 ::= [PRIVATE 38] ErrorInformation-PDU
ErrorRespDynObj7 ::= [PRIVATE 39] ErrorInformation-PDU
ErrorRespDynObj8 ::= [PRIVATE 40] ErrorInformation-PDU
ErrorRespDynObj9 ::= [PRIVATE 41] ErrorInformation-PDU
ErrorRespDynObj10 ::= [PRIVATE 42] ErrorInformation-PDU
ErrorRespDynObj11 ::= [PRIVATE 43] ErrorInformation-PDU
ErrorRespDynObj12 ::= [PRIVATE 44] ErrorInformation-PDU
ErrorRespDynObj13 ::= [PRIVATE 45] ErrorInformation-PDU
-- The definition for DynamicObject-PDU is a placeholder
-- See Clause 5.2.4 for a complete definition
DynamicObject-PDU ::= SEQUENCE {}
ErrorInformation-PDU ::= SEQUENCE {
errorStatus ErrorStatus,
errorIndex INTEGER (0..255)
}
END
5.2. Type Definitions
The Type definitions of CNMP are conceptually similar to those
defined in SNMPv3 [RFC3416] with the following exceptions.
K. Vaughn Expires May 24, 2014 [Page 16]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
5.2.1. ObjectName
CNMP allows the object name to be represented in several different
forms as indicated by the CHOICE construct.
The 'fullOid' option presents the ObjectName as a complete OBJECT
IDENTIFIER, just as it would appear in SNMPv3.
The 'pair' option presents the ObjectName as a base OBJECT IDENTIFIER
coupled with an extension as a RELATIVE-OID. Combining the two
components together provides the complete OBJECT IDENTIFIER as would
be used in SNMPv3.
The 'extension' option presents only an extension. It SHALL be
coupled with the 'base' of the most recent, previously encoded 'pair'
contained within the same PDU. For example, if a PDU contains four
objects, where the first and third use the 'pair' encoding and the
second and fourth use the 'extension' encoding', the second object
extension would be combined with the base from the first object and
the fourth object extension would be combined with the base from the
third object.
The 'dynObject' option presents the ObjectName as a RELATIVE OID,
showing only the node that occurs after the node 'dynObjectValue'
(i.e., the index of this object). For example, the RELATIVE OID for
dynamic object 1 would be { 1 }, which in OER would be encoded as the
hexadecimal value 0x0101, i.e., a length field of 0x01 followed by
the node number of 0x01.
The 'defaultNodeX' options present the ObjectName as a RELATIVE OID,
showing only the node numbers that occur after the node referenced by
'defaultNodeOid.X' (See Clause 4), where the X equals the X in the
option name. A CNMP entity is not required to support the default
node option, but is required to support the defaultNodeMaxRows object
to indicate how many default nodes are supported (including zero).
Response PDUs SHALL use the same ObjectName format as used in the
corresponding request without changing any base. For example, a
GetResponse-PDU to a GetNextRequest-PDU using the 'pair' format SHALL
use the 'pair' format in the response using the same 'base' value. If
there is no such object in the current view, the CNMP entity will
return an endOfRange value.
5.2.2. ObjectSyntax
CNMP adds options for one- and two-byte, signed and unsigned integers
in order to allow for more efficient encoding. The encoding of
integral values SHALL be as follows:
K. Vaughn Expires May 24, 2014 [Page 17]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
* If the object value to be encoded is for an object with a SYNTAX
of Counter64 or any other INTEGER with only a positive value range
that exceeds 2^32-1, the object value SHALL be encoded as a big-
counter-value.
* Otherwise, if the object value to be encoded is for an object with
a SYNTAX of Counter32 or any other INTEGER with only a positive
value range that exceeds 2^31-1, the object value SHALL be encoded
as a big-counter-value.
* Otherwise, CNMP restricts the value of the integer to a 32-bit
signed value. The actual value instance to be encoded SHALL be
encoded as follows:
+-------------------------------+-------------------+
| Value to be Encoded | ObjectSyntax |
+-------------------------------+-------------------+
| Lower Bound | Upper Bound | Option |
+---------------+---------------+-------------------+
|-2,147,483,648 | -32,769 | long |
+---------------+---------------+-------------------+
| -32,769 | -129 | short |
+---------------+---------------+-------------------+
| -128 | -1 | byte |
+---------------+---------------+-------------------+
| 0 | 255 | ubyte |
+---------------+---------------+-------------------+
| 256 | 65,535 | ushort |
+---------------+---------------+-------------------+
| 65,536 | 2,147,483,647 | long |
+---------------+---------------+-------------------+
This mapping allows efficient encoding without knowledge of the
specific object range while also allowing easy translation between
SNMP and CNMP messages for Counter32 and Counter64 values.
5.2.3. PDU Structure
The CNMPVersionedMessage uses one of 11 PDU structures in order to
provide more efficient communications by only including information
that is needed.
The request-id field is removed from these structures; the message-id
field from the parent message shall be used for this purpose.
5.2.4. DynamicObject-PDU
The definition of the DynamicObject-PDU structure SHALL be defined at
run-time based on the current configuration of the indicated dynamic
K. Vaughn Expires May 24, 2014 [Page 18]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
object. Specifically, the definition the DynamicObject-PDU for a
specific dynamic object SHALL be an ASN.1 SEQUENCE of the objects
referenced by the dynObjectVariables for the specific dynamic object,
in the order of their index values, ending at (and excluding) the
first dynObjectVariable that is set to "null" (i.e., 0.0).
EXAMPLE:
dynObjectVariable.1.1 references sysDescr.0
dynObjectVariable.1.2 references sysUpTime.0
dynObjectVariable.1.3 references null
The DynamicObject-PDU structure for dynamic object 1 would be defined
as:
DynamicObject-PDU ::= SEQUENCE {
variable1 DisplayString (SIZE (0..255)),
variable2 TimeTicks
}
6. Elements of Procedure
On generating a management communication, the message wrapper to
encapsulate the PDU is generated according to the "Elements of
Procedure" of the administrative framework in use. A compliant
implementation must support as many bindings (i.e., size of
ReqVarBinds, RespVarBinds, and VarNames) as fit into the overall
maximum message size limit of the CNMP engine, but no more than 255
variable bindings.
On receiving a management communication, the "Elements of Procedure"
of the administrative framework in use is followed, and if those
procedures indicate that the operation contained within the message
is to be performed locally, then those procedures also indicate the
MIB view which is visible to the operation.
6.1.1. GetRequest-PDU
The processing of a GetRequest-PDU SHALL be identical to that as
defined in Clause 4.2.1 of [RFC3416], with the following exceptions:
1) If an ObjectName using the 'extension' option appears prior to an
ObjectSyntax using the 'pair' option, the response PDU SHALL be an
ErrorResponse-PDU. The errorStatus field SHALL be set to
"missingBase", the errorIndex field SHALL indicate the index of
the objectName using the invalid extension format, and the
errorVariable SHALL be set to "null" (0.0).
2) Otherwise, if the rules of [RFC3416] result in a response PDU with
K. Vaughn Expires May 24, 2014 [Page 19]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
a non-zero error-status field, the response PDU SHALL be an
ErrorResponse-PDU, as defined in Clause 5 of this Internet-Draft.
If the errorIndex field is non-zero, the errorVariable field of
the PDU SHALL be set to the full Object identifier of the
requested ObjectName referenced by the errorIndex field;
otherwise, the errorVariable field SHALL be set to 'null' (i.e.,
0.0).
3) Otherwise, the response PDU SHALL be a GetResponse-PDU, as defined
in Clause 5 of this Internet-Draft.
4) If the PDU contains multiple ObjectNames, the implementation may
return a value of "processTimeout" for any request for any
instance of dynObjectValue. This can be useful to prevent
overloading of an agent's processor.
5) Any fields referenced in Clause 4.2.1 of [RFC3416] that do not
have a parallel construct in the response PDU in Clause 5 of this
Internet-Draft shall be ignored.
6.1.2. SetRequest-PDU and SetNoReply-PDU
The processing of a SetRequest-PDU and a SetNoReply-PDU SHALL be
identical to that as defined in Clause 4.2.5 of [RFC3416], with the
following exceptions:
1) If the request is a SetNoReply-PDU, the entity SHALL NOT produce a
response PDU, but all other rules shall be followed.
2) Otherwise, if an ObjectName using the 'extension' option appears
prior to an ObjectSyntax using the 'pair' option, the entire
request SHALL be rejected and the response PDU SHALL be an
ErrorResponse-PDU. The errorStatus field SHALL be set to
"missingBase", the errorIndex field SHALL indicate the index of
the objectName using the invalid extension format, and the
errorVariable SHALL be set to "null" (0.0).
3) Otherwise, if the rules of [RFC3416] result in a response PDU with
a non-zero error-status field, the response PDU SHALL be an
ErrorResponse-PDU, as defined in Clause 5 of this Internet-Draft.
If the errorIndex field is non-zero, the errorVariable field of
the PDU SHALL be set to the full Object identifier of the
requested ObjectName referenced by the errorIndex field;
otherwise, the errorVariable field SHALL be set to 'null' (i.e.,
0.0).
4) Otherwise, if the PDU contains multiple ObjectNames and one or
more of the ObjectNames reference instance(s) of dynObjectValue,
K. Vaughn Expires May 24, 2014 [Page 20]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
the entire request MAY be rejected, in which case, the Response
PDU SHALL be an ErrorResponse-PDU. The errorStatus field SHALL be
set to "processTimeout", the errorIndex field SHALL indicate the
index of the offending ObjectName field, and the errorVariable
SHALL indicate the OBJECT IDENTIFIER of the dynObjectValue
instance.
5) Otherwise, the response PDU SHALL be a SetResponse-PDU, as defined
in Clause 5 of this Internet-Draft.
6) Any fields referenced in Clause 4.2.5 of [RFC3416] do not have a
parallel construct in the response PDU in Clause 5 of this
Internet-Draft shall be ignored.
6.1.3. GetNextRequest-PDU
The processing of a GetNextRequest-PDU SHALL be identical to that as
defined in Clause 4.2.2 of [RFC3416], with the following exceptions:
1) If an ObjectName using the 'extension' option appears prior to
an ObjectSyntax using the 'pair' option, the response PDU SHALL be
an ErrorResponse-PDU. The errorStatus field SHALL be set to
"missingBase", the errorIndex field SHALL indicate the index of
the objectName using the invalid extension format, and the
errorVariable SHALL be set to "null" (0.0).
2) Otherwise, while processing a variable binding that uses a
RELATIVE-OID, if the requested variable binding's name does not
lexicographically precede the name of any variable accessible by
this request which is a sub-node of the base used by the RELATIVE-
OID, i.e., there is no lexicographic successor using the same
base, then the corresponding variable binding produced in the
Response-PDU has its value field set to "endOfRange", and its name
field set to the variable binding's name in the request. If the
endOfRange also corresponds to the endOfMibView, it is
implementation dependent which value field is returned.
3) If the rules of [RFC3416] result in a response PDU with a non-zero
error-status field, the response PDU SHALL be an ErrorResponse-
PDU, as defined in Clause 5 of this Internet-Draft. If the
errorIndex field is non-zero, the errorVariable field of the PDU
SHALL be set to the full Object identifier of the requested
ObjectName referenced by the errorIndex field; otherwise, the
errorVariable field SHALL be set to 'null' (i.e., 0.0).
4) Otherwise, the response PDU SHALL be a GetResponse-PDU, as defined
in Clause 5 of this Internet-Draft.
K. Vaughn Expires May 24, 2014 [Page 21]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
5) If the PDU contains multiple ObjectNames, the implementation may
return a value of "processTimeout" for any instance of
dynObjectValue. This can be useful to prevent overloading of an
agent's processor.
6) Any fields referenced in Clause 4.2.2 of [RFC3416] do not have a
parallel construct in the response PDU in Clause 5 of this
Internet-Draft shall be ignored.
6.1.1. GetResponse-PDU, SetResponse-PDU, InformResponse-PDU, and
ErrorResponse-PDU
The processing of a GetResponse-PDU, SetResponse-PDU, InformResponse-
PDU, and ErrorResponse-PDU SHALL be identical to that as defined in
Clause 4.2.4 of [RFC3416], with the following exceptions:
1) These PDUs are generated by a CNMP entity only according to the
rules defined elsewhere in this Internet-Draft.
6.1.1. GetBulkRequest-PDU
The processing of a GetBulkRequest-PDU SHALL be identical to that as
defined in Clause 4.2.3 of [RFC3416], with the following exceptions:
1) If an ObjectName using the 'extension' option appears prior to
an ObjectSyntax using the 'pair' option, the response PDU SHALL be
an ErrorResponse-PDU. The errorStatus field SHALL be set to
"missingBase", the errorIndex field SHALL indicate the index of
the objectName using the invalid extension format, and the
errorVariable SHALL be set to "null" (0.0).
2) Otherwise, while processing a variable binding that uses a
RELATIVE-OID, if the requested variable instance (i.e., a non-
repeater or any instance of a repeated request) does not have a
lexicographic successor accessible by this request which is a sub-
node of the base used by the RELATIVE-OID, then the corresponding
variable binding produced in the Response-PDU has its value field
set to "endOfRange", and its name field set to the variable
binding's name in the request. If the endOfRange also corresponds
to the endOfMibView, it is implementation dependent which value
field is returned.
3) The response PDU may be generated with a lesser number of variable
bindings if for some value of iteration i, such that i is greater
than zero and less than or equal to M, that all of the generated
variable bindings have the value field set to either "endOfRange"
or "endOfMibView". In this case, the variable bindings may be
truncated after the (N + (i * R))-th variable binding. See
K. Vaughn Expires May 24, 2014 [Page 22]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
[RFC3416] for the definition of i, M, N, and R.
4) If the rules of [RFC3416] result in a response PDU with a non-zero
error-status field, the response PDU SHALL be an ErrorResponse-
PDU, as defined in Clause 5 of this Internet-Draft. If the
errorIndex field is non-zero, the errorVariable field of the PDU
SHALL be set to the full Object identifier of the requested
ObjectName referenced by the errorIndex field; otherwise, the
errorVariable field SHALL be set to 'null' (i.e., 0.0).
5) Otherwise, the response PDU SHALL be a GetResponse-PDU, as defined
in Clause 5 of this Internet-Draft.
6) If the PDU contains multiple ObjectNames, the implementation may
return a value of "processTimeout" for any instance of
dynObjectValue. This can be useful to prevent overloading of an
agent's processor.
7) Any fields referenced in Clause 4.2.3 of [RFC3416] do not have a
parallel construct in the response PDU in Clause 5 of this
Internet-Draft shall be ignored.
6.1.1. Trap-PDU
The processing of a Trap-PDU SHALL be identical to that as defined in
Clause 4.2.6 of [RFC3416].
6.1.1. InformRequest-PDU
The processing of an InformRequest-PDU SHALL be identical to that as
defined in Clause 4.2.7 of [RFC3416], with the following exceptions:
1) Otherwise, the response PDU SHALL be a InformResponse-PDU, as
defined in Clause 5 of this Internet-Draft.
2) Any fields referenced in Clause 4.2.3 of [RFC3416] do not have a
parallel construct in the response PDU in Clause 5 of this
Internet-Draft shall be ignored.
6.1.1. GetDynObjX
Each of the 13 GetDynObjX types represent a get request for the
indicated dynamic object (i.e., GetDynObj1 represents a get request
for dynamic object 1). A GetDynObjX PDU is generated and transmitted
at the request of an application.
Upon receipt of a GetDynObjX PDU, the receiving CNMP entity processes
the request as follows:
K. Vaughn Expires May 24, 2014 [Page 23]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
1) If the PDU contains any information, the entity SHALL increment
the value of snmpInASNParseErrs. The message SHALL be discarded
and processing SHALL be complete.
2) Otherwise, if the dynObjectStatus of the indicated dynamic object
is not 'active', the entity SHALL produce an ErrorInformation-PDU.
The errorStatus field SHALL be set to 'noSuchName' and the
errorIndex field SHALL be set to zero (0).
3) Otherwise, if the dynamic object contains a reference to an object
in one of its dynObjectVariable values that is not in the current
MIB view (i.e., not currently instantiated, not visible, etc.),
the entity SHALL produce an ErrorInformation-PDU. The errorStatus
field SHALL be set to 'noSuchName' and the errorIndex field SHALL
be set to the index of the first dynObjectVariable of the dynamic
object that is invalid.
4) Otherwise, if the dynamic object cannot be retrieved for any other
reason, the entity SHALL produce an ErrorInformation-PDU. The
errorStatus field SHALL be set to 'genErr' and the errorIndex
field SHALL be set to the index of the dynObjectVariable that is
causing the problem, if known, and zero (0) otherwise.
5) Otherwise, the entity SHALL produce a DynamicObject-PDU containing
the value of dynObjectValue.X.
6) The response PDU is then encapsulated into a message. If the size
of the resultant message is less than or equal to both a local
constraint and the maximum message size of the originator, it is
transmitted to the originator of the GetNextDynObjX.
7) Otherwise, an ErrorRespDynObjX is generated for the subject
dynamic object. The value of the errorStatus field SHALL be to
"tooBig" and the value of the error-index field SHALL be zero.
This ErrorRespDynObj is then encapsulated into a message and
transmitted to the originator of the GetDynObjX.
6.1.2. SetDynObjX and SetNoReplyDynObjX
Each of the 13 SetDynObjX types and 13 SetNoReplyDynObjX types
represent a set request for the indicated dynamic object. These PDU
are generated and transmitted at the request of an application.
Upon receipt of such a PDU, the receiving CNMP entity processes the
request as follows:
1) If the dynObjectStatus of the indicated dynamic object is not
'active', the entity SHALL produce an ErrorInformation-PDU. The
K. Vaughn Expires May 24, 2014 [Page 24]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
errorStatus field SHALL be set to 'noSuchName' and the errorIndex
field SHALL be set to zero (0).
2) Otherwise, if the dynamic object contains a reference to an object
in one of its dynObjectVariable values that is not in the current
MIB view (i.e., not currently instantiated, not visible, etc.),
the entity SHALL produce an ErrorInformation-PDU. The errorStatus
field SHALL be set to 'noSuchName' and the errorIndex field SHALL
be set to the index of the first dynObjectVariable of the dynamic
object that is invalid.
3) Otherwise, if the dynamic object contains a reference to an an
object that is not available for set operations with the current
MIB view, the entity SHALL produce an ErrorInformation-PDU. The
errorStatus field SHALL be set to 'readOnly' and the errorIndex
field SHALL be set to the index of the dynObjectVariable that
cannot be set.
4) Otherwise, if any parsing errors occur when decoding the contents
of the DynamicObject-PDU, the entity SHALL increment the value of
snmpInASNParseErrs and SHALL produce an ErrorInformation-PDU. The
errorStatus field SHALL be set to 'badValue' and the errorIndex
field SHALL indicate the index of the dynObjectVariable where
parsing failed.
5) Otherwise, if any of the objects referenced by the dynamic object
cannot be changed for any other reason, the entity SHALL produce
an ErrorInformation-PDU. The errorStatus field SHALL be set to
'genErr' and the errorIndex field SHALL indicate the index of the
dynObjectVariable causing the problem.
6) Otherwise, for each referenced object in the dynamic object
request, the entity SHALL create the object, if necessary, and
SHALL assign the requested value to it. Each of these assignments
occurs as if simultaneously with respect to all other assignments
specified in the same request.
a) If any of these assignments fail (even after all the previous
validations), then the entity SHALL undo all other assignments
and produce an ErrorInformation-PDU. The errorStatus field
SHALL be set to 'commitFailed' and the errorIndex field SHALL
be set to the index of the dynObjectVariable that cannot be
set.
b) If it is not possible to undo all the assignments, then the
entity SHALL produce an ErrorInformation-PDU; the errorStatus
field SHALL be set to 'undoFailed', and the errorIndex field
SHALL be set to zero. Note that implementations are strongly
K. Vaughn Expires May 24, 2014 [Page 25]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
encouraged to take all possible measures to avoid use of either
"commitFailed" or "undoFailed" - these two error-status codes
are not to be taken as license to take the easy way out in an
implementation.
c) Otherwise, the entity SHALL produce a SetRespDynObjX PDU as the
response PDU.
7) If the request was a SetNoReplyDynObjX PDU, the processing SHALL
be complete and no response is sent.
8) The response PDU is then encapsulated into a message and is
transmitted to the originator of the SetDynObjX PDU.
6.1.3. GetNextDynObjX
Each of the 13 GetNextDynObjX types represent a get request for the
next 'active' dynamic object. A GetNextDynObjX PDU is generated and
transmitted at the request of an application.
Upon receipt of a GetNextDynObjX PDU, the receiving CNMP entity
processes the request as follows:
1) If the PDU contains any information, the entity SHALL increment
the value of snmpInASNParseErrs. The message SHALL be discarded
and processing SHALL be complete.
2) The dynamic object is located which is the next lexicographical
successor of the indicated dynamic object where the
dynObjectStatus has a value of 'active'.
3) If there is no lexicographical successor which is a dynamic object
with a status of 'active', the entity SHALL produce an
ErrorInformation-PDU. The response dynamic object SHALL be the
dynamic object contained in the request. The errorStatus field
SHALL be set to 'noSuchName' and the errorIndex field SHALL be set
to zero (0).
4) If there is no lexicographical successor which is a dynamic object
with a status of 'active' that has a dynObjectIndex of 13 or less,
the entity SHALL produce an ErrorInformation-PDU. The response
dynamic object SHALL be the lexicographical successor dynamic
object. The errorStatus field SHALL be set to 'inconsistentValue'
and the errorIndex field SHALL be set to zero (0).
5) Otherwise, if the lexicographical successor dynamic object
contains a reference to an object in one of its dynObjectVariable
values that is not in the current MIB view (i.e., not currently
K. Vaughn Expires May 24, 2014 [Page 26]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
instantiated, not visible, etc.), the entity SHALL produce an
ErrorInformation-PDU. The response dynamic object SHALL be the
lexicographical successor dynamic object. The errorStatus field
SHALL be set to 'noSuchName' and the errorIndex field SHALL be set
to the index of the first dynObjectVariable of the dynamic object
that is invalid.
6) Otherwise, if the lexicographical successor dynamic object cannot
be retrieved for any other reason, the entity SHALL produce an
ErrorInformation-PDU. The response dynamic object SHALL be the
lexicographical successor dynamic object. The errorStatus field
SHALL be set to 'genErr' and the errorIndex field SHALL be set to
the index of the dynObjectVariable that is causing the problem, if
known, and zero (0) otherwise.
7) Otherwise, the entity SHALL produce a DynamicObject-PDU containing
the value of dynObjectValue for the lexicographical successor
dynamic object.
8) The response PDU is then encapsulated into a message. If the size
of the resultant message is less than or equal to both a local
constraint and the maximum message size of the originator, it is
transmitted to the originator of the GetNextDynObjX.
8) Otherwise, an ErrorRespDynObjX is generated for the subject
dynamic object. The value of the errorStatus field SHALL be to
"tooBig" and the value of the error-index field SHALL be zero.
This ErrorRespDynObj is then encapsulated into a message and
transmitted to the originator of the GetNextDynObjX.
The entity SHALL send the response PDU to the originator.
6.1.4. GetRespDynObjX, SetRespDynObjX, and ErrorRespDynObjX
Each of the 13 GetRespDynObjX types and 13 SetRespDynObjX types
represent a response for a dynamic object with the indicated dynamic
object index. These PDUs are generated by a CNMP entity according to
the rules defined elsewhere in this document.
Upon receipt of such a PDU, the receiving CNMP entity presents its
contents to the application which generated the most recent request
PDU for the indicated dynamic object.
7. Acknowledgements
This document is based largely on material contained in [RFC3416] and
K. Vaughn Expires May 24, 2014 [Page 27]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
[STMP].
8. Security Considerations
The protocol defined in this document by itself does not provide a
secure environment. Even if the network itself is secure (for
example by using IPSec), there is no control as to who on the secure
network is allowed access to management information.
It is recommended that the implementors consider the security
features as provided by [Msg]. Specifically, the use of the User-
based Security Model STD 62, RFC 3414 [RFC3414], the Transport
Security Model [RFC5590], and the View-based Access Control Model STD
62, RFC 3415 [RFC3415] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity is properly configured so that:
- only those principals (users) having legitimate rights can access
or modify the values of any MIB objects supported by that entity;
- the occurrence of particular events on the entity will be
communicated appropriately;
- the entity responds appropriately and with due credence to events
and information that have been communicated to it.
9. IANA Considerations
IANA needs to assign an OBJECT IDENTIFIER value (TBD1) to the
"cnmp" node defined near the top of Clause 4 of this Internet-
Draft. This node number must be registered as a part of the
"Structure and Identification of Management Information for
TCP/IP-based Internets" (SMI) naming tree
<http://www.iana.org/assignments/smi-numbers>. It is suggested
that the node be placed under the mgmt node (1.3.6.1.2), but we
leave the exact location to the discretion of the registrar and
the IETF.
In order to define the node, the parent node will need to be
imported into the module defined in Clause 4.
This node number should be the same node number assigned for the
variable TBD1 in draft-vaughn-cnmp-message-00.
10. References
K. Vaughn Expires May 24, 2014 [Page 28]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62,
RFC 3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", STD
62, RFC 3416, December 2002.
[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol
(SNMP) Context EngineID Discovery", RFC 5343, September
2008.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem
for the Simple Network Management Protocol (SNMP)",
RFC 5590, June 2009.
[Msg] Vaughn, K., "Message Processing for Condensed Network
K. Vaughn Expires May 24, 2014 [Page 29]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
Management Protocol (CNMP)", Internet-Draft draft-vaughn-
cnmp-message-00, November 2013.
[Trans] Vaughn, K., "Transport Mappings for Condensed Network
Management Protocol (CNMP)", Internet-Draft draft-vaughn-
cnmp-trans-00, November 2013.
[OER] "Information Technology - ASN.1 encoding rules:
Specification of Octet Encoding Rules (OER)", published by
International Telecommunications Union. Initial Draft
X.oer, January 2014.
10.2 Informative References
[Intro] Vaughn, K., "Document Roadmap for Condensed Network
Management Protocol (CNMP)", Internet-Draft draft-vaughn-
cnmp-intro-00, November 2013.
[STMP] "Transport Management Protocols", published by American
Association of State Highway Officials (AASHTO), Institute
of Transportation Engineers (ITE), and National Electrical
Manufacturers Association (NEMA). NTCIP (National
Transportation Communications for ITS Protocol)
1103v02.17, July 2010.
Authors' Addresses
Kenneth Vaughn
Trevilon LLC
6606 FM 1488 RD
STE 148-503
Magnolia, TX 77316
USA
Phone: +1-571-331-5670
Email: kvaughn@trevilon.com
Alessandro Triglia
OSS Nokolva, Inc.
1 Executive Drive
Suite 450
Somerset, NJ 08873
Email: sandro@oss.com
Robert Rausch
K. Vaughn Expires May 24, 2014 [Page 30]
INTERNET DRAFT Protocol Operations for CNMP November 20, 2013
Transcore, LP
192 Technology Parkway
Suite 500
Norcross, GA 30092
Email: robert.rausch@transcore.com
K. Vaughn Expires May 24, 2014 [Page 31]
