|
|
This chapter provides a description of MPLS CoS with the use of the BPX 8650 ATM Label Switch Router (ATM LSR). It also contains a summary example for configuring BPX 8650 ATM LSRs, their associated LSCs (7200 or 7500 series), and Edge Label Switch Routers. For additional information, refer to Cisco 7200 or 7500 series router and MPLS related IOS documentation. Refer to 9.2 Release notes for supported features.
The chapter contains the following:
The MPLS CoS feature enables network administrators to provide differentiated types of service across an MPLS Switching network. Differentiated service satisfies a range of requirements by supplying the particular kind of service specified for each packet by its CoS. Service can be specified in different ways—for example, through use of the IP precedence bit settings in IP packets or in source and destination addresses.
In supplying differentiated service, MPLS CoS offers packet classification, congestion avoidance, and congestion management. Table 21-1 lists these functions and the means by which they are delivered.
| Service | CoS Function | Description |
|---|---|---|
Packet classification | Committed access rate (CAR). Packets are classified at the edge of the network before labels are assigned. | CAR uses the type of service (TOS) bits in the IP header to classify packets according to input and output transmission rates. CAR is often configured on interfaces at the edge of a network in order to control traffic into or out of the network. You can use CAR classification commands to classify or reclassify a packet. |
Congestion avoidance | Weighted random early detection (WRED). Packet classes are differentiated based on drop probability. | WRED monitors network traffic, trying to anticipate and prevent congestion at common network and internetwork bottlenecks. WRED can selectively discard lower priority traffic when an interface begins to get congested. It can also provide differentiated performance characteristics for different classes of service. |
Congestion management | Weighted fair queueing (WFQ). Packet classes are differentiated based on bandwidth and bounded delay. | WFQ is an automated scheduling system that provides fair bandwidth allocation to all network traffic. WFQ classifies traffic into conversations and uses weights (priorities) to determine how much bandwidth each conversation is allocated, relative to other conversations. |
MPLS CoS lets you duplicate Cisco IOS IP CoS (Layer 3) features as closely as possible in MPLS switching devices, including label switching routers (LSRs), edge LSRS, and ATM label switching routers (ATM LSRs). MPLS CoS functions map nearly one-for-one to IP CoS functions on all interface types.
The MPLS CoS feature can be used optionally with MPLS Virtual Private Networks. MPLS CoS can also be used in any MPLS switching network.
For more information on configuration of the CoS functions (CAR, WRED, and WFQ), refer to the Cisco IOS Class of Service for Tag Switching Feature Guide, and the Cisco IOS Quality of Service Solutions Configuration Guide.
For complete command syntax information for CAR, WRED, and WFQ, refer to the Cisco IOS Quality of Service Solutions Command Reference.
For additional information on BPX 8650 CLI commands, refer to the Cisco WAN Switch Command Reference.
In order to use the MPLS CoS feature, your network must be running the following Cisco IOS features:
Also, the BPX 8650 must have:
ATM-LSR—An ATM label switching router with a number of LC-ATM interfaces. The router forwards the cells among these interfaces using labels carried in the VPI/VCI field.
CAR—Committed Access Rate (packet classification). CAR is the main feature supporting packet classification. CAR uses the type of service (TOS) bits in the IP header to classify packets. You can use the CAR classification commands to classify and reclassify a packet.
CoS—Class of service. A feature that provides scalable, differentiated types of service across a label switched network.
DWFQ—VIP-Distributed WFQ.
DWRED—VIP-Distributed WRED.
edge ATM LSR—A switch router that is connected to the ATM-LSR cloud through LC-ATM interfaces. The edge ATM LSR adds labels to unlabeled packets and strips labels from unlabeled packets.
IP Precedence—3-bit value in TOS byte used for assigning Precedence to IP packets.
MPLS—Multiprotocol Label Switching. Networks using MPLS, transport IP packets over ATM using label switching, thereby realizing the flexibility and scalability of TCP/IP along with the switching speed and reliability of ATM.
QoS—Quality of service. Measure of performance for a transmission system that reflects its transmission quality and service availability.
RED—Random early detection. Congestion avoidance algorithm in which a small percentage of packets are dropped when congestion is detected and before the queue in question overflows completely.
label—A label is a header used by an LSR to forward packets. The header format depends upon network characteristics. In router networks, the label is a separate, 32-bit header. In ATM networks, the label is placed into the virtual channel identifier/virtual path identifier (VCI/VPI) cell header. In the core, LSRs read only the label, not the packet header. One key to the scalability of MPLS is that labels have only local significance between two devices that are communicating.
label imposition—The act of putting the first label on a packet.
edge label switch router (LSR)—The edge device that performs initial packet processing and classification and applies the first label. This device can be either a router, such as the Cisco 7500, or a switch with built-in routing, such as the Cisco BPX 8650.
label switch router (LSR)—The core device that switches labeled packets according to precomputed switching tables. It can also be a switch or a router.
Label VC (LVC)—An ATM virtual circuit that is set up through ATM LSR label distribution procedures.
label-controlled ATM interface (LC-ATM interface)—An interface on a router or switch that uses label distribution procedures to negotiate label VCs.
Label Switched Path (LSP)—Path defined by all labels assigned between end points. An LSP can be dynamic or static
TOS—Type of Service. A byte in the IPv4 header.
VPN—Virtual private network. A secure network that shares resources with one or more physical networks. A VPN can contain one or more geographically dispersed sites that can communicate securely over a shared backbone.
WEPD—Weighted Early Packet Discard
WRED—Weighted RED. A variant of RED in which the probability of a packet being dropped depends on either, its IP Precedence, CAR marking, or Label Switching CoS (as well as the other factors in the RED algorithm).
WFQ—Weighted Fair Queueing. A queue management algorithm that provides a certain fraction of link bandwidth to each of several queues, based on a relative bandwidth applied to each of the queues.
As part of their VPN services, service providers may wish to offer premium services defined by Service Level Agreements (SLAs) to expedite traffic from certain customers or applications. QoS in IP networks gives devices the intelligence to preferentially handle traffic as dictated by network policy. QoS is defined as those mechanisms that give network managers the ability to control the mix of bandwidth, delay, jitter, and packet loss in the network. QoS is not a device feature, it is an end-to-end system architecture. A robust QoS solution includes a variety of technologies that interoperate to deliver scalable, media-independent services throughout the network, with system-wide performance monitoring capabilities.
The actual deployment of QoS in a network requires a division of labor for greatest efficiency. Because QoS requires intensive processing, the Cisco model distributes QoS duties between edge and core devices, which can be multilayer switches or routers. Edge devices do most of the processor-intensive work, performing application recognition to identify flows and classify packets according to unique customer policies. Edge devices also provide bandwidth management. Core devices expedite forwarding while enforcing QoS levels assigned at the edge.
MPLS-enabled networks make use of Cisco IOS QoS features to build an end-to-end QoS architecture:
The key to an effective, network-wide IP QoS plan is scalability. Applying QoS on a flow-by-flow basis is not practical because of the huge numbers of IP traffic flows in carrier-sized networks. A scalable way to provide higher levels of service quality with minimal loss in granularity is to implement multiple service classes, or classes of service (CoSs). For example, a service provider network may implement three service classes: a high-priority, low-latency class, a guaranteed-delivery "mission-critical" service, and a low-priority "best-effort" class. Subscribers can use the mix of services that suits their needs. For example, subscribers may wish to use a guaranteed-delivery, low-latency service for their video conferencing applications, and best-effort service for e-mail traffic.
MPLS makes it possible to apply scalable QoS across very large routed networks and Layer 3 IP QoS in ATM networks, because providers can designate sets of labels that correspond to service classes. In routed networks, MPLS-enabled QoS substantially reduces processing throughout the core for optimal performance. In ATM networks, MPLS makes end-to-end Layer 3-type services possible. Traditional ATM and Frame Relay networks implement CoS with point-to-point virtual circuits, but this is not scalable because of high provisioning and management overhead. Placing traffic into service classes at the edge enables providers to engineer and manage classes throughout the network. If service providers manage networks based on service classes, not point-to-point connections, they can substantially reduce the amount of detail they must track and increase efficiency without losing functionality. Compared to per-circuit management, MPLS-enabled CoS in ATM networks provides virtually all the benefits of point-to-point meshes with far less complexity. Using MPLS to establish IP CoS in ATM networks eliminates per-VC configuration. The entire network is easier to provision and engineer.
In IP+ATM networks, MPLS uses predefined sets of labels for each service class, so switches automatically know which traffic requires priority queuing. A different label is used per destination to designate each service class (see Figure 21-1). There can be up to four labels per IP source-destination. Using these labels, core LSRs implement class based WFQ to allocate specific amounts of bandwidth and buffer to each service class. Cells are queued by class to implement latency guarantees. On a Cisco IP+ATM LSR, the weights assigned to each service class are relative, not absolute. The switch can therefore "borrow" unused bandwidth from one class and allocate it to other classes (according to weight). This scenario enables very efficient bandwidth utilization. The class based WFQ solution ensures that customer traffic is sent whenever unused bandwidth is available, whereas ordinary ATM VCs drop cells in oversubscribed classes even when bandwidth is available.
Packets have their precedence bits in the Type of Service field of the IP header, set at either the host or an intermediate router, which could be the edge Label Switch Router (LSR). The precedence bits define a Class of Service (CoS) 0-3, corresponding for to premium, standard, available, or control, for example.
To establish CoS operation when the BPX and the associated LSC router (7200 or 7500 series) are initially configured, the binding type assigned each LVC interface on the BPX is configured to be multiple LVCs.
Then under the routing protocol (OSPF, for example), four LVCs are set up across the network for each IP source to destination requirement. Depending on the precedence bits set in the packets that are received by the edge LSR, the packet ATM cells that are sent to the ATM LSR will be one four classes (as determined by the cell label, that is, VPI.VCI). Furthermore, two subclasses are distinguishable within each class by the use of the Cell Loss Priority (CLP) bit in the cells.
Then the ATM LSR performs a MPLS data table lookup and assigns the appropriate template class of service template and qbin characteristics. The default mapping for CoS is listed in Table 21-2.
| Class of Service Mapping | Class of Service | IP ToS |
Available | 0 | ToS 0/4 |
Standard | 1 | ToS 1/5 |
Premium | 2 | ToS 2/6 |
Control | 3 | ToS 3/7 |
Figure 21-2 shows an example of IP traffic across an ATM core consisting of BPX 8650 ATM LSRs. The host is seen to be sending two types of traffic across the network, interactive video and non-time critical data. Since multiple LVCs have automatically been generated for all IP source-destination paths, traffic for each source destination is assigned to 1 of 4 LVCs, based on the precedence bit setting in the IP packet header. In this case, the video traffic might be assigned to the premium CoS, and transmitted across the network starting with the cell label "51" out of the Edge LSR-A, and continuing across the network with the cell label "91" applied to the Edge LSR-C. In each BPX 8650 ATM LSR, the cells are processed with the pre-assigned bandwidth, queuing, and other ATM QoS functions suitable to "premium" traffic. In a similar fashion, low priority data traffic cells with the same IP source-destination might be assigned label "53 out of Edge LSR-A and arrive at Edge LSR-C with the label "93", receiving pre-assigned bandwidth, queuing and other ATM QoS functions suitable to "available" traffic.
The service class template provide a means of mapping a set of extended parameters, which are generally platform specific, based on the set of standard ATM parameters passed to the VSI slave in a BXM port interface during initial setup of the interface.
A set of service templates is stored in each switch (BPX 8650) and downloaded to the service modules (BXMs) as needed during initial configuration of the VSI interface when a trunk or line is enabled on the BXM.
For MPLS, an MPLS service termplate is assigned to the VSI interface when the trunk or port is initialized The label switch controller (LSC) automatically sets up LVCs via a routing protocol (e.g., OSPF) and the Label Distribution Protocol (LDP), when the class of service Multiple LVC option is enabled at the edge label switch routers (LSRs). With the Multiple VC option enabled (at edge LSRs), four LVCs are configured for each IP source-destination. Each of the four LVCs is assigned a service template type. For example, one of the four cell labels might be assigned to label cos2 service type category. Each service template type has an associated qbin (see Figure 21-3). The qbins provide the ability to manage bandwidth by temporarily storing cells and then serving them out as bandwidth is available based on a number of factors, including bandwidth availability and the relative priority of different classes of service.
When ATM cells arrive from the edge LSR at the BXM port with one of four CoS labels, they receive CoS handling based on that label. A table look up is performed, and the celsl are processed based on their connection classification. Based on its label, a cell receives the ATM differentiated service associated with its template type, that is, MPLS1 template, and service type, for example., label cos2 bw, associated qbin characteristics, and other associated ATM parameters.
The service template contains two classes of data. One class consists of parameters necessary to establish a connection (that is, per LVC) and includes entries such as UPC actions, various bandwidth related items, per LVC thresholds, etc. The second class of data items includes those necessary to configure the associated class of service buffers (qbins) that provide CoS support.
When a connection setup request is received from the VSI master in the Label Switch Controller, the VSI slave (in the BXM, for example) uses the service type identifier to index into a Service Class Template database (Figure 21-3) containing extended parameter settings for connections matching that index. The slave uses these values to complete the connection setup and program the hardware.
When the upport or uptrk command is used to activate an interface on the BXM card, the default service template, which is MPLS1, is assigned to the interface (Figure 21-3). Each template table row includes an entry that defines the qbin to be used for that class of service. This mapping defines a relationship between the template and the interface qbin's configuration.
Qbin templates are used only with qbins that are available to VSI partitions, namely qbins 10 through 15. Qbins 10 through 15 are used by the VSI on interfaces configured as trunks or ports. The rest of the qbins (0-9) are reserved for and configured by Autoroute.
The basic functions that are applied to a packet, as it makes its way from on host on the left side of a network (see Figure 21-4), through the network consisting of conventional routers, label edge routers (LSRs), Label Switch Routers (LSRs), and ATM LSRs such as a BPX 8650 are as follows:
The typical operation for MPLS CoS in the network shown in Figure 21-4 is as follows:
Step 2 Apply one or more labels, and copy the IP ToS to Label CoS in the label header at the edge label switch router (LSR).
Step 3 Queue the packet in a Label Switch Router (LSR) according to its CoS.
Step 4 Map the MPLS and MPLS CoS bits to an ATM Label-VC in (LSR at edge of ATM cloud).
Step 5 Apply ATM CoS bandwidth and queuing to ATM cells based on their class of service in the ATM LSR (BPX 8650, for example).
Step 6 Receive the packet from the ATM cloud and forward it with appropriate Label CoS through a LSR (could be frame-based LSR) at the edge of the ATM cloud.
Step 7 Receive the labeled packet, remove the label, and forward the IP packet with appropriate CoS towards its destination (edge LSR).
There are four default policy types for MPLS CoS. The default relative bandwidth per xtagatm interface are listed in Table 21-3. The relative bandwidth weights determine the proportion of bandwidth available to MPLS which is given to each class of service on each link. If a CoS does not use the bandwidth given to it, then the bandwidth may be shared among the other CoSes.
| Class of Service Mapping | Class of Service | IP ToS | Default Bandwidth Weight |
Available | 0 | ToS 0/4 | 50 |
Standard | 1 | ToS 1/5 | 50 |
Premium | 2 | ToS 2/6 | 0 |
Control | 3 | ToS 3/7 | 1 |
It is important to reserve a small amount of bandwidth for the Control CoS. This CoS is used for MPLS control traffic, and it is important to guarantee a good quality of service for this traffic. For this reason, it is desirable to reserve a small amount of bandwidth for the Control CoS as shown in Table 21-4.
| Class of Service Mapping | Class of Service | IP ToS | Bandwidth Weight |
Available | 0 | ToS 0/4 | 49 |
Standard | 1 | ToS 1/5 | 50 |
Premium | 2 | ToS 2/6 | 0 |
Control | 3 | ToS 3/7 | 1 |
To verify an xtagatm interface after configuration on the LSC, perform a show xtagatm cos-bandwidth-allocation xtagatmxx, where xx is the interface number. The maximum value for cos bandwidth is 100.
The setup for the configuration example is shown in Figure 21-5.
Configure the following resources according to the example setup shown in Figure 21-5:
When configuring BPX1 and BPX1 verify that no software, card, and trunk errors are reported on the console. In this example, all VSI resources are allocated to maximum value.
BPX configurations:
BPX1
uptrk 1.1 //LSC1 control port
uptrk 1.3 //trunk via BPX1
upln 1.2 //up line for LER1
cnfrsrc 1.1 0 352207 y 1 e 0 3000 1 20 0 352207 //LSC1
cnfrsrc 1.3 0 352207 y 1 e 0 3000 1 20 0 352207 //trunk
cnfrsrc 1.2 0 353207 y 1 e 0 3000 1 20 0 352307 //LER1 port
addshelf v 1 1 //control-id=1;partition number=1
BPX2
uptrk 2.1 //LSC2 control port
uptrk 2.3 //trunk via BPX1
upln 2.2 //up line for LER2
cnfrsrc 2.1 0 352207 y 1 e 0 3000 1 20 0 352207 //LSC2
cnfrsrc 2.3 0 352207 y 1 e 0 3000 1 20 0 352207 //trunk
cnfrsrc 2.2 0 353207 y 1 e 0 3000 1 20 0 352307 //LER2 port
addshelf v 2 1 //control-id=2;partition number=1
Check that VSI resources have been allocated and that the LSC controller was added successfully.
dsptrks //successful with no alarms
dspvsipartinfo //verify lcns and bandwidth are allocated successfully
dsplns //no alarm
dspctrlrs //controller ID is added successfully
There are four default policy parameters for MPLS CoS. The default relative bandwidth per xtagatm interface are as follows: 50 percent for available (0/4 IP ToS), 50 percent for standard (1/5), zero for premium (2/6), and zero for control (3/7) Class of Service. Once xtagatm interface have been defined for each LSC, do a `show xtagatm cos-bandwidth-allocation xtagatmxx', where xx is interface number. Verify that default relative bandwidth are properly assigned in percentage value. The maximum value for cos-bandwidth is 100.
LSC configurations:
LSC1
LSC11-1#config t
LSC1(config)#int atm1/0 //LSC1LSC1 control port
LSC1(config-if)#no shut
LSC1(config-if)#tag-control-protocol vsi
LSC1(config-if)#exit
LSC1(config)#int xtagatm12 //LSR1 port 1.2
LSC1(config-if)#extended-port atm1/0 bpx 1.2
LSC1(config-if)#tag-switching ip
LSC1(config-if)#tag-switching atm cos available 49
LSC1(config-if)#tag-switching atm cos standard 50
LSC1(config-if)#tag-switching atm cos premium 0
LSC1(config-if)#tag-switching atm cos control 1
LSC1(config-if)ip unnumbered loopback0
LSC1(config-if)#exit
LSC1(config)#int xtagatm13 //LSR1 port 1.3
LSC1(config-if)#extended-port atm1/0 bpx 1.3
LSC1(config-if)#tag-switching ip
LSC1(config-if)#tag-switching atm cos available 49
LSC1(config-if)#tag-switching atm cos standard 50
LSC1(config-if)#tag-switching atm cos premium 0
LSC1(config-if)#tag-switching atm cos control 1
LSC1(config-if)ip unnumbered loopback0
LSC1(config-if)#exit
LSC1(config)#int loopback0 //configure loopback0 interface
LSC1(config-if)#ip address 200.200.200.1 255.255.255.255
LSC1(config-if)#exit
LSC1(config)#ip routing //enable IP routing
LSC1(config)#ip cef //enable Cisco Express Forwarding Protocol
LSC1(config)#router ospf 10
LSC1(config-router)#network 200.200.200.1 0.0.0.0 area 0
LSC1(config-router)#end
LSC2
LSC2#config t
LSC2(config)#int atm2/0 //LSC2 control port
LSC2(config-if)#no shut
LSC2(config-if)#tag-control-protocol vsi id 2
LSC2(config-if)#exit
LSC2(config)#int xtagatm22 //LSR2 port 2.2
LSC2(config-if)#extended-port atm1/0 bpx 2.2
LSC2(config-if)#tag-switching ip
LSC2(config-if)#tag-switching atm cos available 49
LSC2(config-if)#tag-switching atm cos standard 50
LSC2(config-if)#tag-switching atm cos premium 0
LSC2(config-if)#tag-switching atm cos control 1
LSC2(config-if)ip unnumbered loopback0
LSC2(config-if)#exit
LSC2(config)#int xtagatm23 //LSR2 port 2.3
LSC2(config-if)#extended-port atm1/0 bpx 2.3
LSC2(config-if)#tag-switching ip
LSC2(config-if)#tag-switching atm cos available 49
LSC1(config-if)#tag-switching atm cos standard 50
LSC1(config-if)#tag-switching atm cos premium 0
LSC1(config-if)#tag-switching atm cos control 1
LSC2(config-if)ip unnumbered loopback0
LSC2(config-if)#exit
LSC2(config)#int loopback0 //configure loopback0 interface
LSC2(config-if)#ip address 200.200.200.2 255.255.255.255
LSC2(config-if)#exit
LSC2(config)#ip routing //enable IP routing
LSC2(config)#ip cef //enable Cisco Express Forwarding Protocol
LSC2(config)#router ospf 10
LSC2(config-router)#network 200.200.200.2 0.0.0.0 area 0
LSC2(config-router)#end
Edge LSR configurations:
LSR1
LSR1LSR1#config t
LSR1(config)#int atm1/0 //LSR1 interface
LSR1(config-if)#no shut
LSR1(config-if)#exit
LSR1(config)#interface atm1/0.1 tag-switching //create tag sub-interface
LSR1(config-subif)#ip unnumbered loopback0
LSR1(config-subif)#tag-switching atm multi-vc //enable multi-vc mode (4 VCs)
LSR1(config-subif)#tag-switching ip
LSR1(config)#int loopback0 //configure loopback0 interface
LSR1(config-if)#ip address 200.200.100.1 255.255.255.255
LSR1(config)#ip routing //enable IP routing
LSR1(config)#ip cef //enable Cisco Express Forwarding Protocol
LSR1(config)#router ospf 10
LSR1(config-router)#network 200.200.100.1 0.0.0.0 area 0
LSR1(config-router)#exit
In default multiple LVC mode, there are four MPLS Cos LVCs created by cos-map with clp set to off. The four classes of service are available (0/4), standard (1/5), premium (2/6), and control (3/7).
LSR2
LSR2#config t
LSR2LSR2(config)#int atm2/0 //LSR2 interface
LSR2(config-if)#no shut
LSR2(config-if)#exit
LSR2(config)#interface atm2/0.1 tag-switching //create tag sub-interface
LSR2(config-if)#ip unnumbered loopback0
LSR2(config-if)#tag-switching ip
LSR2(config)#int loopback0 //configure loopback0 interface
LSR2(config-if)#ip address 200.200.100.2 255.255.255.255
LSR2(config)#ip routing //enable IP routing
LSR2(config)#ip cef //enable Cisco Express Forwarding Protocol
LSR2(config)#router ospf 10
LSR2(config-router)#network 200.200.100.2 0.0.0.0 area 0
LSR2(config-router)#end
LSR2(config)#tag-switching cos-map 1 //configure Cos-Map
LSR2(config-tag-cos-map)#end //for now use default 4 VCs
LSR2#sho tag-switching cos-map //there should be 4 VCs w/ clp off
LSR2#config t
LSR2(config)#access-list 1 permit 200.200.100.1 0.0.0.0 //create access list for network 200.200.100.1
LSR2(config)#tag-switching prefix-map 1 access-list 1 cos-map 1 //map access-list to cos-map 1
LSR2(config)#show tag forward 200.200.100.1 32 detail //verify forwarding table
Verify that the LSC/LSR is operational and BPXs have clear alarms. LSR1 should be able to ping to LSR2 successfully.
Check that VSI resources have been allocated and controller was added successfully. BPXs should have clear alarms and no software log and trunk errors.
BPX1/BPX1
dsptrks //successful with no alarms
dspvsipartinfo //verify lcns and bandwidth are allocated successfully
dsplns //no alarm
dspctrlrs //controller ID is added successfully
Check that LSC/edge LSR interfaces are operational and TDP bindings are successful.
LSC1 and LSC2
LSC1#sho tag interface //xtagatm interfaces are operational
LSC1#sho xtag cross-connect //verify crosss-connect
LSC1#sho xtag vc //verify tag vc
LSC1#sho control vsi descriptor //verify VSI VPI range and Bw
LSC1#sho control vsi control-interface //verify number of connections for each cross-connect
LSC1#sho control vsi traffic //verify traffic statistics
LSC1#sho tag atm bind //verify tag atm bindings
LSC1#sho tag atm sum //verify local/remote connections
LSR1 and LSR2
LSR1#sho tag interface //xtagatm interfaces are operational
LSC2#sho tag tdp disc //verify tdp session rx/tx
LSC2#sho atm vc //verify atm pvc and tvc
Posted: Thu Jul 26 18:38:07 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
