Home > Articles > Networking

  • Print
  • + Share This

High-Level Policies

Within each of the environments described in the previous sections, different types of business needs motivate the deployment of the different technologies. This section looks at some of the business needs that can arise in each of the different environments.

The Enterprise Environment

Within the enterprise environment, the most common needs are that of satisfying the business SLAs that exist between the different parts of the enterprise. For security purposes, an enterprise might need to ensure that access to its network is secure and is accessible only to the employees or other entities that are authorized to have access to specific enterprise resources.

Note - These business needs in this section are intended as illustrative examples for use in subsequent chapters of the book. These examples are not intended as an exhaustive enumeration of all the business needs that can arise in the enterprise environments.

Business SLAs

It is a common practice in many business organizations to have SLAs in place among their different divisions. An SLA is an explicit statement of the expectations and obligations that exist in business relationships between a service provider and its customer [SLAREF]. In the case of an enterprise, the SLA defines the details of the services that an IT department in an enterprise is expected to provide to the other departments that use the computing/networking infrastructure.

Many enterprises choose to outsource the operation and maintenance of their computing infrastructure to another company. This is often the case when the enterprise does not consider running and operating a computer network to be its core skill. The subcontracting company is usually responsible for satisfying an SLA that specifies the performance objectives that are expected from the other company.

An SLA typically contains the following:

  • Description of the type and nature of service to be provided

  • Expected performance level of the service

  • Process for reporting problems with the service

  • Time frame within which a response or resolution of a reported problem is expected

  • Process for monitoring and reporting the service level

  • Credits, charges, or other consequences for the service provider in not meeting its obligation

  • If applicable, any escape clauses describing the conditions under which the SLA might not be valid

Although a significant part of the SLA deals with business aspects, such as the process for reporting problems, service-level compliance, the terms of credits, or escape clauses, I will focus more on the technical aspects of SLAs, such as how you meet the performance objectives outlined in the SLA.

Note - As a matter of terminology, some organizations differentiate between an SLA and an SLO (Service-Level Objective). The SLA refers to the overall business agreement and consists of multiple SLOs that need to be satisfied. One of these SLOs is a performance objective that must be satisfied.

A service's expected performance level has two major aspects: reliability and responsiveness. Reliability includes availability requirements, such as when the service is available and what bounds on service outages may be expected. Responsiveness includes how soon the service would be performed in the normal course of operations. In the context of a computer network, reliability is usually measured in the network's uptime, and responsiveness is measured as bounds on round-trip delays between two customer sites. In order to meet its SLA, the operator of an enterprise network needs to ensure that applications running on the network are available and are performing at the desired level for the target.

The goal for an enterprise IT networking provider is to ensure that the applications supported by to it have a performance that is good enough to meet specific response-time criteria. The performance would be the end-to-end response time of the applications running in the enterprise network.

Chapter 4 describes how business SLAs can be supported effectively by technologies such as capacity planning, Integrated Services, and Differentiated Services.


Although the security needs of many enterprises are quite diverse, we will look at a security scenario that often arises in an enterprise environment. This scenario relates to the provisioning and configuring of extranets among different enterprises.

In an era where all enterprises are connected to the Internet, there are many reasons to move many common business-to-business functions to an Internet-based infrastructure. For example, a company might require that its suppliers conduct business with it electronically. Consider a soft drink bottling company that needs to procure various types of containers from its suppliers. Examples of such containers include plastic bottles, metal cans, and glass bottles. A large bottling company typically procures the containers from a variety of suppliers. Other items supplied by a contractor include labels, bottlecaps, and distilled water. Different bottling plants that are located in different geographic locations might have requirements for different quantities of each type of container or other supplies.

When the bottling company wants to obtain the containers or other supplies, it typically sends a bid out to its list of approved suppliers, who send back quotes and terms for providing the supplies. The bids might be accepted by the company according to a variety of criteria. Although this negotiation is typically done via paper contracts in a traditional fashion, the cost savings that can be realized by migrating the process to an electronic one are significant.

One of the ways in which this system can be realized is by having a bidding server that runs an application that manages the bids received for any specific component, such as containers. The bidding server would be placed so that it is accessible to the suppliers contracted by the company over the Internet. However, for security purposes, the bidding server must be accessible to only a selected subset of suppliers through the Internet.

Such an extranet can be supported and established using the network-level mechanisms of Internet Key Exchange (IKE) as well as the transport-level mechanisms of SSL or TLS. The details of how to exploit these technologies to support the notion of extranets are described in Chapter 4.

The Network Connectivity Provider

Within the context of the network connectivity provider, we will look at the business needs of supporting business SLAs and the creation of a VPN service.

Business SLAs

In the networking services provider environment, customers may use the ISP network in one of the three manners:

  • To access the Internet

  • To interconnect two or more of its sites

  • To access proprietary, industry-specific networks

Most customers in the real world probably want to do a combination of these methods. One of the business objectives of any ISP is to support the communication needs of its customers at a reasonable performance level. These target performance levels are often specified as part of an SLA between the customer and the service provider.

When a customer uses the ISP to connect two or more of its sites, SLAs can be defined to ensure some performance level on the network communication between the pair of access routers that connect those two sites. When accessing the Internet, the customer is present at one of the access routers but can communicate with any of the IXPs in the network. The end objective of the customer communication on the Internet is quite likely to be outside the administrative domain of the ISP. Although the ISP cannot honestly offer any assurances about the performance level of the network outside its domain, it can provide some assurances about the performance of the communication within its own domain.

The SLAs provided to the customer are often specified in terms of the delays that can be provided among the different access points within the ISP network. For example, the ISP might provide connectivity among two private campuses of its customer. It might offer an assurance about the maximum latency a packet would experience in the network between the two campuses. An example of such an SLA is the one offered by UUNET to its customers with leased-line access [UUNETSLA].

Another common performance metric used within SLAs relates to the maximum amount of bandwidth than an ISP will accept from the customer for transport across the network. The ISP promises to transfer the specified amount of bandwidth across its network without a significant loss rate.

The terms specified in the SLA might be the same for all the customers, or they might be different for different customers. The former is the more prevalent case in most ISP environments. However, there are many cases where the SLAs would be defined differently for different customers. A customer trying to distribute real-time stock quotes over the network is likely to demand tighter bounds on network latency from its ISP than a customer dealing primarily with storing and forwarding electronic mail.

As in the case of the enterprise environment, the SLAs within the network may be supported by a variety of techniques, including traffic capacity planning, rate control devices, or the deployment of Differentiated Services.

Virtual Private Networks

The most attractive customers for an ISP are enterprises that need to interconnect their campuses. Quite often, these enterprises have their own private network—their intranet. A typical enterprise network (such as the one shown in Figure 3.2) consists of several campuses with their individual LANs and a WAN connecting the campuses. The WAN usually consists of serial links, such as T1 or T3 links, or where bandwidth demands are not that intense—56Kbps dialed or leased lines. Other techniques used for WAN connectivity are frame relay and ATM connectivity services, which gained popularity in the 1990s. You typically run routers where the IP protocol treats the underlying frame relay or ATM links as a lower-layer protocol. The cost of leasing the links with the right bandwidth is usually the most important factor in the cost of operating the private network.

Because of the growing popularity of the Internet, most enterprise campuses (at least the large ones) are connected to the Internet. The Internet is an open IP network that connects a large part of the world. This results in any pair of enterprise campuses having two paths between themselves—one through the WAN that forms the corporate intranet, and the other one through the Internet. Of course, the intranet path is more secure than the open Internet and is also likely to have much better performance characteristics. As a result, most large corporations maintain their own private corporate networks.

To the ISPs that provide Internet-based connectivity to the enterprise corporations, the emerging scenario provides an attractive option to provide virtual private networks. An ISP can give an enterprise customer the option of eliminating its intranet and replacing it with a virtual network that has comparable performance and security. Such an offering is the virtual private network (VPN).

A VPN provides logical connectivity among the different sites of an enterprise while insulating them from each other. Basically, only the sites involved in the VPN should be allowed to communicate with each other. The only exception to this rule is that every campus needs access to the public Internet through some security device, such as a firewall.

The cheapest VPN is obtained if the campus sites simply connect to the Internet and use encrypted tunnels to carry their traffic across the Internet. However, given the wide variety of threats that exist on the open network, as well as the wide performance fluctuations, it is much more likely that the VPN service would be offered on a private network physically separate from the one that the ISP uses for Internet connectivity. A customer network would get access to both the Internet and the ISP-private network. Several customers would be multiplexed to the ISP-private network. This would reduce the overall cost to the ISP of maintaining its network. The ISP would also be able to offer VPN access to the customer at a reduced cost instead of the customer's having an intranet.

Such a scenario is shown in Figure 3.5. An ISP offers VPN services to two customer enterprises on an ISP-private network. The first customer (Customer A) has three sites connected to the network. The second customer (Customer B) has two sites connected to the network. The ISP connects to other peer ISPs at an exchange point, but it typically supports the private connections from the customers within its own network. The customer sites are connected to both the ISP-private network and through firewalls to the ISP-public network. The firewalls connecting the customers to the Internet typically belong to the customer. At the access routers connecting the customer to the ISP-private network, the ISP has the onus of making sure that the customers are protected from each other. For the sake of brevity, the figure shows access routers and firewalls only at the first campus of both customers. It's implied that a similar structure needs to be in place at each campus.

Figure 3.5
A VPN Deployment Scenario

The high-level policies for deployment—in this case, for the ISP—would be to define the proper set of VPNs and to enable access among its customers in the environment shown in Figure 3.5. Such a solution may be obtained by using IKE and IPsec-based encrypted communication.

Application-Hosting Provider Environment

Within the ASP environment, we will look at the problem of supporting business SLAs and access control as examples of business needs.

Business SLAs

In an application-hosting environment, a service provider can provide its customers with assurances about the availability and reliability of its hosting service. Most service providers promise a 24x7 uptime. In other words, the sites and systems are always operational. From a performance perspective, the application-hosting service provider needs to ensure that the service is running properly and adequately. The service provider also needs to provide SLAs regarding the performance of the applications that will be hosted on the site.

The SLA between the service provider and the hosted customer can be defined in many ways. The simplest and most intuitive way to specify the performance would be to define a response time for a hosted application. The system's response time depends on a variety of factors, including the application design as well as the amount of load in the system. The goal of an application-hosting provider is to ensure that the application operates with specific response targets.

Note that the response target for an application is different from the end-to-end response time that a user of the application service might see. The application-hosting provider has no control over the network that is used to access the application. The network, if congested, can degrade the throughput and end-user response time significantly. However, the application-hosting provider can provide assurance on the part of the server reaction time, which is the time that elapses between the arrival of a request and the beginning of the servicing of the request by the server.

A more typical SLA in the service provider environment might provide the hosted customer with limits on the network bandwidth or server capacity that the customer can use. The limits on network bandwidth can be specified in terms of the absolute bandwidth required, offering a specific customer a slice of bandwidth that connects the application hosting provider site to the Internet. Such an SLA might specify that a customer will receive a performance equivalent to the performance it would have received if it has a dedicated leased line of equivalent bandwidth. Similar rates can also be specified on the connection rates that are supported by the server.

The two most important factors comprising service provider SLAs are the total amount of access bandwidth and the server capacity (the rate of connections that the site can support) allocated to a customer. The fulfillment of business SLAs by an ASP typically involves allocating adequate amounts of these two resources to different customers.

Access Control

From a security perspective, the most complex task of a service provider is to manage the many different types of firewalls that typically exist in a server farm environment. These various firewalls are required to protect the different parts of the server farm from each other. Here are the security functions that need to be implemented in a server farm:

  • Protect the customer's applications from hackers on the Internet

  • Protect the different customers from each other

  • Secure each customer's access into his or her network

  • Secure the administration and management applications within the server farm from the customers

These functions are usually implemented in different firewalls. The goal of these multiple firewalls is to ensure that each customer has the right access to its own part of the server farm. Therefore, the best representation of the security policies in the server farm is provided by specifying each customer and the section of the ASP network that it is allowed to access.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020