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]