Planning
| This section addresses the planning phase of your deployment. Note However, this book is not a project management guide. Many large enterprises already have an official project lifecycle or have adopted one of the national or international standards such as PRINCEII (http://www.ogc.gov.uk/prince2/), BS6079 (http://www.bsi-global.com/index.xalter), or Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK)(www.pmi.org). If your enterprise or organization has a predefined project lifecycle or methodology, follow it. However, for those organizations that do not have a formal project methodology, and even for those that have standards in place, this section makes some general recommendations. We recommend that you address, at a very minimum, the following key elements of your project:
Note The goal is to assist you in defining your business case, to prepare and plan your deployment, and to provide guidance on how to implement, manage, secure, and optimize your WLAN. If you are unfamiliar with standard project management methodologies and project lifecycles, we highly recommend you engage or appoint a professional or dedicated project manager to assist you in your deployment. Project StakeholdersAn important step is to clearly document the project sponsor and stakeholders and how they shall manage and monitor the project. This helps put in place a clear reporting chain and follows established business processes and project methodologies in most large enterprises. Project SponsorBefore you commence, you need a project sponsor. This is usually a senior executive within the organization who either has made the decision to proceed with the deployment or has had the program assigned to him. The project sponsor is by definition a stakeholder who sits on the project board (if one exists). Project BoardThe project board is a committee made up of senior department or group heads that have a vested interest in the program's success. Along with the sponsor, these individuals are sometimes also known as stakeholders. They can include the likes of Finance Director/CFO, IT Director/CIO, Business Operations Manager, and so on. The project stakeholders usually also include a representative of the end users and senior members of the IT department. The project stakeholders/project board should meet regularly to monitor the progress of the program, note deviances, and agree on remediation if necessary. Program TeamAfter you have identified your project sponsor and formulated a list of stakeholders, you need to create a project or program team. In its Project Management Book of Knowledge (PMBOK), PMI defines a project as "a temporary endeavor undertaken to create a unique product or service." A program is simply a collection of interrelated projects. Whether your deployment is considered a project or a program really depends upon its size. Most enterprise-class WLAN deployments are large enough to contain several project tracks, which means that planning your deployment qualifies as a program. For smaller deployments, simply collapse these steps into a single project. Program ManagerA program and its team are usually led by a program manager. The program manager has ultimate responsibility for fulfilling the program goals and managing the program's operations. He typically reports to the stakeholders and sits on the project board. Program managers are responsible for reporting on the program's progress and deviations and, most importantly, ensuring that each constituent project is completed on time, on budget, and in accordance with the overall program plan. Each project has a project manager responsible for its detailed management. Sometimes, especially on smaller programs or where there are resourcing problems, the program manager may also act as a project manager. All project managers usually also report to the program manager. A program manager is critical to a successful delivery of your solution. Ideally, the program manager should not only be someone who is familiar with wireless and/or networking technologies as this will facilitate collaboration with the technical team but also be familiar with your organization. Project TracksMost large programs are broken down into several projects or project tracks. Each project is usually managed by a project manager. Table 3-2 shows examples of typical project tracks and their responsibilities.
Note This list is not exhaustive but simply indicative of several possible groups that should be represented in the program team. UsersIt is important to understand your users so that you can ensure that your WLAN design satisfies their requirements. One common approach is to categorize your users into different types or classes and then identify your primary, secondary, and other user types. User ClassesWhen considering your user base, it is helpful to define various classes of users who share common attributes. These profiles are based on their typical requirements. This includes their primary applications, degree of mobility, bandwidth and latency restrictions, level of security, and typical hours of operation. Note that a user doesn't necessarily need to be an individual. It can also include printers, servers, or automation equipment. It's also important to note that user classes should include anticipated users/devices. Many WLAN deployments are based upon providing network connectivity for users or devices that have not been implemented yet; wireless voice handsets are a prime example. Identifying the various classes and their respective characteristics helps ensure that you design your WLAN to meet their specific requirements. For example, standard users have different security requirements from guest users. The following sections and tables describe different types of users. Standard User ClassThe standard user class is the most common. It covers the common office user, generally outfitted with a laptop or mobile data device (PDA, SmartPhone, and so on). The traffic created by this class is typically identical to normal daily network traffic, and these users can happily coexist with other users in that class within the same WLAN cell. Some standard class devices may require higher levels of bandwidth, because they create streaming voice or video traffic.
Mobile User ClassThe mobile user class covers those users in your organization who are on the move for the majority of their time. They may have a desk and fixed telephone line, but mobility is key to completing their primary job function. As such, they are often equipped with application-specific devices (ASDs), such as asset tracking bar-code readers, PDAs, and standard laptops. This class also includes devices and is not limited to individuals. For example, a mobile user class device could include electric carts with an integral PDA/laptop such as those used in some airports.
Roaming User ClassThe roaming user class is typically limited to individuals (not devices) who are constantly on the move, not only within one location or office, but across multiple locations. This class is also known as road warriors. In many regards they are similar to the mobile user class, with the added requirements of seamless access or "common user experience" at any location.
Hot-Desk User ClassThe hot-desk user class is becoming more common. This class covers users and devices that move from location to location periodically either on a day-to-day basis or throughout the day. Similar to the standard user class, in that they typically require access to everyday network resources, their defining characteristic is that they might remain static for a short period but subsequently move on to another location later. This class includes students in educational organizations and devices such as the mobile check-in desks found in many airports or convention centers.
Guest User ClassThe guest user class covers the users (rarely devices) that require sporadic network access. Usually they require Internet access only, and their access is typically limited to thatthat is, they are not provided with enterprise network connectivity. Many corporations now provide guest wireless access to visitors or temporary users such as contractors or conference attendees. Access is often controlled or monitored and may require the user to accept legal and acceptable usage policies. In-room Internet access for hotel guests is a prime example of the guest user class.
Note that these classifications are not necessarily standard across the industry. These should be considered general descriptive terms. Some companies may not have hot-desk users or may consider them identical to mobile users. Additionally, your organization may include many different user types, but the WLAN is aimed at providing wireless access to only some of them. For example, a university may choose to deploy a wireless network for its security staff (mobile users) but not its student body (hot-desk users). By clearly identifying the types of users in your organization, you can more easily design a network to address your specific goals. These can include providing network access to them all or only to a limited subset of them. After you have classified your user types, you can proceed with identifying your primary, secondary, and even your tertiary users. Primary UsersAfter you identify the user classes within your organization, you should clearly define who the primary target audience is for the WLAN. You may have defined several different classes of users but aim to provide wireless access to only one class. This will have an effect on the breadth and scope of your deployment, the architecture, and the cost. Secondary UsersSecondary users are those who can use the mobility, productivity, and connectivity benefits of the WLAN, even though they were not the primary target. An example could be mobile workers in a manufacturing environment, where wireless was originally installed to provide connectivity to factory equipment. Other UsersSome organizations may choose to provide wireless access to guest users as an incidental benefit or amenity. Although it may not have been a specific project goal or success criterion, fringe benefits can be realized by extending the availability of your WLAN to irregular users. Impact on Application PortfolioWireless networks are slower than conventional wired networks. Today's wired networks typically provide 100 Mbps to 1000 Mbps of dedicated bandwidth per connection. Conversely, today's fastest WLANs offer only up to (and often less than) 54 Mbps that is typically shared among several users. However, as mentioned in Chapter 1, the value of WLANs is not based on speed, but on mobility. As the business decision maker, you must consider the impacts of wireless networks on your existing applications. Most applications will work well, and your workforce will benefit from the added mobility provided by wireless network access. Yet there may be some applications that are so sensitive to bandwidth limitations and lag that their performance is adversely impacted. Remember, a WLAN is a "shared medium" unlike the typical switched wired network. All the users in a particular cell must share the bandwidth, and as such, the amount of bandwidth available to individual users is considerably less than that provided by a wired LAN. Furthermore, the more users there are per cell, the less bandwidth that is available to each user. As such, some applications might not work satisfactorily on your wireless network. An application matrix will help you decide which applications are suitable for wireless networking. A simple five-step process will help you categorize your applications and avoid such an outcome:
The following sections describe additional points to consider when determining the impact of wireless on your application portfolio. The Main Application Base You Want to Use on the WLANApplications can be grouped into generic categories as follows:
This list is not exhaustive, but it is indicative of the application types. Careful consideration is required regarding the application specific characteristics, as well as the environment to which the applications are to be extended by means of WLANs. These considerations are discussed next. Application CharacteristicsIdentifying the characteristics, such as bandwidth required by each application or application mix, is important. Some applications may require consistent or sustained amounts of high bandwidth. If you choose to deploy a WLAN in conjunction with wireless voice services, for example, you must consider the minimum amount of bandwidth required by your voice application. Wireless video cameras are also typical of applications that require a significant or dedicated amount of bandwidth and minimal jitter. Next, identify which applications are susceptible to the characteristics of wireless LANs. Some applications may be susceptible to the "lag" introduced into WLANs when the user roams from cell to cell, for example. This can sometimes add several hundred milliseconds of lag to a session. Most applications can tolerate minor network-related issues like this, but some (including wireless voice, for example) will be negatively impacted. The Portability of the Application Portfolio and Usage Pattern to a WLAN EnvironmentConsider the physical location of users and the mix of applications they use. If you expect a high number of users accessing high-bandwidth applications at the same time in the same location, you may experience potential problems. For example, if you wish to share your WLAN between normal office applications and wireless voice, you may find that you experience voice quality problems if too many data users are "online" at once. You can address this issue with careful radio cell design or with the use of the higher-bandwidth WLAN standards (802.11g and 802.11a). Additionally, you may wish to put limits on the size of your cells to ensure that each user can get enough bandwidth. The use of wireless quality of service (QoS) controls should not be overlooked. Several equipment manufacturers have implemented their own proprietary QoS features (that usually only work with their own equipment and client devices), or you may opt for solutions like that offered by the Cisco Client Extensions (CCX) program, which though proprietary is open for adoption by any manufacturer. Finally, there is the WiFi Multimedia (WMM) standard defined by the WiFi Alliance. Once you have completed this analysis, you can categorize your applications into a sliding scale or application matrix. At one end will be the normal applications that work very well on a wireless network; effectively, they are network agnostic. At the other end will be applications that are not suitable for wireless users. Based upon this categorization, you can flag certain applications as unsuitable or not recommended for wireless use. This will ensure that your support organization and user base are fully informed. Table 3-3 shows a sample application matrix. In this example, certain policy decisions are represented, such as the decision not to support Internet traffic on the WLAN. In your deployment, the entries in the application matrix will be different.
Scalable ArchitectureIn most enterprise environments, it is important that you design your architecture such that it scales in both capacity and capabilities to meet future requirements. Rip-and-replace should be avoided as much as possible due to its excessive organizational and financial burden. Take architectural scalability into account early on. Avoid designs that will not scale across your entire organization or that require excessive operational and support overheads. Architecture's Ability to Grow Easily to Support Additional Users and GroupsEndeavor to design the network such that it can expand easily, either within a single location or across multiple locations. Sometimes this will mean working carefully with the business leaders to align with corporate strategies and forecasted growth, in addition to considering technical requirements. If your enterprise is planning on growing at 10 percent per annum over the next five years, it would be rash to design and implement a WLAN that can only support the current number of users. Avoid nonrepeatable design characteristics. Single Points of FailureDesigns that have single points of failure are typically not considered scalable. For example, if your organization has offices spread across the globe, it is important that you do not architect your WLAN so that all traffic must flow to a central location or single authentication, authorization, and accounting (AAA) server. A design that relies upon a single AAA server is not scalable, especially if you might expand your WLAN to multiple sites in different countries. Common Architecture That Replicates Easily Across All SitesEnsure that the architecture is common for all sites if possible. You want to avoid having individual designs for every site in a large deployment. Standardize as much as possible, ensuring that the WLAN design is the same in different buildings or sites. Avoid using obsolescent equipment or components that are hard to source or restricted in certain countries. For example, if you are undertaking a global deployment, you may wish to ensure that the design can be implemented in Europe, Asia, and the United States. Security StrategyIn today's internetworking world, it is always important to think securely. This is especially the case when dealing with wireless networks due to their broadcast nature. Indeed, press reports on how wireless networks are insecure and prone to hacking cause undue concerns in many organizations. This, in turn, is known as the FUD factor (Fear, Uncertainty, Doubt). The simple fact is that wireless LANs can be secured. The risk lies with WLANs that are not properly secured or those with poorly designed or executed security frameworks. Although you will learn more about security topics in Chapter 7, "Security and Wireless LANs," you should consider security from the very beginning. Careful consideration is required regarding the application-specific characteristics, as well as the environment to which the applications are to be extended by means of WLANs. These considerations are discussed next. Many organizations have information security departments tasked with addressing such topics specifically. However, security is not the responsibility of the IT security team alone. Security standards and policies are also the responsibility of the project implementation team, network engineers, and even business leaders. It may not be possible to finalize a strategy now. Your goals may become clearer as you architect your WLAN or perhaps after you analyze a pilot deployment. However, simply considering these issues during the planning phase may help you highlight the "gaps" in your current security posture and assist you in defining new policies and guidelines. Treating the Wireless Network as Trusted or UntrustedAt a high level, there are basically two different schools of thought on how to deal with wireless LAN security. Either the WLAN is trusted, or it is not. The decision on whether your WLAN will be trusted or untrusted will have a significant impact upon your architecture and technical design. A trusted WLAN is treated as simply another transport medium and is fully integrated into existing network. Security is provided by robust authentication and encryption features provided by the wireless security standards and the equipment manufacturer. An untrusted WLAN is segmented from the core enterprise network as it is considered to be an external network. The WLAN is effectively an extranet. As such, the access points are behind firewalls, and security is provided with the same solutions as for providing remote access to the organization's intranet. A virtual private network (VPN) overlay is a common mechanism for providing secure connectivity in this environment. Considering Wireless Security PoliciesClear and well-defined WLAN security policies will not only facilitate communication with the user community, but also enable the design team to consider specific security requirements early. The engineering team can then craft specific technical solutions and incorporate them into the WLAN's design. As such, you should develop a good understanding of your proposed wireless security policies before you commence the wireless LAN design. The architecture is often influenced by the business and security policies and decisions you define early. Although you will undoubtedly produce finalized and more detailed policies, guidelines, and procedures during and after the deployment, it is appropriate to begin planning these important details now. Dealing with Rogue Access PointsRogue access points are access points that are located within your enterprise that were not installed by your IT department or approved vendors. They present a very serious security threat when connected to your network as they are improperly configured with little or no security settings. The rogue APs create a backdoor into your intranet by effectively bypassing any IT security barriers you have constructed. Rogue APs that are not connected to your network are also a challenge. In these circumstances, the rogue AP installer has not necessarily compromised enterprise security by connecting his personal access point to the network, but the simple fact that the access point is even powered and transmitting can have a negative effect on your official WLAN by creating unwanted radio interference. A method to deal with rogue access points is essential for any enterprise-class WLAN. It is imperative that you define a rogue AP strategy early, acquire tools to help search and identify rogue APs, and define policies and procedures on how they will be dealt with by your IT staff. Define High-Level Program PlanA project plan is a formal, approved document that is used to guide both project execution and project control. At this early stage, you do not need a detailed plan, but rather a brief outline. This can be as simple as a generic Gantt chart with the main project tracks and estimated completion months or quarters noted. This high-level plan will give you a basic understanding of strategy and timelines. Chapter 6 provides further detail to assist you in defining a more accurate and elaborate deployment plan. Once again, it is important to note that the basic guidelines and recommendations contained both here and in Chapter 6 do not obviate the need for you to undertake your deployment in a methodical and clearly defined manner, preferably following your own project lifecycle and methodology or one of the national or international standards. Estimate Resource RequirementsAsking some basic questions, such as the following, will help you estimate your resource requirements:
In turn, the answers to these questions will help you calculate how long the program will take in rough terms. For example, if you are using your own internal IT staff to carry out the site surveys and deployment, the number of sites that can be installed concurrently will be less than if you engaged the professional services of an external vendor. In other words, the more physical resources you have at your disposal, the quicker the project can proceed. Estimate Budgetary RequirementsOnce you have estimated your resource requirements and defined your deployment strategy along with the breadth and scope of your deployment (as discussed earlier in the "Preparation" section), you should be able to calculate a rough program budget cost. This is essential for any large-scale deployment and is a requirement in defining your business case. Produce Project/Program PlansAt this stage and with the rough estimates and projections you have defined so far, you should be able to create a rough program/project plan. This plan should include time and resources required for the design and implementation phase (as detailed in the PPDIOO lifecycle illustrated earlier in Figure 3-1) and cover the multiple project tracks, including options such as a pilot deployment, and phased implementation. You will learn more details in Chapter 6, but at this stage you should be able to produce a high-level program/project plan for your stakeholders as part of your business case. Follow Your Internal Project LifecycleIf your organization is a medium to large enterprise, you likely already have a clearly defined project lifecycle. As such, any advice here may be superfluous; however, at a minimum, you should do the following:
|
EAN: 2147483647
Pages: 163