17 Pipes

Provides Relationships

A provides relationship exists when one entity supplies one or more other entities that cannot exist on their own. You create provides relationships by associating a signal structure with a pipe or by building parent-child hierarchies of pipes.

For example, a TDM facility pipe provides channel pipes through signal structures. In this case, UIM automatically builds hierarchies of child pipes based on the signal structure. See "Understanding Capacity and Signal Structure" for more information about signal structures.

Similarly, a cable pipe provides cable-pair pipes. The child pipes can be defined by the parent pipe's specification. They can also be added manually in UIM. See "Configuring and Implementing Child Pipes for the Cable/Pair Model" for information about provides relationships in cable and cable-pair pipes.

Figure 17-2 shows a provides relationship between a T3 facility and the 28 DS1 channels that it provides.

Figure 17-2 Pipe Provides Relationship

Enables Relationships

A pipe enables another pipe when it supports the transport of data by the other pipe. In its simplest form, enablement refers to the association of a physical resource, such as a cable pair to a customer service, such as POTS. For example, when you enable a local loop by associating it with a cable pair, you are specifying the physical resource that realizes the connectivity of the customer service.

Similarly, channels provided by a facility can enable a service trail. For example, a 100 Mbps service trail represents the connectivity of some service provided to a customer. You can enable the service trail by associating it with two STS1 channels.

When a pipe enables another pipe, it can provide capacity to the enabled pipe. For example, the STS1 channels mentioned in the previous paragraph supply their capacity, defined in the signal structure of their parent OC3 facility pipe, to the service trail they enable. See "Understanding Capacity and Signal Structure" for more information.

Pipes can also be enabled by two separate connectivity paths. For example, multiple paths can exist in SONET/SDH. See "About Multiple Enablement" for more information.

Enables relationships also exist between the pipe termination points of enabling and enabled pipes. In the simplest case, where a single pipe enables another pipe, the termination points of the enabling pipe enable the termination points of the enabled pipe. Pipes can also be enabled by a series of connected pipes that form a connectivity path. The beginning and ending termination points of the connectivity path are therefore not on the same pipe. In this case, the beginning termination point is on the first pipe in the connectivity path and the ending termination point is on the last pipe.

You can enable pipes either manually or automatically by using path analysis. See "Enabling Pipes" for more information.

Provides and Enables Relationships in Combination

Figure 17-3 illustrates how the different types of relationships work together. This example shows the enablement of a local loop by cable pairs. The cable pairs are provided by cables. The local loop trail pipe is enabled by the following pipes that form a continuous connectivity path:

• A feeder cable pair that connects an MDF to a cross-connect terminal.

• A cross-connect in the cross-connect terminal. UIM creates cross-connects when two pipes that enable the same trail pipe are terminated on the same physical device, equipment, or logical device. See "About Connectivity Gaps in Pipe Enablement" for more information.

• A distribution cable pair that connects the cross-connect terminal to the subscriber terminal.

The termination points of the parent cable are mapped to the termination points of the cable pairs they provide. The originating termination point of the first cable pair enables the originating termination point of the local loop, while the end termination point of the second cable pair enables the end termination point of the local loop.

Figure 17-3 Pipe Relationships in a Local Loop Enablement

About Multiple Enablement

The previous examples describe the enablement of pipes by a single connectivity path. It is also possible for a pipe to be enabled by two separate connectivity paths. This capability is required in ring-based network topologies, such as SONET/SDH, which include both a primary and a secondary path.

For example, consider a single-ring SDH network with four optical add-drop multiplexers (OADMs). The four OADMs are modeled as logical devices with device interfaces on which four STM4 facility pipes are terminated. Figure 17-4 illustrates such a ring.

Figure 17-4 STM4 Ring

To enable an E1 service trail from OADM A to OADM C with both a primary path and a secondary path, you can use two connectivity paths:

• From OADM A through OADM B to OADM C

• From OADM A through OADM D to OADM C

This connectivity is supplied by VC12 channels provided by the STM4 facility pipes and by gap pipes as shown in Figure 17-5.

Figure 17-5 Multiple Enablement of an E1 Service Trail

Multiple enablement is also available in more complex ring topologies such as single-homed and dual-homed subtended rings. See "About Network Topologies" and the Design Studio Help for more information.

Multiple enablement can be done manually or automatically by using path analysis. See "Enabling Pipes" for more information.

Simple and Complex Signal Structures

Signal structures can be divided into simple and complex categories:

• A simple signal structure has only two levels: a TTP (Trail Termination Point) and one level of CTPs (Connection Termination Points).

• A complex signal structure has more than two levels: a TTP and two or more levels of CTPs. Each layer in the structure defines how its parent signal breaks down to a lower rate.

The distinction between simple and complex signal structures is important because it governs how channel pipes associated with signal structures are created in UIM.

• When you create a pipe associated with a simple signal structure, all of the channels provided by the pipe are created automatically by UIM, even if they are not currently needed to provide capacity to pipes. Automatic creation of channel pipes is possible because there is no ambiguity about how these channels can be used. They can only be used individually.

  For example, if a DS3 signal structure is mapped to a facility pipe, the 28 DS1 channel pipes provided by the facility are created automatically when you create a DS3 facility pipe. There is no ambiguity about how the DS3 will be channelized, so the channels can be created automatically.

• In complex signal structures, the system cannot know in advance how channels will be used. A higher-level CTP may be mapped as a whole to a pipe, thus making its lower-level CTPs unavailable. Alternatively, low-level CTPs may be mapped individually, thus making its parent CTP unavailable as whole units. Because of this potential ambiguity, UIM creates channels for pipes with complex signal structures only when the channels are required.

  See "Configuring Capacity with Signal Structures" for more information about working with signal structures in UIM.

Simple Signal Structures

Simple signal structures have a hierarchy with only two levels: the TTP and one level of CTPs. For example, a T1 signal structure comprises a TTP with a total capacity of 1.536 Mbps and 28 CTPs representing 64 Kbps DS0 channels. Figure 17-7 illustrates such a signal structure. Other examples include T3 with 28 DS1 channels and E1 with 30 DS0 voice channels.

Figure 17-7 Simple Signal Structure

To supply capacity, the TTP is mapped to the termination points of a pipe. The individual channels defined by the signal structure can then be used to supply capacity to pipes provided by the one associated with the TTP. See "Configuring and Implementing Pipe Termination" for information about mapping signal structures to pipe termination points.

Figure 17-8 illustrates a simple signal structure mapped to pipes. Each of the 24 DS0 channels defined in the signal structure is mapped to a DS0 channel provided by the T1 facility to which the signal structure as a whole is mapped.

Figure 17-8 Simple Signal Structure Mapped to Pipes

In UIM, if you create a T1 facility pipe entity with this signal structure, all of its DS0 channels will automatically be created at the same time. See "Defining Pipe Specifications" for information about creating pipes.

Complex Signal Structures

Complex signal structures are those that contain more than two levels. Examples include OC3, OC12, OC48, and STM1 structures. Figure 17-9 illustrates an OC3 signal structure.

The TTP represents the entire signal structure with 155.52 Mbps capacity. The OC3 is decomposed into two levels of channels. The first level comprises three STS1 channels, each with 51.84 Mbps. Each of the STS1 channels is further subdivided into 28 VT1 channels with 1.728 Mbps each. (The total of all of the VT1 channels' capacity is slightly less than the total C3 capacity of 155.52 Mbps because of some loss to overhead.)

Figure 17-9 OC3 Signal Structure

In UIM, the hierarchy of CTPs in the signal structure dictates some rules about how the structure's capacity can be used:

• After a channel pipe has been used to enable another pipe, higher-level channels in the structure no longer have their full capacity available. In other words, the parent channel cannot be used as a whole unit. For example, if you use one or more VT1 channels from an STS1 channel in an OC3 signal structure to enable a service trail, the STS1 channel as a whole is no longer available. Its remaining unused VT1 channels are available, however.

• Child channels below a parent channel that is being used to enable a pipe are not available because their cumulative capacity has been used by the parent. For example, if you use an entire STS1 channel in an OC3 signal structure to enable a facility pipe, the individual VT1 channels in the STS1 are no longer available.

Figure 17-10 illustrates the OC3 signal structure from Figure 17-9 mapped to an OC3 facility pipe.

• The TTP of the signal structure is mapped to the OC3 facility pipe itself.

• The CTPs for the first seven VT1 channels in the first STS1 channel are mapped to seven VTS channels provided by the OC3 facility. These seven VTS channels are then used to enable an 18 Mbps Ethernet facility pipe.

  Because some VT1 channels in this STS1 have been used, the STS1 as a whole is now unavailable. Its remaining VT1s can be used, however.

• The CTP for the second STS1 channel in the signal structure is mapped to an STS1 channel provided by the OC3 facility. This channel in turn enables an STS1 facility pipe.

  Because the STS1 channel in the signal structure is used as a whole, none of its VT1 channels is available for use.

Figure 17-10 Complex Signal Structure Mapped to an OC3 Facility

Cable/Pair Model

In this model, a parent pipe represents a copper or fiber cable. This cable pipe provides child pipes that represent twisted pairs or fiber strands. Cable pipes are configured in the following way:

• Minimum and maximum quantities for the child pipes are typically identical. As a result, all of them are created automatically when the parent pipe is created in UIM.

• No capacity is provided or required. Because cables and cable pairs can be used only as whole units, no explicit definition of capacity is necessary.

• No signal structure is present.

The cable and cable-pair pipes shown in Figure 17-3, "Pipe Relationships in a Local Loop Enablement", would be configured according to this model.

Packet Facility Model

This model supports Layer 2 links, such as ATM, Frame Relay, and Ethernet. Pipes based on this model provide capacity in bulk to pipes that they enable. An enabled pipe can consume the entire capacity or some smaller quantity depending on its requirements. The facility pipe can enable any number of pipes as long as its maximum capacity and usage percentage are not exceeded.

Packet facility pipes are configured in the following way:

• No signal structure is defined.

• The capacity required is the capacity that the pipe needs from another pipe for enablement.

• The capacity provided is the total capacity provided by the facility pipe.

• No child pipes are defined.

Figure 17-6, "Packet Capacity Example", illustrates a packet enablement scenario. The facility pipe would be configured according to this model.

TDM Facility Model

This model supports channelized technologies, such as TDM/PDH and SONET/SDH.

In this model, facility pipes provide channels that enable service trails. A signal structure is associated to the facility pipe to define its capacity and channelization.

TDM facility pipes are configured in the following way:

• The capacity required is the capacity that is required when enabled by another pipe.

• The pipe includes a signal structure that defines the pipe's capacity provided and how its signal is channelized.

• The capacity provided is not defined directly in the Pipe specification: it is inherited from the signal structure.

• No child pipes are defined. Child pipes are unnecessary because the signal structure defines the channelization of the pipe's signal. Channels are created either automatically or as needed in UIM depending on how the signal structure is organized.

The following figures illustrate various scenarios that involve pipes based on the TDM facility model.

• Figure 17-6, "Packet Capacity Example"

• Figure 17-8, "Simple Signal Structure Mapped to Pipes"

• Figure 17-10, "Complex Signal Structure Mapped to an OC3 Facility"

Defining Pipe Configuration Specifications

You define Pipe Configuration specifications and associate them to Pipe specifications in Design Studio. When you create an entity based on the Pipe specification in UIM, you specify that it is versioned to make possible the creation of pipe configuration versions. See "Implementing Pipe Configurations in UIM" for more information.

When you design a Pipe Configuration specification, you can add the following configuration items:

• Termination. Limits the types of resources on which the pipe can be terminated. You can choose different resources for originating and terminating termination.

• Transport. Limits the types of pipes that can enable the pipe.

• Intermediate Node. Specifies a device or piece of equipment that must be in the connectivity path that enables the pipe. If you specify an intermediate node, that node must be included in enablements whether they are done manually or automatically.

You can constrain the resources that can be used for the Termination, Transport, and Intermediate Node configuration items by specifying entity specifications as specification options. The resources available for termination, transport, and intermediate nodes are limited to entities based on the selected specifications. If you do not add a configuration item or do not select an entity specification for a configuration item, any entity of the supported types (such as pipes for the Transport configuration item) is allowed.

The specification options in a configuration specification are enforced when you configure enablement or resource assignment. They also apply during automatic enablement using path analysis.

Figure 17-11 shows a Pipe Configuration specification for an Ethernet service trail pipe. A Transport configuration item has been added, with a specification option that defines that only entities based on the FiberCable specification can enable the pipe. An Intermediate Node configuration item has also been included.

Figure 17-11 Pipe Configuration Specification

Implementing Pipe Configurations in UIM

When you create a pipe in UIM based on a specification that is associated with a Pipe Configuration specification, you can choose to version the pipe. (You can also configure a pipe to be versioned after you create it, as long as no resources have been assigned to it.)

When you add a pipe configuration, the resource assignments you make to terminate the pipe and the pipes you select to enable it (either manually or through path analysis) are captured as part of the configuration. The configuration becomes effective when it is transitioned into Completed state. See Chapter 4, "Life Cycles and Statuses", for more information about life cycles and statuses.

For versioned pipes, you perform manual enablement or automatic enablement (path analysis) from the Summary page of the pipe configuration. Each version of the pipe configuration design can have a different enablement; a redesign with different enablement is often the reason for creating a new version.

After a configuration version has been completed or canceled, you cannot change its enablement. You must create a new configuration version for the updated enablement. You use the Pipe Configuration Enablement section in the Pipe Configuration page to specify the pipes that enable the parent pipe of the configuration.

See "Enabling Pipes" and the UIM Help for more information about enablement.

Figure 17-12 shows the Summary page for a pipe configuration. You use the Pipe Configuration Enablement section of the page for manual enablement.

Figure 17-12 Pipe Configuration

About Pipe Termination and Rate Codes

Although rate codes apply primarily to channelized connectivity, they are also relevant when you terminate pipe connectivity. (See "About Rate Codes" for information about rate codes in general.)

When you terminate a pipe that has bit rate capacity on a device interface that has a rate code, UIM validates the pipe's capacity against the device interface's rate code. (UIM validates against the pipe's capacity required first. If no capacity required value exists, UIM validates against the capacity provided.) If the pipe's capacity matches the bit rate of the device interface's rate code, UIM allows the termination.

You can define a capacity variance that specifies how much the capacity can vary from the rate code and still be validated successfully. The variance is a percentage that you specify with the connectivity.capacityVariant parameter in the system-config.properties file. See UIM System Administrator's Guide for more information about setting configuration parameters.

Setting a capacity variance is particularly useful when you have upgraded from a previous version of UIM. In this situation, you may have existing pipe capacity defined with bit rates that do not exactly match the rate code bit rates due to rounding.

Configuring Capacity for Packet Facility Pipes

Capacity for packet-based connectivity is defined using the standard UIM capacity capabilities. See "Capacity" for more information.

When you define a specification for a packet-based pipe in Design Studio, you associate it with Capacity Provided and Capacity Required specifications that define the pipe's capacity. A pipe can enable other pipes up to the maximum capacity and consumable percentage defined by the Capacity Provided specification with which it is associated. To be enabled, a pipe requires the capacity defined in the Capacity Required specification with which it is associated.

Defining Capacity Required specifications is similar, but no consumable percentage is involved. See the Design Studio Help for more information.

In UIM, when you create an entity based on a specification that includes a relation to a Capacity Provided or Capacity Required entity specification, the relevant capacity is automatically associated to the entity. UIM automatically keeps track of capacity usage. You are prevented from making enablements that exceed a pipe's maximum capacity provided.

Configuring Capacity with Signal Structures

You use signal structures to define capacity for pipes based on the TDM model. (Channelized Connectivity entities define their signal structures by using the UIM signal architecture. See "About the UIM Signal Architecture" for more information.)

The signal structure defines how a pipe's signal is channelized. The signal structure includes an association to a Capacity Provided specification, meaning that no such association is required for the pipe itself.

To define signal structures and associate them with Pipe specifications, you create hierarchies of Signal Termination Point specifications in Design Studio. The parent-child relationships among the Signal Termination Point specifications determine the organization of the signal structure.

The hierarchy includes one parent specification to represent the top signal structure as a whole, along with one or more layers of child specifications. This organization of Signal Termination Point specifications corresponds to the hierarchy of TTPs and CTPs. See "Understanding Signal Structures" for more information.

For example, if you are creating a signal structure comprising a T3 parent signal termination point and 28 T1 child termination points, you must create a T3 Signal Termination Point specification and a T1 Signal Termination Point specification.

When you design a child Signal Termination Point specification, you define the capacity unit amount, unit of measure, and number of child signals. (See "Defining and Measuring Capacity" for more information about units of measure.) In a T3 scenario, there is only one layer of child signals, so the number of child signals is set to zero for the child Signal Termination Point specification. If there were more layers to the signal structure, you would specify the number of child signals below this one in the hierarchy.

You define the total bandwidth for the signal structure by relating a Capacity Provided specification to the highest-level Signal Termination Point specification in the structure. You also enter the number of child signals in the first layer of the structure and select the Signal Termination Point specification for that layer. For example, for the T3 structure mentioned previously, you would specify 28 child signals and select the T1 Signal Termination Point specification.

When you define a Signal Termination Point specification, you can include compatible capacities and units of measure supported by the signal structure. Using this feature, you can specify that a signal structure can support not only signals of exactly matching capacity but also signals of lesser capacity. For example, you can specify that a SONET STS1 channel with a bit rate of 51.840 Mbps can support an STS transmission facility of 51.840 Mbps capacity or a DS3 facility at a rate of 44.736 Mbps. See the Design Studio Help for more information about configuring Signal Termination Point specifications for compatible signals.

You can associate a Signal Termination Point specification with a Pipe specification in Design Studio. When a pipe entity is created in UIM based on a specification with such an association, the signal structure is created automatically at the same time. The channels defined in the signal structure are created immediately for simple signal structures (those with only one layer of child signals) and as needed for enablement in complex signal structures.

See the Design Studio Help for more information about how you design Signal Termination Point specifications.

In UIM, you can manually associate a signal structure with a pipe that does not already have one. When you make the association, the channels are created under the same rules used for signal structures associated by the specification.

See the UIM Help for more information about associating signal structures with pipes.

Viewing Signal Structure Information in UIM

There are several ways in UIM to view information about a pipe's signal structure:

• Figure 17-14 shows how the Pipe Hierarchy section of the Pipe Summary page displays the channel hierarchy defined by the signal structure. Each channel is shown along with the identity, inventory status, and assignment status of pipes it enables.

  Figure 17-14 Pipe Hierarchy Section

  
  

• Figure 17-15 shows how the Pipe Provides page lists all the child pipes that have been created based on the signal structure.

  Figure 17-15 Pipe Provides Page

  
  

• Figure 17-16 shows how the Signal Structure page displays all the channels defined by the signal structure, even if they have not yet been created in inventory.

  Figure 17-16 Signal Structure Page

  
  Description of ''Figure 17-16 Signal Structure Page''
  
  

See the UIM Help for more information about viewing signal structure information for pipes.

Changing the Capacity of Existing Pipes

You can change the capacity provided or capacity required after you create a pipe in UIM. It is unusual to make such a change, but it may be necessary under some circumstances. For example, you may need to change the capacity of fractional T1 or E1 pipes with capacities of 256, 384, 512 and 768 Kbps.

The following rules apply to changing the capacity provided amount.

• You cannot change the capacity provided information if the pipe has a signal structure because the signal structure defines capacity provided.

• If a pipe is not enabling any other pipes (has no capacity consumed), you can increase or decrease the total capacity provided.

• If a pipe is enabling another pipe (has some capacity consumed), you cannot decrease its capacity provided; you can only increase it.

  The total capacity provided amount factors in the consumable percent value. For example, if you have a pipe that provides 10 Mbps with 100% consumable, you could not change its capacity provided to 10 Mbps with 75% consumable if the pipe is enabling another pipe.

There are no rules about changing the capacity required amount. You can increase the capacity required after a pipe has been enabled by another pipe, even if you increase it to more than the capacity available on the enabling pipe. Changing the capacity required on a pipe that is already enabled by another pipe does not change the amount of capacity consumed on the enabling pipe.

See the UIM Help for more information about changing capacity in UIM.

About Path Analysis Criteria

When you perform path analysis, you specify criteria in the Path Analysis Search page to find paths. These criteria determine how path analysis goes about finding connectivity paths.

The following list provides introductory information about the criteria you can enter. See the UIM Help for detailed information about the criteria and for step-by-step instructions about running a path analysis.

• The only required criteria for a path analysis are the source and target types and IDs. You can enter IDs directly or search for them.

• You can specify an intermediate node that must be included in the path.

  For example, if you need a pipe to connect a subscriber terminal and a switch, path analysis can specify that the path must include a DSLAM by adding it as an intermediate node.

• You can specify the capacity required from the enabling pipe by entering a bit rate and unit of measure. For example, if you are enabling a pipe that requires 1.544 Mbps of capacity, you can specify a bit rate of 1.544 and Mbps as the unit of measure. If the pipe to be enabled is already associated with a Capacity Required specification, the bit rate and unit of measure are automatically selected.

• In cases where fractional capacity is required, you can include a quantity along with the bit rate and unit of measure. For example, to enable a 256 Kbps service trail, you can enter a quantity of 4 and enter a bit rate of 64 Kbps to enable the service trail over four 64-Kbps channels.

• You can specify that path analysis take pipe directionality into account. By default, path analysis treats pipes as bi-directional, but you can override that in cases where directionality is important. See "Understanding Pipe Directionality" for more information.

• You can choose to include partial paths in the path analysis results. Partial paths are those that are not currently continuous from source to target. By default, only continuous paths between source and target are returned.

• You can choose to include network nodes and edges in the path analysis. Network nodes and edges provide no connectivity, so they cannot be used for enablement. Including network nodes and edges can help in identifying the best routes, however.

  Note:

  You must use this option if you specified a network or network node as the source or target.

• You can tune path analysis to control the number of paths returned. The default is to search for the most direct paths, but you can choose to include more paths. Processing time increases as you include more paths.

• You can choose to include secondary paths in the path analysis if a pipe is configured for multiple enablement. Selecting this option means that path analysis results will include primary paths and the ability to select matching secondary paths. See "About Multiple Enablement" for more information.

Figure 17-18 shows a Path Analysis Search page with criteria entered.

Figure 17-18 Path Analysis in UIM

In addition to the criteria that you enter, the path analysis can also include filtering criteria defined in rulesets associated with the specification of the pipe you are enabling. For example, results may be limited to include only pipes that are based on a particular specification or that include certain text in their names. A sample cartridge is supplied with UIM to provide examples of this capability. See UIM Developer's Guide for information about customizing path analysis.

Path analysis results are also limited if the pipe that you are enabling has a Pipe configuration in which a Pipe specification is assigned to the Transport configuration item. In this case, path analysis results include only pipes based on that specification. See "Defining Pipe Configuration Specifications" for more information.

About Path Analysis Results

The results of a path analysis are displayed in the Available Paths page. Each path found between the source and target is shown as a group of rows, with each row representing a segment of the path. The ID in the From ID column of the first row of the path represents the source you entered, and the ID in the To ID column of the last row in the path represents the target.

If the pipe you are enabling is configured for multiple enablement and you want to include secondary paths, the results include both primary paths and the ability to select secondary paths. The primary and secondary paths are displayed in separate tables.

You can open a visualization of the path in the network topology. See the UIM Help for instructions about using UIM topology features.

Figure 17-19 shows search results for the criteria entered in Figure 17-18. In this case, only one path was found. If there were additional paths that met the criteria, they would be listed in rows below the first path.

Figure 17-19 Path Analysis Results

Understanding Path Analysis Modes

Path analysis can operate in two different modes. The way you run a path analysis is the same in both modes, but the mode affects which paths are returned and the amount of processing required.

• In Complex mode (the default), path analysis considers all possible paths between the source and target, which means evaluating a large number of permutations. You can use rulesets to limit the amount of data to be processed. This mode of path analysis is suitable for complex networks with many possible connections.

• In Simple Linear mode, path analysis works by iteratively analyzing paths working from the end points toward a common node. This mode of analysis is suited to paths that are inherently linear and have 10 or fewer hops. For example, Simple Linear analysis is suitable for POTS scenarios. The Simple Linear algorithm is less processor-intensive than the Complex algorithm.

  The analysis mode can be set for UIM as a whole or for specific Pipe specifications. See UIM Developer's Guide for more information.

Viewing a Pipe Enablement Visualization

The enablement visualization of a pipe or pipe configuration shows schematic views of the trail pipe in the upper part of the canvas and the enabling pipes in the lower part. When a pipe is enabled by more than one connectivity path, such as in a SONET/SDH network, both paths are displayed.

The visualization includes the following:

• Pipes. Pipes are labeled with their IDs and names and the names of their parent pipes (if any). For example, if the second channel pipe of Facility Pipe LS_BW_A is included in the enablement, it would be labeled LS_BW_A (LS_BW_A-2) in the schematic view.

• Connectivity Gaps and Cross-Connects. If connectivity gaps or cross-connects were created during the enablement, they are shown as thin lines connecting the thicker lines that represent other pipes.

• Pipe termination points. If the termination points are not terminated on a resource, they are labeled with their IDs. If they are terminated on a resource, they are labeled with the ID and name of the resource or its parent. For example, if a termination point is terminated on a device interface, the visualization displays the name and ID of the logical device that holds the interface. Boxes representing parent resources surround the termination points. If two termination points are terminated on the same parent resource, they are displayed in the same box.

  You can expand termination points in the visualization to view their resource terminations. You can expand individual termination points or all termination points simultaneously.

Figure 17-20 shows a simple enablement in which a service trail is enabled by a connectivity path comprising three pipes that are terminated on logical devices in four locations. Cross-connects have been added on the logical devices that have two pipe termination points.

Figure 17-20 Pipe Enablement