Directory Enabled Networks - The DEN Value Proposition

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By John Strassner, from Directory Enabled Networking (New Riders)

Directory Enabled Networks (DENs) describe a philosophy for transforming the network from a passive collection of devices that route and forward traffic to an active set of cooperating devices that intelligently provide services to the user. DEN can fundamentally change how applications, along with network elements and services, are developed and used.

This chapter provides an overview of the value of DEN and examines some of the benefits it can provide. It then describes how Intelligent Network can be more easily implemented with DEN, and concludes with which standards bodies are currently guiding the further development of DEN.

On This Page

What Is DEN?
Principal Goals of DEN
Realizing Intelligent Network with DEN
The Directory and DEN
Policy Controlled Networking Using DEN
Intelligent Network Device Configuration Using DEN
Characteristics of a DEN-Based Intelligent Network
Transition from a Passive to an Active Network Model
Personalization of Network Services
Coordination of Network Services
Benefits of Intelligent Network
DEN, the DMTF, and the IETF
Summary
Recommended Further Study and References

What Is DEN?

DEN is not a product, or even a technology. DEN is a specification that defines an information model. This prescribes an interoperable model of network elements and services, and how each interacts with other elements of a distributed system. As such, it is an extension of the Common Information Model (CIM) of the Desktop Management Task Force (DMTF). An information model is a means of describing objects comprising a system, their inter-relationships and behavior, and how data flows within the system. CIM is an object-oriented extensible information model for managing systems and devices. We'll explore information models and CIM in much more depth in Chapters 2 and 6, respectively.

CIM defines specific devices and systems that are to be managed. DEN builds on CIM by defining network elements and services, along with the general concepts of profiles and policies, that can be used with CIM objects to model the functions and behavior of a system. The DEN information model can be viewed as an extensible template. The fixed parts of the template describe network elements and services. The variable parts are defined by the specific CIM models that are used, which define various devices and systems that interface with network elements and services. DEN, then, is a way to manage a system that uses network elements and services.

Motivation Behind DEN: Building Intelligent Network

Technology keeps evolving, and networks have become increasingly complex in an attempt to provide better service and to meet the needs of an increased number of users and more sophisticated applications. The increasing number of different types of network elements, each running a (potentially) different set of protocols and services over (possibly) different media, has resulted in an application model that is referred to as stovepipe applications for building network configuration and management applications. For example, in this model, individual applications store their own data needed to configure a device in their own private data stores. This means that the same object (for example, users and devices) may be stored in different ways (for example, named differently). Even if the same representation is used in the different data stores, applications can still only access their own data, and they cannot interoperate with each other.

Two of the promises of DEN are to define a means to store data in a common repository and to provide a way for applications to be able to take advantage of data managed by other applications. This represents a fundamentally new way of thinking about network management applications, along with applications that seek to leverage the power of the network. One example of this is to compare existing network management with directory-based network management that uses DEN. In a traditional network management system, each device in the network is represented once. However, each device has detailed configuration information that is stored not in the network management system, but in either the application itself or in another data store. The role of portraying the device in the network management system is to enable the user to launch a particular management application that is focused on one or more aspects of managing that device. Thus, the network management system provides a common place to represent the device, but not to store its information.

Note: This is very different than a directory-based approach that uses DEN. The fundamental purpose of DEN is to provide a common, unifying information repository that is used to store data and information about the data (that is, metadata) for multiple applications to share and use. This is examined more thoroughly in Chapters 4, 5, and 11.

Thankfully, there are measures that can be taken to alleviate these problems. These take the form of separate efforts that were united in the DEN Initiative and consist of

  • Better utilizing the directory, which is discussed in Chapters 4 and 5

  • Developing and using an information model for representing network element and

  • service information, which is discussed in Chapters 2, 3, and 6 through 10

  • Simplifying the implementation of Intelligent Network, which is discussed in Chapters 11 through 13

Note: The DEN Initiative refers to the formation of an industry-wide ad-hoc working group to develop the DEN specification. The DEN specification is now under the charter of DMTF.

Key to this effort is the transformation of the network from a "dumb" to a "smart" entity. Currently, the network consists of a set of devices that work semi-autonomously. This does not mean to say that there is no information exchanged between the devices. Rather, it means that there is a lack of cooperation between the devices in implementing a service on behalf of a client. The "intelligent" network is one that consists of a set of devices that work together, each delivering its own part to implement a service, and adjusting as appropriate to changes in the environment in order to continue to deliver that service. The intelligent network is one where devices have distinct embedded intelligence, as in the capability to configure themselves. This is the subject of Chapters 11 through 13.

The network must support the differentiation of traffic and application of different qualities of service to different users and applications. Services, not just traffic forwarding or bandwidth, are what is now important.

There are many factors driving the need for an intelligent network. These include customer demand for applications that provide greater productivity, the need of the service provider to support differentiated services, and the need of the enterprise to ensure that the various needs of its traffic are given the appropriate priority. For example, the delivery of mission-critical traffic must be protected from people casually browsing the Internet and downloading large graphics.

The Internet is alluring due to its greatly simplified interaction paradigm, which enables the user to simply click on an object to retrieve more information about that object, and is considerably simpler than even many GUI applications, let alone applications that use a character-based or command line interface. Consequently, application vendors are striving to "Internet-enable" their applications. However, there are many applications, such as intra- and inter-company collaboration (for example, shared white boards and video-conferencing) and electronic commerce tools, that have specialized needs that traditional "best-effort" services cannot support.

The preceding is exacerbated by the growth of private intranets and secure extranets. These require additional security and traffic conditioning options above and beyond the (public) Internet.

DEN was conceived in large part to satisfy these and other concerns. DEN addressed these concerns in two ways:

  • DEN defined a specification to represent and share information. This is the first step in building an intelligent network.

  • It was a method to link business processes and requirements to network elements and services. For example, a service level agreement (SLA) defines a service contract between a customer and a service provider that specifies the expected operational characteristics of their relationship (for example, how to treat different types of traffic). An SLA may be written in relatively high-level terms (for example, provide this subscriber access to his or her corporate intranet). The danger is that the translation of this high-level objective to low-level network commands may be difficult as well as non-standard in a heterogeneous network.

DEN provides specific mechanisms to form the basis of this association in the design of its network element and services classes along with its policy classes (see Chapters 9 and 10). An added benefit is that the users and applications that consume those services can also be linked to both the business processes as well as the network elements and services.

Principal Goals of DEN

DEN has four main objectives:

  • To model network elements and services, and their interaction with other elements in a managed system

  • To provide the means for interoperable network-enabled solutions to be built

  • To enable applications to leverage the power of the network without requiring the user to know or set esoteric network-related information

  • To define a way to manage the network, as opposed to an element within a network

These objectives are described more fully in the following sections.

Modeling Network Elements and Services

Before DEN, directories did not include objects for representing or managing network elements and services. Furthermore, directories were often used to support a single application or set of applications. This gave rise to conflicting schemata that were not compatible with each other. For example, a company might have an email directory and an HR directory. A user might be represented as johns in one and jstrassn in the other. There is no simple way to know that these are in fact the same objects, which means that data not only cannot be shared, but also must be duplicated in each directory.

Furthermore, there is no easy method to determine which data is associated with which object (for example, mail settings are associated with johns, but salary and staff are associated with the jstrassn object). This, of course, increases the overall cost in managing the data and the applications that want to use the data. Management has two aspects here:

  • Consistency checking—Each object must be checked for any changes each time a change to the data it represents changes.

  • Referential integrity—Some objects refer to other objects (for example, the supervisor of a set of employees); when a new supervisor is added or deleted, changes to the employees that are under his or her supervision must also be made.

This segregation of data is referred to as creating information islands, which is the separation of what should be common data that lives in a single common repository into separate data stores. The problem is that data that should be shared is not and cannot be shared. Information islands have in part prevented the development of standard schemata to represent these objects. For example, there are several conflicting proposals for object classes that represent users—see, for example, the Internet Organizational Person proposal from Netscape [INTOPS] and the LIPS schema proposal from the Networks Application Consortium [LIPS]. Both of these are proposals for representing user attributes in a directory.

Schema Standardization

The worry over the lack of standard schemata was, in fact, one of the driving factors behind DEN. Specifically, there was concern that network elements and services were much more complex objects than the traditional objects that were contained in a directory (for example, user and printer objects). DEN therefore needed to propose a standard schema for describing network elements and services before multiple proposals that conflicted with each other (as was the case with person objects) were generated. If everyone could agree on a single standard schema, it would be much easier to build directory-enabled solutions. This was accomplished in the DEN Initiative through two open meetings and an active email list.

In summary, two related problems were addressed by DEN:

  • Network elements and services must be modeled and represented by appropriate object classes in the directory.

  • A standard set of object classes, or schema, must be created to prevent the generation of multiple conflicting proposals to model network elements and services.

When DEN was being designed, it was decided that just defining a set of object classes and attributes to represent network elements and services was not enough. Even if this set of classes was standardized, the result would not be good enough, because schemata don't capture behavior, object relationships, and other non-structural aspects of interacting with a system. This is especially important for a network, whose behavior changes dynamically as a function of the environment.

Instead, a standard information model for representing network elements and services had to be developed. This was especially important because of the increased complexity involved in modeling network elements and services and the different ways they interact with applications, users, and systems. The DEN Initiative stated this as an explicit goal, which was endorsed by more than 175 vendors and customers. The DEN information model has provided a strong foundation for modeling the physical and logical aspects of network elements and services. Furthermore, since it is designed to be an extensible schema, adding new functionality will not affect existing functionality. This, in fact, is what the Networks Working Group of the DMTF is currently doing.

What Is the DMTF?

The Distributed Management Task Force (DMTF) is an industry consortium founded in 1992. It is chartered with the development, support, and maintenance of management standards that simplify the burden of enterprise management. These include Desktop Management Interface (DMI), Common Information Model (CIM), and Web-Based Enterprise Management (WBEM).

The DMTF uses a collaborative, working-committee approach that involves its members in the development of its specifications. The DMTF also works closely with related industry organizations such as the IETF, The Open Group, and the Network Management Forum (NMF) to ensure that DMTF solutions thoroughly address customer issues and overall management needs.

The goal of the DMTF is to ease the burden of PC and enterprise system management, consequently reducing the total cost of ownership.

Building Interoperable Network-Enabled Solutions

The growth in complexity in network functionality has had several impacts. First, configuring an individual network device has become increasingly complicated. This makes configuring a set of network devices to cooperatively work with each other even more difficult. Second, managing a network device is becoming more complicated. This is exacerbated by the greatly increasing number of users who want to use networked devices. The Internet, the growing popularity of extranets for linking together business partners, and the increased features of applications and their network requirements have resulted in a dramatic increase in the number, as well as the complexity, of network devices required.

This trend will keep increasing as people embrace the simpler interface paradigms of the Internet and demand applications with greater functionality to increase their productivity. So how will the needs of these more advanced applications be met?

Fundamentally, applications require the capability to have their traffic differentiated from other traffic. This enables their traffic to receive preferential services. This also implies the need to be able to quickly reconfigure the network in response to an ever-changing environment. In addition, management must be improved so that it is easier to coordinate multiple devices in providing a service. Many technological hurdles must be overcome; the following are the most important of these:

  • Interoperability within the network

  • Interoperability among different networking vendors

  • Interoperability among the different network management applications from

  • different vendors that comprise a network management system

  • Network model extensibility

  • The capability to identify and use the same class of service across different networking technologies

  • Managing the different services in a multi-service network

  • Integrating networking concepts with directories

Interoperability Within the Network

Network design will optimize traffic along different layers. For example, if we consider a service provider architecture, Layer 1 and 2 networks supply traffic from various customers into the network of the Internet service provider (ISP). Different technologies, such as SONET, Dial, Frame Relay, xDSL, and ISDN, all route traffic to the network, which now has to figure out what to do with each type of traffic. The ISP network will use Layers 2 and 3 technologies to treat each traffic stream appropriately. This is illustrated in Figure 1.1.

Cc750196.01fig01(en-us,TechNet.10).gif

Figure 1.1: Simplified service provider support architecture.

In the ISP's network, the network elements at the edge of the network perform a much different set of functions than those in the core of the network. Network elements at the edge are responsible for identifying, filtering, and controlling traffic, whereas network elements at the core of the network want to forward traffic as quickly and as efficiently as possible, along with managing congestion if it occurs. Network edge elements are where service policies are applied and where statistics on customer usage are gathered. Consequently, these devices require the highest intelligence to differentiate traffic and provide the flexibility to create new services.

This implies that to provide an end-to-end service, the edge and core devices must work together to condition the traffic appropriately. DEN is more than just a model that represents the functionality of a given network element; it contains metadata (for example, data describing the purpose and/or use of data) that enable the function or role of the modeled component to be described. This helps relate edge and core functions to the provisioning of a network service.

Interoperability Among Different Networking Vendors

Most service providers and enterprises want to use equipment from different network vendors. This helps them maintain their relative independence from networking vendors. This enables service providers and enterprises to use specialized equipment, provides a good balance between functionality and cost, and diminishes the chances of any one supplier from furnishing all their needs. However, it complicates matters because different network elements now must recognize the same service and play their parts in providing that service. This applies not just to network elements, but also to host devices and servers. For example, Figure 1.2 shows a route that electronic commerce traffic took from within Cisco to a vendor on the Internet.

Cc750196.01fig02(en-us,TechNet.10).gif

Figure 1.2: The complexities in providing an end-to-end service.

DEN provides an extensible information model to help achieve this interoperability between network elements, servers, applications, and other components of an end-to-end service. DEN models each of these components in a customizable amount of detail; then models their various inter-relationships. DEN provides a rich foundation for defining policies to control, manage, and share data between multiple components in a vendor-independent way.

The work of the Policy Framework Working Group of the IETF [PFWG] is also of great importance in solving this problem. This is discussed more thoroughly in Chapters 10 and 11. Note that the PFWG is using all the DEN policy classes as the basis for its work.

Network Model Extensibility

It is very important that the underlying network model be extensible by vendors in order to model their specific devices and mechanisms. This requires a way for the model to enable common information to be communicated in a vendor-independent fashion while providing a means for vendor-specific information to be represented and mapped to the vendor-independent information.

For example, the physical aspects of a network element are divided into a number of different DEN classes. PhysicalPackage is a class that represents physical elements that contain or host other physical elements. Card is a class that defines the characteristics of different types of cards that can be installed in a network device, such as system, networking, and memory cards. There are additional classes that model other physical aspects of a network device. This paradigm of partitioning functionality into separate, modular classes enables vendors to model common information using standard DEN classes and to model vendor-specific information using vendor-specific subclasses derived from the DEN standard classes.

As another example, assume that a Gold class of service is to be provided for streaming video traffic. Further suppose that this traffic will pass through the equipment of multiple network vendors. The parameters of this Gold class of services in high-level terms (for example, jitter, latency, and so on) must be able to be specified in a vendor-independent manner. Each vendor's network element must be able to recognize what is required of that device relative to the delivery of the traffic according to Gold service contract and configure the device appropriately. For example, one vendor might use one form of queuing to manage congestion, whereas another might use a different form of queuing for the same function. Furthermore, this must be equated to the proper filtering and shaping mechanisms used by other mechanisms.

This is accomplished by using DEN as the foundation to define what these services mean and how their corresponding mechanisms are used to implement these services. DEN can also be used to manage the configuration of these devices, and to model what would happen in the rest of the network if device configurations were changed.

Finally, DEN forms the basis of the work of the PFWG, which is defining

  • An overall architecture in which multiple vendors can control heterogeneous devices within a specific policy domain

  • A schema, based on the DEN policy classes, that defines a common representation of policy information and structure to be stored in a policy repository

  • A vendor- and device-independent language to describe policies

Policy services can be provisioned and managed within this standard architecture by using the DEN policy schema. This is discussed further in Chapter 10.

In summary, DEN provides an information model to relate services to systems to hardware.

Mapping the Same Class of Service to Different Networking Technologies

This is a much more difficult problem than it sounds. In general, there are several problems in selecting and delivering a specific class of service or quality of service and communicating that selection between different technologies. This is because different technologies define different mechanisms for delivering these services, and as the packets flow across protocol boundaries, the class of service configuration information is lost because the two protocols do not communicate with each other. For example, the configuration information in Layer 2 signaling mechanisms (such as Frame Relay's Committed Information Rate) cannot be directly communicated to Layer 3 protocols.

This is where DEN can help. DEN can model protocols as well as specific mechanisms used at a given networking layer (for example, different types of queuing and traffic shaping). DEN can add metadata that equates Frame Relay Committed Information Rate to the appropriate Layer 3 mechanisms. This in turn helps the network designer deliver a comprehensive end-to-end strategy that uses the appropriate technology at each given point in the network.

Managing the Different Services in a Multi-Service Network

A multi-service network is defined as a single backbone that combines different technologies to produce a common platform for all offered services (see Figure 1.3).

Cc750196.01fig03(en-us,TechNet.10).gif

Figure 1.3: A multi-service network.

The advantage of using a multi-service network is that it provides more flexibility in deploying services: it allows differentiation by services, quality, or cost. An ATM/SONET backbone is scalable and reliable, and when integrated with IP services, provides easily configurable and customizable services. The problem with using a multi-service network is that a set of different services and technologies is brought together in a single offering.

DEN can make the advantages greater while mitigating the disadvantages. DEN provides a rich model to describe the design of the multi-service network and to plan its configuration. It also enables the many disparate services and technologies provided to be conceptually, logically, and physically modeled as a single cooperating platform.

Integrating Networking Concepts with Directories

Besides being a powerful mechanism to search, find, and retrieve information, directories are the de facto method for representing people, printers, and other common resources on the network. One of the goals of the DEN Initiative was to leverage this use of the directory so that services provided by the network could be associated with clients of the network. This is the first step toward making network devices more intelligent.

By modeling network elements and services and their interaction with other managed system components, DEN enables applications to leverage the power of the network without requiring the user to know or set esoteric system- and network-related information.

Leveraging the Network Using DEN

One of the most important aspects of DEN is that it provides an interoperable information model for exchanging management, as well as operational and functional information describing the network and the systems the network communicates with. This enables network-enabled solutions to be built.

A network-enabled solution is a set of cooperating products and technologies that transparently leverage the network to provide services for its clients. The key word here is transparently. Applications are getting more and more complex as a greater number of people want to use the Internet for an increasingly different set of tasks. Applications therefore require more from the network to provide the user with a good end-user experience as well as to be able to function properly.

Traditionally, this has come at the expense of the user. The user has been required to perform complicated application setup and configuration requirements, know special network and other system settings, and carry out other similarly difficult tasks. DEN offers the promise of embedding this required knowledge in the network and the systems in which the network resides. This enables the application to negotiate appropriate settings with the system to meet the needs of the user without requiring the user to get involved in this process.

DEN Profile classes can be used to personalize the end-user experience as well as customize and store these settings. DEN network element and service classes, as well as application and system classes, can be used to model the components providing the desired services to enable the application to negotiate appropriate settings with the network and the rest of the system.

Finally, DEN Policy classes can be used to control these settings and ensure that they don't conflict with other services the network provides.

Managing the Network Using DEN

There is a large body of work that defines how to manage individual network elements. Recent IETF working groups have started to address managing some network services (primarily to provide a prescribed quality of service [QoS]). However, the management and configuration of a network has yet to be addressed by anything other than DEN. This is what makes DEN different from other efforts. DEN has defined a way to manage the network, as opposed to an element within a network. Similarly, DEN provides a way to manage all the services provided by the network, as opposed to one specific service (that is not related to the other services) provided by the network. This is what makes DEN fundamentally different from SNMP, RMON, and other similar efforts.

Note: It is important to note the difference between how the Lightweight Directory Access Protocol (LDAP) and the Simple Network Management Protocol (SNMP) are used with respect to DEN and managing the network compared to an individual device. LDAP is a directory access protocol and is used to talk to the directory about devices. SNMP is a network management protocol and is used to talk to devices directly. New devices will have the capability to talk SNMP and LDAP.

So how does this fit together? DEN is an information model that unifies data; it defines how to use diverse information to completely describe an entity. As such, DEN unites information contained in directories with other information, such as that gathered from SNMP agents. This enables a more complete picture to be obtained about how the device is currently functioning (from SNMP data) compared to how it is supposed to function.

DEN does this in an extensible manner. All objects that are managed-whether network elements, network services, computers, or other components-are described in both physical as well as logical terms. Furthermore, DEN describes the function of the object as well as how it relates to other objects, and, in certain cases, how it may be used.

Realizing Intelligent Network with DEN

Historically, networks have treated the traffic from every user and application the same. This has often been referred to as a "best effort" service. Unfortunately, this is no longer good enough. For a variety of reasons, enterprises, service providers, and even small businesses are changing to a more intelligent, services-oriented model wherein the network can provide differentiated services to certain users and applications. This is referred to as the intelligent network.

The network gains its intelligence in several ways. These include

  • A robust information model (DEN) for modeling the network and its interaction with the environment

  • A directory as a unified information repository

  • Unique data stores for supplying specific types of information

  • Specialized system components (for example, Policy Servers) for managing and coordinating traffic

The interaction of users and applications with the intelligent network is represented conceptually in Figure 1.4.

Cc750196.01fig04(en-us,TechNet.10).gif

Figure 1.4: Interaction with the intelligent network.

The Directory and DEN

Directories are used to store, identify, and retrieve various types of resources and information in a distributed computing environment. Resources represent objects, such as users, groups, file servers, and printers, which serve a defined purpose in the computing environment. Directory services also provide the foundation for adding, modifying, removing, renaming, and managing system components without disrupting the services provided by other system components.

The advantage of the directory is that it can be used as a single logical repository for storing and accessing information about services provided by the network and clients that want to use those services. The directory serves as the single source of information for the diverse components of a system from which to obtain information.

Policy Controlled Networking Using DEN

One of DEN's strengths is its definition of Policy classes. The successful wide-scale deployment of advanced networks and the services they offer depends on the capability to administer and distribute consistent network element and network service configurations and other types of information. This requires a set of policies that manage and configure the network elements appropriately based on the client of the network.

Policy is used to ensure that different network elements have the same interpretation of the business functions and services they are providing as a group. This requires a dedicated architecture to define, edit, and manage policies, as well as to detect conflicts between different policies and to resolve those conflicts. The DEN Policy class hierarchy plays an essential role in this architecture.

Using Policy to control networks and networked applications requires the following four elements:

  • An extensible information model for network elements, network services, networks, and clients of the network

  • A scalable framework for policy administration, management, conflict resolution, and distribution

  • A policy specification, written in terms of a policy definition language, that can represent business requirements and functions in a vendor- and device-independent manner

  • A scalable means to translate from the device- and vendor-independent policy specification to vendor- and device-specific configuration commands

DEN is the extensible information model referred to in the first point. The PFWG is providing an architecture that meets the second requirement. The PFWG is also defining a Policy Definition Language that has all the characteristics of the third requirement.

The Policy Definition Language becomes the way to ensure that multiple vendors interpret the policy the same way while enabling vendors to provide value-added services. The fourth point is necessarily vendor-specific. Examples illustrating the power of these features working together are given in Chapter 11.

Intelligent Network Device Configuration Using DEN

The use of the directory in applications that administer or configure the network is a powerful configuration management paradigm. It is a way to manage the network, as opposed to individual systems or devices in the network. It is, therefore, inherently different from SNMP and better suited than SNMP to the task of expressing and distributing policy or other types of information that affects multiple devices.

So, where should the added intelligence reside? Simply put, in the network element itself. This will encourage a new era of network elements to be built, which have special capabilities to enable them to respond as managed system elements. Such capabilities will include

  • Dedicated directory interfaces, such as LDAP

  • Dedicated policy interfaces, such as those provided by the Common Open Policy Service (COPS) protocol

  • Dedicated software and/or hardware to generate and respond to policy events

  • Dedicated software and/or hardware to interpret policy requests and commands

This does not mean that functionality such as that offered by SNMP is no longer needed. In fact, it means almost the opposite. SNMP provides specialized information that plays a vital role in managing some system functions. Directories in general and DEN in particular provide a means to integrate information such as that provided by SNMP or RMON with other vital network and system information.

As an example, DEN and the Policy Definition Language provide the ability to define a business function or service ("Voice traffic should get the following class of service in this network") and then relate this directly to a set of device configurations that must be executed. Individual systems and devices will have to interpret this policy locally. For example, one instance may interpret this as Voice over IP. (VoIP) traffic is marked with the Per Hop Behavior of 111000, and should be admitted using RSVP and placed into the EF queue on each interface.

Note: Per Hop Behavior and EF are defined in the Differentiated Services Architecture [DSARCH]. It defines externally observable forwarding behavior applied at a network device.

Another instance might instead use a different Per Hop Behavior that prescribes a different queuing mechanism. DEN enables these different queuing mechanisms to be recognized as being applicable to supplying the same business function.

Configuring network elements is becoming increasingly complicated. SNMP could be used to monitor and perform certain types of configuration, while the directory could manage other aspects of configuration, and manual configuration could be required perhaps for yet other kinds of configuration. DEN provides the framework for keeping these different, yet related, configuration tasks coordinated and applied to the appropriate devices.

More importantly, DEN provides the foundation for translating the business requirement into network device configuration commands. DEN can also represent the equating of the different Per Hop Behaviors, the different mechanisms that they imply, and the relation between signaled and provisioned network services. DEN provides a higher level of abstraction of modeling the network and its services than SNMP and other similar functions. By thinking in this more abstract way, DEN enables new solutions to be built by being able to integrate and use different types of information that are tailored to represent different aspects of network configuration.

Characteristics of a DEN-Based Intelligent Network

The best way to define the features and functions of an intelligent network is to see how it would be managed and function compared to the way existing networks are managed and function. Table 1.1 compares the old (non-DEN) and new (DEN) ways of developing and using applications.

Table 1.1 Comparison Between Current Networks and the Intelligent Network of the Future

Feature or Function

Existing Network Implementation

Intelligent Network Implementation

Configuration Approach

Focus is on configuring individual devices

Focus is on configuring the network and ensuring that all devices in the network work together.

Configuration Process

Separate processes to configure people, applications, and Devices

Links devices to people, applications, and other resources as part of the same process.

Management

A set of loosely related applications that are oriented towards managing individual devices

One or more layered applications that manage the network (with the ability to drill down into network components) as well as devices in the network (with the ability to abstract up into aggregations of devices and the network).

Policy

If present, used to control individual device configurations

Integral part of the system. Used to control the configuration of the system and its components.

Use of Directory

Isolated functionality, if used at all

Integral-it is a unifying information repository.

Use of an Information Model

Not Used

Integral-it models network elements, the network, network services, and how the network relates to the rest of the system.

Passive or Active

Passive-network elements are assigned a role to play in providing network services

Active-network elements play a dynamically changing role in providing network services.

Modeling System Components

Treat applications, devices, services and people as separate entities

Treat applications, devices, services, and people as an integral partnership.

The modeling of system components is especially important. The Intelligent Network binds clients of the network-whether they are users, applications, processes, or services-to the services they require of the network as a function of the application, location, job role, and other factors that belong to both the client and the network.

Transition from a Passive to an Active Network Model

The previous sections have described a transition from a "passive" network model to an "active, services-based intelligent" network model. This is one of the most important things the DEN Initiative started. DEN defined a new approach to building Intelligent Network by introducing the notion of a logically centralized common repository where network elements and services are represented in a common way. This enables applications of different types and functions to use and share information about network elements and services. The notion of a common repository in turn united the up-to-then separate worlds of networking and Object-Oriented Modeling.

This transition replaces the current practice of operating on a best-effort model with a set of dynamic, interoperable services. These services can be customized in a number of different dimensions:

  • With respect to business requirements and processes through a service level agreement

  • As a function of the individual user or application

  • As a function of the group, organization, or other aggregate the client is a part of

  • As a function of the role that the client plays in the group, organization, and so on

  • As a function of the time of day or some other combination of statically defined parameters

  • With respect to a unique event that occurred dynamically (for example, a stock market crash or a firewall breach)

The Intelligent Network unites different technologies, including network- and application-oriented technologies, with specialized services. These services include

  • Standard network services, such as switching and routing

  • Advanced network services (for example, class of service, quality of service, and address management)

  • Other related services (for example, security, including access control and encryption)

The unification of these diverse services can be achieved because of the architecture proposed by standards organizations such as the PFWG and the Networks Working Group of the DMTF, the use of a common information model (DEN), and the use of the directory as a unifying information repository. The result is a unified architecture for managing complex distributed systems in an extensible, object-oriented way.

The Intelligent Network model provides a compelling set of benefits, including the following:

  • Capability to personalize network services

  • Capability to coordinate network services

  • Support for more advanced applications that require specialized network services and treatment without requiring knowledge and interaction from the end user

  • Capability to accommodate QoS and other dynamically changing network services

Personalization of Network Services

Providing value-added services that differentiate classes of users, especially if they offer the capability to be customized to suit the needs of a particular user, are of great importance to service providers. The following two examples describe two different ways in which DEN can help the application developer as well as the service provider and enterprise deliver a better, more compelling end-user experience.

Customizing an Application for Different Users

Consider an application that requires special treatment from the network (for example, NetMeeting, which must have a defined jitter and latency to operate correctly). Assume that there is congestion in the network and that the combination of parameters required for optimal delivery of the full-motion video (bandwidth, jitter, latency, and so on) is not simultaneously available. One user might be willing to sacrifice frame rate in order to view a full-motion video, while another user might instead want to adjust the window size or reduce the color palette, but keep the frame rate as fast as possible. What is required is the capability to

  • Differentiate the different components of the NetMeeting traffic from the other traffic types in the network.

  • Recognize that NetMeeting traffic is in fact comprised of data, audio, and video traffic that require different levels of QoS.

  • Validate that a given client is authorized to have preferential treatment for its NetMeeting traffic, and then ensure that preferential treatment is in fact provided.

DEN helps solve these requirements because its information model can be used to associate the different needs of an application with users and ensure that the appropriate service level agreement is satisfied. DEN Profile classes can be associated with the user (or a higher-level aggregate, such as a group or OrganizationalUnit). DEN Service classes can be used to model the needs of NetMeeting. DEN Policy classes can be used to ensure that traffic differentiation, as defined by any service level agreements, are related to a user as well as a network and an application. It should be noted that either the native DEN classes or subclasses of these DEN classes can be used to incorporate application-specific information. For example, the DEN Profile classes may be subclasses so they can store application profile settings. Subclassing, as explained in Chapter 2, is a way of refining the definition of an existing class such that the new class inherits all the existing attributes and methods of the parent class but also adds new attributes and behavior.

Note: OrganizationalUnit is an X.500 term that refers to a unit of management of a company or organization.

Customizing an Application for Different Events

Most enterprises and service providers build their networks to support a pre-defined set of applications. This is done by mapping the needs of these applications into pre-defined, pre-provisioned service classes. For example, "best-effort" traffic may be assigned to FTP and Telnet applications, whereas certain types of users (for example, the CEO and CTO) may get preferential treatment, and business applications may get a different type of traffic conditioning.

What happens when an unusual event occurs? The CEO might require extra bandwidth for an important video conference, or a stock market crash might have just occurred. Such events cannot really be pre-planned, as they require an abnormally large expenditure of resources for their successful completion. Plus, there is really no way to anticipate when they will occur.

DEN, in combination with middleware solutions that provide, for example, a publish-subscribe event mechanism, can be used to plan for such situations. When these events are detected, the appropriate event(s) can be sent and detected by an entity that is responsible for controlling the configuration of the network (for example, the "Policy Server" described in the Policy Framework, Differentiated Services, and RAP working groups of the IETF). The Policy Server can then issue some emergency configuration changes that all or part of the network will respond to. The modeling of these changes is again made possible by the use of appropriate DEN classes. The advantage is that the network will not have to be engineered to meet these requests statically; it can intelligently react to the changing needs of its environment.

Coordination of Network Services

Sometimes, different network services need to be coordinated to satisfy a particular policy or service level agreement. For example, a video conference might use the Resource Reservation Protocol (RSVP, an explicit signaling mechanism) for reserving bandwidth necessary to conduct the video conference, and then use different mechanisms to ensure that the traffic is detected, prioritized properly, and given precedence. This might require different mechanisms to manage congestion it experiences or to rate-limit its input. All these are different "micro-services" that together implement the "macro-service" according to a prescribed service level agreement.

Note: RSVP is used by a host to request a specific QoS from the network for particular traffic. The network in turn passes these QoS requests to all nodes along the path(s) of the flow of traffic, and establishes and maintains state to provide the requested service. RSVP requests generally result in resources being reserved in each node along the data path.

When multiple services are used to realize a single function, it is imperative that they be properly coordinated. DEN Policy and Service classes (among others) can be used to do this.

Support for Advanced Applications

Certain types of applications require special treatment. For example, some applications use dynamic or negotiated application ports to communicate. A simple example is Telnet. When the Telnet session is opened, the TCP source port is chosen dynamically, while the TCP destination port is fixed (port 23). More complex examples include video-conferencing traffic, as well as many business applications (such as PeopleSoft or SAP), that use a special protocol to negotiate the ports they require. This presents particular problems for firewalls; if they don't know the port beforehand, they can't be configured to admit the traffic.

DEN can be used to model the requirements of these applications. Then, in combination with other techniques (such as stateful inspection), the appropriate action can be taken.

Note: Stateful inspection is a technique used to inspect the control flows associated with an application to determine the particular TCP or UDP port numbers currently in use by the application.

Support for Dynamically Changing Network Services

Consider a network that has different classes of service. Congestion occurs because too much traffic is generated. Policies can govern which clients continue to receive service and which get a degraded form of service. Within a particular service class, policies can even be used to differentiate clients that meet the general requirements of that class. But what happens when the CEO logs on and there isn't enough bandwidth available for him or her to work?

Fortunately, DEN can be used to help plan for such circumstances. In this case, we must find enough bandwidth to make the CEO happy. Since DEN models users and applications as well as services, we can make a detailed matrix that determines how to obtain the required bandwidth for the CEO. This matrix details what qualities (for example, bandwidth, latency, and so on) each application the CEO runs should be assigned. The matrix is then stored in a common (DEN) repository. This enables all applications and policy decision and enforcement devices (see Chapter 11) to ensure that the CEO obtains the desired services. For example, policy decision and enforcement devices can be used to detect traffic from the CEO. They follow the general guidelines of the different service classes defined in this common matrix, but are free to modify them to obtain their application- and/or user-specific goals. This may take the form of degrading or even logging out other users to retrieve the required bandwidth under severe conditions of network congestion. Without DEN, there is no structured way to do this because of the number of different types of objects (users, applications, SLAs, capabilities of certain devices in the network, and so on) that must concurrently be changed.

Benefits of Intelligent Network

As businesses increase their use of various forms of networking-the Internet, as well as corporate intranets and extranets-Intelligent Networks become more and more important. This enables two important benefits to be realized: differentiated services and more efficient sharing of networked resources between users and applications.

There are three main problems faced in building Intelligent Networks:

  • Managing the increasing configuration complexity of devices

  • Ensuring that consistent policies are applied to all elements of the system

  • Enabling the needs of applications to be related to the services the network provides

This is shown conceptually in Figure 1.5.

Cc750196.01fig05(en-us,TechNet.10).gif

Figure 1.5: Problems the Intelligent Network solves, and derived benefits.

Key to all these is the capability to manage and maintain a comprehensive Information Model that enables each of these components to be related to each other. The Information Model presents a single mechanism to represent how network elements provide services, and how policies can be used to control them. It also links to existing models of users, applications, printers, and other resources, and associates their use with network services.

This results in a new philosophy that can be used to build Intelligent Networks: a service-oriented philosophy. Enterprises and service providers alike can use this.

Many specific benefits can be obtained from a directory-enabled network. The rest of this section provides a brief overview of some of them. These are all discussed more thoroughly in Chapters 11 through 13.

Enterprises

Enterprises can use DEN in many different ways. However, they are concerned mostly with its application to policy-controlled network services.Enterprises can lose millions of dollars in a matter of hours if a mission-critical application becomes unavailable or does not run correctly, quickly, or completely. Mission-critical applications need special handling to ensure that delivery of their traffic will not be adversely affected by other applications using the network.

As important as mission-critical applications are, however, enterprises must also strive to satisfy the needs of the rest of their users. This includes accommodating the special needs of Web traffic (including push technology and dynamic Java applets) as well as multi-media and voice applications (including distance learning and training, audio- and video-conferencing, and collaborative applications). These application needs must be combined with the rest of the traffic, which should receive "best-effort" delivery.

Both of these require associating a given user or application with a number of different parameters (time of day, job role or function of the user, type of traffic being sent, and so on). The combination of a large number of parameters and a large number of objects mandates a robust information model. The directory is particularly well suited to represent users, applications, printers, and so on, and DEN defines additional objects that can be used to represent network elements and services. These diverse objects are then combined into a managed system through the use of relationships and other object-oriented tools of the DEN information model.

The association between user and service must be done independent of location and type of connection to as large an extent as possible. This requires intimate knowledge of the physical and logical topology of the network, which is provided by the DEN information model. DEN provides a framework for associating all of these complex elements together through the coordinated modeling of each element in the system. It also provides a way for enterprises to define policy and use it to assign different levels of service to its users and applications.

Service Providers

Service providers need the ability to differentiate their service offerings based on providing added value. This added value is achieved through the delivery of end-to-end services that offer a wide variety of pricing options based on the type of service, quality of service, and usage. This is complicated by the desire of service providers to address many different market segments.

Therefore, service providers demand an open, standards-based solution that can be integrated with existing legacy systems while providing a minimum of, and preferably no, disruption to their currently deployed services. Many service providers are looking toward work being done in the IETF to standardize the protocols and APIs, and more recently schemata, used to build their infrastructure.

DEN is well-suited to meet these requirements. DEN is itself a standard and is being used now by several groups of the IETF. In addition, important IETF work, like the differentiated services [DIFSRV] and integrated services [INTSRV] efforts, along with the Policy Framework [PFWG] work, can all be modeled using DEN. The DEN framework is able to model these protocols and architectures and, more importantly, relate them to other managed systems and system elements.

Perhaps the most important benefit to service providers is the following: DEN enables service providers to sell services, as opposed to "just" connections.

Developers and Independent Software Vendors

Developers and independent software vendors (ISVs) are very excited about DEN. This is because the DEN information model enables the developer or ISV to represent the entire system and how each component communicates with each other. This in turn provides a means for applications to take advantage of the power of the network in a transparent fashion.

Consider a video-conferencing application. DEN provides the application developer with additional information that can be detected by the network and used to provide a more powerful and compelling end-user experience. This is illustrated by the following example.

Suppose that users log onto the network using dynamically assigned IP addresses (for example, using DHCP). Further suppose that software is in place that detects each logon and, through querying various DEN classes, determines if that user can run a video-conferencing application. If it is determined that the user can run a video-conferencing application, software can gather information defining how a user is currently logging onto the network (for example, through Ethernet in the corporate campus, or through a PPP analog modem). The type of connection, plus additional information (for example, which subnet the user is placed on) can then be used to determine default settings for the video-conferencing application (for example, don't send streaming video over a slow modem connection; instead, send text). Network information can be used to further supplement this (for example, a particular network policy is in place that restricts the services a user receives when that user logs on).

The advantage of DEN is the tight integration between the network and the application, and the capability to pass detailed information specific to the user (whether it is network- or system-related) to the application without requiring the user to do anything. This enables the application to appear "more intelligent" to the user and automatically adjust to different environmental conditions. This is achieved through access to common information represented through DEN that is stored in a common repository. This enables one application to use information in the repository by other applications as well as share its own information in that repository. In this example, the video-conferencing application can determine who the user is and the rights of that user from information in the DEN repository that was put there by other applications. The video-conferencing application can also put its own information in the common DEN repository that other applications can use. It is this capability for applications to share and use information from other applications that is so important to developers and ISVs.

End Users

Continuing the preceding example, note that additional information can be seamlessly integrated into the end user's experience. For example, as additional users log in, similar information can be gathered and displayed in a dialog. The end user can simply click on an entry in the dialog, as opposed to entering the IP address of a user to video-conference with. Furthermore, each user will already know the transmitting and receiving capabilities of each other.

Most importantly, the end user can concentrate on using, as opposed to configuring, the video-conferencing application.

DEN, the DMTF, and the IETF

This section provides a brief review of how DEN was created; then describes how its development is proceeding in the standards community.

How DEN Was Created

DEN started as an idea proposed by Cisco and Microsoft to leverage the power of the network using a directory. Cisco and Microsoft created the DEN Ad-Hoc Working Group (AHWG) to propose this as an open standard in which all vendors could participate. Because the purpose of DEN was ultimately to bind users and applications to services available from the network, the AHWG specifically solicited advice and guidance from end users and customers who would benefit from DEN. This group was termed the DEN AHWG Customer Advisory Board (CAB). The DEN CAB was comprised of representatives from four different sectors to ensure that a wide set of interests was represented. The CAB members were from Sprint, Charles Schwab, Texaco, and the University of Washington.

After the general community endorsed the DEN effort, it was time to examine how its further development would take place. There were several directions that could have been taken with DEN. It could have remained an ad-hoc working group, or it could be given to an industry consortium. What the DEN AHWG decided was to select a standards organization that could adopt DEN and put its development under the formal methodology and procedures of that standards organization. The DMTF was selected because of its role in the development of CIM, the Common Information Model. At that time, the DEN specification was changed to embrace CIM and to become an extension of CIM. The Networks Working Group of the DMTF was selected as the particular subgroup that would own the continuing development of DEN.

The initial draft of the DEN specification was authored by Steven Judd of Microsoft and me. An email discussion list was then set up so that all interested parties could comment on the specification and add to it; this was hosted by Carnegie-Mellon University. Valuable input was received from many organizations as they embraced DEN and started to experiment with its use.

The draft went through three major revisions. It also tracked the continuing evolution of CIM. Indeed, DEN added to the richness of CIM, and CIM provided valuable knowledge and concepts that helped DEN immensely. A Last Call was issued, which then produced the final version of the DEN AHWG: DEN v3.0c5. This version was then approved by the DEN CAB for submission to the DMTF. The DMTF formally accepted ownership of the DEN specification on September 28, 1998.

DEN and the DMTF

The DMTF is the standards organization that now owns the development of DEN. Most of the work is done in the Networks Working Group of the DMTF. However, work that affects CIM in general or other technologies of interest to the DMTF as a whole is worked on by the Technical Development Committee [DMTF].

CIM is concerned about information modeling independent of the underlying implementation. This means that CIM can be implemented by a directory, by a relational or object database, or by other means. DEN extends CIM, but also defines optimizations that enable the object-oriented features of CIM to be mapped into a directory implementation (this is covered in more detail in Chapter 7).

DEN and the IETF

The IETF defines protocols, schema, and APIs. Protocols and APIs that are developed in the IETF, such as LDAP and SNMP, represent the standard way the industry uses to communicate with various system components. The DEN information model assumes the use of these protocols and APIs to access and transfer information between system components.

Recently, the IETF has chartered focused schema work. The work of most relevance to DEN is that done for directories that use LDAPv3 as their access protocol. There is now an excellent exchange of information between the DMTF and the IETF, as evidenced by several Internet drafts that are based on parts of DEN and the PFWG. The PFWG is chartered to standardize policy schemata for various IETF working groups and a policy definition language to communicate policy. The PFWG uses DEN as the basis for all its work. All these efforts are discussed further in Chapters 8 through 11.

Summary

This chapter has provided an overview for what DEN is, the motivation for its creation, and how it can be used. DEN is a specification that describes how the network can be transformed from a passive collection of devices that route and forward traffic to an active set of cooperating devices that intelligently provide services to the user. It represents both a philosophy as well as part of the means to build service-oriented solutions. This is fundamentally a different way of thinking about how to build networks and applications.

The strength of DEN lies in its interoperable framework that describes how heretofore unrelated system components can work together to provide a service. DEN provides a uniform way to manage different network mechanisms, such as congestion avoidance and rate limiting, which can be used in conjunction to provide a network service (for example, quality of service). DEN also provides a uniform way to combine network services together (for example, quality of service, encryption, and compression) as directed by one or more applications on behalf of a user.

DEN provides many benefits for enterprises, service providers, and developers. These include being able to dynamically configure the network to provide personalized network services; providing the means for different services to be provided based on cost, quality, and other metrics on a per-user and/or per-application basis; and enabling applications to be built that transparently leverage the network without requiring end users to configure them (or the network). End users will benefit from applications that can take better advantage of the network.

DEN is now a recognized standard under the auspices of the DMTF. In addition, the IETF is basing more and more of its work under DEN.

[COPS]: The RSVP Admission Policy (RAP) Working Group of the IETF is concerned with developing standards for enabling a scalable policy control model that can provide quality of service on the Internet using explicit signaling protocols like RSVP. Common Open Policy Service (COPS) defines a protocol to transmit policy requests and responses. More information on both can be found at

https://www.ietf.org/html.charters/OLD/rap-charter.html

[DIFSRV]: The Differentiated Services IETF Working Group is defining "relatively simple and coarse methods of providing differentiated classes of service for Internet traffic." Specifically, a small, well-defined set of building blocks is defined that enables quality of service to be defined on a "per-hop" basis. This work is described in

https://www.ietf.org/html.charters/wg-dir.html

[DMTF]: The Desktop Management Task Force (DMTF) is the industry consortium

chartered with development, support, and maintenance of management standards for PC systems and products, including CIM and DEN. The following URLs will direct you to more information about the DMTF in general and DEN in particular:

https://www.dmtf.org (home page for the DMTF)

https://www.dmtf.org (pointer for DMTF members to access various workgroups and subcommittees, such as the Networks Working Group)

(specific pointer for DMTF members to access the Networks Working Group)

https://www.dmtf.org/about/committees/

public pointer to access information about CIM, including downloading specs, viewing the tutorial, and so forth)

[DSARCH]: This Internet RFC defines an architecture for implementing scalable service differentiation in the Internet. This can be retrieved as

ftp://ftp.isi.edu/in-notes/rfc2475.txt

[INTSRV]: The Integrated Services Working Group of the IETF. Recent experiments demonstrate the capability of packet switching protocols to support Integrated Services: the transport of audio, video, real-time, and classical data traffic within a single network infrastructure. These experiments suggest that expanding the Internet service model would better meet the needs of these diverse applications. The purpose of this working group is to specify this enhanced service model and then to define and standardize certain interfaces and requirements necessary to implement the new service model.

The working group will focus on defining a minimal set of global requirements that transition the Internet into a robust integrated-service communications infrastructure. Enhancements to individual protocols (for example, adding additional routing information to routing protocols, or choosing IP queuing disciplines for routers) will be left to other working groups, except in those rare cases where detailed definitions of behavior are critical to the success of the enhanced architecture.

https://www.ietf.org/html.charters/OLD/intserv-charter.html

[LDAP]: The LDAP Extensions (LDAPEXT) Working Group of the IETF is chartered with continuing to develop an Internet directory service. The LDAPEXT Working Group defines and standardizes extensions to the LDAP version 3 protocol, extensions to the use of LDAP on the Internet, and the API to LDAP. More information can be obtained from

https://www.ietf.org/html.charters/wg-dir.html

[LIPS]: Another proposal for defining a person object class is called the Lightweight Internet Person Schema, available from the Network Application Consortium. Their URL is

https://www.netapps.org/index.htm

[PFWG]: The Policy Framework Working Group of the IETF. The charter is available from

https://www.ietf.org/html.charters/OLD/policy-charter.html

[RMON]: The Remote Network Monitoring Management Information Base is available in two versions. The following RFCs define it:

ftp://ftp.isi.edu/in-notes/rfc1757.txt

(Remote Network Monitoring Management Information Base)

ftp://ftp.isi.edu/in-notes/rfc2021.txt

(Remote Network Monitoring Management Information Base v2 using SMI v2)

ftp://ftp.isi.edu/in-notes/rfc2074.txt

(Remote Network Monitoring MIB Protocol Identifiers)

[RSVP]: Several RFCs define RSVP. The ones most relevant to this book are listed later. Also check the RAP Working Group. Go to the following URL:

https://www.rfc-editor.org/rfc.html

Pull the following files:

  • rfc2205.txt-RSVP Functional Specification

  • rfc2206.txt-RSVP Management Information Base Using SMIv2

  • rfc2207.txt-RSVP Extensions for IPsec Data Flows

  • rfc2208.txt-RSVP Applicability Statement

  • rfc2209.txt-RSVP Message Processing Rules

  • rfc2210.txt-The Use of RSVP with IETF Integrated Services

[SNMP]: There are several IETF working groups that actively work on the development of Simple Network Management Protocol (SNMP). Two to examine are

https://www.ietf.org/html.charters/OLD/agentx-charter.html

https://www.ietf.org/html.charters/OLD/snmpv3-charter.html

The goal of the first working group is to make the SNMP Agent more extensible.

The goal of the SNMPv3 Working Group is to define the next generation of SNMP.

This chapter reproduced courtesy of New Riders Publishing

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.