Ellison Software Consulting » Standards Development http://ellisonsoftware.com SNMP and MIB Consulting Fri, 02 Jul 2010 17:32:19 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 NETCONF & YANG: Potential Markets http://ellisonsoftware.com/2010/07/02/netconf-yang-potential-markets/ http://ellisonsoftware.com/2010/07/02/netconf-yang-potential-markets/#comments Fri, 02 Jul 2010 17:31:32 +0000 Mark http://ellisonsoftware.com/?p=1010 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 are probably not attractive solution 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.

]]> http://ellisonsoftware.com/2010/07/02/netconf-yang-potential-markets/feed/ 0 NETCONF & YANG: Architecture http://ellisonsoftware.com/2010/05/17/netconf-yang-architecture/ http://ellisonsoftware.com/2010/05/17/netconf-yang-architecture/#comments Mon, 17 May 2010 14:12:32 +0000 Mark http://ellisonsoftware.com/?p=492 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.

]]> http://ellisonsoftware.com/2010/05/17/netconf-yang-architecture/feed/ 0 NETCONF & YANG: Motivation and Inception http://ellisonsoftware.com/2010/04/14/netconf-yang-motivation-and-inception/ http://ellisonsoftware.com/2010/04/14/netconf-yang-motivation-and-inception/#comments Wed, 14 Apr 2010 18:36:12 +0000 Mark http://ellisonsoftware.com/?p=474 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.

]]> http://ellisonsoftware.com/2010/04/14/netconf-yang-motivation-and-inception/feed/ 0 NETCONF & YANG: Introduction and Overview http://ellisonsoftware.com/2010/03/31/netconf-yang-introduction-and-overview/ http://ellisonsoftware.com/2010/03/31/netconf-yang-introduction-and-overview/#comments Wed, 31 Mar 2010 14:36:59 +0000 Mark http://ellisonsoftware.com/?p=471 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.

]]> http://ellisonsoftware.com/2010/03/31/netconf-yang-introduction-and-overview/feed/ 0 Work-in-Progress: Current IETF Activity Related to MIB Modules http://ellisonsoftware.com/2009/01/22/work-in-progress-current-ietf-activity-related-to-mib-modules/ http://ellisonsoftware.com/2009/01/22/work-in-progress-current-ietf-activity-related-to-mib-modules/#comments Thu, 22 Jan 2009 19:38:50 +0000 Mark http://agentsv.com/?p=279
Updated on Tuesday 09 March 2010

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-12 – 9-Jan-08


Routing Area:

  • Inter-Domain Routing (idr)


Individual Submissions:


Recently Published RFCs:

  • 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

  • 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

  • Ethernet Pseudowire (PW) Management Information Base (MIB)
    RFC5603 – July 2009

  • Management Information Base for OSPFv3
    RFC5643 – August 2009

]]> http://ellisonsoftware.com/2009/01/22/work-in-progress-current-ietf-activity-related-to-mib-modules/feed/ 1 Work-in-Progress: Current IETF Activity Related to Network and Service Management http://ellisonsoftware.com/2009/01/07/work-in-progress-current-ietf-activity-related-to-network-and-services-management/ http://ellisonsoftware.com/2009/01/07/work-in-progress-current-ietf-activity-related-to-network-and-services-management/#comments Wed, 07 Jan 2009 13:39:48 +0000 Mark http://agentsv.com/?p=76
Updated on Tuesday 09 March 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 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 Internet-Drafts include:


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:

  • 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:

    • 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 ideas.

]]> http://ellisonsoftware.com/2009/01/07/work-in-progress-current-ietf-activity-related-to-network-and-services-management/feed/ 1