Internet DRAFT - draft-vaughn-cnmp-intro
draft-vaughn-cnmp-intro
INTERNET-DRAFT K. Vaughn
Intended Status: Informational Trevilon LLC
Expires: May 24, 2014 A. Triglia
OSS Nokalva, Inc.
R. Rausch
Transcore, LP
November 20, 2013
Document Roadmap for Condensed Network Management Protocol (CNMP)
draft-vaughn-cnmp-intro-00
Abstract
The purpose of this document is to provide an overview of the first
version of the Condensed Network Management Protocol (CNMP)
Framework. This Framework follows the Internet-Standard Management
Framework (SNMPv3), but CNMP provides a more efficient encoding of
data by using Octet Encoding Rules (OER) coupled with a more compact
set of message structures, including a set of "dynamic objects",
which are defined at runtime, as originally used by the Simple
Transportation Management Protocol (STMP).
The document is intended to provide an option to using SNMPv3 and is
not intended to replace SNMPv3. SNMPv3 will continue to offer the
advantage of providing a conceptually simple protocol, whereas CNMP
allows more compact messaging in high volume and bandwidth
constrained environments.
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
K. Vaughn Expires May 24, 2014 [Page 1]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
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
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Octet Encoding Rules . . . . . . . . . . . . . . . . . . . 4
1.2. Relative Object Identifiers . . . . . . . . . . . . . . . 4
1.3. Optimized Message Structure . . . . . . . . . . . . . . . 4
1.4. Dynamic Objects . . . . . . . . . . . . . . . . . . . . . 4
1.5. Consistency with Existing Standards . . . . . . . . . . . 5
1.6. History . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Documentation Roadmap . . . . . . . . . . . . . . . . . . . . 7
3.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . . 8
3.2. Applicability Statement . . . . . . . . . . . . . . . . . 9
3.3. Coexistence and Transition . . . . . . . . . . . . . . . . 9
3.4. Transport Mappings . . . . . . . . . . . . . . . . . . . . 9
3.5. Message Processing and Dispatcher . . . . . . . . . . . . 9
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 9
3.8. Applications . . . . . . . . . . . . . . . . . . . . . . . 9
3.9. Access Control . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Structure of Management Information . . . . . . . . . . . 10
3.11. Textual Conventions . . . . . . . . . . . . . . . . . . . 10
3.12. Conformance Statements . . . . . . . . . . . . . . . . . 10
3.13. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 10
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 10
4.1. CNMP Normal Requests . . . . . . . . . . . . . . . . . . . 10
4.2. CNMP Dynamic Object Requests . . . . . . . . . . . . . . . 10
4.3. CNMP Notifications . . . . . . . . . . . . . . . . . . . . 11
K. Vaughn Expires May 24, 2014 [Page 2]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
5. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Base Conformance . . . . . . . . . . . . . . . . . . . . . 12
5.2. Dynamic Objects . . . . . . . . . . . . . . . . . . . . . 12
5.3. Default Nodes . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Manager . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Notification Originator . . . . . . . . . . . . . . . . . 13
5.7. Notification Receiver . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Sample Encoding . . . . . . . . . . . . . . . . . . . 16
A.1. Get Request with No Security . . . . . . . . . . . . . . . 17
A.2. Get Response with No Security . . . . . . . . . . . . . . 17
A.3. Set Request with Authentication . . . . . . . . . . . . . 18
A.4. Set Response with Authentication . . . . . . . . . . . . . 20
A.5. Get Dynamic Object without Security . . . . . . . . . . . 20
A.6. Get Response for Dynamic Object without Security . . . . . 20
A.7. Get Dynamic Object with Security . . . . . . . . . . . . . 21
A.8. Get Response for Dynamic Object with Security . . . . . . 21
A.9. GetBulk PDU for Table Retrieval . . . . . . . . . . . . . 22
A.10. GetResponse PDU for Table Retrieval . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
K. Vaughn Expires May 24, 2014 [Page 3]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
1. Introduction
This document is an informational roadmap that captures, organizes,
and summarizes the documents that a CNMP implementer, experimenter,
or student should be aware of. Particular comments or broad
categorizations that this document makes about individual mechanisms
and behaviors are not to be taken as definitive, nor should the
content of this document alone influence implementation decisions.
The Simple Network Management Protocol (SNMP) provides a useful and
generic mechanism for a management system to exchange data with an
agent device. This mechanism has been successfully adopted by a
variety of systems. However, the encoding rules and message formats
used by SNMP result in relatively verbose communications, which limit
its application in some environments. The Condensed Network
Management Protocol (CNMP) follows the same basic rules as SNMP, but
provides for more efficient encoding of data so that it can be used
in more demanding environments. For example, this protocol can be
used to efficiently poll agents on a second-by-second basis on low-
speed, multi-party communication links. The specific variations used
by CNMP are outlined below.
1.1. Octet Encoding Rules
The ITU-T has recently initiated a new work item to develop the Octet
Encoding Rules [OER], which provide more efficient encoding and
processing than the Basic Encoding Rules used by SNMP. CNMP uses
these encoding rules to significantly reduce encoding size,
especially for small integer values.
1.2. Relative Object Identifiers
The ASN.1 standard has been updated since the original development of
SNMP to include the definition of the RELATIVE-OID type, which allows
a field to encode the OID from a known reference node. This
mechanism is used in several locations to reduce encoding size.
1.3. Optimized Message Structure
CNMP uses a modified data packet structure to minimize the amount of
redundant information typically contained within an SNMP packet. In
particular, fields that are not needed in a given context.
1.4. Dynamic Objects
CNMP defines a set of dynamic objects that an agent may support. A
manager can configure each dynamic object to reference a sequence of
up to 255 elemental objects (i.e., an instance of an object type that
K. Vaughn Expires May 24, 2014 [Page 4]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
is defined in the agent's MIB). The sequence of referenced objects
can then be exchanged as a single unit without having to refer to the
OBJECT IDENTIFIER of each referenced object. This is particularly
useful for management stations that frequently exchange the same set
of data.
While dynamic objects significantly reduce the size of messages,
there is an associated processing and code complexity cost. In
addition, there is overhead associated with initially configuring the
dynamic objects.
Dynamic objects allow a single agent design to be deployed for use
with a broad range of managers while still providing efficient
communications.
1.5. Consistency with Existing Standards
CNMP has been designed to be consistent with the Internet-Standard
Management SNMP Framework established with SNMPv3 and the protocol
formats defined by the Simple Transportation Management Protocol
[STMP], as defined by the National Transportation Communications for
Intelligent Transportation Systems (ITS) Protocol (NTCIP). CNMP can
coexist with any SNMP version and CNMP operations work on the same
SNMP objects.
1.6. History
SNMP version 1 was released in 1990 and was quickly adopted by a
number of industries. In 1994, the Intelligent Transportation
Systems (ITS) began to investigate its use, but was concerned about
the overhead requirements that it imposed. As a result, in 1996, the
National Transportation Communications for ITS Protocol (NTCIP)
defined the Transportation Management Protocols.
The Transportation Management Protocols included a triad of
protocols. SNMPv1 was the default protocol with an option to support
the Simple Transportation Management Protocol (STMP) and another
option for Simple Fixed Message Protocol. STMP defined the concept
of dynamic objects coupled with a specialized protocol to exchange
these dynamic objects using a custom message set encoded with a
custom set of ASN.1 encoding rules. SNMPv1 was still used to
configure the dynamic objects, but once configured, the data could be
exchanged using the more encoding efficient STMP. Deployments using
this framework began in the late 1990's and are now common in the
United States and several other countries.
In 2004, several organizations became interested in using dynamic
objects in exception-based reporting (i.e., similar to SNMP traps).
K. Vaughn Expires May 24, 2014 [Page 5]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
While this mechanism was never formally standardized, it has been
deployed by multiple vendors in an interoperable manner.
Over time, OER found a number of other uses in the ITS community,
often being used to formally document message structures in ASN.1
that were previously defined in normal text (often with ambiguities).
Experiments with these encoding rules revealed that they were both
compact for transmission and easier to process than the Packed
Encoding Rules (PER). As a result, OER also began to be used by the
financial services industry and in 2013, ITU-T launched a new work
item to formally define OER as an international standard so that they
would be easier to reference by other groups.
In the meantime, the original SNMP was updated to enhance security,
error reporting, and other features. The updates also developed a
modular architecture to define SNMP frameworks.
There is now active interest in elevating the suite of Transportation
Management Protocols to an international standard for ITS
environments within ISO TC 204; however, the international community
has requested that the international version be based on SNMPv3 and
include security. Upon drafting the international version, it dawned
on us that the resulting protocol is likely applicable to a wide
range of other industries and that it may be appropriate to offer it
as an INTERNET-DRAFT before pursuing as strictly an ITS standard.
CNMP is the result of that update. The updated name reflects the
fact that we believe this protocol is of use in general network
management rather than just for transportation systems. It also
reflects that while not as simple as SNMP, it produced considerably
more condensed encodings.
CNMP attempts to integrate all of these advancements into a complete
solution that can be readily discovered and referenced by any
industry. It:
* Fully conforms to the SNMPv3 framework
* Defines a dynamic object configuration MIB
* Defines dynamic object messages without security for 100%
backwards compatibility with STMP
* Defines dynamic object messages with security
* Defines a GetBulk that can be constrained to a portion of the MIB
* Defines all messages using ASN.1
K. Vaughn Expires May 24, 2014 [Page 6]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
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.
3. Documentation Roadmap
CNMP conforms to the SNMP Management Framework as defined by
[RFC3411] "An Architecture for Describing SNMP Management
Frameworks", [RFC5343] "Simple Network Management Protocol (SNMP)
Context EngineID Discovery", and [RFC5590] "Transport Subsystem for
the Simple Network Management Protocol (SNMP)". The Framework
includes a number of documents, as depicted in the following figure.
The remaining clauses of this INTERNET-DRAFT indicate where each
document in this roadmap is defined.
K. Vaughn Expires May 24, 2014 [Page 7]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
+------------------------- Document Set ----------------------------+
| |
| +----------+ +-----------------+ +----------------+ |
| | Document | | Applicability | | Coexistence | |
| | Roadmap | | Statement | | & Transition | |
| +----------+ +-----------------+ +----------------+ |
| |
| +---------------------------------------------------------------+ |
| | Message Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Transport | | Message | | Security | | |
| | | Mappings | | Processing and | | | | |
| | | | | Dispatcher | | | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | PDU Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Protocol | | Applications | | Access | | |
| | | Operations | | | | Control | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | Information Model | |
| | +--------------+ +--------------+ +---------------+ | |
| | | Structure of | | Textual | | Conformance | | |
| | | Management | | Conventions | | Statements | | |
| | | Information | | | | | | |
| | +--------------+ +--------------+ +---------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | MIB Modules written in various formats, e.g.: | |
| | +----------------+ +----------------+ | |
| | | SMIv1 (STD 18) | | SMIv2 (STD 58) | | |
| | | format | | format | | |
| | +----------------+ +----------------+ | |
| +---------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
3.1. Document Roadmap
Clause 3 of this document defines the Document Roadmap for CNMP. The
Document Roadmap identifies the documents that define the CNMP
Framework when taken together.
K. Vaughn Expires May 24, 2014 [Page 8]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
3.2. Applicability Statement
Clause 4 of this document defines the Applicability Statement for
CNMP. The Applicability Statement describes the environment for
which CNMP was developed.
3.3. Coexistence and Transition
The Coexistence and Transition is defined by [COEX]. The Coexistence
and Transition document describes recommended and required behaviors
for resolving the interactions between models within the
architecture. For example, it describes how MIB views work with CNMP
messages that do not contain any community or security information.
3.4. Transport Mappings
The Transport Mappings are defined by [TRANS]. The Transport
Mappings define how mapping between CNMP and the transport is done.
3.5. Message Processing and Dispatcher
The Message Processing and Dispatcher is defined by [MSG]. The
Message Processing and Dispatching document defines the message
structures used by CNMP and the supporting MIB module.
3.6. Security
CNMP Security is defined by [RFC3414] and [RFC5590]. The Security
model provides message level security for messages that contain
security information.
3.7. Protocol Operations
CNMP Protocol Operations are defined by [PDU]. The Protocol
Operations document defines the syntax and elements of procedure for
sending, receiving, and processing CNMP requests.
3.8. Applications
The Applications document is defined by [RFC3413]. The Applications
document describes five types of applications which make use of a
CNMP engine and a supporting MIB.
3.9. Access Control
CNMP Access Control is defined by [RFC3415]. The Access Control
document defines the elements of procedure for controlling access to
management information. This document also includes a supporting MIB.
K. Vaughn Expires May 24, 2014 [Page 9]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
3.10. Structure of Management Information
The Structure of Management Information is defined by [RFC2578]. The
Structure of Management Information document defines the format of
the MIB modules used in CNMP.
3.11. Textual Conventions
Textual Conventions are defined by [RFC2579]. The Textual
Conventions document defines several data types with more precise
semantics so that these additional semantics can be easily referenced
within other MIBs.
3.12. Conformance Statements
Conformance Statements are defined by [RFC2580]. The Conformance
Statements document defines the notation used to define the minimal
requirements for an implementation to claim conformance to a MIB.
3.13. MIB Modules
CNMP defines several MIB modules within the documents identified
above. In addition, it is expected that most agents will support
other MIB modules that correspond to the core functionality of the
device upon which the CNMP agent resides, however these modules are
beyond the scope of this INTERNET-DRAFT.
4. Applicability Statement
CNMP consists of three major parts: normal requests, dynamic object
requests, and notifications.
4.1. CNMP Normal Requests
CNMP Normal Requests are designed for environments with the following
characteristics:
* The requests (GETs or SETs) are infrequent and/or contained varied
information. Frequent requests containing the same information
are more appropriately handled by CNMP Dynamic Object Requests.
* Available bandwidth on the communications link is a concern. If
there is sufficient bandwidth, SNMPv3 notifications could be used.
4.2. CNMP Dynamic Object Requests
CNMP Dynamic Object Requests are designed for environments with the
following characteristics:
K. Vaughn Expires May 24, 2014 [Page 10]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
* The manager frequently requests (GETs or SETs) the same
information. This is especially true of polling operations or
systems that use centralized second-by-second commands.
* There is only one or a small number of coordinated managers that
need to use dynamic objects. The protocol only supports 13
dynamic objects per agent; thus, if there are multiple managers,
they will need to coordinate on either how these objects are
configured or assign specific dynamic objects to specific
managers. Other managers can still interface with the device with
normal requests.
* Available bandwidth for the communications link is typically
limited. Dynamic objects provide the most condensed form of
messaging offered by CNMP; even links as slow as 1200 bps can
support multiple messages a second using the right lower layers.
Environments that are not constrained by bandwidth may find normal
requests or SNMPv3 easier to implement.
* There is no consensus on the exact contents of the frequently
requested information prior to development. If the contents of
the frequently requested information can be fixed during the
design stage, the complexity of dynamic objects can be avoided
with minimal added overhead. This can be done by defining normal
CNMP/SNMP objects as OCTET STRINGS containing an OER-encoded
structure and then using CNMP Normal Requests to exchange this
data.
4.3. CNMP Notifications
CNMP Notifications are designed for environments with the following
characteristics:
* The manager wishes to monitor data in real-time without constantly
polling the agent.
* The communication network allows different agents to issue
notifications in rapid succession.
* Available bandwidth on the communications link is a concern. If
there is sufficient bandwidth, SNMPv3 notifications could be used.
5. Conformance
CNMP is made up of several features and not all of them are required.
This section precisely defines which components are required and
optional.
K. Vaughn Expires May 24, 2014 [Page 11]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
5.1. Base Conformance
All CNMP implementations SHALL support the CNMPVersionedMessage, as
defined in [MSG] and all components within this structure except for
those explicitly mentioned as being a part of an option defined in
the following clauses.
5.2. Dynamic Objects
A CNMP implementation MAY support dynamic objects. An implementation
supporting dynamic objects SHALL support:
* All of the CHOICE options contained within the CNMPMessage, as
defined in [MSG].
* At least one dynamic object (i.e., dynObjectMaxRows.0 >= 1)
* The dynObjectGroup as defined in [PDU].
* The dynObject option of the ObjectName CHOICE defined in [PDU].
5.3. Default Nodes
A CNMP implementation MAY support default nodes. An implementation
supporting default nodes SHALL support:
* At least one default node (i.e., defaultNodeMaxRows.0 >= 1)
* The "defaultNode" CHOICE options (i.e., as contained within the
ObjectName CHOICE statement defined in [PDU]) that correspond to
the number of default nodes supported (as indicated by
defaultNodeMaxRows.0).
5.4. Agent
A CNMP entity that includes an agent application SHALL support the
CNMP-MPD-MIB as defined in [MSG] and the CNMP-PO-MIB as defined in
[PDU].
A CNMP entity that includes an agent application, as defined by
[RFC3413], SHALL support receiving the following PDUs:
* GetRequest-PDU
* SetRequest-PDU
* SetNoReply-PDU
* GetNextRequest-PDU
* GetBulkRequest-PDU
A CNMP entity that includes an agent application, as defined by
[RFC3413], SHALL support transmitting the following PDUs:
* GetResponse-PDU
* SetResponse-PDU
* ErrorResponse-PDU
If the agent supports dynamic objects, it SHALL support receiving the
K. Vaughn Expires May 24, 2014 [Page 12]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
following CNMPMessage structures:
* GetDynObj#, for the lesser of dynObjectMaxRows.0 or 13
* SetDynObj#, for the lesser of dynObjectMaxRows.0 or 13
* SetNoReplyDynObj#, for the lesser of dynObjectMaxRows.0 or 13
* GetNextDynObj#, for the lesser of dynObjectMaxRows.0 or 13
If the agent supports dynamic objects, it SHALL also support
transmitting the following PDUs:
* GetRespDynObj#, for the lesser of dynObjectMaxRows.0 or 13
* SetRespDynObj#, for the lesser of dynObjectMaxRows.0 or 13
* ErrorRespDynObj#, for the lesser of dynObjectMaxRows.0 or 13
5.5. Manager
A CNMP entity that includes a manager application, as defined by
[RFC3413], SHALL support receiving the following PDUs:
* GetResponse-PDU
* SetResponse-PDU
* ErrorResponse-PDU
A CNMP entity that includes a manager application, as defined by
[RFC3413], SHALL support transmitting the following PDUs:
* GetRequest-PDU
* GetRequest-PDU
* SetNoReply-PDU
* GetNextRequest-PDU
* GetBulkRequest-PDU
If the manager supports dynamic objects, it SHALL support receiving
the following CNMPMessage structures:
* All 13 of the GetRespDynObj# messages
* All 13 of the SetRespDynObj# messages
* All 13 of the ErrorRespDynObj# messages
If the manager supports dynamic objects, it SHALL also support
transmitting the following PDUs:
* All 13 of the GetDynObj# messages
* All 13 of the SetDynObj# messages
* All 13 of the SetNoReplyDynObj# messages
* All 13 of the GetNextDynObj# messages
5.6. Notification Originator
A CNMP entity that includes a notification originator application, as
defined by [RFC3413], SHALL support receiving the InformResponse-PDU.
A CNMP entity that includes a notification originator application, as
defined by [RFC3413], SHALL support transmitting the following PDUs:
K. Vaughn Expires May 24, 2014 [Page 13]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
* InformRequest-PDU
* Trap-PDU
5.7. Notification Receiver
A CNMP entity that includes a notification receiver application, as
defined by [RFC3413], SHALL support receiving the following PDUs:
* InformRequest-PDU
* Trap-PDU
A CNMP entity that includes a notification originator application, as
defined by [RFC3413], SHALL support transmitting the InformResponse-
PDU.
6. Acknowledgements
This protocol is based largely on material contained in [RFC3416] and
[STMP].
K. Vaughn Expires May 24, 2014 [Page 14]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
7. Security Considerations
CNMP offers the same security levels and options as provided by
SNMPv3. For a full discussion of CNMP security issues, see [MSG].
8. IANA Considerations
This document has no IANA actions.
9. References
9.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.
[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.
[MSG] Vaughn, K., "Message Processing for Condensed Network
Management Protocol (CNMP)", draft-vaughn-cnmp-message-00,
November 2013.
[PDU] Vaughn, K., "Protocol Operations for Condensed Network
Management Protocol (CNMP)", draft-vaughn-cnmp-pdu-00,
November 2013.
K. Vaughn Expires May 24, 2014 [Page 15]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
[COEX] Vaughn, K., "Coexistence for Condensed Network Management
Protocol (CNMP)", draft-vaughn-cnmp-coex-00, November
2013.
[TRANS] Vaughn, K., "Transport Mapping for Condensed Network
Management Protocol (CNMP)", draft-vaughn-cnmp-trans-00,
November 2013.
9.2 Informative References
[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.
[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.
[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.
[OER] "Information Technology - ASN.1 encoding rules:
Specification of Octet Encoding Rules (OER)", published by
International Telecommunications Union. Initial Draft
X.oer, January 2014.
Appendix A. Sample Encoding
The following clauses provide examples of encoded CNMP messages and
provides a comparison to SNMP message sizes. In general, CNMP
provides significant savings as follows:
K. Vaughn Expires May 24, 2014 [Page 16]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
* Compared to SNMPv1
- Get/Response pairs are reduced by roughly a third
- Set/Response pairs are reduced by roughly two-thirds
- Frequent requests can be reduced by more than 95%
- Security can be provided as an option
* Compared to SNMPv3
- Get/Response pairs are reduced by 30-60% depending on security
- Set/Response pairs are reduced by more than 50%
- Frequent secure requests can be reduced by two-thirds
- Provides same level of security
A.1. Get Request with No Security
This is a sample GetRequest that might be sent in an environment
where security is provided by other means (e.g., either physically or
by lower layers) and default-level access to the device is
appropriate.
The message totals 40 bytes. The equivalent SNMPv1 message would be
68 bytes and in SNMPv3 it would be 125 bytes.
60 cNMPVersionedMessage
01 msgVersion = 1
msgGlobalData
00 14 msgID = 20
04 00 msgMaxSize = 1024
80 msgSecurityFlags =
report + noAuthNoPriv
00 msgSecurityParameters
1F msgData = 31 bytes
00 contextEngineID
00 contextName (default)
80 data = getRequest
01 03 three items in VarNames
80 08 ObjectName1=fullOid, 8 bytes
2B 06 01 02 01 01 01
00 sysDescr.0
81 ObjectName2=pair
05 2B 06 01 02 01 base = 5 bytes, 1.3.6.1.2.1
03 01 02 00 extension = 3 bytes, 1.2.0
(sysObjectID.0)
82 ObjectName3=extension
03 01 03 00 extension = 3 bytes, 1.3.0
(sysUpTime.0)
A.2. Get Response with No Security
K. Vaughn Expires May 24, 2014 [Page 17]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
This is a sample GetResponse to the sample request in A.1.
The message totals 68 bytes. The equivalent SNMPv1 message would be
91 bytes and in SNMPv3 it would be 148 bytes.
60 cNMPVersionedMessage
01 msgVersion = 1
msgGlobalData
00 14 msgID = 20
04 00 msgMaxSize = 1024
00 msgSecurityFlags = noAuthNoPriv
00 msgSecurityParameters
1F msgData = 40 bytes
00 contextEngineID
00 contextName (default)
C0 data = getResponse
01 03 three items in VarBinds
VarBind1
80 08 name = fullOid of 8 bytes
2B 06 01 02 01 01 01
00 sysDescr.0
04 0D value of 13 bytes
53 61 6D 70 6C 65 20
73 79 73 74 65 6D Sample system
VarBind2
81 name = pair
05 2B 06 01 02 01 base = 5 bytes, 1.3.6.1.2.1
03 01 02 00 extension = 3 bytes, 1.2.0
(sysObjectID.0)
06 08
2B 06 01 04 01 CC 17
01 {enterprises trevilon 1}
VarBind3
82 name = extension
03 01 03 00 extension = 3 bytes, 1.3.0
(sysUpTime.0)
4A value = unsigned short
07 D0 2000
A.3. Set Request with Authentication
This is a sample SetRequest with authentication that configures the
first dynamic object. It is assumed that the dynamic object is in
the 'notInService' state and that it is changed to the 'active' state
prior to use. If DES encryption was used, the message length would
increase by 8 bytes for the 'salt' contained in the
msgPrivacyParameters field.
K. Vaughn Expires May 24, 2014 [Page 18]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
The message totals 142 bytes or roughly 154 bytes with encryption.
The equivalent SNMPv1 message would be 158 bytes (without any real
security) and in SNMPv3 it would be 227 bytes (or 239 with
encryption).
60 cNMPVersionedMessage
01 msgVersion = 1
msgGlobalData
00 15 msgID = 21
04 00 msgMaxSize = 1024
A1 msgSecurityFlags =
report + authNoPriv
29 msgSecurityParameters = 41 bytes
09 80 00 26 17 01 C0 A8 01 0A msgAuthoritativeEngineID
00 00 00 01 msgAuthoritativeEngineBoots
03 02 7B 92 msgAuthoritativeEngineTime
07 6B 76 61 75 67 68 6E msgUserName
0C 0C DF 8B 2A FE 4A C5 4C 33
63 A6 2C C8 msgAuthenticationParameters
00 msgPrivacyParameters
1F msgData = 31 bytes
00 contextEngineID
00 contextName (default)
90 data = setRequest
01 03 three items in VarNames
VarBind1
81 ObjectName = pair
0B 2B 06 01 02 ?? 02
02 01 04 01 02 01 base = dynObjectVariable.1
01 01 extension = .1
(dynObjectVariable.1.1)
06 0F Value = 15 bytes
2B 06 01 04 01 89 36
04 02 01 01 04 01 04
01 phaseStatusGroupGreens.1
VarBind2
82 ObjectName2 = extension
01 02 extension = .2
(dynObjectVariable.1.2)
06 0D Value = 13 bytes
2B 06 01 04 01 89 36
04 02 01 03 05 00 unitControlStatus.0
VarBind3
82 ObjectName3 = extension
01 03 extension = .3
(dynObjectVariable.1.3)
06 0D Value = 13 bytes
2B 06 01 04 01 89 36
K. Vaughn Expires May 24, 2014 [Page 19]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
04 02 01 03 06 00 unitFlashStatus.0
VarBind3
82 ObjectName3 = extension
01 04 extension = .4
(dynObjectVariable.1.4)
06 0D Value = 13 bytes
2B 06 01 04 01 89 36
04 02 01 03 09 00 shortAlarmStatus.0
A.4. Set Response with Authentication
This is a sample SetResponse to the sample request in A.3.
The message totals 53 bytes or roughly 65 bytes with encryption. The
equivalent SNMPv1 message would be 158 bytes (without any real
security) and in SNMPv3 it would be 227 bytes (or 239 with
encryption).
60 cNMPVersionedMessage
01 msgVersion = 1
msgGlobalData
00 15 msgID = 21
04 00 msgMaxSize = 1024
21 msgSecurityFlags =
authNoPriv
29 msgSecurityParameters = 41 bytes
09 80 00 26 17 01 C0 A8 01 0A msgAuthoritativeEngineID
00 00 00 01 msgAuthoritativeEngineBoots
03 02 7B 92 msgAuthoritativeEngineTime
07 6B 76 61 75 67 68 6E msgUserName
0C 0C DF 8B 2A FE 4A C5 4C 33
63 A6 2C C8 msgAuthenticationParameters
00 msgPrivacyParameters
03 msgData = 03 bytes
00 contextEngineID
00 contextName (default)
D0 data = setResponse
A.5. Get Dynamic Object without Security
The following provides an example response for the request in A.5.
The message totals 1 byte. The equivalent SNMPv1 message would be 106
bytes and in SNMPv3 it would be 163 bytes.
K. Vaughn Expires May 24, 2014 [Page 20]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
81 CNMPMessage = getDynObj1
A.6. Get Response for Dynamic Object without Security
The following provides an example response for the request in A.5.
The message totals 5 bytes. The equivalent SNMPv1 message would be
110 bytes and in SNMPv3 it would be 167 bytes.
C1 CNMPMessage = getRespDynObj1
22 phaseStatusGroupGreens.1 = Phases 2&6
02 unitControlStatus.0 = systemControl
02 unitFlashStatus.0 = noFlash
00 shortAlarmStatus.0 = no alarms
A.7. Get Dynamic Object with Security
The following provides an example response for the request in A.5.
The message totals 58 bytes or roughly 60 bytes with encryption. The
equivalent SNMPv1 message would be 106 bytes (without any real
security) and in SNMPv3 it would be 175 bytes (or 187 with
encryption).
60 cNMPVersionedMessage
01 msgVersion = 1
msgGlobalData
00 16 msgID = 22
04 00 msgMaxSize = 1024
A1 msgSecurityFlags =
report + authNoPriv
29 msgSecurityParameters = 41 bytes
09 80 00 26 17 01 C0 A8 01 0A msgAuthoritativeEngineID
00 00 00 01 msgAuthoritativeEngineBoots
03 02 7B 92 msgAuthoritativeEngineTime
07 6B 76 61 75 67 68 6E msgUserName
0C 0C DF 8B 2A FE 4A C5 4C 33
63 A6 2C C8 msgAuthenticationParameters
00 msgPrivacyParameters
08 msgData = 08 bytes
00 contextEngineID
00 contextName (default)
80 data = getRequest
01 01 VarNames = 1 item
83 01 ObjectName1=dynObject, 1 byte
01 dynObjectValue.1
K. Vaughn Expires May 24, 2014 [Page 21]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
A.8. Get Response for Dynamic Object with Security
The following provides an example response for the request in A.5.
The message totals 64 bytes or roughly 76 bytes with encryption. The
equivalent SNMPv1 message would be 110 bytes (without any real
security) and in SNMPv3 it would be 179 bytes (or 191 with
encryption).
60 cNMPVersionedMessage
01 msgVersion = 1
msgGlobalData
00 16 msgID = 22
04 00 msgMaxSize = 1024
21 msgSecurityFlags =
authNoPriv
29 msgSecurityParameters = 41 bytes
09 80 00 26 17 01 C0 A8 01 0A msgAuthoritativeEngineID
00 00 00 01 msgAuthoritativeEngineBoots
03 02 7B 92 msgAuthoritativeEngineTime
07 6B 76 61 75 67 68 6E msgUserName
0C 0C DF 8B 2A FE 4A C5 4C 33
63 A6 2C C8 msgAuthenticationParameters
00 msgPrivacyParameters
0E msgData = 14 bytes
00 contextEngineID
00 contextName (default)
C0 data = getResponse
01 01 VarBinds = 1 item
VarBind1
83 01 ObjectName=dynObject, 1 byte
01 dynObjectValue.1
04 04 Value = string-value 4 bytes
22 phaseStatusGroupGreens.1
02 unitControlStatus.0
02 unitFlashStatus.0
00 shortAlarmStatus.0
A.9. GetBulk PDU for Table Retrieval
The following provides an example of retrieving the udpEndpointTable.
When encapsulated within a message, the CNMP packet would be roughly
67 bytes with authentication and 79 bytes with encryption. There is
no direct parallel of this request in SNMPv1. The GetBulk in SNMPv3
also would not serve as a parallel as it would return entries beyond
the end of the table and there is no way to limit the results to just
K. Vaughn Expires May 24, 2014 [Page 22]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
what is in the table in SNMPv3.
F0 data = getBulkRequest
00 non-repeaters = 0
0A max-repetitions = 10
01 01 variables = 1 entry
81 pair
07 2B 06 01 02 01 07 07 base = udpEndpointTable
00 extension = 0 length
A.10. GetResponse PDU for Table Retrieval
The following provides an example response for the request in A.5.
When encapsulated within a message, the CNMP packet would be roughly
165 bytes with authentication and 177 bytes with encryption.
C0 data = getResponse
01 02 variables = 2 items
VarBind1
81 ObjectName = pair
07 2B 06 01 02 01 07 07 base = udpEndpointTable
2C extension = LL bytes
01 08 udpEndpointProcess
02 index1 = localAddrType = 2
10 20 01 0D B8 00 00
00 00 00 00 00 00 00 index2 = localAddr =
00 41 7A 2001:DB8::417A
AC 33 index3 = localPort = 5683
02 index4 = remoteAddrType = 2
10 20 01 0D B8 00 00
00 00 00 00 00 00 00 index5 = remoteAddr =
00 59 C1 2001:DB8::59C1
BE 40 index6 = remotePort = 8000
87 06 54 5F index7 = instance = 14789215
42 03 AB 85 8D Value = ulong = 61572493
VarBind1
81 ObjectName = extension
2C extension = LL bytes
01 08 udpEndpointProcess
02 index1 = localAddrType = 2
10 20 01 0D B8 00 00
00 00 00 00 00 00 00 index2 = localAddr =
00 41 7A 2001:DB8::417A
AC 33 index3 = localPort = 5683
02 index4 = remoteAddrType = 2
K. Vaughn Expires May 24, 2014 [Page 23]
INTERNET DRAFT Document Roadmap for CNMP November 20, 2013
10 20 01 0D B8 00 00
00 00 00 00 00 00 00 index5 = remoteAddr =
00 59 C1 2001:DB8::59C1
BE 40 index6 = remotePort = 8000
87 06 54 5F index7 = instance = 14789215
82 Value = endOfMibView
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
Transcore, LP
192 Technology Parkway
Suite 500
Norcross, GA 30092
Email: robert.rausch@transcore.com
K. Vaughn Expires May 24, 2014 [Page 24]
