How Free is Open-Source Software?

I recently discussed an interesting issue with a long term client:  Why should we pay recurring royalty fees to a commercial software vendor when we could replace the commercial software subsystem used in our product with free open-source software?

A previous post, Commercial or Open-Source Software?  Lowering the Cost of SNMP Applications Development, reviewed the “build or buy” analysis from a green fields perspective, when the initial development of an SNMP application is the focus and concern.

But what about a long time fielded product?   Sure it is always good to eliminate a recurring expense, but what is the real cost to replace working SNMP Agent code with new code based upon open-source software?

Are you prepared for substantial development costs?  An SNMP Agent development kit, commercial or open-source,  provides the core agent functions and an API for implementing the MIB modules appropriate to an internet enabled device or service.  Different development kits, different APIs.

Be prepared to port or migrate your existing MIB code to use the new API.  The ‘method’ routines comprise the code that is generated by the MIB compiler and interface with the developers’ kit API.   If the existing code has separate  ‘instrumentation’ routines, the code for retrieving and setting actual system dependent values, then most or all of the instrumentation code can be ported more easily than instrumentation code that was originally placed directly into the generated method code.

If  we are talking about an embedded, memory constrained device, then we need to consider any additional memory budget required by the open-source software.  Will a hardware change be required to increase flash memory capacity to accommodate the new code?  How does the potential recurring cost of this additional hardware part compare with the existing recurring cost for software royalties?  If the costs are similar, the obvious decision is to continue to pay royalties.

Let us be aware that changing a software subsystem within a fielded product will incur additional costs for software quality assurance activities as well as incur additional costs for ongoing maintenance to remedy software defects reported by QA and customers.

As we add up the costs necessary to move to “free” open-source software, we can make a quantifiable comparison:  How many units of royalty will it take before we break even on new development and maintenance costs?  For an established product line, we are able to convert the count of units into a time duration representing a payback period.  Any payback period longer than five to seven years is probably not attractive enough to make the switch to open-source from commercial software.

One final point to consider: Is it a viable alternative to approach the commercial software vendor and buy out the recurring royalties?  A buy out may be considerably less than the estimated cost of converting to open-source software.

Over the past 20+ years I have gained experience with the best commercial and open-source SNMP developers’ kits.  Please contact me and start a conversation about your project needs.  And, be sure to use Ellison Software Consulting to bring value to your SNMP enabled product designs!

 

 

 

 

Leave a Comment

Virtual Machine Software Development Environments

As a software consultant, I see a variety of client requirements regarding software development environments. As recently as a two years ago, a new client project often translated into obtaining new hardware to host a dedicated OS for the desired software development environment.

With newer chipsets now implementing support for virtualization, the age of physical machines is in decline and the age of virtual machines rises towards prominent use.

From my investigation of and experimentation with various Virtual Machine (VM) distributions, my opinions and preferences follow:

  • I prefer using either 32-bit or 64-bit Linux host Operating Systems (OSes)
  • I think that Oracle’s Virtual Box (VB) builds smaller virtual disks than does VMWare Player
  • It appears that VB is more memory efficient and guest OSes run faster in VB than with VMWare Player
  • I am more comfortable with the VBoxManage utility than the equivalent VMWare utility
  • VB is free!  With VMWare, improved capabilities and performance require purchasing another VMWare product

As you can see, the above points express a strong preference for Oracle’s Virtual Box distribution.

There are a number of pre-built virtual disks that can be used as the basis for VM guest OSes and it is a simple and easy task to build your own virtual disk for Linux or for Microsoft OSes.

While I wish all software development could be accomplished using Linux alone, the reality is that many embedded development environments require one or another Microsoft OS.  Fortunately, since I have a set of DVDs from an old Microsoft MSDN subscription, I am able to create Windows XP guest OSes to host the various embedded developer tools as well as Ubuntu guest OSes for similar purposes.

Even though Microsoft licensing permits me to build a guest OS from an OEM version of any of its OSes, I must run only one copy exclusively on the machine upon which it was originally installed.  Unfortunately, the ever vigilant “Genuine Microsoft” utility eventually decides the guest OEM OS is “not genuine” and prompts for reactivation.  Of course, reactivation requires a 25 character UUID that is not provided with the OEM OS.

Since there is a UUID associated with the MSDN subscription, reactivation is not an issue, but remember- I can only use an MSDN OS for development purposes.  Not that I want to, but if I find I really need another Microsoft OS for development purposes, I could purchase an OS only MSDN subscription (at time of publication around $700).  Alternatively, I could purchase a Microsoft OS in a full retail box for less than the OS MSDN subscription, but Microsoft licensing limits my use of a retail box to a single instance of a guest OS.  This instance of the guest OS can be migrated from one host OS and hardware to another as needed.  In addition to software development tools, I can run any compatible software I like inside a guest VM created from a retail box OS.

Of course such complexities and considerations exist with Microsoft OSes only, not with Linux guest OSes.  Unfortunately, until such time as all development and application software run on a native Linux distribution, I must play by the appropriate licensing rules.

If you find this information helpful, please let me know…and if you have interesting insights to share about VMs for software development, please do!

Leave a Comment

Work-in-Progress: Current IETF Activity Related to Network and Service Management

Updated on Friday 11 February 2010

I am often asked, “What Internet-Drafts on network and services management are IETF working groups developing?”.  The following provides a brief outline of and links to the current works-in-progress.

Note that Internet-Drafts are works-in-progress and expire when a subsequent revision is available, or six months after initial publication, whichever occurs first.

I am happy to discuss the usefulness and applicability of the below works-in-progress to your project.  Just contact me with your project requirements and ideas.


Within the Security Area:

  • Integrated Security Model for SNMP Working Group (isms)
    *The ISMS working group is now concluded*
    The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model.

    Current RFCs include:

    • Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings
      RFC6065 – December 2010
    • Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
      RFC5953 – August 2010
    • Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models
      RFC5608 – August 2009
    • Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
      RFC5592 – June 2009
    • Transport Subsystem for the Simple Network Management Protocol (SNMP
      RFC5591 – June 2009
    • Transport Subsystem for the Simple Network Management Protocol (SNMP)
      RFC5590 – June 2009


Within the Operations and Management Area:

  • Network Configuration Working Group (netconf)
    The NETCONF Working Group is chartered to produce a protocol suitable for network configuration. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications.

    Current Internet-Drafts include:

    Current RFCs include:

    • Partial Lock Remote Procedure Call (RPC) for NETCONF
      RFC5717 – December 2009
    • NETCONF over Transport Layer Security (TLS)
      RFC5539 – May 2009
    • Experience of Implementing NETCONF over SOAP
      RFC5381 – October 2008
    • NETCONF Event Notifications
      RFC5277 – July 2008
    • Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)
      RFC4744 – December 2006
    • Using NETCONF over the Simple Object Access Protocol (SOAP)
      RFC4743 – December 2006
    • Using the NETCONF Configuration Protocol over Secure Shell (SSH)
      RFC4742 – December 2006
    • NETCONF Configuration Protocol
      RFC4741 – December 2006

  • NETCONF Data Modeling Language Working Group (netmod)
    The NETMOD Working Group will define a “human-friendly” modeling language defining the semantics of operational data, configuration data, notifications, and operations.

    Current Internet-Drafts include:

  • Current RFCs include:

    • Guidelines for Authors and Reviewers of YANG Data Model Documents
      RFC6087 – January 2011
    • Common YANG Data Types
      RFC6021 – October 2010
    • YANG – A data modeling language for NETCONF
      RFC6020 – October 2010

  • Operations and Management Area Working Group (opsawg)

    The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group.

    Current Internet-Drafts include:

    Current RFCs include:

    • Expressing SNMP SMI Datatypes in XML Schema Definition Language
      RFC5935 – October 2010
    • Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
      RFC5675 – October 2009
    • Alarms in Syslog
      RFC5674 – October 2009
    • Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions
      RFC5706 – November 2009
    • Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
      RFC5345 – October 2008
    • Simple Network Management Protocol (SNMP) Context EngineID Discovery
      RFC5343 – September 2008 (Updates RFC3411 )


Individual Submissions:

Management Information Base (MIB) modules are designed within the applicable protocol working group and is the topic of another article.

I am happy to discuss the usefulness and applicability of the above works-in-progress to your project. Just contact me with your project parameters and idea.

Leave a Comment

Work-in-Progress: Current IETF Activity Related to MIB Modules

Updated on Thursday 10 February 2011

I am often asked, “What MIB modules are IETF working groups developing?”. MIB modules are defined within the relevant working group and reviewed by a small cadre of IETF MIB doctors prior to publication as an RFC. The following provides a brief outline of and links to the current works-in-progress.

Note that Internet-Drafts are works-in-progress and expire when a subsequent revision is available, or six months after initial publication, whichever occurs first.

I am happy to discuss the usefulness and applicability of the below works-in-progress to your project. Just contact me with your project requirements and ideas.


Operations and Management Area:


Internet Area:

  • Pseudowire Emulation Edge to Edge (pwe3)
    • SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2
      draft-ietf-pwe3-cep-mib-14” – 18-Jan-11


Routing Area:

  • Bidirectional Forwarding Detection (bfd)
    • Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management
      draft-ietf-bfd-tc-mib-00” – 7-Sep-10

  • Inter-Domain Routing (idr)
    • Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version
      draft-ietf-idr-bgp4-mibv2-11” – 17-Jan-11
    • Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4)
      draft-ietf-idr-bgp4-mibv2-tc-mib-02” – 17-Jan-11


Individual Submissions:


Recently Published RFCs:

  • Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
    RFC5907 – June 2010
  • Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11
    RFC5834 – May 2010
  • Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB
    RFC5833 – May 2010
  • Definitions of Managed Objects for IP Flow Information Export
    RFC5815 – April 2010
  • Forwarding and Control Element Separation (ForCES) MIB
    RFC5813 – March 2010
  • The SatLabs Group DVB-RCS MIB
    RFC5728 – March 2010
  • Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
    RFC5676 – October 2009
  • Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
    RFC5675 – October 2009
  • Alarms in Syslog
    RFC5674 – October 2009
  • Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)
    RFC5650 – September 2009
  • Management Information Base for OSPFv3
    RFC5643 – August 2009
  • Managed Objects for ATM over Packet Switched Networks (PSNs)
    RFC5605 – July 2009
  • Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)
    RFC5604 – July 2009
  • Ethernet Pseudowire (PW) Management Information Base (MIB)
    RFC5603 – July 2009
  • Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
    RFC5602 – July 2009
  • Pseudowire (PW) Management Information Base (MIB)
    RFC5601 – July 2009
  • Definitions of Textual Conventions for Pseudowire (PW) Management
    RFC5542 – May 2009
  • Reliable Server Pooling MIB Module Definition
    RFC5525 – April 2009
  • Multicast Group Membership Discovery MIB
    RFC5519 – April 2009
  • Network Mobility (NEMO) Management Information Base
    RFC5488 – April 2009
  • Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices
    RFC5428 – April 2009
  • Textual Conventions for Syslog Management
    RFC5427 – March 2009
  • Transmission of Syslog Messages over UDP
    RFC5426 – March 2009

  • Transport Layer Security (TLS) Transport Mapping for Syslog
    RFC5425 – March 2009
  • The Syslog Protocol
    RFC5424 – March 2009

Leave a Comment

NETCONF & YANG: Potential Markets

Will there be a successful outcome for NETCONF and YANG standards?

Can NETCONF and YANG shift the management paradigm from configuring individual devices to the configuration of entire networks?

Which network and service equipment is most likely to incorporate a NETCONF server?

Early adopters of NETCONF include two large router companies. Juniper has led the charge by incorporating NETCONF across its entire product line, while cisco is actively working toward incorporating NETCONF into its product line.

Other early adopters include Tail-f Systems, SNMP Research International, InterWorking Labs and EmbeddedMIND.  These companies offer NETCONF software development tool kits.

Both the TeleManagement Forum and the Metro Ethernet Forum have expressed an interest in considering YANG as a schema definition language for data models used for managing carrier grade communications equipment.

Within the IETF, the IP Flow Information Export (ipfix) working group is using YANG to  create a configuration data model for IPFIX and PSAMP.

Characteristic Strengths

What are the characteristic strengths of NETCONF and YANG that are likely to be attractive to vendors and operators of networks and services?

From my perspective characteristic strengths include:

  • the ability to add NETCONF operations to suit operational requirements
  • the capacity for NETCONF to perform well at a frequency of configuration changes that exceeds human ability via CLI or Web form
  • the ability of YANG to provide excellent support for complex data models and namespaces
  • the design of YANG enables data models to grow over time via augmentation and extension
  • the use of the XPATH filtering mechanism supports efficient use of network bandwidth

And the key aspect to keep in mind is that YANG provides a concise language for data modelling that overcomes the limitations of XSD and that YANG modules are fully mappable to equivalent RELAX NG.

Characteristic Weaknesses

What are the characteristic weaknesses of NETCONF and YANG that are likely to be unattractive to vendors and operators of networks and services?

From my perspective characteristic weaknesses include:

  • YANG is ‘overkill’ for simpler, less sophisticated network equipment and services
  • YANG lacks a robust configuration object lifecycle model
  • An appropriate approach towards authorization remain a work-in-progress for NETCONF and YANG
  • Compared to XSD, YANG has little support for schema creation and editing and for validation of instance documents
  • NETCONF does not scale well for frequent configuration of 1000s of devices due to the overhead of establishing TCP connections and SSH sessions

Potential Application Realms

What are the potential application realms for NETCONF and YANG?

Given the above characteristic strengths and weakness, NETCONF and YANG are potentially attractive in realms that include:

  • Smart grid
  • Multi-tenant managed IT services
  • Cloud computing and data centers
  • Carrier grade telecommunications and internetworking equipment

NETCONF and YANG probably are not attractive solutions for simpler, low end network devices, single user computing systems and web applications designed for SOHO environments.

Summary

NETCONF and YANG are well suited for advanced configuration management of complex networks and services.  These technologies have an interesting market potential and stake holders are working towards raising the visibility of NETCONF and YANG within the communication and computing industries.

The degree to which these technologies are embraced by the market will depend upon the perception that YANG is a superior data modelling language.

Early adopters have already integrated NETCONF and YANG into products.  Ultimately, the degree of success enjoyed by NETCONF and YANG will be determined by the rate and level of adoption within potential markets.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Leave a Comment

NETCONF & YANG: Architecture

In this article we explore the architecture of NETCONF and YANG.  Much of the information presented in this article is derived from RFC 4741, “NETCONF Configuration Protocol”.

Introduction

The Network Configuration (NETCONF) protocol is designed as a simple mechanism through which the configuration data residing on a network device may be inspected and manipulated. The NETCONF protocol uses the abstraction of operations with parameters to facilitate the development of applications for configuration management of network devices.

Within the NETCONF architecture, there exist two peer roles: the NETCONF client and the NETCONF server.

The client role is fulfilled by a person or a management application.  The client is responsible for the configuration management of some number of network devices.  The server role is fulfilled by software residing on a network device.  The server is responsible for the exchange of NETCONF messages and for the orderly manipulation of local configuration data.

In order to exchange NETCONF messages, a client must first establish a NETCONF session with a server.  When a session is established, each NETCONF peer exchanges a list of its capabilities with the other peer.

A NETCONF capability is represented by a uniform resource name (URN).  Each capability corresponds to a set of features supported by a NETCONF peer.  A feature may provide support for an RPC operation or specify the semantics for parameters associated with an RPC operation.

The concept of capabilities is a powerful tool and enables the extensibility of the NETCONF protocol.  The base NETCONF capability is the minimum set of features each a NETCONF peer must implement, represented as “urn:ietf:params:netconf:base:1.0″.

NETCONF Protocol Layers

The NETCONF protocol can be conceptually partitioned into four layers.

Messages exchanged on a NETCONF session between a client and server pass through each layer.  We discuss the purpose of each layer within the NETCONF protocol in the following sections.

The Transport Protocol Layer

The transport protocol layer provides an end-to-end network connection for the exchange of messages between a client and a server.  Section 2 of RFC 4741 discusses requirements of the transport protocol layer.

The transport protocol provides the following features:

  • indicates the session type: client or server
  • connections are persistent, durable and stateful
  • reliably delivers an ordered sequence of messages
  • releases resources associated with a session when its connection terminates
  • responsible for user authentication

A NETCONF implementation must support the SSH transport protocol mapping.  The NETCONF mapping for SSH is specified in RFC 4742.  Optional transport mappings include console shell, and TLS (RFC 5539).

The RPC Layer

Tje RPC layer provides a communication model for framing NETCONF requests and responses. Section 4 of RFC 4741 discusses requirements of the RPC layer.

NETCONF requests use an <rpc> element and NETCONF replies use an <rpc-reply> element.  The <rpc> element within a NETCONF request contains a mandatory “message-id” attribute and may contain any optional attributes useful to the client.  The “message-id” attribute facilitates the correlation of a request with its response.  The <rpc-reply> element of a NETCONF response always contains an unmodified copy of the set of attributes present in the <rpc> element of the corresponding NETCONF request.

The RPC operation name and its parameters are encoded as the content within the <rpc> element.

When the result of an RPC operation contains errors, one or more <rpc-error> elements are present within the <rpc-reply> element of the response.  Each <rpc-error> element describes an error encountered during processing of the RPC operation.  When the result of an RPC operation is free of error, an <ok> element is present within the <rpc-reply> element of the response.

Once a NETCONF session is established, a client may send multiple requests to the server without waiting for a reply.  A NETCONF server responds to each request in the order it was received.

The Operations Layer

The operations layer provides a mechanism for the proper handling of NETCONF operations present within requests and for the proper handling of reply content present within responses.  Section 7 of RFC 4741 discusses requirements of the operations layer.

The NETCONF protocol base capability defines a small set of operations and associated parameters for the inspection and manipulation of configuration data.  The NETCONF protocol base capability is extensible.  A client or server that supports additional operations or parameters will advertise its extensions in its capabilities exchange when establishing a NETCONF session.

Each <rpc> element in a request contains a NETCONF operation name and an associated set of XML-encoded parameters. The following table summarizes the set of operations in the NETCONF protocol base capability.

operation name operation purpose
get retrieve the running configuration and state information
get-config retrieve all or a portion of a configuration datastore
edit-config load all or part of a source configuration into a target configuration datastore
copy-config create or replace an entire target configuration datastore with a complete source configuration
delete-config delete the contents of a configuration datastore
lock lock a configuration datastore for exclusive edits by a client
unlock release the lock on a configuration datastore
close-session gracefully terminate a NETCONF session
kill-session forcefully terminate a NETCONF session

Operations Supported by NETCONF 1.0 Base Capability

We will revisit NETCONF operations and associated parameters in a future article.

The Content Layer

The content layer provides the NETCONF protocol with a mechanism for encapsulating configuration data. Section 5 of RFC 4741 discusses requirements of the content layer.

Configuration data associated with a NETCONF operation is XML-encoded within a <config> element.  On a network device,  configuration data resides within a configuration datastore.

Proper configuration data is constrained by the semantics of the YANG schema defined for a network device.  The YANG data modeling language, currently a work-in-progress of the IETF NETMOD working group, was created primarily to address the needs of modeling the configuration and state data conveyed by the NETCONF protocol.

A YANG schema defines a set of data nodes organized as a hierarchical tree.  Each data node in the tree has a name and either a value or a set of child nodes.  YANG schema are structured into modules and submodules that  may be published by a standards organization, an enterprise or an industry forum.

A key design feature of YANG is its support for modular extensibility.  One YANG module may define additional data nodes augmenting the data nodes defined in another YANG module.

Since configuration data is specific to the data model of a network device, the NETCONF protocol does not inspect or manipulate configuration data.  The set of YANG modules defining the schema of a network device is identified within the list of capabilities sent by its server to a client when a NETCONF session is established.

The NETCONF client can subsequently retrieve and inspect the YANG schema for a network device to gain an understanding of the layout, containment, keying and other semantic constraints imposed upon the configuration and state data exchanged with a NETCONF server.  Note that the schema for a network device can be fully mapped from YANG to other XML based schema languages, such as DSDL to facilitate validation tasks.

The <get> and <get-config> NETCONF operations support subtree filtering when a <filter> element is present.  Subtree filtering enables a client to limit the data returned by a server to the set of subtrees matching the filter expression.

There are five types of components that may be present in a subtree filter:

  • Namespace Selection
  • Attribute Match Expressions
  • Containment Nodes
  • Selection Nodes
  • Content Match Nodes

An optional extension allows filters to use XPATH expressions.

Using the YANG data modeling language to create schema and using the NETCONF subtree filtering mechanisms to match portions of the schema tree are interesting topics that we will revisit in future articles.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Leave a Comment

NETCONF & YANG: Motivation and Inception

In this article we explore the motivation and inception of IETF standards work on the NETCONF protocol and the YANG data modeling language.

MOTIVATION:

Over the past two decades, some significant issues emerged relative to the current best practices for the configuration of networks and services:

Using SNMP as the basis for configuration tasks for the many network devices sold by communications equipment vendors became rather complicated.  Most MIB modules published by the IETF proved useful for monitoring purposes. However, for configuration tasks, vendors chose expedience over interoperability by implementing their own private enterprise MIB modules instead of working with peer vendors to define a common set of configuration objects for similar communications devices.

Further more, the semantics of the CLI across communications devices from multiple vendors lacked uniformity and lacked stability.  Vendors’ methods for session establishment and user authentication needed by configuration tasks varied.  The format and content of configuration data as well as error values and their meanings differed across vendors’ products.  Sometimes semantic changes were encountered within the CLI across revisions of a single vendor’s product.

Using the HTTP and web-based forms encountered issues similar to those found with the CLI.

Such realizations evolved into a set of known issues and gained mind share during discussions between network operators and participants within the IETF.

What could be done to reduce the complexity of operator tasks associated with the configuration of networks and services?  Did participants think this work was feasible?  Who would propose and how would standards be developed for the configuration of networks and services?

Inception:

The feasibility of the Network Configuration (NETCONF) protocol was initially discussed at IETF 56 in San Francisco during March of 2003.

Participants discussed the known issues in the configuration of networks and services and discussed the set of requirements solicited from network operators and protocol developers, as described in RFC3535 , “Overview of the 2002 Network Management Workshop”.

Based upon a rough consensus achieved during these initial discussions, a new IETF working group was convened within the Operations and Management area.  The full charter for the working group, is provided on the NETCONF web page.

The NETCONF working group charter provides key aspects for the protocol design as follow:

  • Provides retrieval mechanisms which can differentiate between
    configuration data and non-configuration data
  • Is extensible enough so that vendors will provide access to all
    configuration data on a device using a single protocol
  • Has a programmatic interface (avoids screen scraping and
    formatting-related changes between releases)
  • Uses a textual data representation, that can be easily manipulated
    using non-specialized text manipulation tools
  • Supports integration with existing user authentication methods
  • Supports integration with existing configuration database systems
  • Supports network wide configuration transactions (with features such
    as locking and rollback capability)
  • Is as transport-independent as possible
  • Provides support for asynchronous notifications

In addition to the key aspects above, the NETCONF charter specifies the use of XML for data encoding purposes, because XML is “a widely deployed standard supported by a large number of applications”.

And significantly for YANG, The NETCONF charter states that the data modeling language for describing configuration and state data should remain independent of the NETCONF protocol.  This NETCONF requirement provided the impetus for the eventual creation of the NETCONF Data Modeling Language (NETMOD) working group, with informal discussions during IETF 70 in Vancouver in December of 2007.

To focus emerging NETMOD discussions, an internet draft on the Requirements for a Configuration Data Modeling Language (draft-presuhn-rcdml) was prepared and a charter established.

The NETMOD working group charter provides key aspects for the data modeling language as follow:

  • Designs a “human-friendly” modeling language with a focus upon readability and ease of use
  • Has semantics for defining:

    • Operational data
    • Configuration data
    • Notifications
    • Operations
  • Uses YANG (draft-bjorklund-netconf-yang) as the starting point
  • Defines standard mapping rules from YANG to the ISO/IEC 19757 Document Schema Definition Languages (DSDL) data modeling framework with additional annotations to preserve semantics
  • Consults with the NETCONF working group so that decisions do not conflict with NETCONF work

Since the pool of participants in the NETCONF and NETMOD working groups overlap to a significant degree, consulting on the implication and potential conflict of decisions would appear to be easily handled.

Summary:

Work on the NETCONF protocol and YANG data modeling language came about due to the realized short comings of using the SNMP, the CLI, and the HTTP and web-based forms as the basis of a consistent and stable mechanism for the configuration of networks and services.

Standards work on the first version of the IETF NETCONF protocol commenced in 2003. This work is currently nearing completion with seven published RFCs and four work-in-progress Internet-Drafts.

Standards work on the YANG data modeling language commenced in 2008. This work is currently proceeding within the IETF NETMOD working group with five work-in-progress Internet-Drafts related to YANG under technical review and discussion.

In our next article, we gain an understanding of the architecture of the NETCONF protocol.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Leave a Comment

NETCONF & YANG: Introduction and Overview

This article is the first in a series of articles on the emerging NETCONF and YANG standards published by the IETF.

Over the past several years, participants within the IETF Operations and Management area have published two complementary series of RFCs that specify a proposed standard for the advanced configuration of networks and services.

The first series of RFCs specify the protocol operations (NETCONF) for manipulating configuration data and examining state information contained within network devices and services.

The second series of RFCs specify the schema language (YANG) for defining the XML-based configuration data transported by NETCONF.

Together, NETCONF and YANG provide operators and vendors a standards based alternative to relying upon the varied semantics encountered when using some combination of CLI, SNMP and HTML based configuration applications.

Our technical overview is comprised of a number of topics exploring some interesting aspects of the design and features found within NETCONF and YANG.  Topics are each presented in a separate article and include:

  • Motivation and Inception: What were the reasons for this standards work?  When and how did work start on these standards?
  • Architecture:  What is the organization of the design features and fundamental components found in NETCONF and YANG?
  • Potential Markets:  What portions of the IT industry are most likely to incorporate NETCONF and YANG technology into their management approach?
  • Basic Terms and Concepts: What are the basic terms and concepts within NETCONF and YANG?  What are the relationships among concepts?
  • Operations:  Which operations are part of the base set of capabilities?  How is the set of basic operations extended?
  • Capabilities:  What are NETCONF and YANG capabilities.  Why are capabilities important?
  • Configuration Schema:  Why was a new language defined for creating schema for the data modelling of configuration data?
  • Data Modelling: How do I use YANG to create a schema for my configuration data?
  • Data Modelling: How do I use YANG to extend and augment another data model?

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Leave a Comment

Work-in-Progress: Current IETF Activity Related to YANG Modules


The YANG data modeling language is currently being designed and standardized by the IETF NETMOD working group.

YANG modules are to NETCONF as MIB modules are to SNMP. YANG modules are defined within the relevant working group and reviewed by a small cadre of IETF YANG experts prior to publication as an RFC. The following provides a brief outline of and links to the current works-in-progress.

Note that Internet-Drafts are works-in-progress and expire when a subsequent revision is available, or six months after initial publication, whichever occurs first.

I am happy to discuss the usefulness and applicability of the below works-in-progress to your project. Just contact me with your project requirements and ideas.


Operations and Management Area:

Leave a Comment

Product Evaluation: DMH Software’s SNMPv3 SDK

Every so often I have the opportunity to evaluate a software developers kit (SDK) targeted for use in network and services management applications.

I recently evaluated the SNMPv3 Advanced SNMP Agent SDK offered by DMH Software.   A product profile and evaluation synopsis follow.

Product Profile

DMH Software sells a software developers kit consisting of an SMIv2 MIB compiler and their portable, SNMPv3 capable Advanced SNMP Agent runtime libraries.

NetBurner sells a single board device running uc/OS on a Freescale Coldfire 68K processor that served as the embedded target environment.

Evaluation Approach

For this evaluation, the ALARM-MIB (RFC 3877) was implemented using the DMH Software SDK for the NetBurner embedded environment.  The ALARM-MIB was selected for reasons that include:

  • the OBJECT-TYPE definitions include every possible SMIv2 sytnax type.
  • the tables have multiple index components using OCTET STRING and INTEGER syntax types.
  • the two NOTIFICATION-TYPE definitions, alarmActiveState and alarmClearState, enable evaluation of APIs for sending notifications.
  • the design of the alarmActiveVariableTable allows each row to contain one of the variable bindings sent in a notification. As such, the alarmActiveVariableTable is a ‘sparse’ table containing rows with only three accessible object instances out of ten accessible OBJECT TYPE definitions.

To implement the ALARM-MIB, the following steps were taken:

  • the host environment was set up on a Windows XP laptop with the NetBurner supplied Eclipse based IDE and cross compiler, linker and debug utilities.  A NetBurner model 5234 board was used as the target environment.
  • the DMH Software SMIv2 MIB compiler was used to generate code from the ALARM-MIB.
  • custom code was added to the generated code to complete the functional implementation.
  • the NetBurner SDK was used to compile the generated and custom code and to link it with the DMH Software SNMPv3 agent and NetBurner runtime libraries.
  • the resulting executable was flashed onto the NetBurner board and tested using the Net-SNMP command line tools.

Evaluation Results – MIB compiler

The DMH Software SMIv2 MIB compiler is based upon and extends utilities that are part of the well known open-source libsmi distribution.  Thus, I experienced a familiar and comfortable feel with the DMH MIB compiler utilities.  Version 1.4.5.0.5 of the SMIv2 MIB compiler was used in the evaluation.

The code generated for the ALARM-MIB consisted of three source files, alarm-mib.c, alarm-mib.h and alarm-mib-sys.c.  The generated source code was modular, of good quality and well annotated with information from the ALARM-MIB as well as comments that clearly indicated where custom code was required to complete a functional implementation.

During the evaluation I encountered several minor issues with the source code generated from the DMH Software MIB compiler:

  • generated code contained erroneous range checking for the SMIv2 BITS construct.  NOTE: this issue was resolved within three days of reporting it to DMH Software.
  • some code was not generated for the alarmActiveDateAndTime nor alarmClearDateAndTime index components.  NOTE:  this issue was resolved within three days of reporting it to DMH Software.
  • generated code for enumerated values would be a welcome addition.
  • generated code could do a better job handling SMIv2 Textual-Conventions.  Most of the generated code and comments accurately reflect the underlying base syntax type, rather than the restrictions placed upon the base syntax by the Textual-Convention.  NOTE: support for the RowStatus and StorageType Textual-Conventions are built into the SNMPv3 SDK APIs.

Evaluation Results – SNMPv3 SDK

The DMH Software Advanced SNMP Agent was designed to produce a small executable with embedded and real-time applications in mind.  From tests run, I was pleased to find excellent support for version 3 of the SNMP that included the set of SNMPv3 MIBs for USM, VACM, and Notification targets.  Version 5.0.1.12-2 of the SNMPv3 SDK was used in the evaluation.

The provided developers’ documentation consisted of an integrated set of html pages.  It took a little time to get used to navigating the frames and tabs of the documentation to find the information I needed.  In a handful of instances I found information not available in the documentation by searching through the SNMPv3 SDK include files.

The provided API consisted of a small, concise and well thought out set of functions. From my perspective, a small and concise set of functions is beneficial, serving well the target audience of developers creating management applications.  In general, I found the API provided with the DMH SNMPv3 SDK easy to understand and use.

During the evaluation I encountered a couple of minor issues with the DMH SNMPv3 Agent API:

  • the agent cited an error when passed a variable binding tagged with a syntax of Opaque.  NOTE:  This issue was resolved within three days of reporting it to DMH Software.
  • while there are two API functions for sending notifications, neither provided a mechanism for the caller to provide the value for sysUpTime.0 for an outgoing notification.  While perceived as a hindrance upon implementing the ALARM-MIB for this evaluation, DMH did offer to resolve this issue in a future release.

Evaluation Results – Summary and Conclusion

Overall, I was pleased with the functionality, features and support offered by DMH Software in their Advanced SNMP Agent SDK product.

Additionaly, I am pleased to report that the SMIv2 MIB compiler generated modular code of good quality and that DMH Software’s response time on technical issues was superb.

If your software development project involves the NetBurner embedded target environment and has a need for an SNMPv3 agent then I recommend you consider using the DHM Software Advanced SNMP Agent for your software development project.

Please contact me if you need to identify applicable IETF published MIB modules. need to design a private enterprise MIB module, or require a quick and sure start with the DMH SDK.  Find out how easily my expertise and skills can support your development team and contribute to a successful design and realization of your software project.

Leave a Comment