The enterprise architecture framework, and therefore the Cisco SRND for teleworkers, emphasizes a few ideas for the overall solution. These ideas are the primary goals of the solution:
■ Defining safe boundaries within which the solution may be deployed (facilitated by proper expectation setting). That is, the solution must maintain the security standards of the corporation to avoid or mitigate exposure. The teleworker must agree to be bound by corporate security policies in the residential office.
■ Providing hardware and software recommendations for a given deployment model
■ Including or referencing performance and configuration information
These goals are meant to allow the extension of integrated services to teleworker homes in a safe, secure manner while maintaining a comparable service level to that provided to campus-based employees. The overall goal is similar to that of the other architectures put forth by SONA, including protection, cost reduction, and scalable growth potential.
Remote connectivity is not without its challenges, obviously. For each challenge, innovation has brought forth new possibilities for connectivity. Regardless of the chosen option, the common theme still rings true, "Design today with tomorrow in mind." Some of the available options for remote connectivity are as follows:
■ Traditional Layer 2 technologies such as Frame Relay, ATM, or leased lines
■ Service provider MPLS VPNs offering scalable, flexible, and fully meshed connections
■ Site-to-site and remote-access IPsec VPNs over the public Internet
Each of these options could easily be selected and expected to fully serve the basic needs of the remote site or employee. However, each comes with its own challenges where the balance of cost versus security is concerned.
Traditional Layer 2 connections such as Frame Relay and ATM are, most importantly, not available to residential premises (typically). Also, the nature of a Layer 2 connection does not provide much in the way of QoS configuration beyond basic traffic shaping over the link. This aspect alone might be enough to disqualify it as an option if it were available to the teleworker premise. However, these technologies tend to be quite secure, even if there is near-total reliance on the service provider for that security.
MPLS VPNs, as a technology, tend to be the preferred method of the day. The nature of the technology is to provide Layer 3, any-to-any connectivity throughout the network in a secure manner. A similar Layer 2 deployment would prove to be cost prohibitive simply due to the number of circuits required. This is where MPLS shines. A single circuit provides the needed connectivity for all sites. MPLS networks allow the extension of enterprise QoS across the service provider network and the honoring of service levels dictated therein. This alone is a tremendous step forward in the quest for the IIN. There is a bit of confusion associated with VPNs however.
The confusion comes in the service provider's specific implementation. At what point is the traffic flow being tagged and protected according to established QoS policies? This is a bit of a sticking point because it varies from provider to provider. At the time of this writing, the majority of providers are still backhauling traffic to their core prior to any tagging or traffic classification. The chapters in Part II, "Implementing Frame Mode MPLS," discuss this in more detail. For now, suffice to say that, prior to selecting a service provider, you should take precautions and ask in-depth questions regarding QoS policies.
NOTE MPLS, being a Layer 3 technology, still requires a Layer 2 technology for connectivity at the local loop. This is most often accomplished with a Frame Relay connection from the CPE to the provider ingress edge.
This solution tends to be the most prevalent for teleworker solutions, because the Layer 2 and Layer 3 technologies previously mentioned are more appropriate for campus-to-branch connectivity and typically are not available to a residence (due to cost and/or availability). The site-to-site VPN solution tends to have the highest volume of security-related considerations as well, due to its contact with the public Internet.
The use of the Internet as a transport for VPN connections back to the campus or central site is likely the most feasible and cost effective due to the widespread broadband capabilities available (and already installed) in most homes. This allows the corporation to avoid taking on the actual cost of the connection, if so desired, while enabling it to easily provide secure connectivity back to the central site.
The manner in which that is accomplished, however, is open to debate based on the needs of the user and the nature of the connection. Is the connection to be transparent to the user in the form of a nailed-up VPN connection established by a router placed in the home? Or, is that connection going to be one established by the use of a VPN client launched from a laptop on an as-needed basis? Each is a viable solution.
Was this article helpful?