Enterprise QoS Solution Reference Network Design Guide
Enterprise QoS Solution Reference Network Design Guide
Enterprise QoS Solution Reference Network Design Guide
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Site-to-Site V3PN <strong>QoS</strong> Considerations<br />
6-8<br />
Figure 6-5 Packet Size Changes of a G.729 IPSec-Encrypted Packet<br />
Packet<br />
Size (Bytes)<br />
20<br />
Payload<br />
(20)<br />
60<br />
IP (20)<br />
UDP (8)<br />
RTP (12)<br />
Payload<br />
(20)<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 />
Therefore, the calculation, inclusive of Layer 2 overhead, is as follows. This example assumes that a<br />
G.729 call will be encrypted over a slow speed (£ 768-kbps Frame Relay link), which requires FRF.12<br />
fragmentation and interleaving.<br />
60 bytes per packet (G.729 voice)<br />
24 bytes per packet (IP GRE overhead)<br />
52 bytes per packet (IPSec ESP overhead)<br />
4 bytes per packet (FR overhead)<br />
+ 4 bytes per packet (FRF.12 overhead)<br />
44 bytes per packet<br />
· 8 bits per byte<br />
1152 bits per packet<br />
· 50 packets per second<br />
57,600 bits per second (rounded up to 58 kbps)<br />
In summary, it is important always to include Layer 2 overhead in accurate bandwidth provisioning for<br />
IPSec-encrypted applications.<br />
cRTP and IPSec Incompatibility<br />
78<br />
Ethernet (14)<br />
802.1Q (4)<br />
IP (20)<br />
UDP (8)<br />
RTP (12)<br />
Payload<br />
(20)<br />
IPSec VPN<br />
(Frame Relay<br />
Access)<br />
140<br />
FR (4)<br />
IPSec (52)<br />
GRE (24)<br />
IP (20)<br />
UDP (8)<br />
RTP (12)<br />
Payload<br />
(20)<br />
Layer 2<br />
Size<br />
The significant increases in bandwidth required by IPSec encryption lead many administrators to<br />
consider the use of IP RTP header compression (cRTP) to offset these increases.<br />
However, one of the caveats of encryption is that key portions of the original IP packet that could be<br />
referenced for <strong>QoS</strong> (and other) purposes are no longer readable. Such is the case with cRTP.<br />
cRTP and IPSec are inherently incompatible standards. The original IP/UDP/RTP header already is<br />
encrypted by IPSec by the time the RTP compressor is called upon to perform the compression.<br />
Therefore, because cRTP cannot associate the encrypted IP/UDP/RTP packet with a known media<br />
stream, compression cannot occur and cRTP bandwidth savings cannot be realized. The encrypted<br />
IP/UDP/RTP packet simply bypasses the compression process and continues (uncompressed) to the<br />
transmit queue.<br />
This is illustrated in Figure 6-6.<br />
78<br />
Ethernet (14)<br />
802.1Q (4)<br />
IP (20)<br />
UDP (8)<br />
RTP (12)<br />
Payload<br />
(20)<br />
60<br />
IP (20)<br />
UDP (8)<br />
RTP (12)<br />
Payload<br />
(20)<br />
20<br />
Payload<br />
(20)<br />
Version 3.3
Change language