Release Notes for Cisco Service Selection Dashboard, Release 3.0(1)

SSD Release 3.0(1) provides extremely robust, highly scalable connection management to Internet services. It provides the end user (the subscriber) with a single web page for accessing multiple Internet services. The ISPs and NAPs deploying SSD Release 3.0(1) can customize the content of the web pages and thereby control the subscriber experience for different categories of subscribers.

These release notes discuss the following topics:

Introduction

The Cisco Service Selection Dashboard (SSD) uses the following software components:

SSD software—The SSD Release 3.0(1) software is a set of Java-based components that are used by ISPs and NAPs to create customized web server applications. An SSD web server application presents subscribers with a menu of services, enabling them to access and disconnect from different services using a web browser.
Service Selection Gateway (SSG)—SSG is a feature module embedded in Cisco IOS software that runs on the Cisco 6400 Universal Access Concentrator (UAC). Each node route processor on the Cisco 6400 UAC can host an SSG.
RADIUS server—This solution works with any RADIUS server that can accept vendor specific attributes (VSAs). The Cisco Access Registrar (Cisco AR) is recommended.

For subscribers of Internet services, SSD offers flexibility and convenience, including the ability to access multiple services simultaneously. Subscribers interact with SSD from a web page using a standard Internet browser. They do not need to download any software or plug-ins to use SSD.

For Internet service providers, SSD provides a way to control the user experience and promote customer loyalty. Service providers can change the look and feel of an SSD application, brand the application, and control the content of the pages displayed to their subscribers.

New World Service Provider Sample Application

The SSD installation package includes a sample SSD application, called the New World Service Provider (NWSP), that you can configure and subsequently execute as an example of SSD capabilities. You can create the desired look-and-feel and branded aspects of a customized SSD application by altering the sample application or writing your own application using the NWSP as an example.

Captive Portal Sample Application

The SSD installation package includes a captive portal sample application. This application demonstrates how several powerful features in SSD Release 3.0(1) work together to redirect unauthorized users to an SSD signon page immediately after opening a web browser. See the "New Features" section for more information about this and other SSD features.

Demo Installation

The SSD installation program provides an option to install a demo version of the NWSP and captive portal sample applications. The demo version simulates the actions of an SSD application without actually using an SSG or a RADIUS server. The demo is intended for demonstration purposes only and does not predict SSD performance in a production environment.

Host Key Feature on SSG

The host key is an important new feature on the SSG. The host key is a software token (or key) that uniquely identifies each subscriber (or host) currently logged on to SSD, even when multiple subscribers are using the same IP address. The host key feature provides the following advantages to SSD applications:

Host key allows SSD applications to robustly handle overlapping IP addresses, nonroutable IP addresses, and dynamically assigned IP addresses.
Host key eliminates the need to explicitly map subscriber subnets to SSGs.

Jetty Server

SSD applications are Java 2 Platform, Enterprise Edition (J2EE) compliant web server applications. In the sample SSD application, J2EE services are provided by embedded Jetty server components from Mort Bay Consulting. The SSD installation procedure installs these Jetty server components along with the SSD application. If desired, web developers at your site can deploy a J2EE-compliant server other than the Jetty server.

Note Initially, the host key feature will work only with SSD applications running on the Jetty server.

Required Cisco IOS Release for SSG

SSD Release 3.0(1) software requires the SSG embedded in Cisco IOS Release 12.1(5)DB/DC or later.

Upgrading Earlier SSD Applications

The configuration and deployment of SSD Release 3.0(1) is different from earlier SSD releases. The main differences are:

The look and feel of an SSD application is controlled by Java Server Pages (JSPs) rather than HTML templates.
The configuration is enhanced with the use of Java Management Extensions (JMX) and XML.

If you are currently using SSD Release 2.5(1) or earlier, see the "Upgrading from SSD Release 2.5(1)" section for migration information.

Installation Note

The SSG and RADIUS components do not need to be installed and configured before you execute the SSD Release 3.0(1) installation program. However, the installation program prompts you for configuration information about these components, such as IP addresses, ports, shared secrets, and other information required for SSD to communicate with them. You should know these values before you perform the installation. Otherwise, you will need to reconfigure the solution later.

If you are installing the demo, you do not need SSG and RADIUS communication parameters.

Documentation Set

See the following documentation regarding the SSD Release 3.0(1) solution.

Cisco Service Selection Dashboard Installation and Configuration Guide
Cisco Service Selection Dashboard Web Developer Guide
Cisco 6400 Feature Guide, Chapter 4, "Service Selection Gateway"
Cisco 6400 NRP - Release Notes for Cisco IOS Release 12.1(5)DC

New Features

The key new features in this release are:

Captive portal
JSP support
Host key, which provides support for overlapping IP addresses and non-routable IP addresses
Subscriber device and locale awareness
Localization support

Features in SSD Release 3.0(1)

Table 1 describes SSD features. Column 3 in the table indicates whether the feature was carried over from SSD 2.5(1) or is new to SSD Release 3.0(1).

Table 1: Features in SSD

Feature	Description	New
Multiple service selection gateway	This feature provides a single gateway to all Internet services for a subscriber. An SSD web server application performs the following for the subscriber: User authentication—Verifies the identity of a subscriber. Service authorization—Verifies that the subscriber has permission to access a specific Internet service. Service connection—Connects to an Internet service.	No
Single sign-on in a point-to-point (PPP) network	This feature offers a streamlined login procedure in a PPP network. A subscriber who logs on using a PPP client can access the SSD without having to re-enter the username and password.	No
Host key	This feature on the SSG ensures that each currently logged-on subscriber is uniquely identified, regardless of the IP address being used. This SSG feature allows SSD applications to support the following types of subscribers: Overlapping IP addresses in PPP and bridged environments—SSD can differentiate between various subscribers using the same IP address. Nonroutable subscriber IP addresses—SSD supports subscribers at sites using private IP addressing schemes, including subscribers of ISPs using private addressing schemes. Dynamic IP address assignment—The subscriber session state status within SSG and SSD remains synchronized when a subscriber's IP address changes.	New
Java Server Pages (JSPs)	This feature provides a standard way to integrate Java code with HTML to present interactive, dynamically updated, personalized, and branded web pages to your subscribers.	New
Walled gardens, retail pages, and service advertisements	The following features are implemented through the use of customized JSPs: Walled Gardens—Service providers can use SSD to offer a walled garden, a branded offering of value-added services specific to a particular service provider. Retail Pages—Wholesale providers can offer retail pages with a customized look and feel for each Internet service provider. Service Advertisement—Service providers can use SSD to reach subscribers with targeted messages and thereby increase the take rate on new services.	No
Captive portal	This feature works with the TCP redirect feature on the SSG to redirect HTTP requests for unauthenticated subscribers. The TCP redirect feature on the SSG redirects incoming TCP packets to a specified SSD web server. SSD Release 3.0(1) can redirect packets originating from unauthorized users, which, in effect, redirects packets from subscribers when they first open their Internet browsers and are not yet authenticated by SSD. Future releases will allow redirection based on the packet's source network or destination port. An SSD web server in captive portal mode is configured with a corresponding captive portal application that redirects the HTTP requests to the authentication page of the main application. The following examples show how a captive portal application might handle redirected packets. A captive portal application can redirect packets from unauthorized users to the SSD logon page. With this implementation, service providers do not need to provide an URL to the SSD logon page; the subscribers are sent automatically to the logon page when they start an Internet session. A captive portal application can authenticate the subscriber and redirect the packet to the originally requested URL, thus honoring a subscriber's home page. A captive portal application can authenticate the subscriber and redirect the packet to a device-specific, locale-specific, or branded page.	New
Device and locale awareness	This feature, used with the captive portal feature, can redirect a subscriber to an appropriate web page based on the subscriber's device (such as PC or wireless) and locale (country or primary language).	New
Localization	This feature provides language localization through the use of resource bundles.	New
Highly scalable	An SSD web server application is highly scalable in the following ways: SSD leverages the load-balancing features of J2EE technology. SSD applications are completely stateless regarding subscriber sessions. SSG signals SSD when state changes occur. Therefore, the SSD applications can be started and stopped without affecting a subscriber. Manual mapping of subscriber subnets to SSGs will be eliminated when the SSG host key feature becomes available.	No

Important Notes

The following sections describe some important considerations related to the Cisco SSD Release 3.0(1).

Version Compatibility

SSD Release 3.0(1) introduces two new features which require support on the SSG:

Captive portal
Host key

To use the captive portal feature in SSD, the Cisco 6400 NRP must be running Cisco IOS Release 12.1(5)DC or later and the SSG captive portal feature must be configured appropriately. To use the host key feature, the Cisco 6400 NRP must be running Cisco IOS Release 12.2(2)B or later and the SSG host key feature must be configured appropriately. Further, the host key feature can be enabled and disabled on both the SSD and SSG products to ensure backwards compatibility.

JIT Error with Java Runtime Environment, Version 1.2.2

On Windows platforms, JRE version 1.2.2 outputs the following messages at SSD application startup:

A nonfatal internal JIT (3.10.107(x)) error 'Relocation error:
NULL relocation target' has occurred in
'org/apache/crimson/parser/Parser2.maybeComment (Z)Z': Interpreting method.

Ignore this message.

Poor Performance with Java Runtime Environment, Version 1.3.0 on Solaris

It has been observed that the performance of the Java Runtime Environment (JRE) Version 1.3.0 on Solaris is less than optimal. Later versions of the JRE may have improved performance. The reference JRE for SSD Release 3.0(1) is JRE Version 1.2.2_08.

Determining the Installed Version and License Number

The licensenum.txt file in the root of the installation directory contains the version number and license key.

JMX Management Console

The Sun example JMX server includes an HTML adaptor server that produces a web-based management console. This console displays the currently set values for all attributes in the XML configuration files and is useful for development environments.

However, the JMX HTML adaptor server is not production quality. For example, configuration changes that you make using this console are not persistent. You should remove this server from your configuration files before transitioning the SSD application to public use.

To remove the JMX HTML adaptor server, comment out the following element in the nwsp/config/nwsp.xml file:

<Configure init="99"
class="com.sun.jdmk.comm.HtmlAdaptorServer"
name="com.cisco.aggbu:name=HtmlAdaptorServer">
<Set name="Port" type="int"><SystemProperty
name="management.portno"/></Set>
<Call name="start"/>
</Configure>

Cisco SSD Security

Cisco SSD Release 3.0(1) uses numerous security mechanisms:

SSD uses Java technology based on the J2EE specification. SSD applications inherit the security features both of the Java language platform and the security framework in J2EE.
SSD web server applications are deployed on a web server that enforces HTTP security.
Because the Cisco SSD plays a role in user authentication, it enforces constraints on user access.

Server Hardware

If you are using a Sun Ultra or Enterprise, you must use Solaris Version 2.6 or later. For live deployments, we recommend using an Enterprise class server with hot-swappable components and load-balancing across multiple servers. The Cisco Content Services Switch 11000 (CSS 11000) is preferred for load balancing.

For Windows NT installations, we highly recommend that you use hardware that meets the Windows NT Hardware Compatibility List (HCL) guidelines set by Microsoft with at least 64 MB of RAM (128 MB of RAM is recommended).

Upgrading from SSD Release 2.5(1)

This section describes how to upgrade your software from SSD Release 2.5(1) to SSD Release 3.0(1). The section discusses the following topics:

SSD Web Application Development Differences

In Release 2.5(1), the look and feel of an SSD application was controlled by HTML templates defined for the Cisco solution.

In Release 3.0(1), predefined templates are not used. Rather, you use standard JSP technology to customize the look and feel of your SSD application.

To migrate from an SSD Release 2.5(1) application to an SSD Release 3.0(1) application, you must recode your application's Web pages to integrate them into the JSP technology. In most cases, the design of your application presentation and the individual web page designs can be reused. SSD Release 3.0(1) allows but does not require frames. Graphic images and branding efforts can all be reused.

See the Cisco Service Selection Dashboard Web Developer Guide for information on creating an SSD Release 3.0(1) web server application.

Configuration File Differences

Table 2 shows configuration file differences between SSD Release 2.5(1) and SSD Release 3.0(1).

Table 2: Comparing Configuration Files in SSD Releases 2.5(1) and 3.0(1)

Configuration Files in SSD Release 2.5(1)	Configuration Files in SSD Release 3.0(1)
dashboard.conf servers.conf dashboardRealm.properties dashboard.xml	MBean configuration files, as explained in the Cisco Service Selection Dashboard Installation and Configuration Guide

Configuration Parameter Differences

Table 3 is a reference for administrators who are familiar with SSD Release 2.5(1). The table explains how SSD Release 3.0(1) handles parameters and features that you might have implemented in SSD Release 2.5(1).

Table 3: Comparing Configuration Parameters and Features

Feature	SSD Release	Sample Contents (from dashboard.conf and nwsp.xml, unless otherwise noted)
Single Sign-on	2.5(1)	`# To use SSO, set REAUTHENTICATE=off, otherwise on. REAUTHENTICATE=on`
Single Sign-on	3.0(1)	`<Set name="singleSignOn" type="boolean">true</Set>`
Stress test	2.5(1)	`# STRESS_TEST=true allows the client IP address to be added to the URL. This allows a stress test client to be used, # to simulate connections from multiple IP addresses. STRESS_TEST=false`
Stress test	3.0(1)	The stress test feature is not implemented in SSD Release 3.0(1).
Demo mode	2.5(1)	`# DEMO_SSD=true will simulate an SSG and AAA server using data from the AAAFILE, otherwise false. DEMO_SSD=true # The resource or file containing user and service data for when FAKESSG=true. AAAFILE=com/cisco/aggregation/radius/util/session/aaa.txt`
Demo mode	3.0(1)	The following element in the SSD MBean sets SSD to run in Demo mode. `<Set name="mode">Demo</Set>` The following element specifies the filename containing demonstration data. `<Configure name="com.cisco.aggbu:name=SSDDemoMode"> <Set name="demoDataFile" type="java.lang.String"><SystemProperty name="application.home"/>/config/demo.txt</Set> </Configure>`
Service list format	2.5(1)	`# SERVICE_LIST=text displays service names as text; =icon displays them as images. SERVICE_LIST=text`
Service list format	3.0(1)	`<Put name="useIcons" type="boolean">TRUE</Put>`
Default template	2.5(1)	`# DEFAULT_TEMPLATE sets directory to find HTML images if no template directory matches a service name. # This is relative to the docRoot of the web server as defined in web.xml DEFAULT_TEMPLATE=/templates/default`
Default template	3.0(1)	Not applicable. Templates are not used in this release.
Templates location	2.5(1)	`# TEMPLATE_ROOT_DIR is the root directory from which all template directories are enumerated. TEMPLATE_ROOT_DIR=/templates`
Templates location	3.0(1)	Not applicable. Templates are not used in this release.
Cache managing	2.5(1)	`# IDLE_TIMEOUT_SECONDS is the period for which a user object remains in the SSD cache. IDLE_TIMEOUT_SECONDS=86400 # IDLE_TIMEOUT_SCAVENGE_INTERVAL_SECONDS is the time between checks for timed out user objects. IDLE_TIMEOUT_SCAVENGE_INTERVAL_SECONDS=3600`
	3.0(1)	`Not applicable.`
	2.5(1)	`# SERVICE_IDLE_TIMEOUT_SECONDS is the time before a service cache object is removed from memory. SERVICE_IDLE_TIMEOUT_SECONDS=86400 # GROUP_IDLE_TIMEOUT_SECONDS is the time before a group cache object is removed from memory. GROUP_IDLE_TIMEOUT_SECONDS=86400`
	3.0(1)	`<Set name="profileCachePeriod" type="int">600</Set>`
Auto logon	2.5(1)	`# Specifies if SSD should perform service auto logons. Normally performed by SSG. Default is off. SSD_AUTO_LOGON=off`
Auto logon	3.0(1)	`<Set name="autoConnect" type="boolean">false</Set>`
Sessions	2.5(1)	`# Initial number of session objects created in the SSD and added to a pool INITSESSIONPOOL=20`
Sessions	3.0(1)	Not applicable in the new SSG interface implementation.
Server URL	2.5(1)	`# Server URL. This specifies where clients go to in search of server pages. # If not specified or blank, the server name is used. SERVER_URL=`
Server URL	3.0(1)	`Not applicable in this release.`
Templates	2.5(1)	`# Period in seconds between checking for modified HTML files in cache for replacement. TEMPLATE_CLEANUP_PERIOD=3600`
Templates	3.0(1)	Not applicable. Templates are not used in this release.
SSL redirects	2.5(1)	`# Redirect to SSL port. If set, all HTTP requests are redirected to # HTTPS at this port REDIRECT_TO_SSL_PORT= # Redirect to SSL uri. If redirecting to SSL, use this URL. If not # set use original request URI. REDIRECT_TO_SSL_URI= # Redirect to initial page. This URL is used by the Index servlet at /index.html to # redirect to the initial page REDIRECT_TO_INITIAL_URI=/templates/default/user.html`
SSL redirects	3.0(1)	Not applicable. Frames are not required in this release.
Authenticate level	2.5(1)	`# Authenticaton level 0=trust IP, 1=Trust SSL, 2=Trust Session 3=Trust SSL/Session 4=No trust AUTHENTICATION_LEVEL=0`
Authenticate level	3.0(1)	This feature is implemented using a combination of HTTP sessions, cookies, and the host key feature.
Message server	2.5(1)	# This section defines the messaging server to which the SSG can send system messages. [MESSAGING_SERVICE] # IP address of the message server, typically the same as the SSD address. IPADDRESS=127.0.0.1 # Note that this port cannot be the same as a HTTPListener port as defined in dashboard.xml. PORT=9002 # Maximum time in minutes for which a message is kept in the message server. MAX_MESSAGE_TIME_TO_LIVE=120 # Maximum number of unread messages per user logged into the SSD. MAX_OUTSTANDING_MESSAGES_PER_USER=10 # Maximum number of messages that the message server will keep absolutely. MAX_OUTSTANDING_MESSAGES=10000
Message server	3.0(1)	Not applicable. The SSG asynchronous messaging service is superseded by the host key feature and its ability to signal state changes.
AAA configuration, primary and secondary servers	2.5(1)	This section defines the primary RADIUS server that the SSD queries for service profiles. [AAA_PRIMARY] PORT=1234 SHAREDSECRET=cisco # Note that this must match the password defined for the service profile in the RADIUS dictionary. SERVICE_GROUP_PASSWORD=cisco TIMEOUTINSECONDS=10 IPADDRESS=1.2.3.4 PACKETRETRY=5 # This section defines the RADIUS server to try if the primary times out on PACKETRETRY number of # requests and is a copy of the primary. [AAA_SECONDARY] PORT=1234 SHAREDSECRET=cisco # Note that this must match the password defined for the service profile in the RADIUS dictionary. SERVICE_GROUP_PASSWORD=cisco TIMEOUTINSECONDS=10 IPADDRESS=1.2.3.4 PACKETRETRY=5
AAA configuration, primary and secondary servers	3.0(1)	`<Configure name="com.cisco.aggbu:name=AAA,connection=ServiceProfile"> <Set name="timeOut" type="int">4</Set> <Set name="retryCount" type="int">3</Set> <Set name="primaryIP">127.0.0.1</Set> <Set name="primaryPort" type="int">1645</Set> <Set name="secret">cisco</Set> <Set name="secondaryIP">127.0.0.2</Set> <Set name="secondaryPort" type="int">1645</Set> <Set name="servicePassword">servicecisco</Set> <Call name="open"/> </Configure>`
SSG mappings	2.5(1)	servers.conf file
SSG mappings	3.0(1)	`<Configure name="com.cisco.aggbu:name=SSG"> <Call name="setGlobalAttribute"><Arg>PORT</Arg><Arg>1645</Arg></Call> <Call name="setGlobalAttribute"><Arg>SECRET</Arg><Arg>cisco</Arg></Call> <Call name="setGlobalAttribute"><Arg>MASK</Arg><Arg>255.255.255.0</Arg></Call> <Call name="setGlobalAttribute"><Arg>BUNDLE_LENGTH</Arg><Arg>0</Arg></Call> <Call name="setSubnetAttribute"><Arg>10.1.1.0</Arg><Arg>255.255.255.0</Arg><Arg>IP </Arg><Arg>5.1.1.2</Arg></Call> </Configure>`
Localization	2.5(1)	localizationDB.conf file
Localization	3.0(1)	.properties files For example, a file named message_en.properties holds English language message text. See the Cisco Service Selection Dashboard Web Developer Guide for more information.

Caveats

Table 4 describes known problems in SSD Release 3.0(1).

Table 4: Caveats in SSD Release 3.0(1)

Caveats	Description
CSCdu33191	The captive portal cannot determine the port number of the original HTTP request that has been redirected by the SSG TCP redirect feature. When the captive portal recreates the original request, it uses the port number the application server is listening on. Workaround: To ensure that the browser is redirected to the correct server and port after authentication, ensure the SSD web server is running on port 80 (which is the default HTTP port).
CSCdu25966	If the captive portal URI is missing a preceding "/", then the redirect URL will be malformed and hence the browser will not be able to find the correct page. Workaround: The URI entered during installation should be /decorate/pages/home.jsp.
CSCdu12277	The status entry for a service in the NWSP application does not show bytes in/out. The byte and packet counts are currently not available from the SSG, but will be supported in a future release of SSG. Workaround: None.
CSCdu12329	The installation application does not check for incorrect entries, based on either content or format. Workaround: Make sure to enter the correct details during the installation.
CSCdu33767	SSD Release 3.0(1) does not include a stop script. Workaround: To stop the application server on Windows NT, go to the Task Manager, Select the process, and click End Task. On Solaris, enter ps -eaf \| grep java and kill -9 the appropriate process.
CSCuk23419	Occasionally, the logon page is displayed without styles. This results in the background color and the fonts not being set correctly. Workaround: Reload the page.
CSCdu47568	The average memory consumption per subscriber in an SSD application is 10 kilobytes. The Java Virtual Machine (JVM) has an upper memory limit defined by the value of the -Xmx argument to the JVM. For example, if your configuration includes `java -Xmx 40m`, then the maximum heap size is 40 MB. This supports approximately 6000 concurrent logged in subscribers. So, in this example, if the number of concurrent logged in subscribers exceeds approximately 6000, then the JVM process will produce an out-of-memory exception and a segmentation fault may occur. Workaround: Make sure the JVM memory argument is large enough to handle the expected load.
CSCdu06756	If you make changes to the JSPs (for example, to change the look-and-feel elements), then there must be a JDK available so that the Java web server can recompile those pages. After the pages are recompiled, they can be deployed in production without a JDK. The start script (start.sh or start.cmd) checks for the existence of a JDK, and if it does not find one, it generates a warning message. Workaround: If you changed the JSPs, they require recompiling. Load a JDK. Otherwise, ignore this message.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.

Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.

Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.

To access Cisco.com, go to the following website:

http://www.cisco.com

Technical Assistance Center

The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.

Contacting TAC by Using the Cisco TAC Website

If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:

http://www.cisco.com/tac

P3 and P4 level problems are defined as follows:

P3—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.

In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.

To register for Cisco.com, go to the following website:

http://www.cisco.com/register/

If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:

http://www.cisco.com/tac/caseopen

Contacting TAC by Telephone

If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

P1 and P2 level problems are defined as follows:

P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.
P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.

AccessPath, AtmDirector, Browse with Me, CCDE, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0105R)

Table of Contents

Release Notes for Cisco Service Selection Dashboard, Release 3.0(1)

Release Notes for Cisco Service Selection Dashboard, Release 3.0(1)