Internet DRAFT - draft-vaughn-cnmp-coex

draft-vaughn-cnmp-coex



 



INTERNET-DRAFT                                                 K. Vaughn
Intended Status: Standards Track                            Trevilon LLC
Expires: May 24, 2014                                         A. Triglia
                                                       OSS Nokalva, Inc.
                                                               R. Rausch
                                                           Transcore, LP
                                                       November 20, 2013

  Coexistence between Condensed Network Management Protocol (CNMP) and
             the Simple Network Management Protocol (SNMP)
                       draft-vaughn-cnmp-coex-00

Abstract

   The purpose of this document is to describe coexistence between the
   Condensed Network Management Protocol (CNMP) and the various versions
   of the Simple Network Management Protocol (SNMP). 

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
 


K. Vaughn                 Expires May 24, 2014                  [Page 1]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  MIB Modules  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Translating Notification Parameters  . . . . . . . . . . . . .  3
   5.  Approaches to Coexistence in a Multi-lingual Network . . . . .  3
     5.1.  Access to MIB Data . . . . . . . . . . . . . . . . . . . .  4
     5.2.  Multi-lingual implementations  . . . . . . . . . . . . . .  4
       5.2.1.  Command Generator  . . . . . . . . . . . . . . . . . .  4
       5.2.2.  Command Responder  . . . . . . . . . . . . . . . . . .  4
         5.2.2.1.  Integer Encoding . . . . . . . . . . . . . . . . .  4
         5.2.2.2.  New Structures . . . . . . . . . . . . . . . . . .  4
       5.2.3.  Notification Originator  . . . . . . . . . . . . . . .  5
       5.2.4.  Notification Receiver  . . . . . . . . . . . . . . . .  5
     5.3.  Proxy Implementations  . . . . . . . . . . . . . . . . . .  5
       5.3.1.  CNMP Upstream and SNMP Downstream  . . . . . . . . . .  5
         5.3.1.1.  Dynamic Object Messages  . . . . . . . . . . . . .  5
         5.3.1.2.  Other Messages . . . . . . . . . . . . . . . . . .  5
       5.3.2.  CNMP Downstream and SNMP Upstream  . . . . . . . . . .  8
         5.3.2.1.  Dynamic Objects  . . . . . . . . . . . . . . . . .  8
         5.3.2.2.  Other Messages . . . . . . . . . . . . . . . . . .  8
     5.4.  Error Status Mappings  . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 12
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13













 


K. Vaughn                 Expires May 24, 2014                  [Page 2]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


1.  Introduction

   The purpose of this document is to describe coexistence between the
   Condensed Network Management Protocol (CNMP) and the Simple Network
   Management Protocol (SNMP).  For a complete overview of CNMP, see
   [Intro].

   There are four general aspects of coexistence described in this
   document.  Each of these is described in a separate section:

   -  Conversion of MIB documents between SMIv1 and SMIv2 formats is
      documented in section 3.

   -  Mapping of notification parameters is documented in section 4.

   -  Approaches to coexistence between CNMP and SNMP entities in a
      multi-lingual network is documented in section 5.  This section
      addresses the processing of protocol operations in multi-lingual
      implementations, as well as behaviour of proxy implementations.

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.  MIB Modules

   MIB modules defined using the SMIv1 may continue to be used with
   CNMP, once they are updated to the SMIv2 format according to the
   rules defined in Clause 2 of [RFC3584].

4.  Translating Notification Parameters

   CNMP Notifications use the same format as SNMPv2 and SNMPv3. SNMPv1
   notification parameters can between this format and SNMPv1 according
   to the rules defined in Clause 3 of [RFC3584].

5.  Approaches to Coexistence in a Multi-lingual Network

   This document defines how to translate between CNMP and SNMPv3.
 


K. Vaughn                 Expires May 24, 2014                  [Page 3]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


   Messages can be further translated to SNMPv2 or SNMPv1 according to
   the rules defined in [RFC3584].

5.1.  Access to MIB Data

   The part of a CNMP agent which actually accesses instances of MIB
   objects and which actually initiates generation of notifications
   SHALL be identical to SNMPv2 Access to MIB Data.  The conversion
   between this access and SNMPv1 Access to MIB Data SHALL be as defined
   in [RFC3584].

5.2.  Multi-lingual implementations

   A multi-lingual implementation SHALL conform to the following rules.

5.2.1.  Command Generator

   A command generator SHALL select an appropriate message version when
   sending requests to another entity.  One way to achieve this is to
   consult a local database to select the appropriate message version.

   In addition, a command generator SHALL 'downgrade' GetBulk requests
   to GetNext requests when selecting SNMPv1 as the message version for
   an outgoing request.  This is done by simply changing the operation
   type to GetNext, ignoring any non-repeaters and max-repetitions
   values, and setting error-status and error-index to zero.

5.2.2.  Command Responder

   A command responder SHALL follow the same rules as defined in Clause
   4.2.2 of [RFC3584] with CNMP being treated as another message format
   for SNMPv2 Access to MIB Data, with the following additional rule:

5.2.2.1.  Integer Encoding

   When converting a CNMP ObjectValue which is a byte, short, long,
   ubyte, or ushort to SNMP, the value SHALL be encoded as an SNMP
   integer-value.  

   When converting an SNMP integer-value to CNMP, the value SHALL be
   encoded according to the rules defined in Clause 5.2.2. of [PDU]. 

5.2.2.2.  New Structures

   Structures that are new to CNMP do not need to be converted.  For
   example, a GetDynObjX structure can only be generated by CNMP
   manager.  If the agent does not support CNMP, it will ignore the
   request.  A CNMP agent will never receive a GetDynObjX structure from
 


K. Vaughn                 Expires May 24, 2014                  [Page 4]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


   a known SNMP version.  Thus, no conversion rules are necessary.

5.2.3.  Notification Originator

   A notification originator SHALL follow the same rules as defined in
   Clause 4.2.2 of [RFC3584] with CNMP being treated as another message
   format for SNMPv2 Access to MIB Data.

5.2.4.  Notification Receiver

   There are no special requirements of a notification receiver.

5.3.  Proxy Implementations

   A proxy implementation may be used to enable communication between
   one entity that only supports CNMP and another entity that only
   supports SNMP.  This is accomplished in a proxy forwarder application
   by performing translations on messages.  The following sections
   describe the translations between CNMP and SNMPv3; the rules defined
   in Clause 4.3 of [RFC3584] MAY be used to further translate to any
   older version of SNMP.  

   In the following sections, the 'Upstream' refers to the link between
   the command generator or notification receiver and the proxy, and
   'Downstream' refers to the link between the proxy and the command
   responder or notification originator, regardless of the PDU type or
   direction.

   NOTE: The proxy may change the port number used for the exchanges in
   a implementation dependent manner.

5.3.1.  CNMP Upstream and SNMP Downstream

5.3.1.1.  Dynamic Object Messages

   If a Dynamic Object Class PDU (a.k.a. a Simple Transportation
   Management Protocol [STMP] message) is received, the proxy SHALL
   forward the received message without change.  

5.3.1.2.  Other Messages

   If a Normal Object Class PDU is received, the proxy SHALL attempt to
   translate and forward the received message according to the following
   rules.

5.3.1.2.1.  Caching

   If the proxy receives an Confirmed Class PDU, the proxy SHALL cache
 


K. Vaughn                 Expires May 24, 2014                  [Page 5]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


   the following information:
   * pduType
   * msgID 
   * request-id, if present
   * variable bindings, if present

   The proxy may clear messages from the cache in an implementation
   dependent manner.

5.3.1.2.2.  msgVersion

   The msgVersion field SHALL be changed to indicate the appropriate
   version for the translated message.

5.3.1.2.3.  msgID

   If the proxy receives a message containing an InformResponse-PDU from
   the Upstream entity, the proxy SHALL search its cache for a pduType
   of InformRequest-PDU and a msgID where the lowest 16-bits match the
   value of the incoming msgID.  The proxy SHALL forward the cached
   value of msgID.

   For all other messages, the msgID SHALL be truncated to a 16-bit
   unsigned value before forwarding.  

5.3.1.2.4.  msgMaxSize

   If the msgMaxSize value is greater than 65535, the forwarded
   msgMaxSize SHALL be 65535; otherwise, the msgMaxSize value shall be
   forwarded unchanged.

5.3.1.2.5.  msgFlags

   The msgFlags shall be forwarded unchanged.

5.3.1.2.6.  msgSecurityModel

   The msgSecurityModel shall be translated in an implementation
   dependent manner. 

5.3.1.2.7.  msgSecurityParameters

   The msgSecurityParameters shall be updated according to the selected
   msgFlags, i.e., authenticated and encrypted messages will be 1)
   authenticated, 2) unencrypted, 3) translated, 4) re-encrypted, and 5)
   re-authenticated.

5.3.1.2.8.  contextEngineID
 


K. Vaughn                 Expires May 24, 2014                  [Page 6]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


   The contextEngineID, if present, shall be forwarded unchanged.  If
   the contextEngineID is absent, the proxy SHALL determine the default
   contextEngineID in an implementation dependent manner and forward
   that value.

5.3.1.2.9.  contextName

   The contextName, if present, shall be forwarded unchanged.  If the
   contextName is absent, the proxy SHALL determine the default
   contextName in an implementation dependent manner and forward that
   value.

5.3.1.2.10.  request-id

   If the proxy receives a message containing an InformResponse-PDU from
   the Upstream entity, the proxy SHALL search its cache for a pduType
   of InformRequest-PDU and a msgID where the lowest 16-bits match the
   value of the incoming msgID.  The proxy SHALL forward the cached
   value of request-id.

   For any other message received from the Upstream entity, the request-
   id in the Downstream message SHALL be the same as the msgID contained
   in the Upstream message.

   For any message received from the Downstream entity, the request-id
   value SHALL NOT be forwarded.

5.3.1.2.11.  PDU Translations

   1) If the proxy receives a message containing a Response-PDU from the
      Downstream entity, the proxy SHALL search its cache for a msgID
      that matches the value of the incoming msgID.

      a) If a match is not found, the proxy SHALL NOT forward the
         message and processing of the message is complete.

      b) If the pduType of the cached message is SetNoReply-PDU, the
         proxy SHALL NOT forward the message and processing of the
         message is complete.

      c) If the received message contains a non-zero error-status value,
         the proxy SHALL forward the error-status value and error-index
         value in an ErrorResponse-PDU.  The errorVariable SHALL be set
         to "null" (0.0), if the error-index is zero; otherwise, it
         SHALL be set to the referenced ObjectName.

      d) Otherwise, if the pduType of the cached message is a
         SetRequest-PDU, the proxy SHALL forward a SetResponse-PDU.  
 


K. Vaughn                 Expires May 24, 2014                  [Page 7]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


      e) Otherwise, the proxy SHALL forward a GetResponse-PDU containing
         the variable bindings in the received message.  

         i) The proxy SHALL attempt to translate the ObjectName into the
            form used in the matched request.  If any error occurs in
            this process, the forwarded message SHALL directly forward
            the ObjectName by using the fullOID form.

         ii)The proxy SHALL translate integer-values according to the
            rules in 5.2.2.1.

      f) Otherwise, the message SHALL NOT be forwarded.

   2) If the proxy receives a message containing a Notification Class
      PDU from the Downstream entity, the proxy SHALL forward the
      translated PDU contents.

   3) If the proxy receives a message containing a Read Class or a Write
      Class PDU from the Upstream entity, the proxy SHALL forward the
      translated PDU contents.

      a) CNMP PDUs SHALL map to their corresponding SNMP PDU, with the
         exception that a CNMP SetNoReply-PDU SHALL map to an SNMP
         SetRequest-PDU.

      b) Missing ObjectValue fields from CNMP Read Class PDUs SHALL be
         replaced with NULL values (i.e., the unSpecified encoding
         option).

   4) If the proxy receives a message containing an InformResponse-PDU
      from the Upstream entity, the proxy SHALL forward the translated
      PDU contents as a Response-PDU filling in the variable-bindings
      field based on the cached information.

5.3.2.  CNMP Downstream and SNMP Upstream

5.3.2.1.  Dynamic Objects

      If a Dynamic Object Class PDU (a.k.a. a Simple Transportation
      Management Protocol [STMP] message) is received, the proxy SHALL
      forward the received message without change.  

5.3.2.2.  Other Messages

      If a Normal Object Class PDU is received, the proxy SHALL attempt
      to translate and forward the received message according to the
      following rules.

 


K. Vaughn                 Expires May 24, 2014                  [Page 8]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


5.3.2.2.1.  Caching

      If the proxy receives an Confirmed Class PDU, the proxy SHALL
      cache the following information:
      * pduType
      * msgID 
      * request-id, if present
      * variable bindings, if present

      The proxy may clear messages from the cache in an implementation
      dependent manner.

5.3.2.2.2.  msgVersion

      The msgVersion field SHALL be changed to indicate the appropriate
      version for the translated message.

5.3.2.2.3.  msgID

      If the proxy receives a message containing an Response Class PDU
      from the Downstream entity, the proxy SHALL search its cache for a
      Read or Write Class PDU with a msgID where the lowest 16-bits
      match the value of the incoming msgID.  The proxy SHALL forward
      the cached value of msgID.

      For all other messages, the msgID SHALL be truncated to a 16-bit
      unsigned value before forwarding.  

5.3.2.2.4.  msgMaxSize

      If the msgMaxSize value is greater than 65535, the forwarded
      msgMaxSize SHALL be 65535; otherwise, the msgMaxSize value shall
      be forwarded unchanged.

5.3.2.2.5.  msgFlags

      The msgFlags shall be forwarded unchanged.

5.3.2.2.6.  msgSecurityModel

      The msgSecurityModel shall be translated in an implementation
      dependent manner. 

5.3.2.2.7.  msgSecurityParameters

      The msgSecurityParameters shall be updated according to the
      selected msgFlags, i.e., authenticated and encrypted messages will
      be 1) authenticated, 2) unencrypted, 3) translated, 4) re-
 


K. Vaughn                 Expires May 24, 2014                  [Page 9]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


      encrypted, and 5) re-authenticated.

5.3.2.2.8.  contextEngineID

      The contextEngineID, if present, shall be forwarded unchanged.  If
      the contextEngineID is absent, the proxy SHALL determine the
      default contextEngineID in an implementation dependent manner and
      forward that value.

5.3.2.2.9.  contextName

      The contextName, if present, shall be forwarded unchanged.  If the
      contextName is absent, the proxy SHALL determine the default
      contextName in an implementation dependent manner and forward that
      value.

5.3.2.2.10.  request-id

      If the proxy receives a message containing an Response Class PDU
      from the Downstream entity, the proxy SHALL search its cache for a
      Read or Write Class PDU with a msgID where the lowest 16-bits
      match the value of the incoming msgID.  The proxy SHALL forward
      the cached value of request-id.

      For any other message received from the Downstream entity, the
      request-id in the Upstream message SHALL be the same as the msgID
      contained in the Downstream message.

      For any message received from the Upstream entity, the request-id
      value SHALL NOT be forwarded.

5.3.2.2.11.  PDU Translations

   1) If the proxy receives a message containing a Read Class or a Write
      Class PDU from the Upstream entity, the proxy SHALL forward the
      translated PDU contents.  

      a) The proxy MAY use more compact forms to encode the ObjectName.

         b) The proxy SHALL translate integer-values according to the
         rules in 5.2.2.1.

   2) If the proxy receives a message containing an Response-PDU from
      the Upstream entity, the proxy SHALL search its cache for a msgID
      that matches the value of the incoming msgID.

      a) If a match is not found, the proxy SHALL NOT forward the
         message and processing of the message is complete.
 


K. Vaughn                 Expires May 24, 2014                 [Page 10]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


      b) If the pduType of the cached message is InformRequest-PDU, the
         proxy SHALL forward the translated PDU contents as a
         InformResponse-PDU.  

      c) Otherwise, the proxy SHALL NOT forward the message and
         processing of the message is complete.

   3) If the proxy receives a message containing a Response Class PDU
      from the Downstream entity, the proxy SHALL search its cache for a
      Read or Write Class PDU with a msgID where the lowest 16-bits
      match the value of the incoming msgID.  

      a) If a match is not found, the proxy SHALL NOT forward the
         message and processing of the message is complete.

      b) If the received message contains an ErrorResponse-PDU, the
         proxy SHALL forward the error-status value and error-index
         value in an Response-PDU.  The proxy SHALL include the
         variable-bindings information from the cache.

      c) Otherwise, if the received message contains an SetResponse-PDU,
         the proxy SHALL forward a Response-PDU.  The proxy SHALL
         include the variable-bindings information from the cache.

      d) Otherwise, if the received message contains an GetResponse-
         PDU,the proxy SHALL forward a Response-PDU containing the
         information from the VarBinds.  

         i) The proxy SHALL translate all ObjectNames into their full
            OIDs.

         ii)The proxy SHALL translate long, short, byte, ubyte, and
            ushort values to integer-values.

      f) Otherwise, the message SHALL NOT be forwarded.

   4) If the proxy receives a message containing a Notification Class
      PDU from the Downstream entity, the proxy SHALL forward the
      translated PDU contents.

5.4.  Error Status Mappings

      All error codes SHALL be passed without translation, with the
      exception of the following CNMP error codes that do not exist in
      SNMPv3.  These error codes SHALL be translated as follows.



 


K. Vaughn                 Expires May 24, 2014                 [Page 11]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


            CNMP error-status      SNMPv3 error-status
            ===================    ===================
            invalidName            inconsistentName
            processTimeout         resourceUnavailable

6.  Security Considerations

   Security issues for each protocol are defined within the context of
   each protocol definition.  When protocols co-exist, the security of
   the system will be defined by the weakest link in the system.

   It is recommended that the implementors consider the security
   features as provided by the CNMP and SNMPv3 framework.  Specifically,
   the use of the User-based Security Model STD 62, RFC 3414 [RFC3414],
   the Transport Security Model [RFC5590], and the View-based Access
   Control Model STD 62, RFC 3415 [RFC3415] is recommended.

   It is then a customer/user responsibility to ensure that the entity
   giving access to a MIB is properly configured to give access to the
   objects only to those principals (users) that have legitimate rights
   to indeed GET or SET (change) them.

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1  Normative References
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC3584]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
              "Coexistence between Version 1, Version 2, and Version 3
              of the Internet-standard Network Management Framework",
              BCP 74, RFC 3584, August 2003.

   [RFC5590]  Harrington, D. and J. Schoenwaelder, "Transport Subsystem
              for the Simple Network Management Protocol (SNMP)",
 


K. Vaughn                 Expires May 24, 2014                 [Page 12]

INTERNET DRAFT         Document Roadmap for CNMP       November 20, 2013


              RFC 5590, June 2009.

   [PDU]      Vaughn, K., "Protocol Operations for Condensed Network
              Management Protocol (CNMP)", Internet-Draft draft-vaughn-
              cnmp-pdu-00, November 2013.

8.2  Informative References

   [Intro]    Vaughn, K., "Document Roadmap for Condensed Network
              Management Protocol (CNMP)", Internet-Draft draft-vaughn-
              cnmp-intro-00, November 2013.

   [STMP]     "Transport Management Protocols", published by American
              Association of State Highway Officials (AASHTO), Institute
              of Transportation Engineers (ITE), and National Electrical
              Manufacturers Association (NEMA). NTCIP (National
              Transportation Communications for ITS Protocol)
              1103v02.17, July 2010.

Authors' Addresses 

   Kenneth Vaughn
   Trevilon LLC
   6606 FM 1488 RD
   STE 148-503
   Magnolia, TX 77316
   USA

   Phone: +1-571-331-5670
   Email: kvaughn@trevilon.com

   Alessandro Triglia
   OSS Nokolva, Inc.
   1 Executive Drive
   Suite 450
   Somerset, NJ 08873

   Email: sandro@oss.com

   Robert Rausch
   Transcore, LP
   192 Technology Parkway
   Suite 500
   Norcross, GA 30092

   Email: robert.rausch@transcore.com





K. Vaughn                 Expires May 24, 2014                 [Page 13]