Table Of Contents
Connected Imaging—Medical Image Architecture 2.0 Application Design Guide
Deployment Option 1 (Version 1.0)
Deployment Options 2 and 3 (Version 2.0)
Deployment Model A: Small Hospital/Standalone Clinic using CSS
Deployment Model B: Medium Size Hospital/Large Clinic using 6500 and ACE module
Deployment Model C: Large Hospital/Multiple Clinic using 6500, ACE module and WAE
Interconnection and Interoperability
Solution Features and Components
Features, Services, and Application Design Considerations
Scalability and Capacity Planning
Anticipated Volumes of DICOM traffic
Implementing and Configuring the Solution
Implementation or Testing Approach
Test Topology A: CSS Implementation
Failover of a Switch and/or CSS
Test Topology B: ACE and 6500 Implementation
Test Topology C: ACE and 6500 and WAAS Implementation
Appendix B—DICOM Header Information
Appendix C—DICOM / WAAS Test Results
Aggregation 6500 Configuration
Cisco Wide Area Application Services Engine Console
Connected Imaging—Medical Image Architecture 2.0 Application Design Guide
February 4, 2009
Introduction
This document is intended to provide information on the implementation and configuration for the Connected Imaging—Medical Image Infrastructure solution for healthcare.
Intended Audience
The target audience for this solution is new and existing healthcare providers.
It is assumed that administrators of Connected Imaging—Medical Image Infrastructure have experience with installation and acceptance of the products covered by this network design. In addition, it is assumed that the administrator understands the procedures required to upgrade and troubleshoot networks at a basic level.
Typical users of this guide include the follow groups:
•
Customers with technical staff experienced enough to perform the installation and configuration of the elements required for this solution
•
•
•
Solution Overview
Executive Summary
The Connected Imaging—Medical Image Infrastructure solution is based on the Cisco and partner technologies that provide a highly available and scalable infrastructure to support the various Picture Archive Communication System (PACS) used today. The Connected Imaging—Medical Image Infrastructure solution addresses scalability, application, and storage performance challenges with advanced networking, image routing, and storage technologies. This portion of the end-to-end image management solution improves image availability, and provides outstanding storage performance at low cost. Through the Cisco Medical-Grade Network (MGN), the Cisco Connected Imaging solution provides scalable imaging services and increases PACS performance, to manage today's high-bandwidth images. It supports centralized image storage for quick image access and retrieval across a distributed storage environment.
The applications of these products are produced through direct consultation with radiology or imaging services providers to address many key concerns as the growth and complexity of imaging services increases exponentially. By addressing these issues, CI can provide direct value to clinical leadership and have the clinical leadership include advanced infrastructure technologies in imaging services budgets.
Solution Description
PACS is at the core of medical image management. PACS is comprised of a cluster of application, database and web servers. The PACS architecture will dictate the quantity and function of the servers, but they will all require high availability, typically greater than 99.99%. When more than a single PACS server and/or multiple modalities are present, a situation is created where it is often difficult to provide high availability and fault tolerance.
By coupling Cisco core technologies with DICOM Services Grid™ software from Acuo Technologies® we can effectively enhance image management performance. The AcuoMed™ Image Manager is a secure, open-system software solution for transporting, storing, tracking and retrieving digital images across an entire storage system network. It is a DICOM 3.0 Level 2 compliant solution which uses Microsoft Windows® 2000, 2003 Server or Microsoft Windows® XP Professional on a recommended AMD platform. AcuoMed™ works in conjunction with AcuoStore™ , a digital asset manager. AcuoStore™ serves as a digital vault, communicating the instructions of AcuoMed™ with the diverse DICOM storage devices in which digital DICOM image and patient information is contained.
Each Acuo system works in concert with other DICOM devices to create local intelligent workflow using its dynamic router, enabling a single view of the entire DICOM network through its peer-aware collaboration feature. Acuo's Next Generation technology offers local caching of image data, seamless integration of legacy data and interoperability with the available information systems for real-time image reconciliation and RIS/PACS synchronization.
There are 3 deployment options of the solution available. All 3 options provide optimized traffic Routing using DICOM Services Grid™ software from Acuo Technologies® as well as dynamic load balancing and stateful failover providing high availability and increased performance. With the addition of the Cisco ACE module and WAAS services, the solution can easily support a large Data Center or multi-site implementation.
Deployment Option 1 (Version 1.0)
In Version 1, sitting in front of these DICOM routers (DICOM Services Grid™) is the Cisco Content Services Switch which dynamically load balances the traffic between the DICOM routers in the grid. This is accomplished through the use of the Acuo Load Optimizer, which monitors the work queues on each DICOM router and sends updates to the Cisco Content Services Switch when a particular router is loaded beyond a pre-defined threshold. When this happens, the Cisco Content Services Switch lowers the weight of that particular router and sends the data to one of the others in the configuration.
Version 1 is intended to enhance operations in a clinic or remote radiology site or small to mid-size hospitals.
Deployment Options 2 and 3 (Version 2.0)
In Version 2, the Cisco Application Control Engine (ACE) module/appliance is added to the overall solution to create a more robust service offering. In the solution testbed, the ACE module was inserted into the Cisco 6500 Catalyst switch to provide the load balancing functionality for data center type deployments. The Cisco ACE module dynamically load balances the traffic between the DICOM routers in the grid. This is accomplished through the use of the Acuo Load Optimizer, which monitors the work queues on each DICOM router and sends updates to the Cisco Content Services Switch when a particular router is loaded beyond a pre-defined threshold. When this happens, the Cisco ACE module lowers the weight of that particular router and sends the data to one of the others in the configuration.
For more information on the ACE module, refer to the following URL:
http://www/en/US/products/ps6906/tsd_products_support_model_home.html
In addition, the Cisco Wide-area Application Engine (WAE) is also added to the Version 2 configuration. The WAE is part of Cisco Wide Area Application Services (WAAS), which includes best of breed caching, compression and protocol optimizations technology that overcome bandwidth and latency limitations associated with TCP/IP and client-server protocols.
Cisco WAAS is an application acceleration and WAN optimization solution for the branch office, remote clinic or remote data center that improves the performance of any TCP-based application operating in a WAN environment. With Cisco WAAS, IT organizations can consolidate PACS deep archive servers and storage into centrally managed data centers, and deploy PACs storage systems directly from a data center, while offering LAN-like application performance for the remote users. For more information about the Cisco WAAS, refer to the following URL:
http://www/en/US/products/ps5680/Products_Sub_Category_Home.html
Version 2 is intended for enterprise or multi-site customers looking to centralize their imaging operations and enhance the scalability and performance of their existing implementation. Three different deployment models are included, each intended to enhance operations in a clinic or remote radiology site, or small to mid-size hospitals.
The dynamic load-balancing integration between the Cisco Content Services Switch or the Cisco ACE and the Acuo DICOM routers makes this solution unique in the healthcare market.
Target Market
This solution has three deployment options. While the Medical Image Infrastructure Deployment Option 1 (Version 1.0) focused on small to medium size hospitals and radiology clinics, deployment Options 2 and 3 (Version 2.0) is targeted at large clinics, enterprise, and multi-site hospitals.
For this solution, the size of the hospital is based upon the number of modalities, size of the images scanned, number of images /exam and the exams per year. The following numbers are averages based upon feedback from organizations that reflect the sizing for each. The following shows the approximate number of modalities and images per year for each size hospital or clinic. For details on how these numbers were conceived, please see Sec. 5.2 for more information.
Small Hospital or Remote Clinic:
•
•
Mid-Size Hospital or Large Clinic
•
•
Large Hospital
•
•
The interested party at a customer site for this solution is most likely the CIO or CTO, as well as the IT management. Because it is primarily targeted at enhancing the backend storage, network, and imaging workflow solutions, as well as the availability and management of those products, they are most likely to understand the benefits of the solution.
It is not likely that radiologists or radiology departments will be the primary target, because the particulars of this solution deal with the availability of the storage device, as well as imaging workflow and network issues. However, because there are other functions that the Acuo DICOM Services Grid can provide (for example, image cache), and the solution does enhance the performance of the availability of the image in the overall workflow, they should not be ignored.
Solution Benefits
The Connected Imaging—Medical Image Infrastructure solution improves the performance and scalability of the multi-vendor PACS systems used by healthcare providers. Modern imaging requires large amounts of resources because of the size of the images, sometimes in the gigabit range. To complicate the issue, each vendor has their own proprietary protocol.
In Deployment Option 1, the Cisco Content Services Switch improves the overall scalability by intelligently load balancing the PACS/DICOM traffic to the Acuo DICOM Services Grid™.
Deployment Options 2 and 3 add the benefit of using the ACE Module and 6500 to improve the overall scalability by intelligently load balancing the PACS/DICOM traffic to the Acuo DICOM Services Grid.
The addition of the Cisco WAAS/WAE improves the overall performance by optimizing the Wide Area Network (WAN).
Testing was done by a combination of teams in Germany to study the effects of WAAS/WAE on DICOM traffic. Here is a synopsis of those test results:
•
•
•
•
•
–
–
–
–
Faster studies means less impact on existing infrastructures and existing applications
The details of the test and the results can be found in the appendices of this document.
The Acuo DICOM Services Grid is an enabling open-systems software solution that facilitates a DICOM infrastructure built on a services-oriented architecture that can aggregate/federate DICOM objects and query results, virtualize and replicate storage assets; and is built on a collaborative and extensible grid computing model.
The Cisco Connected Imaging—Medical Image Infrastructure solution provides the ability to connect proprietary PACS systems such that they operate together seamlessly. It also allows images to be routed based on metadata contained in the DICOM header. The Acuo DICOM Services Grid™ directs the image traffic based on a set of business rules, and provides image storage services by either placing into storage or forwarding to the diagnostic workstation.
Solution Features
The Connected Imaging—Medical Image Infrastructure solution addresses multiple challenges in healthcare today. It enables healthcare organizations to reduce patient scan times, effects a high availability application environment, and improves patient satisfactions. The solution solves these challenges by configuring the components in the solution to allow for the following:
•
•
•
•
•
•
Scope of the Solution
The scope of this solution is limited to workflows for modality image acquisition, to PACs storage.
This document is intended to provide implementation and configuration information for the components required to provide intelligent load balancing of DICOM images using Cisco Content Services Switches or Cisco ACE Modules and Acuo DICOM routers. Information has been provided to allow for capacity planning as well as extensibility and scaling. As the solution is easily extensible, care should be taken in the design to allow for baseline projections and then a gradual implementation to allow for adequate bandwidth and processing to support the imaging environment. For more information, refer to the Acuo Technologies® re: sizing Acuo DICOM Services Grid™ implementations at the following URL:
The radiology workflow is a multi-step process with large file transfers and multiple communications and this solution is focused on the steps highlighted in the Figure 1.
Figure 1 Radiology Workflow
Through the implementation of a DICOM Services layer, we can more effectively route DICOM traffic making the workflow more efficient. It allows for intelligent routing of the images based on information in the DICOM header and business rules that are configured in the Acuo DICOM Services Grid™ software. Additional capabilities of the DICOM Services layer, although not included in this phase of the solution, include cacheing, better performance on image retrievals, and allow for expanded collaboration within the imaging environment.
This workflow represents a typical, in-house radiologist workflow. In the case of a multi-entity customer, you could potentially be moving large amounts of data across the WAN, depending on where your central PACS system, modalities, and diagnostic workstations are located.
High Level Architecture
The Cisco Service-Oriented Network Architecture (SONA) provides a foundation for the Connected Imaging—Medical Image Infrastructure solution. This architecture identifies an end-to-end system offering to provide adaptive image routing to medical facilities that require better care for their patients. The Connected Imaging—Medical Image Infrastructure solution is an integrated solution of Cisco and partner products to provide a highly available foundation for image routing in the healthcare environment.
The SONA architecture (see Figure 2) shows how these components come together in the solution. The modalities and diagnostic image viewers can exist practically anywhere in the network. The core of the solution along with the storage subsystem or PACS system would typically exist in the data center or imaging center.
Figure 2 DICOM Services within the Cisco SONA model
The following three layers provide the architectural foundations of the Connected Imaging—Medical Image Infrastructure solution that deliver an innovative solution offering to solve the challenges image routing in healthcare today:
•
•
•
For more information on DICOM Services or to reference the DICOM 3.0 Specification, see the following URL:
http://www.rsna.org/Technology/DICOM
Process Flow
Figure 3 Process Flow
Solution Architecture
Network Architecture
The Cisco Medical Image Infrastructure version 2 solution plays a critical part in providing optimal traffic management for the transport of images from modalities to PACs storage components. The architecture for this solution(Figure 4) is based on Cisco's Medical-Grade Network (MGN) architecture, thus providing high availability as well as scalability. It is beyond the scope of this document to discuss the Cisco MGN architecture in detail. For more information about the MGN architecture, refer to the following URL:
http://www.cisco.com/web/strategy/docs/healthcare/MGN_Architecture.pdf
Figure 4 Overall Medical Image Infrastructure Architecture
Figure 4 illustrates the high level architecture of the Connected Imaging—Medical Image Infrastructure solution. The following key functional blocks are represented:
•
Small hospitals (performing on average of 100,000 exams per year) may have their own dedicated PACs and storage systems to serve the technologies and radiologists. Local modality endpoints ingest images from CTI, Mammo, and Catscan into the PACs systems. Usually the infrastructure consists of basic IP connectivity and switching capabilities. This is represented by the Medical Grade Network (MGN). The Cisco Content Switch is used to perform load balancing to the ACUO servers that front-end the storage PACs devices.
•
Remote clinics may only house viewers to image examination, without any modalities. In this case, the clinic use a WAN link back to the centralized PACs systems. A wide area acceleration engine is used to perform DICOM traffic acceleration over the WAN.
•
A mid-size hospital is generally large enough to own its own PACs systems and MGN infrastructure. In this case, both modality and viewing services would be located at the campus. An MGN architecture could be deployed at this size hospital along with the ACUO DICOM Grid servers. If the campus supports a local data center with a 6500, then an ACE module and could be used to handle the load balancing functions to the ACUO DICOM Grid.
•
A large size hospital will own the PACs system, as well as serve both modalities and viewers within the hospital infrastructure. For very large operations, the hospital may support a centralized data center that supports large storage systems for images. In this type of deployment model, remote clinics send or retrieve images over the wide area network. In addition mid or small size clinics/hospitals may also use the centralized PACs storage.
•
Diagnostic equipment used to capture images such as X-rays, CTs, etc.
•
Image views enables radiologists and physicians to view high-resolution images stations. Images are accessed from the manufacturer's PACS systems.
•
Network that connects remote locations to the the data center.
Deployment Models
Deployment Model A: Small Hospital/Standalone Clinic using CSS
Deployment model A (see Figure 5) is used for small hospital and/or standalone clinics where modality/viewer endpoints are distributed locally at a single location. Here, the content services switch (CSS) is used for load balancing functionality and distribution to the ACUO Services Grid. The PACs system is located behind the ACUO grid. Since this is a single context type of deployment, the CSS is recommended for environments that do not have aggregation or core size switches (for example, 6500). This is the main deployment model supported included from Version 1 of the solution.
Figure 5 Deployment Model A
Deployment Model B: Medium Size Hospital/Large Clinic using 6500 and ACE module
Deployment model B (see Figure 6) is used for a medium size hospital and/or large clinics, where modality/viewer endpoints may be distributed locally at a single location, but may also have a centralized data center on campus with. Here, the 6500 is used with the Application Control Engine (ACE) module to perform the load balancing functions and distribution to the ACUO Services Grid. The PACs system is located behind the ACUO grid.
The ACE module supports up to 256 separate contexts, which allows multiple administrators within a hospital to manage the contexts that they individual own. For example, if the data center has an ACE module to perform SSL acceleration, you can add a new context for DICOM load balancing to the PACs application without disrupting the existing services.
Figure 6 Deployment Model B
Deployment Model C: Large Hospital/Multiple Clinic using 6500, ACE module and WAE
Deployment model C (see Figure 7) is used for a large size hospitals and/or multi-site clinics, where modality/viewer endpoints may be distributed locally at remote different locations, and may meshed back to a centralized data center. Here, the 6500 is used with the ACE module to perform the load balancing functions and distribution to the ACUO Services Grid. The PACs system is located behind the ACUO grid.
At the remote locations, wide area acceleration engines are used in conjunction with the edge routers, typically the Cisco ISR 1800/2800/3800s to perform the necessary DICOM traffic compression and optimization across the WAN. The WAE is also deployed at the central data center site behind the 6500 aggregation device.
Figure 7 Deployment Model C
Interconnection and Interoperability
Once an image is captured at a modality, it is stored locally in its cache until it can off-load it to the PACS system. Typically, the modality is configured to point directly at the PACS system. If the PACS system is unavailable, the images must remain in local cache until they can be off-loaded.
In the Connected Imaging—Medical Image Infrastructure solution, the modality is pointed to the virtual IP address hosted by the Cisco CSS or Cisco ACE module (depending on the deployment model implemented) via the Cisco MGN. When it attempts to transfer the image, the content switch looks at its weight table and determines the least busy Acuo DICOM router in place and opens a conversation with that server. At this point, the image is off-loaded to the Acuo DICOM router, which then forwards it to the appropriate PACS system based on the business rules in the system. If the PACS server is not available, the image will remain on the Acuo DICOM router until it can be transferred, but once the image is on the Acuo DICOM router, a commit is sent back to the modality so that the image can be purged from the local cache. In this case, the Acuo DICOM router is acting as a proxy for the PACS systems so that the images do not backup on the modality.
In the case of a multi-campus implementation, the image capture and transfer to a local Acuo DICOM router or PACS system happens as described above. If the image is to be read locally, it will be kept local for a period of time. If not, the image would be transferred back to the central site. In this case, the image would go from the local Acuo DICOM router or PACS system, through the WAE where it would be compressed if the image is not already compressed, and transferred across the WAN, where it is received by the WAE and transferred to the Acuo DICOM router or PACS system on the other side, based on the business rules in the system.
If there is a request from a local diagnostic workstation, the request would be made to the Acuo DICOM router, which would transfer the image to the workstation, if it is still cached locally; or it would transfer that image to the workstation for reading.
If the request comes from a diagnostic workstation remote to the PACS system or remote to the location of the image, the request would go through the Acuo DICOM router, which retrieves the image from its current location and transfer that image to the diagnostic workstation for reading.
Solution Features and Components
The Connected Imaging—Medical Image Infrastructure solution contains the following equipment, software, and architectural designs:
•
http://www.cisco.com/web/strategy/docs/healthcare/MGN_Architecture.pdf
•
http://www.cisco.com/univercd/cc/td/doc/solution/dcidg21.pdf
•
The Cisco Catalyst Ethernet switches provide the Layer 3 to the MGN and the Layer 2 connectivity to the CSS and Acuo servers supporting interface speeds ranging from 10 to 1000 Mbps. Catalyst Ethernet switches also provide segmentation of traffic via the use of VLANs and supported EtherChannel and HRSP for redundancy purposes.
The following Cisco Catalyst Ethernet switches are used for the Connected Imaging—Medical Image Infrastructure Architecture solution:
–
–
–
–
–
–
–
•
•
Hardware Components
Table 1 provides the hardware components of this solution.
Software Components
Table 2 lists the software used in this solution.
Features and Functionality
Table 3 lists the features and functionality of the solution.
Table 3 Features and Functionality
WS-C4948-10GE1
Layer 2 and Layer 3
The WS-C4948-10GE acts as an L3 router providing support for routing protocols (OSPF for this solution) and also acts as an L2 switch providing support for VLAN traffic. Note that the WS-C4948-10GE also provides redundancy for the L2 and L3 with the use of an EtherChannel between the two WS-C4948-10GEs and HSRP for the routed interface.
WS-C4948-10GE1
Layer 2
The WS-C4948-10GE acts as an access layer switch that includes redundancy between the two WS-C4948-10GEs via an EtherChannel.
6500/ACE
Layer 4 load balancer
The ACE and 6500 provides L4 load balancing based on load balancer updates from ACUO that adjust queue weights
AcuoMed Image Manager
DICOM 3.0 Level 2 compliant Image Manager
AcuoMed Manager provides transport, storing, tracking, and retrieving of digital images.
AcuoStore Asset Manager
Digital asset manager
AcuoStore communicates the instructions of AcuoMed with the diverse DICOM storage devices in which digital content is contained.
Acuo Load Optimizer
Monitor service for dynamic load optimization of Content Services Switch
During normal operations, the weights are set equally, usually at 5. From there, the service monitors the queue depth of the servers. As a server becomes congested, the service changes its weight on the CSS to lower than 5. The value is determined by the amount of depth in the queue that the server is handling. At the same time, the service finds the least congested server and changes the weight value from 5 to 10, depending on the load.
1 Note that other Cisco switches support the listed features and functions similar to the WS-C4948-10GE and may be used, but testing and validation of the solution was performed with the WS-C4948-10GE.
Features, Services, and Application Design Considerations
•
•
•
•
•
Designing the Solution
Scalability and Capacity Planning
The design includes a pair of Cisco Content Services Switches (CS11503) or Cisco ACE modules and multiple Acuo DICOM Routers for redundancy. The throughput of the solution is based on the throughput of the Cisco CSS or Cisco ACE module and the ability for the Acuo DICOM routers to handle the load.
You do not need to have separate pairs of CSS or ACE modules for this deployment, you can run on existing hardware as long as there is bandwidth and processor available. The benefit of ACE over CSS is not only throughput, but you can create multiple contexts within the ACE environment to effectively virtualize your DICOM traffic. This is not possible in CSS. The benefit of the virtualization is that you can process without affecting other traffic outside of the virtual environment (context) created.
Cisco CSS
Total throughput of the CSS is based on the configuration deployed. Use the following as a reference to determine the proper configuration for your deployment.
For more information about the Cisco CSS options is available, refer to the following: http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_data_sheet0900aecd800f851e.htm
Cisco ACE Module
Total throughput of the Cisco ACE is based on the configuration and license deployed. Use the information in Table 4 to determine the ACE configuration necessary.
Acuo DICOM Router
Total throughput of the Acuo DICOM router is based on the hardware platform on which it was deployed, and is affected by processor type and size, amount of memory, etc. Additional information on sizing the Acuo DICOM router is available from Acuo Technologies.
If any of these devices are unable to handle the volume of images being produced by the modalities, the solution allows for the addition of one or more devices to handle the increased load.
Anticipated Volumes of DICOM traffic
The Table 5, Table 6, and Table 7 provide sample network traffic volume that you can see in a given hospital or clinic. the tables also provide sample image sizes that are used in various size hospitals. You can use these tables as a reference to determine what type of traffic patterns you will see and need to plan for given a particular size clinic, or you can use the tools available from Acuo Technologies to perform a more complete capacity plan, including data storage necessary for the Acuo products.
Performance Considerations
Performance testing is outside of the scope of this solution because of the complexities associated with different types of modalities, PACS systems and other traffic on the network. If you use the tables provided as a guideline for amount of traffic, you should be able to provide a solution that performs acceptably; however, you mileage may vary.
The complexities are due in large part to the specific implementation of the different systems. For instance, some PACS systems will compress their images before they send them to a diagnostic workstation, and the workstation will de-compress the image. Some modalities will do the same as they send images to the PACS systems.
Additionally, it will depend on the type of images you are sending as to what effect the WAAS/WAE will have on your network. If you are sending an ultrasound, for example, there is a lot of black space surrounding the image that will be compressed out. However, an X-ray, even though it is gray-scale, may not compress as well. You can also expect to see improvement when moving images between Acuo DICOM routers, as they have a proprietary compression algorithm that they use when moving images between systems.
In general, you need to understand the systems being connected, the images they are sending and make sure you test specifically the areas where the bottlenecks occur so that tuning can be done.
Quality of Service
Because of the varied devices that one could run into when deploying a solution such as this, no specific QoS design considerations were tested. The volume of traffic anticipated should be used as a guide to size and understand the impact on existing networks and QoS of other traffic should be marked accordingly.
High Availability
Based on the Cisco MGN, the solution has been designed with high availability in mind. Deployment Option 1 of the solution includes a pair of Cisco Content Services Switches configured in active/passive mode. If the primary fails, the secondary CSS continues to direct traffic to the appropriate Acuo DICOM router. Deployment Options 2 and 3 of the solution includes a pair of ACE modules configured in active/active mode. If the primary fails, the secondary continues to direct traffic to the appropriate Acuo DICOM router.
The high availability piece of the solution also include the Acuo load optimizer running on one of the Acuo DICOM routers in the grid. This service monitors the work queues on each of the Acuo DICOM routers and adjusts the weight of each router accordingly in the Cisco Content Services Switch or Cisco ACE module. If one of the Acuo DICOM routers becomes unavailable, the load optimizer removes that router from the rotation by lowering the weight of the device, allowing the others to consume the load.
Security
While security is not specifically covered in this phase of the solution, there are specific tests to validate that basic access security is in place on each of the devices. Additional security design including path isolation will be included in future phases.
Implementing and Configuring the Solution
Implementation or Testing Approach
The following deployment models were tested as part of the lab validation testing
•
•
•
•
What was Implemented/Tested
The following key features and services were implemented:
•
•
•
•
•
•
•
•
Test Topology A: CSS Implementation
Figure 8 Test Topology A: CSS Implementation
The sequence is as follows:
1.
2.
3.
–
–
The CSSs monitor their respective interfaces to ensure redundancy as an interface/link fails.
4.
–
–
–
–
–
The service monitors the connectivity to the servers via an ICMP keepalive to ensure that traffic is not sent to a downed or inactive server. The CSS uses Weighted Round Robin (WRR) to forward the image traffic to the Acuo DICOM Services Grid. The Acuo Load Optimizer service running on the primary server in the Acuo DICOM Services Grid monitors the queue depth of each of the servers in the grid and updates the service on each of the CSSs based on the load on each server. As the queue depth of a server becomes longer, the Acuo Load Optimizer service connects to the CSS and changes the weight to a lower value for that server. This causes the incoming image traffic to connect and flow to other servers that have higher weight values in the CSS and shorter queues on the DICOM router.
5.
6.
Redundancy in the Acuo Services Grid is dependant on the number of Acuo servers deployed in the solution. A minimum of two servers are required. The SQL server can be placed on the Acuo servers, which is the recommended topology.
The storage device can be a network-attached storage (NAS) device, or an independent storage device can be located in the following places:
•
•
•
Failover of a Switch and/or CSS
Figure 9 shows the sequence of events for a failover of a switch and/or a CSS.
Figure 9 Failover Sequence
The sequence is as follows:
1.
2.
a.
b.
3.
–
–
The CSSs monitor their respective interfaces to ensure redundancy as an interface/link fails.
4.
–
–
–
–
–
The service monitors the connectivity to the servers via an ICMP keepalive to ensure that traffic is not sent to a downed or inactive server. The CSS uses WRR to forward the image traffic to the Acuo DICOM Services Grid. The Acuo Load Optimizer service running on the primary server in the Acuo DICOM Services Grid monitors the queue depth of each of the servers in the grid and updates the service on the CSSs based on the load on each server. As the queue depth of a server becomes longer, the Acuo Load Optimizer service connects to the CSS and changes the weight to a lower value for that server. This causes the incoming image traffic to connect and flow to other servers that have higher weight values in the CSS and shorter queues on the DICOM router.
5.
6.
Test Topology B: ACE and 6500 Implementation
Topology B (see Figure 10) represents the Deployment Model B: Medium Size Hospital/Large Clinic using 6500 and ACE module.
Figure 10 Test Topology B: ACE/6500
The following flows were tested, simulating a local data center deployment type:
1.
testman.exe -r100 -s -t10.1.240.10 -eAcuoMedStore01 -ns1 -ne1 -ni1 -i5000
2.
3.
–
–
–
–
For example:
rserver host AcuoMed1ip address 10.0.40.100inservicerserver host AcuoMed2ip address 10.0.40.104inservicerserver host AcuoStore1ip address 10.0.40.101inservicerserver host AcuoStore2ip address 10.0.40.105inserviceserverfarm host DICOMpredictor leastconnsprobe PINGrserver AcuoMed1inservicerserver AcuoMed2inservicerserver AcuoStore1inservicerserver AcuoStore2inservice4.
5.
6.
In the lab setup, all servers performed both AcuoMed and AcuoStore functions.
Test Topology C: ACE and 6500 and WAAS Implementation
Topology C (see Figure 11) Deployment Model C: Large Hospital/Multiple Clinic using 6500, ACE module and WAE.
Figure 11 Test Topology C: 6500/ACE and WAAS
The following flows were tested, simulating a wide area acceleration deployment over a simulated WAN.
1.
testman.exe -r100 -s -t10.1.240.10 -eAcuoMedStore01 -ns1 -ne1 -ni1 -i5000
2.
3.
4.
5.
6.
7.
–
–
–
–
For example:
rserver host AcuoMed1ip address 10.0.40.100inservicerserver host AcuoMed2ip address 10.0.40.104inservicerserver host AcuoStore1ip address 10.0.40.101inservicerserver host AcuoStore2ip address 10.0.40.105inserviceserverfarm host DICOMpredictor leastconnsprobe PINGrserver AcuoMed1inservicerserver AcuoMed2inservicerserver AcuoStore1inservicerserver AcuoStore2inservice8.
9.
10.
In the lab setup, all servers performed both AcuoMed and AcuoStore functions.
Solution Components Tested
Hardware Tested
Table 8 lists the hardware used in the testing of this solution.
Software Tested
Table 9 lists the software that was tested with this solution.
Configuration Task Lists
The following information was required before configuration of the equipment for the CSS (see Table 10):
•
•
•
–
–
–
–
–
–
•
•
•
Configuration and Menus
See Appendix D—IOS Configurations for the final IOS for the ACE and WAAS configurations.
See Appendix E—ACUO Configuration for the relevant ACUO configuration screen shots.
Caveats or Limitations
Caveats, limitations, and workarounds are as follows:
•
–
–
–
–
•
–
•
If Server A and Server B are weighted as 4, and server C is weighted as 3, the Content Services Switch sends 4 connections to Server A, 4 Connections to Server B, and 3 connections to Server C, then starts the process again. At the end of 11 connections, the connection count look like AAAABBBBCCC.
–
This is masked somewhat by the Acuo Load Optimize because it monitors the load on the server queues and updates the weight tables accordingly.
•
–
Appendix A—DICOM Definition
Digital Imaging and Communications in Medicine (DICOM) is a standard for handling, storing, printing, and transmitting information in medical imaging. It includes a file format definition and a network communications protocol. The communication protocol is an application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged between two entities that are capable of receiving image and patient data in DICOM format. The National Electrical Manufacturers Association (NEMA) holds the copyright to this standard. It was developed by the DICOM Standards Committee whose members are also partly members of NEMA.
For more information refer to the following link:
http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicine#_note-0#_note-0
http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicine#_note-1#_note-1
http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicine#_note-2#_note-2
DICOM enables the integration of scanners, servers, workstations, printers, and network hardware from multiple manufacturers into a picture archiving and communication system. The different devices come with DICOM conformance statements which clearly state the DICOM classes they support. DICOM has been widely adopted by hospitals and is making inroads in smaller applications like dentists' and doctors' offices.
Appendix B—DICOM Header Information
The following information is from http://www.sph.sc.edu/comd/rorden/dicom.html and is provided for informational purposes.
Figure 12 shows a hypothetical DICOM image file. In this example, the first 794 bytes are used for a DICOM format header, which describes the image dimensions and retains other text information about the scan. The size of this header varies depending on how much header information is stored. Here, the header defines an image which has the dimensions 109x91x2 voxels, with a data resolution of 1 byte per voxel (so the total image size will be 19838). The image data follows the header information (the header and the image data are stored in the same file).
Figure 12 Hypothetical DICOM Image File
Figure 13 shows a more detailed list of the DICOM header as displayed by the software. Note that DICOM requires a 128-byte preamble (these 128 bytes are usually all set to zero), followed by the letters 'D', 'I', 'C', 'M'. This is followed by the header information, which is organized in 'groups'. For example, the group 0002hex is the file meta information group The example on the left contains three elements: one defines the group length, one stores the file version and the third stores the transfer syntax.
Figure 13 Detailed DICOM Header
The DICOM elements required depends on the image type, and are listed in part 3 of the DICOM standard. For example, this image modality is 'MR' (see group: element 0008:0060), so it should have elements to describe the MRI echo time. The absence of this information in this image is a violation of the DICOM standard. In practice, most DICOM format viewers (including MRIcro and ezDICOM) do not check for the presence of most of these elements, extracting only the header information which describes the image size.
The NEMA standard preceded DICOM, and the structure is very similar, with many of the same elements. The main difference is that the NEMA format does not have the 128-byte data offset buffer or the lead characters 'DICM'. In addition, NEMA did not explicitly define multi-frame (3D) images, so element 0028,0008 was not present.
Of particular importance is group: element 0002:0010. This defines the DICOM standard. This value reports the structure of the image data, revealing whether the data has been compressed. Note that many DICOM viewers can only handle uncompressed raw data. DICOM images can be compressed both by the common lossy JPEG compression scheme (where some high frequency information is lost) as well as a lossless JPEG scheme that is rarely seen outside of medical imaging (this is the original and rare Huffman lossless JPEG, not the more recent and efficient JPEG-LS algorithm). These codes are described in Part 5 of the DICOM standard (see ftp://medical.nema.org/medical/dicom/2000/draft/). An introduction to this the transfer syntax is provided at www.barre.nom.fr.
Note that as well as reporting the compression technique (if any), the Transfer Syntax UID also reports the byte order for raw data. Different computers store integer values differently, so called 'big endian' and 'little endian' ordering. Consider a 16-bit integer with the value 257, the most significant byte stores the value 01 (=255) and the least significant byte stores the value 02. Some computers would save this value as 01:02, while others will store it as 02:01. Therefore, for data with more than 8-bits per sample, a DICOM viewer may need to swap the byte-order of the data to match the ordering used by your computer.
In addition to the Transfer Syntax UID (Table 11), the image is also specified by the Samples Per Pixel (0028:0002), Photometric Interpretation (0028:0004), the Bits Allocated (0028:0100). For most MRI and CT images, the photometric interpretation is a continuous monochrome (e.g. typically depicted with pixels in grayscale). In DICOM, these monochrome images are given a photometric interpretation of 'MONOCHROME1' (low values=bright, high values=dim) or 'MONOCHROME2' (low values=dark, high values=bright). However, many ultrasound images and medical photographs include color, and these are described by different photometric interpretations (e.g. Palette, RGB, CMYK, YBR, etc). Some color images (e.g. RGB) store three-samples per pixel (one each for red, green and blue), while monochrome and paletted images typically store only one sample per image. Each images store 8-bits (256 levels) or 16-bits per sample (65,535 levels), though some scanners save data in 12-bit or 32-bit resolution. So a RGB image that stores 3 samples per pixel at 8-bits per can potentially describe 16 million colors (256 cubed).
Appendix C—DICOM / WAAS Test Results
WAAS/WAE was tested with DICOM in Germany in cooperation with Dimension Data and DFC Systems. This section describes the outcome of that testing.
Testing was done by sending DICOM images form a modality to a PACS workstation. Data sets from the following modalities were included in the test: MR, CT, CR and Digital Mammography. Both compressed and uncompressed Lossless images were part of the study. Multiple bandwidths were tested, including 64, 128, 256 and 512 Kbps and 1, 2, 6 and 10 Mbps. All tests were performed with 40ms latency.
The results:
•
•
•
•
•
•
All testing was done with empty WAE caches. If the cache was not cleared, the performance improvements were considerably faster, but this does not represent real-world scenarios.
Mammography and CR studies showed the best results probably because of the large percentage of black values in those images.
One additional test showed that the percentage of improvement increased as the latency went up. Improvements may not be as dramatic across a campus as they would across a Wide Area Network.
Appendix D—IOS Configurations
ACE Module ConfigurationACE1-Slot3 login: adminPassword:Cisco Application Control Software (ACSW)TAC support: http://www.cisco.com/tacCopyright (c) 2002-2006, Cisco Systems, Inc. All rights reserved.The copyrights to certain works contained herein are owned byother third parties and are used and distributed under license.Some parts of this software are covered under the GNU PublicLicense. A copy of the license is available athttp://www.gnu.org/licenses/gpl.html.ACE1-Slot3/Admin# show contextNumber of Contexts = 5Name: Admin , Id: 0Description:Resource-class: defaultFT Auto-sync running-cfg configured state: enabledFT Auto-sync running-cfg actual state: enabledFT Auto-sync startup-cfg configured state: enabledFT Auto-sync startup-cfg actual state: enabledName: context1, Id: 1Description: SharePoint TestingResource-class: defaultVlans: Vlan82, Vlan210-211FT Auto-sync running-cfg configured state: enabledFT Auto-sync running-cfg actual state: enabledFT Auto-sync startup-cfg configured state: enabledFT Auto-sync startup-cfg actual state: enabledName: context2, Id: 2Description: Web Logic TestingResource-class: GoldVlans: Vlan220-221FT Auto-sync running-cfg configured state: enabledFT Auto-sync running-cfg actual state: enabledFT Auto-sync startup-cfg configured state: enabledFT Auto-sync startup-cfg actual state: enabledName: context3, Id: 3Description: Web Sphere TestingResource-class: defaultVlans: Vlan230-231FT Auto-sync running-cfg configured state: enabledFT Auto-sync running-cfg actual state: enabledFT Auto-sync startup-cfg configured state: enabledFT Auto-sync startup-cfg actual state: enabledName: dicom , Id: 4Description: Dicom TestingResource-class: defaultVlans: Vlan240-241FT Auto-sync running-cfg configured state: enabledFT Auto-sync running-cfg actual state: enabledFT Auto-sync startup-cfg configured state: enabledFT Auto-sync startup-cfg actual state: enabledACE1-Slot3/Admin# change ?Admindicomcontext1context2context3ACE1-Slot3/Admin# change dicomACE1-Slot3/dicom# sh runGenerating configuration....login timeout 60access-list ANYONE line 10 extended permit ip any anyaccess-list ANYONE line 20 extended permit icmp any anyprobe icmp PINGinterval 2faildetect 2probe tcp PROBE-TCPinterval 2faildetect 2passdetect interval 10passdetect count 2rserver host AcuoMed1ip address 10.0.40.100inservicerserver host AcuoMed2ip address 10.0.40.104inservicerserver host AcuoStore1ip address 10.0.40.101inservicerserver host AcuoStore2ip address 10.0.40.105inserviceserverfarm host DICOMpredictor leastconnsprobe PINGrserver AcuoMed1inservicerserver AcuoMed2inservicerserver AcuoStore1inservicerserver AcuoStore2inserviceclass-map type management match-any REMOTE-MANAGEMENT2 match protocol telnet any3 match protocol icmp any4 match protocol ssh any5 match protocol snmp any6 match protocol http any7 match protocol https anyclass-map match-all VIP-HTTP-102 match virtual-address 10.1.240.10 tcp eq 4321policy-map type management first-match REMOTE-MANAGEMENTclass REMOTE-MANAGEMENTpermitpolicy-map type loadbalance first-match VIP-POLICY-10class class-defaultserverfarm DICOMpolicy-map multi-match LB-VIPclass VIP-HTTP-10loadbalance vip inserviceloadbalance policy VIP-POLICY-10loadbalance vip icmp-replyinterface vlan 240description Client side vlanip address 10.1.240.5 255.255.255.0alias 10.1.240.4 255.255.255.0peer ip address 10.1.240.6 255.255.255.0access-group input ANYONEservice-policy input LB-VIPservice-policy input REMOTE-MANAGEMENTno shutdowninterface vlan 241description Server side vlanip address 10.0.40.2 255.255.255.0alias 10.0.40.1 255.255.255.0peer ip address 10.0.40.3 255.255.255.0access-group input ANYONEservice-policy input REMOTE-MANAGEMENTno shutdownip route 0.0.0.0 0.0.0.0 10.1.240.1ACE1-Slot3/dicom#Aggregation 6500 Configuration
ANS1-AGG-1#sh runBuilding configuration...Current configuration : 9091 bytes!upgrade fpd autoversion 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice counters max age 5!hostname ANS1-AGG-1!boot system flash disk0:s72033-adventerprisek9_wan-mz.122-18.SXF10.binenable password cisco!username admin password 0 adminno aaa new-modelclock timezone PDT -7svclc multiple-vlan-interfacessvclc module 3 vlan-group 1svclc vlan-group 1 82,210,211,220,221,230,231,240,241,500,501ip subnet-zero!!!no ip domain-lookupipv6 mfib hardware-switching replication-mode ingressmls ip multicast flow-stat-timer 9no mls flow ipno mls flow ipv6no mls acl tcam share-globalmls cef error action freeze!!!!!!!!redundancymode ssomain-cpuauto-sync running-configspanning-tree mode pvstno spanning-tree optimize bpdu transmissiondiagnostic cns publish cisco.cns.device.diag_resultsdiagnostic cns subscribe cisco.cns.device.diag_commands!vlan internal allocation policy ascendingvlan access-log ratelimit 2000!!!!interface Loopback0ip address 10.1.6.3 255.255.255.255!interface Port-channel1switchportswitchport trunk encapsulation dot1qswitchport mode trunkno ip addressspanning-tree guard loop!interface GigabitEthernet2/1description connection to ANS1-acc-1switchportswitchport trunk encapsulation dot1qswitchport trunk native vlan 100switchport trunk allowed vlan 1-209,211-219,221-229,231-4094switchport mode trunkno ip address!interface GigabitEthernet2/2description connection to ANS1-acc-2switchportswitchport trunk encapsulation dot1qswitchport trunk native vlan 100switchport trunk allowed vlan 1-209,211-219,221-229,231-4094switchport mode trunkno ip address!interface GigabitEthernet2/3description to WAAS Central Managerswitchportswitchport access vlan 21switchport mode accessno ip addressspeed 1000duplex fullspanning-tree portfast!!interface GigabitEthernet2/25description Net QoS SuperAgent Collector SPAN Portswitchportno ip address!interface GigabitEthernet2/26no ip addressshutdown!interface GigabitEthernet2/27no ip addressshutdown!interface GigabitEthernet2/28no ip addressshutdown!interface GigabitEthernet2/29no ip addressshutdown!interface GigabitEthernet2/30no ip addressshutdown!interface GigabitEthernet2/31no ip addressshutdown!interface GigabitEthernet2/44no ip addressshutdown!interface GigabitEthernet2/45switchportswitchport access vlan 100switchport mode accessno ip addressspeed 1000duplex full!interface GigabitEthernet2/46no ip addressshutdown!interface GigabitEthernet2/47no ip addressshutdown!interface GigabitEthernet2/48description connection OOBswitchportswitchport access vlan 82switchport mode accessno ip address!interface TenGigabitEthernet4/1description To ANS1-AGG-2switchportswitchport trunk encapsulation dot1qswitchport mode trunkno ip addresschannel-protocol lacpchannel-group 1 mode active!interface TenGigabitEthernet4/2description To ANS1-AGG-2switchportswitchport trunk encapsulation dot1qswitchport mode trunkno ip addresschannel-protocol lacpchannel-group 1 mode active!interface TenGigabitEthernet4/3description To ANS1-CORE-1ip address 10.1.3.2 255.255.255.0!interface TenGigabitEthernet4/4description To ANS1-CORE-2ip address 10.1.2.2 255.255.255.0!interface TenGigabitEthernet4/5no ip address!interface TenGigabitEthernet4/6no ip address!interface TenGigabitEthernet4/7description To DICOM 4948 Access Cswitchportswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 1-81,83-209,211-219,221-229,231-239,241-4094switchport mode trunkno ip address!interface TenGigabitEthernet4/8description To DICOM 4948 Access Dswitchportswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 1-81,83-209,211-219,221-229,231-239,241-4094switchport mode trunkno ip address!!interface Vlan1no ip addressshutdown!interface Vlan21description to WAAS Central Managerip address 10.1.21.1 255.255.255.0ip nat inside!interface Vlan82description OOB management vlanip address 172.28.196.43 255.255.255.0ip nat outside!interface Vlan100description General purpose Network - outside ACEip address 10.1.100.2 255.255.255.0standby 1 ip 10.1.40.1standby 1 timers 1 3standby 1 priority 51standby 1 preempt delay minimum 120standby 100 ip 10.1.100.1standby 100 priority 150standby 100 preempt!interface Vlan150description Server VLAN 150ip address 10.1.50.2 255.255.255.0shutdownstandby priority 150standby preemptstandby 150 ip 10.1.50.1!interface Vlan240description DICOM ACE Client side connectionip address 10.1.240.2 255.255.255.0standby 240 ip 10.1.240.1standby 240 priority 150standby 240 preempt!!!dial-peer cor custom!!!alias exec s show ip interface briefalias exec sb sh ip int briefalias exec ss sh standby!line con 0line vty 0 4session-timeout 60exec-timeout 60 0password ciscono loginline vty 5 15session-timeout 60exec-timeout 60 0login!!monitor session 1 source vlan 100 , 210monitor session 1 destination interface Gi2/25no cns aaa enableendANS1-AGG-1#4948c Configuration
4948c#sh runBuilding configuration...Current configuration : 4971 bytes!version 12.2no service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice compress-config!hostname 4948c!boot-start-markerboot-end-marker!!no aaa new-modelip subnet-zerono ip domain-lookup!vtp domain ciscovtp mode transparent!!!power redundancy-mode redundantno file verify autospanning-tree mode pvstspanning-tree extend system-id!vlan internal allocation policy ascending!vlan 40,103!vlan 241name DICOM-ACE-CLIENT!interface Port-channel5switchportswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 1,40switchport mode trunk!interface GigabitEthernet1/1switchport access vlan 241switchport mode accessspeed 100duplex full!interface GigabitEthernet1/2switchport access vlan 241switchport mode accessspeed 100duplex full!interface GigabitEthernet1/3switchport access vlan 241switchport mode accessspeed 100duplex full!interface GigabitEthernet1/4switchport access vlan 241switchport mode accessspeed 100duplex full!interface GigabitEthernet1/5switchport access vlan 40switchport mode access!interface GigabitEthernet1/6switchport access vlan 40switchport mode access!interface GigabitEthernet1/7!interface GigabitEthernet1/8!!interface GigabitEthernet1/34switchport access vlan 103switchport mode access!interface GigabitEthernet1/35!interface GigabitEthernet1/36!interface GigabitEthernet1/37!interface GigabitEthernet1/38!interface GigabitEthernet1/39!interface GigabitEthernet1/40switchport access vlan 40switchport mode access!interface GigabitEthernet1/41!interface GigabitEthernet1/42!interface GigabitEthernet1/43switchport trunk encapsulation dot1qswitchport mode trunk!interface GigabitEthernet1/44switchport trunk encapsulation dot1qswitchport mode trunk!interface GigabitEthernet1/45switchport access vlan 40switchport mode access!interface GigabitEthernet1/46switchport trunk encapsulation dot1qswitchport trunk allowed vlan 1,40switchport mode trunkchannel-group 5 mode desirable non-silent!interface GigabitEthernet1/47switchport trunk encapsulation dot1qswitchport trunk allowed vlan 1,40switchport mode trunkchannel-group 5 mode desirable non-silent!interface GigabitEthernet1/48shutdown!interface TenGigabitEthernet1/49!interface TenGigabitEthernet1/50!interface Vlan1no ip address!interface Vlan40no ip address!ip default-gateway 10.0.40.1ip route 0.0.0.0 0.0.0.0 10.0.40.1ip http server!!!!!control-plane!!line con 0stopbits 1line vty 0 4loginline vty 5 15login!end4948c#4948c#sh vlanVLAN Name Status Ports---- -------------------------------- --------- -------------------------------1 default active Gi1/7, Gi1/8, Gi1/9, Gi1/10Gi1/11, Gi1/12, Gi1/13, Gi1/14Gi1/15, Gi1/16, Gi1/17, Gi1/18Gi1/19, Gi1/20, Gi1/21, Gi1/22Gi1/23, Gi1/24, Gi1/25, Gi1/26Gi1/27, Gi1/28, Gi1/29, Gi1/30Gi1/31, Gi1/32, Gi1/33, Gi1/35Gi1/36, Gi1/37, Gi1/38, Gi1/39Gi1/41, Gi1/42, Gi1/43, Gi1/44Gi1/46, Gi1/4840 VLAN0040 active Gi1/5, Gi1/6, Gi1/40, Gi1/45103 VLAN0103 active Gi1/34241 DICOM-ACE-CLIENT active Gi1/1, Gi1/2, Gi1/3, Gi1/41002 fddi-default act/unsup1003 token-ring-default act/unsup1004 fddinet-default act/unsup1005 trnet-default act/unsup612 WAE Configuration
Cisco Wide Area Application Services Engine Console
Username: admin
Password:
The device is configured with a well known default username/password for ease of initial configuration.This default username/password should be changed in order to avoid unwanted access to the device.
System initialization finished.
WAE-DICOM#sh run! WAAS version 4.0.13 (build b12 Aug 9 2007)!device mode application-accelerator!!hostname WAE-DICOM!!!!!!!primary-interface GigabitEthernet 1/0!!!interface GigabitEthernet 1/0ip address 10.1.26.2 255.255.255.0exitinterface GigabitEthernet 2/0shutdownexit!!!ip default-gateway 10.1.26.1!no auto-register enable!! ip path-mtu-discovery is disabled in WAAS by default!!ip route 0.0.0.0 0.0.0.0 10.1.26.1!!!!wccp router-list 1 10.1.26.1wccp tcp-promiscuous router-list-num 1 password ****wccp version 2!!!username admin password 1 bVmDmMMmZAPjYusername admin privilege 15!!!!authentication login local enable primaryauthentication configuration local enable primary!!!!!!!tfo tcp optimized-send-buffer 512tfo tcp optimized-receive-buffer 512!!no adapter epm enable!!policy-engine applicationname Authenticationname Backupname CADname Call-Managementname Conferencingname Consolename Content-Managementname Directory-Servicesname Email-and-Messagingname Enterprise-Applicationsname File-Systemname File-Transfername Instant-Messagingname Name-Servicesname P2Pname Printingname Remote-Desktopname Replicationname SQLname SSHname Storagename Streamingname Systems-ManagementAppendix E—ACUO Configuration
The XML script required to communicate with the ACE module is below:
xml_cmd=<?xml version="1.0" encoding="utf-16" standalone="yes"?><request_xml><serverfarm type="host" name="dicom"><rserver_sfarm name="DICOM12" port="4321"><weight value="5"> </weight><inservice sense="yes"> </inservice></rserver_sfarm></serverfarm></request_xml><response_xml><config_command><command>serverfarm host dicomrserver DICOM12 4321weight 5inservice</command><status code="100" text="XML_CMD_SUCCESS"/></config_command></response_xml>Cisco Validated Design
The Cisco Validated Design Program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit www.cisco.com/go/validateddesigns.
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website 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. (0711R)
