Virtual Connections

This chapter provides an overview of virtual connections, their characteristics and applications, and a functional explanation of each type of virtual connection. These explanations are accompanied by steps to provide a high-level overview of configuration.

Note The information in this chapter is applicable to the Catalyst 8540 MSR, Catalyst 8510 MSR, and LightStream 1010 ATM switch routers. For detailed configuration information, refer to the ATM Switch Router Software Configuration Guide and the ATM Switch Router Command Reference publication.

This chapter includes the following sections:

Understanding ATM Virtual Connections

A virtual connection is established as a bidirectional facility to transfer ATM traffic between two ATM layer users. The following sections provide basic information about the types of ATM virtual connections, their applications, and their autonegotiated parameters.

Types of Virtual Connections

ATM provides two kinds of virtual connection services, permanent and switched. Permanent virtual connections (PVCs), are manually set up and remain up until manually torn down. Following are the two main types of PVCs:

Permanent virtual channel connections (PVCCs), specified by a virtual path identifier (VPI) and a virtual channel identifier (VCI)
Permanent virtual path connections (PVPCs), specified by a VPI only

Both PVCCs and PVPCs can support point-to-point and point-to-multipoint connections.

Switched virtual connections (SVCs) are set up through signaling and remain up only as long as they are in use. Following are the two main types of SVCs:

Switched virtual channels (SVCCs), specified by a VCI/VPI
Switched virtual paths (SVPCs), specified by a VPI

Both SVCCs and SVPCs also support point-to-point and point-to-multipoint connections.

Soft PVCs, which includes soft PVCCs and soft PVPCs, are a hybrid between switched and permanent connections. Soft PVCs are specified by source and destination VPI/VCI values and the destination ATM address. They are then set up through signaling but, unlike SVCs, remain up until manually torn down.

Transit and Terminating Connections

From the standpoint of the ATM switch router, virtual connections can be further characterized as transit or terminating connections. Transit connections are switched from the ingress to the egress of the connection, while terminating connections terminate at the ATM switch router. Terminating connections usually end on the CPU interface and are used for management and signaling purposes, though the endpoint of a normal data connection can also be considered as terminating.

Connection Components

Figure 4-1 shows an example virtual channel connection (VCC) between ATM user A and user D. The end-to-end VCC has two parts:

Virtual channel links, labelled VCL. These are the interconnections between switches, either directly or through VP tunnels.
Internal connections, shown by the dotted line in the switch. These connections are also sometimes called cross-connections or cross-connects.

The common endpoint between an internal connection and a link occurs at the switch interface. The endpoint of the internal connection is sometimes referred to as a connection leg or half-leg. A cross-connect connects two legs together.

Figure 4-1: VCC Example

Notice that the value of the VPIs and VCIs can change as the traffic is relayed through the ATM network. These values must be configured, either manually or through signaling, at each point along the connection path.

Table 4-1 lists the types of virtual connections supported on the ATM switch router.

Table 4-1: Supported Virtual Connection Types

Connection Point-to-
Point Point-to-
Multipoint Transit Terminate

Permanent virtual channel link (PVCL)

X

X

—

—

Permanent virtual path link (PVPL)

X

X

—

—

Permanent virtual channel connection (PVCC)¹

X

X

X

X

Permanent virtual path connection (PVPC)¹

X

X

X

—

Soft permanent virtual channel connection (soft PVCC)

X

—

X

—

Soft permanent virtual path connection (soft PVPC)

X

—

X

—

Switched virtual channel connection (SVCC)

X

X

X

X

Switched virtual path connection (SVPC)

X

X

X

—

¹ Refers to concatenated links and internal connections that comprise an entire virtual connection, such as from user A to
user D in Figure 4-1

Connection	Point-to- Point	Point-to- Multipoint	Transit	Terminate
Permanent virtual channel link (PVCL)	X	X	—	—
Permanent virtual path link (PVPL)	X	X	—	—
Permanent virtual channel connection (PVCC)¹	X	X	X	X
Permanent virtual path connection (PVPC)¹	X	X	X	—
Soft permanent virtual channel connection (soft PVCC)	X	—	X	—
Soft permanent virtual path connection (soft PVPC)	X	—	X	—
Switched virtual channel connection (SVCC)	X	X	X	X
Switched virtual path connection (SVPC)	X	X	X	—

Autoconfigured Parameters of Virtual Connections

When your ATM switch router initially starts up, with no previous configuration, the Integrated Local Management Interface (ILMI) protocol negotiates certain values across the UNI that serve as parameters for virtual connections. Devices on either end of the UNI connection learn and dynamically configure themselves based on the parameters received from their peers. The virtual connection-related parameters that are negotiated via ILMI are as follows:

Number of VPI bits supported—determines the maximum number of virtual path connections (VPCs) supported.
Number of VCI bits supported—determines the maximum number of VCCs supported.

If there are previously configured PVPs or PVCs, ILMI determines these as well.

Applications for Virtual Connections

The application of various virtual connection types is summarized as follows:

PVCs (PVCCs and PVPCs) connect to a node that needs quick access without signaling delay. Examples include the following:
- DNS server connections
- Terminating point-to-point and point-to-multipoint connections
- Any connection that needs to stay up permanently; for example, to connect buildings
- VP tunnels, which can connect through a public network without signaling
SVCs (SVCCs and SVPCs) connect to a node that requires longer data exchanges but infrequent connections. Examples include the following:
- E-mail server
- CAD/CAM server
- Any connection that must be established on demand, such as LAN emulation
- Connections that require VPI/VCI values within a specific range (for special applications or interworking with nonstandard equipment)
Soft PVCs, like hard PVCs, are permanent connections and have similar applications. However, they offer the advantages of setup with minimal manual configuration and the ability to reroute a connection if failure occurs. In this respect, soft virtual connections are considered more robust than hard virtual connections.

The main practical difference between a PVC and a soft PVC is that a soft PVC is automatically rerouted if a switch or link in the path fails. From that perspective a soft PVC is considered more robust than a hard PVC.

The difference between an SVC and a soft PVC is that an SVC is established on an "as needed" basis through user signaling. With a soft PVC the called party cannot drop the connection.

PVCCs

The following sections provide a general procedure for configuring PVCCs and example scenarios with PVCCs.

General Procedure for Configuring PVCC

Configuring a PVCC, such as the one shown in Figure 4-1, requires the following steps:

Step 1 Configure the connection traffic table rows (optional).

The connection traffic table specifies traffic management parameters for a connection. See the "Connection Traffic Table" section.

Step 2 Select the interface to configure and enter interface configuration mode.

Step 3 Configure the PVCC by mapping the source VPI/VCI values to the destination interface and VPI/VCI values. Do this for each cross-connect.

Using the example in Figure 4-1, you connect VPI/VCI 0/50 on interface 3/0/1 to VPI/VCI 2/100 on interface 3/0/2, and VPI/VCI 2/100 on interface 0/0/0 to VPI/VCI 50/255 on interface 0/0/1. Notice that the VPI/VCI values change on the cross-connect segment, but are the same at each end of a link between two systems.

Tips The VPI and VCI values at both ends of a link segment, for example, interface 3/0/2 on
switch B and interface 0/0/0 on switch C, must match.

Terminating PVCCs

Terminating connections provide internal connections to the ATM switch router's route processor for LAN emulation (LANE), IP over ATM, and control channels for Integrated Local Management Interface (ILMI), signaling, and Private Network-to-Network Interface (PNNI) plus network management.

In Figure 4-2, the upper diagram shows a point-to-point connection terminating on the CPU of the switch. The lower diagram shows a point-to-multipoint connection with one leaf of the connection terminating on the CPU and the other two leaves transiting the switch into the ATM network cloud.

Figure 4-2: Terminating Virtual Connection Types

The procedure for configuring a terminating PVCC is the same as for a regular PVCC, as described in the previous section, "General Procedure for Configuring PVCC." The CPU interface, on which the PVCC terminates, is always atm0 on the ATM switch router.

Point-to-Multipoint PVCCs

Figure 4-3 shows a point-to-multipoint PVCC in which cells entering the ATM switch router at the root point (0/0/0, VPI = 50, VCI = 100) are duplicated and switched to the leaf points (output interfaces) that connect into the ATM network cloud.

Figure 4-3: Point-to-Multipoint PVCC Example

The procedure for configuring a point-to-multipoint PVCC is the same as for a point-to-point PVCC, except that the VPI/VCI at the root interface must be separately mapped to the VPI/VCI on each of the leaf interfaces.

PVPCs

Figure 4-4 shows an example of PVPCs through the ATM switch routers connecting user A and user D. Because these are PVPCs, not PVCCs, they are identified by only VPIs.

Figure 4-4: PVPC Example

Configuration Overview

Configuring a PVPC, such as the one shown in Figure 4-4, requires the following steps:

Step 1 Configure the connection traffic table rows (optional).

The connection traffic table is used to specify traffic management parameters for a connection. See the "Connection Traffic Table" section.

Step 2 Select the interface to configure and enter interface configuration mode.

Step 3 Configure the PVPC by mapping the source VPI value to the destination interface and VPI value. Do this for each cross-connect.

Using the example in Figure 4-4, you would connect VPI 1 on interface 3/0/1 to VPI 2 on interface 3/0/2, and VPI 2 on interface 0/0/0 to VPI 50 on interface 0/0/1. The VPI values change on the cross-connect segment, but not on the link.

Point-to-Multipoint PVPCs

Figure 4-5 shows a point-to-multipoint PVPC in which cells entering the ATM switch router at the root point (VPI = 50), are duplicated and switched to the leaf points (output interfaces).

Figure 4-5: Point-to-Multipoint PVPC Example

The procedure for configuring a point-to-multipoint PVPC is the same as for a point-to-point PVPC, except that the VPI at the root interface must be separately mapped to the VPI on each of the leaf interfaces.

Soft PVCs

The following sections provide examples and an overview of configuring soft PVCCs and soft PVPCs.

Soft PVCCs

Figure 4-6 illustrates a soft PVCC connecting user A and user D through the ATM network cloud. Unlike hard PVCCs, the interface and VPI/VCI identifiers are needed only for the endpoints of the connection; the values for the intermediate switching points are not needed for the configuration, as these are determined by signaling.

Figure 4-6: Soft PVCC Example

Configuration Overview

Configuring a soft PVC, such as the one shown in Figure 4-6, requires the following steps:

Step 1 Configure the connection traffic table rows (optional).

The connection traffic table specifies traffic management parameters for a connection. See the "Connection Traffic Table" section.

Step 2 Decide which of the two connection endpoints you want to designate as the destination (or passive) side of the soft PVC.

This decision is arbitrary—it makes no difference which port you define as the destination end of the circuit.

Step 3 Retrieve the ATM address of the destination end of the soft PVC.

Step 4 Retrieve the currently used VPI/VCI values at both ends.

You must select unused VPI/VCI values for the connection.

Step 5 At the source end interface, specify a soft PVC with unused VPI/VCI values to the ATM address and VPI/VCI values of the destination interface.

Using the example in Figure 4-6, you would connect VPI/VCI 0 200 on interface 0/0/0 to the destination address 47.0091.8100.00.0000.1111.1111.1111.1111.1111.1111.00 with VPI/VCI 0 100.

Soft PVPCs

Figure 4-7 illustrates a soft PVPC that connects user A and user D through the ATM network cloud. The information needed to configure the soft PVPC is similar to that for a soft PVCC, except that only VPI values are used as connection identifiers.

Figure 4-7: Soft PCPC Example

The procedure for configuring a soft PVPC is identical to that used for a soft PVCC, except that no VCI values are used.

Route Optimization for Soft PVCs

PVCs typically have a much longer life than switched virtual connections. This means that the route chosen, for example, during connection setup remains the same even though the topology of the network can change over time, making the original route less than optimal. With route optimization for soft PVCCs and soft PVPCs, the route can be recomputed periodically based on the following parameters:

Time—a specified time period during which route optimization should be performed, and a time interval at which routes should be recomputed
Threshold—a specified percentage by which an alternative route must represent an improvement over the existing route for route optimization to be triggered

At the specified time, all of the soft PVCs on the interface are checked to see if a better route exists. They are only rerouted if there is an available route that passes any QoS requirements and has a cumulative administrative weight that is better than the existing route by a percentage determined by the configured route-optimization percentage-threshold value (default 30 percent). Administrative weight is similar to hop count. For a description of administrative weight, see the "Administrative WeightGlobal Mode and Per-Interface Values" section.

The route optimization feature applies to soft PVCCs and soft PVPCs on both ATM and Frame Relay interfaces.

Configuration Overview

Configuring the route optimization feature for soft PVCs requires the following steps:

Step 1 From global configuration mode, enable route optimization and specify a threshold value.

Step 2 Select the interface to configure and enter interface configuration mode. You configure route optimization on the source end only of a soft PVC.

Step 3 Specify during what time of day and how often routes should be recomputed on this interface.

You can also manually trigger route optimization on a specific soft PVC.

Note Route optimization for soft PVCs should not be configured with constant bit rate (CBR) connections.

Soft PVCs with Explicit Paths

PNNI performs dynamic routing of calls using soft PVCCs and soft PVPCs that are automatically set up over paths that meet the traffic parameter objectives. However, manually configured paths can be used in cases where a fully or partially specified explicit path is preferred. This feature is further described in the "Manually Configured Explicit Paths" section.

The explicit paths are assigned using precedence numbers 1 through 3. The precedence 1 path is tried first; if it fails the soft connection is routed using the precedence 2 path, and so forth. If all of the explicit paths fail, standard on-demand PNNI routing is tried unless routing has been configured to only use explicit paths.

An explicit path is defined using a series of entries. If the soft connection destination address is reachable at one of the included entries in an explicit path, any subsequent entries in that path are automatically disregarded. This allows longer paths to be reused for closer destinations. It is also possible to specify a point in the entries beyond which further path entries should be disregarded.

You can add, modify, or remove explicit paths without tearing down existing soft connections. When you redo a soft connection, you specify the VPI and VCI values; all applicable explicit path options are replaced by the respecified explicit path options.

The soft connection is not immediately rerouted using the new explicit path. However, reroutes using the new explicit path can happen for the following four reasons:

1. A failure occurs along the current path.

2. Route optimization has been enabled for the soft connection.

3. Route optimization has been enabled on the interface and the retry time interval has expired.

4. The soft PVC is disabled and then reenabled.

Nondefault Well-Known PVCCs

ATM needs to set up and maintain well-known virtual connections for purposes such as signaling and management. Normally the default well-known virtual connections are automatically created with the default VCIs defined by the standards. In unusual circumstances, however, you can configure nondefault well-known VCI values on a per-interface basis. Two possible instances in which you might configure nondefault well-known VCI values are:

When the ATM switch router connects with nonstandard equipment
When the ATM switch router connects with service providers who offer SVC service and need multiple signaling channels

Table 4-2 lists the well-known PVVCs and their default VPI/VCI values.

Table 4-2: Well-Known Virtual Channels

Channel Type Virtual Path Identifier Virtual Channel Identifier

Connection control signaling (QSAAL)

0

5

ILMI

0

16

PNNI

0

18

Tag switching

0

32

Channel Type	Virtual Path Identifier	Virtual Channel Identifier
Connection control signaling (QSAAL)	0	5
ILMI	0	16
PNNI	0	18
Tag switching	0	32

Caution Do not swap virtual channel values between two types of well-known VCs.

Configuration Overview

Following is an overview of the steps needed to configure nondefault well-known virtual connections:

Step 1 Display the currently configured well-known virtual connections on the interface.

Step 2 Delete any existing automatically created well-known virtual connections on the interface.

Step 3 Configure the new VPI/VCI values on the interface and specify the encapsulation type (QSAAL, ILMI, PNNI, tag).

Step 4 Save these changes to your startup configuration file so that they are not lost if the switch reboots.

VPI/VCI Ranges for SVCs

VPI/VCI conflicts can inadvertently occur when setting up SVCCs and SVPs. For example, suppose you specify a soft PVCC with VPI 0 and VCI 50 on the destination interface. An SVCC on that interface might have already taken VPI 0 and VCI 50 just before the soft PVCC setup message arrives at the destination interface. In this case, the soft PVCC is rejected because VPI 0 and VCI 50 are already taken.

Specifying the VPI/VCI range for SVCs allows you to avoid such connection setup rejections. ILMI 4.0 uses this range when negotiating the VPI/VCI values for switched connections. Even if you specify a range, you can still configure PVCCs and PVPCs of any supported value, including any VPI/VCI range you configured for SVCCs and SVPCs.

The default maximum VPI for an SVPC or SVCC is 255. For interfaces configured with a 12-bit VPI space (NNI only) the default maximum is 4095. See Table 4-3.

Table 4-3: Maximum SVP VPI Ranges

VPI Bit Type Maximum Value Range

8-Bit VPI

0-255

12-Bit VPI¹

0-4095

¹12-bit VPI configuration is available for NNI interfaces only on the Catalyst 8540 MSR.

VPI Bit Type	Maximum Value Range
8-Bit VPI	0-255
12-Bit VPI¹	0-4095

Note The maximum value specified applies to all interfaces except logical interfaces, which have a fixed value of 0.

You can change the maximum VPI value. For example, in Figure 4-8 the maximum SVPC VPI is configured as 100. Therefore, VPIs 1 to 100 are reserved for SVPCs. You can use VPIs 101 to 255 for PVPCs; however, you are not restricted to that range.

Figure 4-8: Example SVPC VPI Range

Note In Figure 4-8 the maximum available VPI value would be 4095 instead of 255 for ports configured with a 12-bit VPI.

The default maximum VCI for an SVCC is 255, and the default minimum VCI for an SVCC is equal to 35. However, you can also change the minimum SVCC VCI. In the example shown in Figure 4-9, the maximum SVCC VPI is 100 and the minimum SVCC VCI is 60. Therefore, VPIs 0 through 100 and VCIs 60 through 16,383 are reserved for SVCCs.

Figure 4-9: Example SVCC VPI/VCI Range

Note In Figure 4-9 the maximum available VPI value would be 4095 instead of 255 for ports configured with a 12-bit VPI.

Every interface negotiates the local values for the maximum SVPC VPI, maximum SVCC VPI, and minimum SVCC VCI with the peer's local value during ILMI initialization. The negotiated values determine the ranges for SVPCs and SVCCs. If the peer interface does not support these objects or autoconfiguration is turned off on the local interface, the local values determine the range.

Note The ATM router module has a default VCI space of 11 bits.

Configuration Overview

Configuring VPI/VCI ranges for SVPC and SVCCs requires the following steps at each interface where you need to specify a range:

Step 1 Select the interface to configure and enter interface configuration mode.

Step 2 Configure the maximum VPI value for SVPCs.

Step 3 Configure the maximum VPI value for SVCCs.

If you want to configure a maximum VPI greater than 255, then you must enable 12-bit VPIs on the interface. This option is platform dependent and is available on NNI interfaces only; see the configuration overview in the "NNI Interfaces" section.

Step 4 Configure the minimum VCI value for SVCCs.

VP Tunnels

Virtual path (VP) tunnels provide the ability to interconnect ATM switch routers across public networks that do not support switched virtual connections. The VP tunnel uses a permanent virtual path (PVP) through the public network; signaling is done inside the PVP.

Figure 4-10 shows a public UNI interface over a DS3 connection between the ATM switch router (HB-1) in the Headquarters building and the ATM switch router (SB-1) in the remote sales office. To support signaling across this connection, a VP tunnel must be configured.

Figure 4-10: Public VP Tunnel Network Example

Your ATM switch router supports three types of VP tunnels.

Simple VP tunnel—supports a single service category with no traffic shaping
Shaped VP tunnel—supports a single service category with rate-limited output
Hierarchical VP tunnel—supports multiple service categories with rate-limited output

Simple VP Tunnels

The simplest type of VP tunnel is one that serves a single service category. Only virtual connections of that service category can transit the tunnel. Figure 4-11, for example, shows a single VP tunnel configured as CBR with CBR virtual connections inside the tunnel.

Figure 4-11: Simple VP Tunnel

You cannot use this type of VP tunnel to send traffic of varying service categories. If you have this requirement, you should use a hierarchical VP tunnel. Also, this type of VP tunnel is not a good choice if your service provider is policing the traffic on your leased bandwidth. If you have this requirement, you should consider a shaped or hierarchical VP tunnel.

Note Simple VP tunnels do not support interface overbooking.

Configuration Overview

Configuring a VP tunnel for a single service category without traffic shaping requires the following steps:

Step 1 Configure the connection traffic table rows (optional).

The connection traffic table specifies traffic management parameters for a connection. See the "Connection Traffic Table" section.

Step 2 Select the interface to configure and enter interface configuration mode.

Step 3 Configure a PVP on the interface with a VPI value.

Step 4 From global configuration mode, create a tunnel using the VPI of the PVP as the subinterface number.

Shaped VP Tunnels

A shaped VP tunnel is configured as a PVP of the CBR service category. By default, this VP tunnel carries virtual connections only of the CBR service category. However, it is possible to configure a shaped VP tunnel to carry virtual connections of other service categories by substituting the new service category after the tunnel interface has been initially configured. The bandwidth of the shaped VP tunnel is shared by the active virtual connections inside the tunnel in strict round-robin (RR) fashion.

Figure 4-12 shows two shaped VP tunnels configured on a single physical port. One of the VP tunnels carries virtual connections of the default CBR service category; the other VP tunnel carries virtual connections of the UBR service category.

Figure 4-12: Shaped VP Tunnels

The overall output of this VP tunnel is rate-limited by hardware to the peak cell rate (PCR) of the tunnel. This feature is useful and often necessary when sending traffic through a public network using leased bandwidth that might be policed by the service provider.

Restrictions on Shaped VP Tunnels

Shaped VP tunnels have the following restrictions:

Shaped VP tunnels are not supported on systems with the FC-PCQ.

Shaped VP tunnels do not support merged VCs for tag switching. If you need to support merged VCs, you can use a hierarchical VP tunnel.

UBR+ and ABR VCs with non-zero minimum cell rate (MCR) are not allowed on a shaped VP tunnel interface. If you need to support these traffic categories, you can use a hierarchical VP tunnel.

A maximum of 128 virtual connections can transit a shaped VP tunnel interface.

There are platform-specific restrictions on the interfaces and the number of shaped VP tunnels that can be configured. Refer to the for details.

Configuration Overview

Configuring a shaped VP tunnel requires the following steps:

Step 1 Configure a CBR connection traffic table row with the desired peak cell rate (PCR).

The connection traffic table is used to specify traffic management parameters for a connection. See the "Connection Traffic Table" section.

Step 2 Select the interface to configure and enter interface configuration mode.

Step 3 Configure a PVP on the interface with a VPI value.

Step 4 From global configuration mode, create a shaped tunnel using the VPI of the PVP as the subinterface number.

Hierarchical VP Tunnels

A hierarchical VP tunnel allows virtual connections of multiple service categories to pass through the tunnel. In Figure 4-13, for example, hierarchical VP tunnels, configured as CBR, carry virtual connections of all five different service categories.

Figure 4-13: Hierarchical and Shaped VP Tunnels

The overall output of the VP tunnel is rate-limited to the PCR of the PVP. There is no general limit on the number of connections allowed on such a tunnel. Hierarchical VP tunnels can also support merged virtual connections for tag switching.

Hierarchical VP tunnels support the following service categories:

Constant bit rate (CBR)
Variable bit rate (VBR)
Available bit rate (ABR) with a nonzero MCR
Unspecified bit rate (UBR+) with a nonzero MCR

While capable of carrying any traffic category, a hierarchical VP tunnel is itself defined as CBR with a PCR.

Restrictions on Hierarchical VP Tunnels

Hierarchical VP tunnels have the following restrictions:

Hierarchical VP tunnels are not supported on systems with the FC-PCQ.

A hierarchical VP tunnel cannot coexist on a physical interface with other VP tunnels or other virtual connections, including tag switching.

Either merged virtual connections for tag switching or ATM Forum virtual connections can be carried inside the hierarchical tunnel, but not both simultaneously.

Bandwidth allocated on output to a hierarchical VP tunnel cannot be used by another hierarchical VP tunnel.

You cannot add new hierarchical VP tunnels on a physical interface if the interface's bandwidth guarantees exceed the MaxCR, regardless of any overbooking configured on that interface. See the "Interface Overbooking" section.
There are platform-specific restrictions on the interfaces and number of hierarchical VP tunnels that can be configured. Refer to the ATM Switch Router Software Configuration Guide for details.

Configuration Overview

Configuring a hierarchical VP tunnel requires the following steps:

Step 1 Enable hierarchical mode globally and save the configuration.

Step 2 Reload the ATM switch router.

Caution When you reload the ATM switch router, all active connections are lost.

Step 3 Configure the connection traffic table row with the desired CBR PCR.

The connection traffic table specifies traffic management parameters for a connection. See the "Connection Traffic Table" section.

Step 4 Select the interface to configure and enter interface configuration mode.

Step 5 Configure a PVP on the interface with a VPI value.

Step 6 From global configuration mode, create a hierarchical tunnel using the VPI of the PVP as the subinterface number.

PVCC to VP Tunnel Connections

The end point of a PVCC usually needs to be configured to transit a VP tunnel interface once the interface has been configured.

Restrictions on Configuring PVCC to VP Tunnel Connections

The following restrictions apply to an end point of a PVC-to-PVP tunnel subinterface:

The VPI number of the tunnel leg of any PVCC must match the subinterface number of the tunnel.
For single service-category VP tunnels, the service class specified by the connection-traffic-table-row (CTTR) of any PVCCs must match the service category for the row(s) selected for the tunnel PVP (for simple VP tunnels), or the configured service category (for shaped VP tunnels). This restriction does not apply to VP tunnels configured for multiple service categories (hierarchical VP tunnels).
For service classes other than UBR, the PCRs of all PVCCs must be within the PCR of the tunnel PVP. This setup requires new CTTR rows to be defined for CBR or VBR PVCCs, with peak cell rates that are less than the intended tunnel PVP.

Configuration Overview

Configuring a PVCC to a VP tunnel is similar to configuring other cross-connections, and requires the following steps:

Step 1 Enter interface configuration mode for the interface you want to connect to the VP tunnel.

Step 2 Configure the PVCC by associating its VPI and VCI values to the subinterface and VPI/VCI values for the VP tunnel.

Signaling VPCI for VP Tunnels and Virtual UNI

When VPI values on VP tunnels or virtual UNI interfaces are remapped as they traverse a VP switch, signaling can fail. For example, a VP tunnel connection from an ATM switch router on VPI 2, VCI X, to a router with a VP switch in between, would have a signaling message with connection ID, VPI 2, VCI X. If the VP tunnel at the router end is on VPI 3, VCI X, the connection is refused. By configuring VPCI to 3, you can configure the signaling message explicitly to contain connection ID VPI 3, VCI X, instead of VPI 2, VCI X.

A similar situation occurs when a virtual UNI is configured. For example, multiple VP tunnels traversing a VP switch might all carry signaling on VPI 0, VCI X. But these get remapped at the VP switch to, for example, VPI 1, VCI X. The end system expects VPI 0, VCI X, so the signaling request fails.

This problem is solved by specifying a signaling virtual path connection identifier (VPCI). The signaling VPCI specifies the value that is to be carried in the signaling messages within a VP tunnel. The connection identifier information element (IE) is used in signaling messages to identify the corresponding user information flow. The connection identifier IE contains the VPCI and VCI.

Note By default, the VPCI is the same as the VPI on the ATM switch router.

Configuration Overview

Configuring the signaling VPCI requires the following steps:

Step 1 Select the subinterface (VP tunnel) to configure and enter interface configuration mode.

Step 2 Specify a VPCI value.

Configuring the VPCI with a value of 0 works in most circumstances.

Table of Contents

Virtual Connections