13 Connectivity Overview
This chapter provides an overview of the connectivity features in Oracle Communications Unified Inventory Management (UIM).
Note:
The word connectivity is used in two ways in this guide. It is used in a general sense to mean the ability to transfer information to and from devices and locations. It is also used more specifically to refer to Connectivity entities.
UIM supports several different types of connectivity. This chapter covers features that are common to all types of connectivity.
About Connectivity
In the telecommunications industry, connectivity refers to the ability to transport information to and from devices and locations by using physical or logical media. The inventory of a telecommunications provider includes networks of routers, switches, multiplexers, and other devices located in various places. The devices and locations are connected to each other using various networking technologies, such as Ethernet, Frame Relay, SONET, and so on.
In UIM, Connectivity entities provide built-in support for a variety of technologies and can be customized to suit your business needs. UIM supports three types of Connectivity entities:
-
Channelized Connectivity entities support multiplexed technologies such as E-Carrier, T-Carrier, J-Carrier, SDH, SONET, and WDM. See "Channelized Connectivity".
Note:
In releases previous to UIM 7.3, all Channelized Connectivity entities were based on the same specification. This restriction no longer applies. You can create multiple Channelized Connectivity specifications in Design Studio and deploy them to UIM. In addition, a variety of sample Channelized Connectivity specifications are included in the OracleComms_UIM_Channelized cartridge.
-
Packet Connectivity entities support packet-based technologies such as Carrier Ethernet, Frame Relay, and ATM. See "Packet Connectivity".
-
Service Connectivity entities represent the connectivity requirements of a service, such as the locations to be connected and the necessary bandwidth. Unlike other connectivity entities, you create Service connectivities in the context of Service configurations. See "Service Connectivity".
In addition to Connectivity entities, UIM includes Pipe entities that can be used in scenarios when the more specialized Connectivity entities are not appropriate. Pipe entities are more generic than Connectivity entities and include fewer features. Pipe entities and Connectivity entities are not mutually exclusive: you can include them both in the same network. For example, pipes can enable channelized connectivity. See "Pipes" for more information.
Connectivity entities cannot be associated with the following:
-
Reservations
-
Conditions
-
Roles
-
Inventory groups
-
Place entities. (Channelized connectivity can be associated with property locations. See "About Connectivity Locations" for more information.)
Figure 13-1 shows the General Information tab of a Connectivity Details page for a Connectivity entity. This Connectivity entity represents DS3 channelized connectivity.
The General Information tab is used for all types of Connectivity entities. It includes the basic details about the connectivity that were established when the entity was created. See "Working with Connectivity Entities in UIM" for information about other tabs in the Connectivity Details page.
Figure 13-1 Connectivity Details: General Information Tab
Description of "Figure 13-1 Connectivity Details: General Information Tab"
Although each type of Connectivity entity has specialized capabilities, they also share functionality and attributes. See the following sections for information about features common to all Connectivity entities:
Technologies, rate codes, and connectivity functions are defined by specifications in the ora_uim_basetechnologies cartridge. You must deploy this cartridge to UIM before using connectivity features. See UIM Cartridge Guide for information about deploying cartridges.
About Connectivity Locations
Connectivity entities have A and Z end points that must be geographically located at a property location. Each end point must be a property location that is one of the following:
-
Network location. A network location is one that hosts devices involved in connectivity. Defining a property location as a network location requires the assignment of a network location code. See "About Network Locations".
-
Network entity location. Network entity locations define a specific logical device (a network entity) at a network location. See "About Network Entities".
-
Service location. A service location is one where a service originates or is delivered. Service locations are often outside the service provider network. See "About Service Locations".
See "About Network Locations" for more information about network locations and network entity locations.
Most connectivities have both end points on network locations or network entity locations. Certain types of connectivities, such as those that represent connectivity from a customer location to the service provider network, have at least one end point on a service location. For example, the UNI Connectivity specification supplied in the Carrier Ethernet cartridge has one end point on a service location.
The locations you specify determine where the end points can be terminated. For example, if you specify a network location for the A end point, the end point must be terminated on a device interface provided by a network device at that network location. See "About Termination" for more information. Similarly, if you specify a service location as the A location of a connectivity, the connectivity can be terminated only on an interface provided by a device at that location.
The A and Z network locations can be the same, as in an intra-office transmission facility. In this case, one end is typically located at a network entity location within the network location.
About Connectivity Technologies
When you create a Connectivity entity, you specify its technology it uses. The technology you choose determines which specifications you can select for the entity.
For example, if you select the Ethernet technology and have deployed the OracleComms_UIM_Carrier Ethernet cartridge, you can choose from the three Ethernet specifications (UNI Connectivity, INNI Connectivity, ENNI Connectivity) and from any custom specifications that have been assigned the Ethernet technology.
The OracleComms_UIM_Packet sample cartridge includes specifications for the ATM and Frame Relay technologies:
-
ATM
-
Frame Relay
Similarly, when you select a channelized connectivity technology, such as T-Carrier or SONET, you can select from base or other installed specifications that have been assigned that technology. The OracleComms_UIM_Channelized sample cartridge includes specifications that are based on the following technologies:
-
SONET
-
SDH
-
E-Carrier
-
T-Carrier
-
J-Carrier
-
WDM
Selecting the technology of a connectivity also limits the rate codes you can select. For example, if you set the technology to T-Carrier, rate codes are limited to DS0, DS1, and so on. Similarly, selecting a rate code limits the technologies from which you can select. See "About Rate Codes" for more information.
About Rate Codes
UIM uses rate codes to define the technology and bit-rate capacity that apply to Logical Device, Device Interface, and Connectivity entities.
Each rate code definition includes:
-
A name, such as STS1 or VC3
-
One or more networking technologies, such as Ethernet, SDH, or SONET
-
A bit rate and unit of measure, such as 51.840 Mbps or 48.960 Mbps
Rate codes associated with facility signals can also include a connectivity function, such as T1, that describes how a connectivity is used.
You assign rate codes to Connectivity entities when you create them. The rate codes you select from are limited by the connectivity's technology and specification.
The rate code you select determines other attributes of the connectivity configuration, including the signal structure. For example, if you specify that a connectivity has a DS3 rate code, the connectivity signal architecture specifies that you can channelize the connectivity to either DS2 or DS1.
The rate codes of a connectivity also determines which connectivities can be enabled by or ride them. For example, a for connectivity entity to be enabled by a channel, its rate code must match or be compatible with the rate code of the channel. See "About Rate Code Compatibility" for more information.
Pipes can also be enabled by channels provided by channelized connectivity, but compatibility is not based on rate code. Instead, UIM uses the underlying bit-rate capacity provided by the channel to determine whether enablement is allowed. For example, a channelized connectivity with a DS1 rate code provides DS0 channels. These channels can enable a Pipe service trail that requires 64 Kbps because that capacity matches the 64 Kbps of the DS0 rate code.
You can also apply rate codes to device interfaces. You can terminate a connectivity on a device interface only if the rate codes match. See "Associating Rate Codes to Device Interfaces" for more information.
About Rate Code Compatibility
When UIM determines whether one connectivity can enable another, it considers rate code compatibility. Compatible rate codes are those whose bit-rate capacities and technologies allow interoperability. For example, the VC12 and E1 rate codes are compatible because a VC12 channel can transport an E1 signal. Similarly, a Ethernet UNI connectivity with a rate code of 1 Gbps can be enabled by 16 STS1 Channels because the rate codes are compatible.
Note:
Packet connectivity cannot enable other packet connectivity, whatever the rate code.
Compatibility is defined in the signal architecture by relationships between Signal Termination Point specifications. See "About the UIM Signal Architecture" and UIM Information Model Reference for more information.
About Connectivity Functions
Connectivity functions identify the purpose or role that a Connectivity entity performs. For example, the T1 connectivity function identifies a connectivity as a T-Carrier transmission facility operating at a DS1 rate code. Similarly, the GE100 connectivity function identifies an Ethernet facility operating at the 100GigE rate (100 Gbps).
Connectivity functions are included in connectivity identifiers. See "About Connectivity Identifiers" for more information. Connectivity functions are applicable only to Connectivity entities that represent facilities.
You determine a facility's function when you assign its rate code. Similarly, if you select a connectivity function when defining a connectivity, UIM sets the applicable rate code and technology.
No default behavior is associated with connectivity functions, but you can use them to extend UIM with rulesets. Supported functions are defined in the ora_uim_basetechnologies base cartridge.
About Connectivity Identifiers
UIM connectivities can be identified in three ways, depending on the context:
-
A location-based format is used for connectivities that are terminated on network locations. See "Location-Based Connectivity Identifiers".
-
A service-based format is used for connectivities in which one end point is terminated on a service location. See "Service-Based Connectivity Identifiers".
-
A custom format can be used for packet and channelized connectivities to implement an identification scheme that is specific to your business. See "Custom Connectivity Identifiers".
Location- based and service-based identifiers comprise a number of attributes or elements separated by spaces and forward slashes. The information in the identifier is organized with the most significant information first and the most granular information last.
Note:
Channels in Channelized Connectivity also have identifiers. See "About Channel Identifiers" for more information.
Location-Based Connectivity Identifiers
You use the location-based connectivity identifiers for entities that are terminated on network locations or network entity locations.
Note:
Service connectivities cannot use location-based connectivity identifiers.
These are the five attributes used to construction a location-based connectivity identifier:
-
Network/Entity Location A. The location of the A end point of the connectivity. This value can be a network location code or a network entity location code. See "About Network Locations" for more information.
-
Network/Entity Location Z. The location of the Z end point of the connectivity. This value can be a network location code or a network entity location code. See "About Network Locations" for more information.
-
Rate Code. The rate code of the connectivity. See "About Rate Codes" for more information.
-
Function. The functional role that the connectivity plays. See "About Connectivity Functions" for more information.
-
The serial number for the connectivity. The serial number is unique among connectivities that share the same A Network/Entity, Z Network/Entity, Rate Code, and Technology values. When you create a connectivity, you can either accept the automatically generated serial number or enter one of your own.
Forward slashes separate the fields in the identifier. For example,
PLANTXUSXA.A01 / PLANTXUSXA.K01 / DS1 / T1 / 99
identifies a connectivity with endpoints at the network entities A01 and K01, both at the network location PLANTXUSXA. This connectivity operates at the DS1 rate code and has the T1 connectivity function. It is uniquely identified by the serial number 99.
Channels in channelized connectivities are also identified with the location-based format, with the addition of a unit value. See "About Channel Identifiers" for more information.
Service-Based Connectivity Identifiers
Connectivities that have at least one end point on a service location use the service-based identifier format. Service connectivities and packet connectivities designed for access, such as UNI connectivities, have service-based identifiers.
Identifiers in this format are constructed of two or three elements:
-
Function. The function that the connectivity plays, such as VPN, IPTV, or VoIP.
-
Serial Number. The serial number must be unique for all connectivities that share the same connectivity function.
-
Segment. A segment uniquely identifies each termination leg of a multipoint connectivity arrangement. This element is absent in point-to-point connectivities.
For example, a service connectivity connecting several locations of a bank could have the service-based connectivity identifier VPN / 001011 / 0001, where VPN is the connectivity function, 001011 is a serial number shared by all the service connectivities in the multipoint service, and 0001 is the segment value that identifies the specific service connectivity.
Custom Connectivity Identifiers
Service providers often have their own naming standards for connectivity. UIM supports these corporate naming standards by allowing custom identification formats.
If you create a connectivity in UIM that is based on a specification that specifies a custom identifier format, UIM passes information about the connectivity to a ruleset that generates the identifier. This information includes:
-
A network or service location
-
Z network or service location
-
Technology
-
Rate code
-
Function
-
Serial number
-
Specification
UIM also generates a unique serial number for the connectivity, which can optionally be included in the identifier. UIM validates custom identifiers to ensure that they are unique across all connectivity entities.
About Termination
Channelized connectivity entities must be terminated on media interfaces (logical devices at the top of their device interface hierarchies.). These media interfaces must be provided by logical devices hosted at network locations or service locations.
Most connectivities are terminated on media interfaces at the network locations or network entity locations associated with their end points. For example, Figure 13-2 illustrates a channelized connectivity with its A end point at network location FRSCTXUSXA and its Z end point at network entity location PLANTXUSXA.K01. The connectivity is terminated on device interfaces provided by logical devices at those locations.
Figure 13-2 Connectivity Termination with Network and Network Entity Locations
Description of "Figure 13-2 Connectivity Termination with Network and Network Entity Locations"
In this case, the A end point is terminated on the FRSCTXUSXAM1301 multiplexer, which is not associated with a network entity location code. Because the A end point is located at the FRSCTXUSXA network location and not a network entity location, it can terminate on any device at the location, including devices not associated with a network entity location code. The Z end point is located at the PLANTXUSXA.K01 network entity location and therefore must terminate on that device.
The interfaces you can choose to terminate the connectivity depend on whether the end point is at a network location of a network entity location:
-
If the end point is located at a network location, the connectivity can be terminated on the interfaces of any device at the location that has a matching rate code.
-
If the end point is located at a network entity location, the connectivity can be terminated on any interface of that device that has a matching rate code.
Some connectivities, such as Ethernet UNI connectivities, can have end points at service locations. In this situation, you can choose to terminate the connectivity on any compatible media interface at the service location. If the service location is also a network location, all of the compatible interfaces associated with the network location code are also available for terminating the connectivity.
You terminate a connectivity during the connectivity design process. See "Designing Connectivity" for more information.
Packet connectivities that are enabled by other packet connectivities have special termination rules. See "Packet-Over-Packet Termination Rules" for more information.
About Connectivity Enablement
Connectivities are enabled to specify the resources used to realize end-to-end continuity. For example, if you use a Channelized Connectivity entity to represent a DS1 service trail from network location FRSCTXUSXA to network location PLANTXUSSL, you enable the connectivity to specify how it is realized.
Similarly, if you use a Packet Connectivity entity to represent INNI connectivity in a Carrier Ethernet solution, you enable it to specify the transport details. For example, the INNI connectivity could be enabled by one or more channels in a channelized connectivity. It can also be enable by another packet connectivity of higher capacity.
Note:
When you enable a connectivity, you do not necessarily have to supply transport details. In some cases, those details are irrelevant to your inventory. For example, you may not need to specify how a INNI connectivity is enabled because the transport is supplied by a third party whose resources are outside your network. In this case, you include an accepted gap in the connectivity design.
Several different types of resources can be segments in a connectivity path:
-
Channels provided by Channelized Connectivity entities
-
Packet connectivities
-
Pipes with signal structures (if terminated on device interfaces of devices located at network locations)
-
Interconnections, including cross-connects and jumpers
-
Accepted connectivity gaps (segments where the connectivity is not specified)
You enable a connectivity during the connectivity design process. See "Designing Connectivity" for more information.
Working with Connectivity Entities in UIM
In UIM, you use the Connectivity Details page to enter and view information about Connectivity entities. Unlike many other UIM pages, the Connectivity Details page is arranged into several tabs. Each tab is used for a different purpose. The tabs you see depend on the type of Connectivity entity.
These are the tabs that can be displayed in the Connectivity Details page:
-
You use the General Information tab to view and edit basic information about Connectivity entities. You also use the tab to open the other tabs for editing.
-
You use the Connectivity Design tab in the Connectivity Details page to enable and terminate connectivity. The Connectivity Design tab has two subtabs:
-
The Design subtab includes a table that includes rows for each segment in the connectivity path. The rows display icons and information about the segments. For example, the connectivity identifier and status are displayed for each connectivity, channel, or pipe that is assigned to a segment.
-
The Schematic subtab of the Connectivity Design tab displays a graphical representation of the connectivity enablement and termination design created in the Design subtab. The Design Versions control in the upper-right corner of the Schematic subtab enables you to switch between current and previous versions of the connectivity design.
-
-
You use the Capacity tab in the Connectivity Details page to configure the capacity of a channelized connectivity by determining its signal structure. The Capacity tab displays a hierarchy of nodes and levels. A control section in the upper level enables you to change how the nodes and levels are displayed.
-
You use the Channels tab in the Connectivity Details page of a channelized connectivity to view the channel hierarchy.
-
You use the Riders tab in the Connectivity Details page for packet connectivity entities to view the pipes and connectivities that are enabled by (or ride) this connectivity.
The following list shows which tabs are displayed for each connectivity type:
- Channelized Connectivity
-
-
General Information Tab
-
Connectivity Design Tab
-
Channels Tab
-
Capacity Tab
-
Associated Resources Tab
-
- Packet Connectivity
-
-
General Information Tab
-
Connectivity Design Tab
-
Riders Tab
-
Associated Resources Tab
-
- Service Connectivity
-
-
General Information Tab
-
Connectivity Design Tab
-
Associated Resources Tab
-
Designing Connectivity
In UIM, you use the Connectivity Design tab in the Connectivity Details page to enable and terminate connectivities. Figure 13-3 shows the Connectivity Design tab.
About Connectivity Design Visualizations
You can see a read-only visualization of a connectivity design in the Schematic subtab of the Connectivity Design tab. The visualization includes schematic views of the trail in the lower part of the canvas and the enabling connectivities in the upper part. You can choose to display the current design version or a previous design version.
When a trail is enabled by more than one path, such as in a SONET/SDH network, you can select an alternate path from the Paths dropdown.
The visualization includes the following:
-
Connectivities. Connectivities and channels are shown as thick lines labeled with their connectivity identifiers.
-
Connectivity gaps. If gaps exist in the design, they are shown as dotted lines.
-
Devices and network locations. Icons represent A and Z network locations as well as devices or network locations on which connectivities are terminated. You can expand the icons to view more detailed termination information. For example, you can expand a device to see the device interfaces on which connectivities are terminated and any interconnections between those interfaces.
-
Interconnections. Jumpers and cross-connects are shown as thick lines. Icons indicate whether a line represents a jumper or cross-connect.
See the UIM Help for more information about the icons and about using the connectivity design visualization.
Figure 13-4 shows a connectivity design visualization that includes logical devices, connectivities, a gap, and jumpers.
Figure 13-4 Connectivity Design Visualization
About Design Versions
Connectivity entities are versioned. The first design version is created automatically when you create a connectivity. You create subsequent versions manually. Only one version can be active at a time; you cannot create a new design version until the current one is completed or canceled.
You work with design versions in the Connectivity Design tab of the Connectivity Details page. See the UIM Help for more information.
About Connectivity Gaps
A connectivity gap exists when the details are unknown for a segment of connectivity. When you design a connectivity, UIM creates Connectivity Gap entities to represent these segments.
An unresolved gap occurs when the gap has no business validity. For example, unresolved gaps naturally occur when you have not yet completed a connectivity design. All connectivity designs begin with an unresolved gap between the A and Z end points.
Connectivity designs cannot be completed if there are unresolved gaps. You can resolve gaps in the following ways:
-
By accepting the gap. You can mark a gap as acceptable when knowledge of the connectivity details are not necessary for your business. For example, an acceptable gap may exist for the “last mile" of connectivity when one service provider hands off to another or when transport passes through a third-party network. When you mark such a gap as acceptable, it can be included as part of a completed design. See the UIM Help for information about how to accept gaps.
-
By assigning transport to a gap. For example, if a gap exists between two network locations, you can assign a pipe (if it is terminated on device interfaces of devices located at network locations) or a channel from a channelized connectivity. You can assign transport manually or use gap analysis to find transport automatically.
-
By using interconnections. Interconnections bridge connectivity between device interfaces. See "About Interconnections" for more information.
Figure 13-5 shows a simple, completed connectivity design. In this case, a DS1 trail is enabled by a channel from a DS3 facility and two cross-connects. The cross-connects bridge the gaps between device interfaces on a logical devices at the ALLNTXQA network location.
Resolving one gap sometimes causes another to be created. For example, if you resolve a gap by assigning a channel that terminates on a device at a network location, a new gap may be created if the next segment is terminated on a different device at the same network location.
Gaps on the ends of the connectivity can be resolved only when the ends are terminated on device interfaces. For example, in Figure 13-5, the A end point is terminated on device interface 1012-1 and the Z end point is terminated at device interface 1013-1.
Assigning Transport
When you assign transport to a segment of a connectivity design, you specify the details of how the signal is carried from one location to another. For example, if you are designing a DS1 service trail, you can specify that the signal be carried on (or ride) a channel provided by a Channelized Connectivity entity that represents a T3 facility. Similarly, when you are designing an 100 Mbps Ethernet INNI connectivity, you can specify that it be enabled by channels from an SDH facility or by capacity provided by a 1 Gbps Ethernet connectivity.
Note:
Channelized connectivity can enable packet connectivity, but packet connectivity cannot enable channelized connectivity.
You can also use Pipe entities as transport. For pipes to be used to enable channelized connectivity, however, the pipes must be terminated on device interfaces of devices that are located at network locations. That means that the devices have to have been assigned network location codes or network entity codes.
You can assign transport manually or by using gap or path analysis.
When you assign transport manually, you search for a pipe, channel, or connectivity using the standard entity-specific Search pages. For example, you can search for all channelized connectivity entities that have a particular rate code and an end point at a specific network location. UIM returns all the entities that meet your criteria and you then select a channel from among those provided by those entities.
Gap analysis enables you to automatically find packet connectivity and channelized connectivity channels by specifying starting and ending criteria. You can optionally include other criteria, such as an intermediate location and specific device identifiers.
Figure 13-6 shows the Gap Analysis section with a network entity code specified for the starting location and a network location code for the ending location.
Path analysis is similar to gap analysis except that it finds pipes rather than connectivities. Path analysis in this context is almost identical to gap analysis when used to enable pipes. Figure 13-7 shows the Path Analysis section with the starting point and ending points specifying logical device IDs. See "Enabling Pipes Automatically with Path Analysis" and the UIM Help for more information.
Both gap analysis and path analysis return lists of matching pipes or connectivities from which you can select. The results are organized by the number of hops, with the lowest number listed first. Figure 13-8 shows the results of a gap analysis. In this case, only a single connectivity met the criteria.
See UIM Help for instructions about using the features in the Connectivity Design tab to assign transport.
About Interconnections
Interconnections participate in the continuity of an end-to-end trail by forming bridges between interfaces on which connectivities are terminated.
There are two types of interconnections: cross-connects and physical jumpers.
About Cross-Connects
A cross-connect represents a software, electrical, or wireless connection between two device interfaces within a logical device. Cross-connects are logical; they do not represent physical objects. Cross-connects can enable both Pipe and Connectivity entities.
Cross-connects can be interface-bound or trail-bound.
-
An interface-bound cross-connect is bound to the life of the interface it connects. If either interface is removed, the cross-connect is also removed. For example, you could create interface-bound cross-connects between the line and drop interfaces of an M13 multiplexer logical device. You create interface-bound cross-connects manually in Device Interface pages. See "About Interface-Bound Cross-Connects" for more information.
-
A trail-bound cross-connect is bound to the life of the trail it enables. If the trail is removed, the cross-connect is removed. Trail-bound cross-connects are automatically created during connectivity design when segments are joined at a common logical device and when an interface-bound cross-connect does not already exist. You can also create cross-connects manually when you design a connectivity. For example a trail-bound cross-connect could be used when a DS1 Interface is interconnected to another DS1 interface to enable a trail that passes through a 3/1/0 DACS.
You cannot change a trail-bound cross-connect into an interface-bound cross-connect or change an interface-bound cross-connect into a trail-bound cross-connect.
Duplicate cross-connects are not allowed. For example, if there is already an interface-bound cross-connect between two device interfaces in a multiplexer, a trail-bound cross-connect cannot be added between those same interfaces. If you use gap analysis to find connectivity in such a situation, UIM automatically includes the existing cross-connect.
If you assign a channel or pipe with an end point that terminates on a device interface in a device, and then assign another channel or pipe with an end point that terminates on another interface in the same device, UIM automatically creates a trail-bound cross-connect between the two interfaces.
Interconnections do not have rate codes because their purpose is to bridge different interface signals. But rate codes are relevant when determining whether a cross-connect can be created. Cross-connects are not allowed when only one interface has a rate code or when the interface rate codes are incompatible. See "About Rate Code Compatibility" for more information.
About Physical Jumpers
A jumper represents a physical connection between device interfaces (in Logical Device entities) or ports (in Physical Device and Equipment entities). The device interfaces or ports can be on the same device or between devices at the same network location.
For example, a jumper could represent a twisted-pair connection between DSX jack panels or in an MDF (main distribution frame). A jumper could also represent an optical connection between fiber distribution panels.
Physical jumpers participate in the end-to-end continuity of a trail design. For example, when you design a connectivity, a jumper can represent a segment in the enablement of a facility. Similarly, a jumper can represent one segment in the enablement of a trail pipe.
Only one physical jumper is allowed per device interface or port. If a jumper already exists on an interface or port, you cannot add a new one without deleting the existing one. You can add a physical jumper to a device interface that already has a cross-connect, however.
Physical jumpers between device interfaces must be between media interfaces (device interfaces that represent a physical interface or port that can host a physical connection). A device interface is a media interface when it is the root interface in its device interface hierarchy.
Rate codes are not required for device interfaces interconnected by a physical jumper. If both interfaces have rate codes, they must match or be compatible. This same rule applies to device interfaces mapped to physical ports interconnected by a physical jumper.
There are two types of physical jumpers:
-
Trail-bound jumpers are created by UIM during pipe and connectivity enablement. For example, if there are two pipes representing twister-pair cables that are terminated on different ports of the same physical device, UIM creates a physical jumper when you use the two pipes to enable a trail pipe. These jumpers exist only in the context of the trails they enable. If a trail is removed, the jumper is removed.
-
Hardwired jumpers are created manually from the Physical Jumper page. You can open the Physical Jumper page from Logical Device, Physical Device, and Equipment Summary pages. Jumpers created in this way are tied to the life cycle of the entities they connect. (They are similar in this respect to interface-bound cross-connects.)
See UIM Help for information about creating jumpers manually.
See UIM Help for information about creating jumpers manually.