Virtual circuits (VCs) are used interchangeably
with the terms virtual circuit number (VCN), logical
channel number (LCN), and virtual channel identifier (VCI).
A VC can be a permanent virtual circuit (PVC) or, more commonly, a
switched virtual circuit (SVC).
An SVC exists only for the duration of the session.
Three phases are associated with SVCs:
- Call setup
- Information transfer
- Call clear
A PVC is similar to a leased line. Both the
network provider and the attached X.25 subscriber must provision the
VC. PVCs use no call setup or call clear that is apparent to the
subscriber. Any provisioned PVCs are always present, even when no
data traffic is being transferred.
The X.25 protocol offers simultaneous service
to many hosts (for example, a multiplex connection service). An X.25
network can support any legal configuration of SVCs and PVCs over
the same physical circuit attached to the X.25 interface. However,
configuring of X.25 assumed service for time-sharing and
terminal-to-host applications, not contemporary computer-to-computer
applications. Cisco routers provide numbering for up to 4095 VCs per
X.25 interface.
Throughput for encapsulating a specific
protocol can be improved by using multiple SVCs. Multiple SVCs
provide a larger effective window size, especially for protocols
that offer their own higher-layer resequencing. SVCs may be combined
to improve throughput for a particular protocol. This combination of
SVCs does not benefit traditional X.25 applications, such as those
available from a time-sharing host.
Single Protocol Virtual Circuits
The traditional encapsulation method for the
Cisco router enables different protocols to transport their
datagrams through an X.25 cloud because the router uses separate
VCs. Each protocol is specified in an individual x25 map
command that references the X.121 address used to reach the
destination.
Multiprotocol Virtual Circuits
In Cisco IOS® Release 10.2 and later
releases, a single VC to a host can carry traffic from multiple
protocols. One X.25 map statement contains several protocol
addresses, mapped to a single X.121 address associated with the
destination host.
This capability uses the method described in
RFC 1356. Each of the supported protocols can map
to a destination host. Because routing multiple protocols over a VC
generates higher traffic loads, combining SVCs, as described earlier
in this chapter, may improve throughput.
X.25 Encapsulation
Two methods are available to
encapsulate traffic in X.25: The long-available Cisco encapsulation
method and the Internet Engineering Task Force’s (IETF's) standard
method (defined in RFC 1356). The latter allows hosts to exchange
several protocols over a single VC. The Cisco encapsulation method
is the default (for backward compatibility), unless the interface
configuration command specifies IETF.
|