Contents

• Capability Directory Overview
• Capability Directory Functions
• Capability Directory Architecture
• Process for Transporting Capabilities Messages
• PEP Presence Using Multi-user Chat Rooms
• Policy Agent Restart

Capability Directory Overview

---

These sections describe the Capability Directory component of the Cisco Network Positioning System (NPS).

• Capability Directory Functions
• Capability Directory Architecture
• Process for Transporting Capabilities Messages
• PEP Presence Using Multi-user Chat Rooms
• Policy Agent Restart

Capability Directory Functions

The Capability Directory performs these functions for the NPS product:

• Subscribes to and receives all capability advertisements in a given domain.
• Presents a real-time view of all resources and capabilities in the domain to the NPS component or other consumers.
• Provides appropriate debugging and troubleshooting methods.

The capability advertisement interface is primarily used by policy agents and control point agents to advertise functional and performance capabilities.

Capability Directory Architecture

During runtime, the Capability Directory communicates with other NPS modules.

• The NPS component accesses the Capability Directory using the CD API interface.
• Each control point agent publishes its capabilities to the Capability Directory using the XMPP Pub-Sub interface.
• The Capability Directory validates capability advertisements and writes them to the capability database.

Process for Transporting Capabilities Messages

Capabilities message transport follows these steps:

1. The policy agents within each data center discover the devices that they own or control and learn about their functional and performance capabilities.
2. The policy agents use a local device model to generate a capability advertisement document. The capability advertisement document conforms to the Cloud Capability Definition Language (CCDL) XML/XSD schema.
3. The control point agent (CPA) publishes the XML document to the domain XMPP server using the XMPP Pub-Sub interface to the domain's XMPP server.
4. The Capability Directory registers as a subscriber to the XMPP Pub-Sub point, and then it receives the device advertisement XML document.
5. After validating the incoming XML document, the Capability Directory stores the capability data into the database. If the XML fails validation, the Capability Directory logs a syslog message notifying the operator of the error.
6. The data becomes available to Capability Directory clients such as NPS.

PEP Presence Using Multi-user Chat Rooms

Personal Eventing Protocol (PEP) relies on XMPP presence notifications with status updates. For the Capability Directory to receive PEP presence notifications, it needs to have every device policy agent to be added to its roster.

NPS uses a XMPP multiuser chat room (XEP-0045 Multi User Chat) as a separate out-of-band mechanism to learn about the policy agents presence information. The Capability Directory and all of the policy agents join a predefined chat room when they first come up. Each member's presence information is automatically made available to all other members. Using this presence information, the Capability Directory adds the policy agents' Jabber IDs to its XMPP roster. This enables it to receive the PEP presence notifications (which contain the Pub-Sub data) from individual policy agents.

Policy Agent Restart

When the policy agent restarts or gets disconnected from the XMPP server, it sends a complete update to the Capability Directory. The Capability Directory replaces the contents of its database for that element with the contents of the new advertisement.

In addition, the policy agent publishes the full update only when a significant update is detected.