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]