Downloads |
Document ID: 12236
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
CP-CP Sessions
CP-CP Session
Topology
Related Information
Introduction
A Control Point (CP) manages end node (ENs), network nodes (NNs), and their resources, in order to provide these services:
-
Address space manager
-
Session services
-
Directory services
-
Configuration services
-
Management services
-
Topology services
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software or hardware versions.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
CP-CP Sessions
In order for a CP to perform services for a node—that is, Directory Services (DS), Directory Database (DD), and Topology Services (TS)—the CP maintains a pair of parallel CP-CP sessions to exchange information. All CP-CP sessions are logical unit 6.2 (LU 6.2) protocols. After the node is contacted (after the exchange identification 3 [XID3] exchange between adjacent nodes), CP-CP sessions are established. The first thing that the CP-CP session does is exchange capabilities. If this exchange fails, the CP-CP sessions are terminated.
Because there are two CP-CP sessions, one session is started from each node. The session that each node starts is called the “contention winner.” The other session is called the “contention loser.”
The CP-CP session is established as shown in Figure 1:
Figure 1
Information is exchanged at two different levels: through the XID transfer and, later, across the CP-CP session.
The XID transfer exchanges the node type (EN or NN), pacing, and segmenting support information. With this information, the nodes know what to expect from the adjacent node and know how it will be sent.
The Directory or Topology Updates information flows across the CP-CP session. The NN receives topology updates both from ENs and NNs. The NN also receives directory updates from the EN on its CP-CP session, which identifies the resources that are associated with the EN.
Figure 2
CP-CP Session
Figure 3 shows diagrams of full and minimal CP-CP connectivity:
Figure 3
Every NN must have at least one CP-CP session with an adjacent NN, but it is not required to have one with all adjacent NNs. Trade-offs must be made between the length of the wait to get information and the size of the topology database in each node.
If you provide minimal CP-CP connectivity (sessions with only one adjacent node), then you reduce memory and bandwidth requirements, but you increase convergence time (the time it takes to update all NNs about changes in the network).
The left diagram in Figure 3 shows full CP-CP connectivity: each NN is connected to every adjacent NN. Each node is at most two hops from the NN that would initiate a topology update. (NN3 to NN2 would require two hops, while others would require only one.)
The right diagram in Figure 3 shows minimal CP-CP connectivity. It could take the nodes more hops to receive topology updates and, thus, there could be a longer convergence time. As the network size increases, this problem could be magnified many times, depending on the configuration.
Topology
Figure 4 shows a sample topology for a network that uses CP-CP sessions:
Figure 4
Both ENs and NNs maintain topology databases. ENs maintain only local databases, which include information about the attached LU and transmission group (TG) that connects the EN to the NN. NNs maintain two topology databases:
-
local database—Contains information about its LU and the low-entry networking node (LEN) and EN that are attached to it.
-
network database—Contains information about all NNs and TGs in the network. Depending on the number of CP sessions with adjacent NNs, an NN may receive more than one instance of a topology update.
The size of the topology database in an NN grows with the size of the network. With very large networks, the size of the database (or the system that implements the NN) might limit the network size.
Related Information
| Updated: Sep 09, 2005 | Document ID: 12236 |