19.07.2013 Views

Enterprise QoS Solution Reference Network Design Guide

Enterprise QoS Solution Reference Network Design Guide

Enterprise QoS Solution Reference Network Design Guide

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Teleworker V3PN <strong>QoS</strong> Considerations<br />

Bandwidth Provisioning<br />

6-32<br />

<strong>Enterprise</strong> <strong>QoS</strong> <strong>Solution</strong> <strong>Reference</strong> <strong>Network</strong> <strong>Design</strong> <strong>Guide</strong><br />

Chapter 6 IPSec VPN <strong>QoS</strong> <strong>Design</strong><br />

DOCSIS 1.1 also provides the capabilities to shape traffic at Layer 2 before transmission over the cable<br />

network. Although the circuit and frequencies physically are shared, access to the medium can be<br />

controlled by the headend so that a device can be guaranteed specified bandwidth.<br />

At the time of this writing, the only recommended deployment model for cable is the Integrated Unit +<br />

Access Model, as shown in Figure 6-22.<br />

Figure 6-22 Teleworker Deployment Model for Cable<br />

Integrated Unit +<br />

Access Model<br />

A few key differences with respect to bandwidth provisioning need to be taken into account for<br />

broadband teleworker scenarios, as compared to site-to-site VPNs.<br />

The first is that usually only a single call needs to be provisioned for (unless two teleworkers share a<br />

single residential broadband connection, which is rarely the case). If bandwidth is low, G.729 codecs are<br />

recommended. The second key bandwidth-provisioning consideration is the inclusion of the overhead<br />

required by the broadband access technologies, whether DSL or cable.<br />

Note Sometimes multicast support is not required in a teleworker environment. For example, routing protocols<br />

(which depend on multicast support) might not be required by teleworkers (because default gateways are<br />

usually sufficient in this context). In such cases, IPSec tunnel mode (no encrypted IP GRE tunnel) can<br />

be used to achieve additional bandwidth savings of 24 bytes per packet.<br />

For the remainder of this chapter, IPSec tunnel mode (no encrypted IP GRE tunnel) is the assumed mode<br />

of operation.<br />

NAT Transparency Feature Overhead<br />

IP<br />

831/171X DSL<br />

Modem<br />

DSL<br />

Backbone<br />

To <strong>Enterprise</strong><br />

Beginning in Cisco IOS Release 12.2(13)T, NAT transparency was introduced and is enabled by default,<br />

provided that both peers support the feature. It is negotiated in the IKE exchange between the peers. This<br />

feature addresses the environment in which IPSec packets must pass through a NAT/pNAT device, and<br />

it adds 16 bytes to each voice and data packet. The overhead that this feature adds is shown in<br />

Figure 6-23.<br />

Version 3.3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!