This whitepaper proposes a new generation of configuration management tools to deal with the fast changing environment faced by service providers and OSS and EMS developers. The proposed approach leverages dynamic data modeling, automated configuration, and mechanisms for transaction integrity. By automating the connection between service activation and device configuration, the excess cost and delay associated with hardwired, service-specific software is eliminated. http://www.tail-f.com

1. Tail-f Systems Whitepaper
Closing the Services Configuration Gap
Introduction
Delivering valued-added services, like MPLS VPNS, Metro Ethernet, and IP TV is critical to the profitability
and growth of service providers. In most operator networks, there are bottlenecks that get in the way of
activating services in a timely and cost effective manner. We call this the “Services Configuration Gap.”
Current systems use either legacy software or third party applications that are expensive and inflexible, often
requiring manual intervention, frequent software updates, and maintenance of layers of mediation software.
These systems are being strained by the increased rate of change as services are enhanced, new services are
introduced, and network devices are replaced and added. Both OSS and EMS developers are burdened with
these problems. For network equipment vendors, developing EMS applications, the focus is more on device
adaptations than service applications.
This whitepaper describes the Services Configuration Gap and proposes a new generation of configuration
management tools to deal with the fast changing environment faced by service providers and OSS and EMS
developers. The proposed approach leverages dynamic data modeling, automated configuration, and
mechanisms for transaction integrity. By automating the connection between service activation and device
configuration, the excess cost and delay associated with hardwired, service-specific software is eliminated.
Service Configuration Today
The steps involved in creating and activating a service include many processes, support systems, and network
devices. As shown below in Figure 1, the TM Forum’s eTOM Process Map divides the processes into two
major areas: strategy (left) and operations (right).
Figure 1: The eTOM Process Map
The strategy product lifecycle addresses service introduction and retirement. The design of new services
includes how the service is represented in systems like customer care, assurance, and billing and requires
services to be modeled so that all systems can have a common view of their characteristics and decomposition.
Tail-f Systems © 2010
Page 1 of 11

2. Tail-f Systems Whitepaper
The design and modeling includes the mapping to the
resource layer, as well as defining what devices and
configurations are needed to support a service. When a
service has been designed it is handed over to operations
processes which are responsible for activating the service
in the network. The activation process which includes
assurance and billing is shown in Figure 2.
For example, if a customer orders an MPLS VPN, the
order handling process makes sure that the order is
properly managed including credit authorization and
overall order tracking. The order process then triggers the
service configuration and activation process which in turn
configures the customer service. The process might
include manual steps such as the installation of Figure 2: eTOM Service Activation
customer equipment.
Service models are commonly expressed in UML models and implemented in vendor-specific repositories at
the OSS level. The device data models are typically available as SNMP MIBs and vendor-specific CLIs.
Challenges with Existing Service Configuration Approaches
Service Models
The Services Configuration Gap is a function of the way existing service models and their mapping processes
connect to the corresponding device data models. Due to the rapid change of customer requirements, adoption
of new services, and a constantly changing network topology, these models and mappings must be frequently
revised. Today this process is semi-automated and not dynamic, resulting in changes often being reflected
throughout the system in weeks rather than hours.
To reach new time-to-market expectations, the next generation of service management tools must have the
following capabilities:
• Be model-driven and allow user and programmatic interfaces to be automatically updated from the
service model without other inputs.
• Support model-aware APIs that let programmers work directly with classes from the service model
rather than low-level protocol based APIs.
• Ability to load new versions and models at runtime and propagate changes immediately.
• Modeling tools and support that allow for quick changes while still validating the model correctness
and completeness.
• The model must interface seamlessly with the subsequent mapping step to ensure that the complete
chain from service model to device model is managed.
• Modern software engineering approaches including modularity, aspects, and annotations (rather than
inheritance) should be used to avoid dependencies and long build times.
Tail-f Systems © 2010
Page 2 of 11

3. Tail-f Systems Whitepaper
Device Management
The process of configuring network devices is generally a manual and time-consuming task. Unlike alarm and
performance management, configuration activities involve writing data and changing states on devices whereas
alarm and performance management is mostly a read-only activity. Furthermore, the configuration process also
has more complex operation requirements such as validation and transactions. An additional challenge is the
fact that configuration data models are vendor-specific and often hard to understand.
While network configuration in large networks will always be demanding and need skilled network
administrators, this should not prevent the use of automated configuration management at the "plumbing
level.” Currently, most configuration management operations are performed using scripts on top of command
line interfaces or even partly with SNMP. The use of CLIs and SNMP comes with major limitations as
discussed below.
SNMP MIBS
• It is hard to find the correct MIB Modules using SNMP. There is no defined discovery procedure
other than an ad hoc SNMP walk and, even after a MIB walk, there is no formal and automated way to
find the correct MIB module.
• All MIBs do not define fundamental concepts, including which data is configuration data versus
operational data, sequencing and transactional dependencies, or constraints between variables.
• The module structure of SNMP MIBs has worked well in guaranteeing unique identifiers. However,
the administrative based tree-structure does not suit automated rendering of interfaces or favor
readability and extensibility in a logical way.
CLI Models
• The data-model for CLIs is informally defined and is managed by scripts that parse the actual strings.
This is a fragile way of working since misspellings and version changes break the scripts.
• There is no room for automated rendering of tools since no formal model is defined.
While improvements can be made to traditional solutions at considerable cost, the result falls short of a fully
automated approach where the latter includes the following capabilities:
• Discovery of data models.
• Resolution of data model versions.
• Rendering of interfaces from data models.
• Synchronization of configuration data from and to devices.
• Validations and transactions to ensure correct configuration.
• Transactions that are tolerant of unreachable devices and capability variants.
The Service Configuration Gap is a byproduct of inflexible, partially automated systems that struggle to keep
up with the rate of change in a service operator’s environment. Symptoms of the Service Configuration Gap
include:
• Delays in the introduction of new services that result in the postponement of incremental revenue.
• The need for large teams of custom programmers to update and maintain adapter software.
• Configuration errors that result in loss of service and negatively impact customer satisfaction.
Tail-f Systems © 2010
Page 3 of 11

4. Tail-f Systems Whitepaper
Dynamic Service Configuration
The combination of dynamic service modeling and automated configuration is the basis of the next generation
of configuration management tools and we call this new approach “Dynamic Service Configuration.” With
Dynamic Service Configuration operators are able to dynamically adapt the service configuration solution
according to changes in their service portfolio, rather than being based on raw device configurations.
The configuration management tools that enable
Dynamic Service Configuration sit between the network
devices and the order management system. As shown in
Figure 3, with this new approach there will be a Service
Layer and a Device Layer. The Service Layer supports
dynamic modeling of services with short development
time and model-driven dynamic updates of dependant
interfaces. The Device Layer automatically manages the
device interfaces, such as synchronization of
configuration data, multinode configuration
deployment, and interface versioning.
In the context of the eTOM processes (see Figure 2),
Dynamic Service Configuration implements Service
Configuration and Activation and Resource
Provisioning.
Many operators have systems in place for managing
work-flows across the complete OSS chain, our
proposed approach sits below such systems and
provides an efficient network facing transaction engine.
Furthermore, it replaces in-house CLI scripts or
expensive adaptors and provides a dynamic and Figure 3: Dynamic Service Configuration
managed solution for such environments.
The input to the configuration management system is a request to change or add a service, such as a NGOSS
Contract or an MTOSI request. The output from the system is a validated network change, an alert that
validation has failed, or the proposed change was rejected due to some other reason.
Dynamic Service Configuration uses the NETCONF protocol and YANG data modeling as foundations.
YANG is used to bridge the higher level models to device interfaces and NETCONF is used as the means of
deploying the configuration to the devices. This approach can benefit from many automated features such as
model and transaction management where devices support these standards directly. Non-NETCONF devices
such as SNMP and CLI managed network elements can also be mapped by using a mediator and still benefit
from the NETCONF design principle with support of transactions and model-based management.
NETCONF and YANG are described in more detail below.
Tail-f Systems © 2010
Page 4 of 11

5. Tail-f Systems Whitepaper
NETCONF
The Network Configuration Protocol, NETCONF, is an IETF network management protocol and is published
in RFC 4741. NETCONF is being adopted by major network equipment providers and has gained strong
industry support.
NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices.
Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The NETCONF protocol
uses XML based data encoding for the configuration data as well as the protocol messages. NETCONF is
designed to be a replacement for CLI based programmatic interfaces, such as Perl + Expect over Secure Shell
(SSH). NETCONF is usually transported over the SSH protocol, using the ’NETCONF’ sub-system and in
many ways it mimics native proprietary CLI over SSH interfaces available in a device. However, it uses
structured schema-driven data and provides detailed structured error return information, which the CLI cannot
provide.
Operators need a way to distribute changes to the devices and validate them locally before activating them.
This is indicated by the two bottom options in Figure 4 where configuration data can be sent to candidate
databases in the devices before they are committed to running in production applications. All NETCONF
devices must allow the configuration data to be locked, edited, saved, and unlocked. In addition, all
modifications to the configuration data must be saved in non-volatile storage.
Figure 4: NETCONF Configuration Databases
YANG
YANG is a data modeling language that provides breakthrough advantages to modeling configuration and state
data. The YANG modeling language is currently being standardized by the IETF in the NETMOD working
group. The authors of YANG were involved in the development of the next generation SNMP SMI and are
very experienced in the IETF network management arena. Modern network standards groups such as the Metro
Ethernet Forum are adopting YANG as a device configuration standard.
Tail-f Systems © 2010
Page 5 of 11

6. Tail-f Systems Whitepaper
YANG is tree-structured rather than object-oriented. Configuration data is structured into a tree and the data
can include complex types such as lists and unions. The definitions are contained in modules and one module
can augment the tree in another module. Strong revision rules are defined for modules.
YANG also differs from previous network management data model languages through its strong support of
constraints and data validation rules. The advantages of using YANG for data models include:
• YANG is simple, easy to learn, and most important of all, it is easy to read and understand. The
complexity of other languages has made it hard to review information models and find problems,
thereby undermining the ability of developers to build management applications.
• YANG is written for network management. It is a domain specific language designed to do what it
needs to do well. It is not constrained by or overloaded by any framework it is derived from.
• YANG is flexible and modular. Existing modules can be augmented in a controlled manner.
An Example of Dynamic Service Configuration in Action
The following is an illustration of Dynamic Service Configuration in action using YANG as a general
modeling language and showing the power of dynamically modeling services and automated configuration of
network devices.
We are using the scenario of activating MPLS VPN for customers. The hypothetical network topology for this
example is shown in Figure 5 below.
Figure 5: Network Topology
A VPN contains customer devices attached to the Customer Edge (CE) routers. The customer devices use a
MPLS VPN to exchange information between devices within the VPN. The CE routers are not aware of the
VPN as this is managed by the Provider Edge (PE) routers. At service fulfillment time, network resources are
allocated in the required geographic sites to suit the customer. Having selected the devices to be used, the
configuration system can build the required resource facing service template and then populate it with the
customer specific instance details. The service and device model for this example is shown in Figure 6 below.
Tail-f Systems © 2010
Page 6 of 11

7. Tail-f Systems Whitepaper
Figure 6: Service and Device Model
The classes at the top of Figure 6 are standard classes in the Service and Device Layers. The Device Class is
automatically augmented with the YANG modules that are discovered from the device (in this case, with PE
and CE classes). The CE router, being VPN agnostic, contains a simple model for IP interfaces while the PE
routers model MPLS information in addition to standard IP interfaces.
The SID standard Resource and Customer Facing Service Classes are augmented as part of a dynamic service
modeling activity. The Customer facing Service Class is augmented with the Customer VPN service and the
Resource facing service with the MPLS VPN. The Customer VPN service represents what the customer
bought, a VPN service connecting the points of presence. The network facing service (MPLS VPN) is the
implementation of the customer service using MPLS technology and it refers to the access links connecting the
CE with the PE. The separation of customer facing services versus the resource facing services is an important
modeling pattern inherited from the TM Forum SID model.
Next, a fully meshed MPLS VPN “RED” is created. The core network is assumed to be configured (PE
routers). This scenario involves the following steps:
• Setup connectivity PE1-CE1 and PE2-CE3
• Creation of the VPN RED resource facing service instance “vpn-red” and its access links “northwest”
(PE1-CE1) “southeast” (PE2-CE3).
• Creation of the customer facing service instance “acme-vpn.
• Addition of “acme-vpn” to customer “acme”.
This model is depicted in Figure 7 below.
Tail-f Systems © 2010
Page 7 of 11

8. Tail-f Systems Whitepaper
Figure 7: Meshed MPLS VPN
First, the CE interfaces on the PE routers facing VPN RED service are created as shown in Listing 1 below.
ncscli >set ncs managed-device pe1 config interface eth1 enabled ip 192.168.7.2 mask 255.255.255.0
ncscli >set ncs managed-device pe2 config interface eth3 enabled ip 192.168.6.2 mask 255.255.255.0
ncscli>commit
Listing 1: Create Service in CLI
Note the commit command at the end. This will result in a multi-node transaction towards two PE routers.
Either the complete transaction succeeds or fails and in the latter case can be roll-backed.
The next step is to create the mpls vpn “vpn-red” with its access-links “north-west” and “south-east”:
ncscli> set ncs service vpn-red service-type mplsVpn access-link north-west ce ce1 ce-if eth0 pe pe1 pe-
if eth1 subnet 192.168.7.0/24
Value for 'route-distinguisher' (<string, max: 16 chars, min: 3 chars>): 300:1
Value for 'ncs service VPN_GREEN properties mplsVpn vpn-id' (<RFC 2685>): 300:1
ncscli>set ncs service vpn-red service-type mplsVpn access-link south-east ce ce3 ce-if eth0 pe pe2 pe-if
eth3 subnet 192.168.6.0/24
ncscli>commit
Listing 2: Create Resource Facing MPLS Service in CLI
The constraints expressed in the model will ensure that only references are made to valid objects for the
access-link. The “Value for” prompts are automatically generated from the model and the CLI asks for these
attributes since they are mandatory. While not possible to illustrate here, the automatically rendered CLI will
only accept keyboard entries according to the data type, so for example only digits and dots in the right places
are allowed when the IP address is entered.
If for some reason the network changes are undesired, a rollback “undo” can easily be performed.
Next the customer facing VPN service “acme-vpn” is created as shown in Listing 3 below. The command
refers to the existing customer “acme”.
Tail-f Systems © 2010
Page 8 of 11

9. Tail-f Systems Whitepaper
ncscli> set ncs service acme-vpn service-type custVpn mplsVpn vpn-red vpnCust acme
ncscli> commit
Listing 3: Create Customer Facing VPN in CLI
This refers to the VPN service “vpn-red” allocated previously and to the customer “acme” that needs to be
associated with the service resource. The customer is defined in an external system and queried for validity at
creation time.
The above examples of modeling and configuration have been illustrated with CLI commands, but this could
have equally been achieved with a Web Interface dynamically generated by the model.
Mapping Service Models
When a customer wants to add access to their VPN, the Service Logic needs to define the new CE, allocate the
required PE port, and define what VPN types are needed to be configured. Our approach is to define the
Customer Service in a YANG model so that the service fulfillment is simply the mapping of the Service Layer
model to the underlying Device Layer models.
If a device does not support NETCONF, a mediator embeds transactional mapping logic which resolves many
repetitive and error-prone transformation tasks. The two main interface categories for OSS systems, such as
inventory systems or other network management systems, are SQL databases or APIs. In these cases, a YANG
view of the required data is created and mapped to the external database or API.
From the perspective of the configuration management application, it looks as though the data resides within
the application while every access is forwarded to the external system. This approach gives the following
benefits to model mapping:
• Allows for federation as an approach to data integration.
• The service logic is always a YANG to YANG mapping procedure. No service mapping logic is
contained in adaptors to other interfaces.
• It is possible to provide solutions to hard problems like transactions, calculating delta operations,
validation of data, and pre-provisioning.
• Device configuration integration is reduced to a minimum for NETCONF devices.
Rather than requiring the implementer to write code for every model attribute and operation, the definition of a
single create template is all that is required. All other operations like sets and deletes are automatically
calculated. In coding terms, this means 1,000 lines of code can be collapsed to 100 lines, reducing service
activation lead times, programming, and maintenance costs.
Implementing Dynamic Service Configuration
There are many implementation details that will be required to make systems using Dynamic Service
Configuration effectively integrate with existing systems and operations.
Examples of these implementation details include:
• Capability to automatically discover the supported device modules and resolve transactions across
different versions.
• Managing the propagation of changes from service to device models. When a service is changed, the
corresponding device changes are managed in a separate transaction. These changes can be inspected
and used for reverse operation calculations.
Tail-f Systems © 2010
Page 9 of 11

10. Tail-f Systems Whitepaper
• Pre-provisioning – used when the configuration management systems caches the operations for
network elements not installed. In normal circumstances, transactions would fail because a device
does not respond, but with this capability the missing commands are executed whenever devices are
available.
• Backlogging – used when changes to the network must be made as soon as possible and the
transaction should succeed even if some devices are not responding. Here operations to non-
responsive devices are cached.
• Capability to enforce all service models to implement self-test functions. For example, in the
MPLS scenario the MPLS VPN will perform a MPLS ping to verify the connectivity. Actual test
instrumentation may be available on the devices themselves or in external probes.
• Ability to restore a broken service. A typical scenario is where technicians modify devices manually
without being aware of negative effects on services.
• Replay function to show the differences between elements with inconsistent configuration parameters.
This is used to see which devices are out of synch versus the desired configuration and the
corresponding audit log.
Conclusions
To effectively deliver new services in a rapidly changing environment, service providers cannot continue to
rely on existing configuration management systems.
Current systems use either legacy software or third party applications that are expensive, inflexible, require
manual intervention, and frequent software updates plus maintenance of layers of mediation software. These
systems are being strained by the increased rate of change as existing services are enhanced, new services are
introduced, and network devices are replaced and added. As a result, there is a Services Configuration Gap
that can be measured in terms of delays in introducing new services, lost revenue, and excess software
maintenance costs.
A new approach to configuration management is proposed called Dynamic Service Configuration. Dynamic
Service Configuration leverages the NETCONF and YANG standards and is based on dynamic data modeling,
automated configuration, and transaction integrity. From a software implementation point of view, 1,000 lines
of code can be collapsed to 100 lines, reducing service activation lead times, programming, and maintenance
costs.
About Tail-f Systems
Tail-f Systems is a leading developer of configuration management software for networking equipment
providers, EMS providers, and OSS development organizations. Six of the ten largest global networking
equipment providers are Tail-f Systems’ customers.
Tail-f Systems provides a full family of products to build and extend network management systems.
ConfD, the company’s on-device configuration management toolkit, renders management interfaces from a
single data model and includes a lightweight embedded database. Customers using ConfD radically reduce
their time-to-market and benefit from carrier-grade implementations of NETCONF, CLI, Web, and SNMP
interfaces.
Active in standards development organizations, Tail-f Systems is the leading provider of configuration
management solutions based on the NETCONF and YANG standards.
Tail-f Systems © 2010
Page 10 of 11

11. Tail-f Systems Whitepaper
Tail-f Systems has implemented the concepts behind Dynamic Service Configuration in a family of
configuration management products and tools. For more information on Tail-f Systems’ order fulfillment and
configuration solutions, please contact us at mailto:info@tail-f.com.
Tail-f Systems is headquartered in Stockholm, Sweden. For more information on the company, please visit
http://www.tail-f.com.
Further Reading
1. Martin Bjorklund. Why YANG. http://www.yang-central.org/twiki/bin/view/Main/WhyYang
2. W. Enck, P. McDaniel, S. Sen, P. Sebos, S. Spoerel, A. Greenberg, S. Rao, and W. Aiello.
Configuration management at massive scale: System design and experience, Pages 73–86, 2007.
3. R. Enns. NETCONF Configuration Protocol. RFC 4741 (Proposed Standard), December 2006.
4. TM Forum. eTom, http://www.tmforum.org/browse.aspx, TM Forum, 2005.
5. Balasz Lengyel. www.yang-central.org/twiki/pub/Main/YangDocuments/draft-lengyel-why-yang-
00.txt.
6. ITIL. http://www.itil-officialsite.com.
7. Stefan Wallin and Viktor Leijon. Telecom network and service management: An operator survey. In
12th IFIP/IEEE International Conference on Management of Multimedia and Mobile Networks and
Services (MMNS), October 2009.
8. H. Xu and D. Xiao. Considerations on NETCONF-Based Data Modeling. In Proceedings of the 11th
Asia-Pacific Symposium on Network Operations and Management: Challenges for Next Generation
Network Operations and Service Management, 2008.
9. Schonwalder, J., Pras, A., and Martin-Flatin, J.P. On the Future of Internet Management
Technologies. IEEE Communications Magazine, vol 41, pages 90- 97
10. Phil Shafer, Juniper. An NETCONF- and NETMOD-based Architecture for Network Management.
http://www.ietf.org/id/draft-ietf-netmod-arch-05.txt.
Tail-f Systems © 2010
Page 11 of 11