Link Efficiency 47
• Shared reservation—This is a flow that originates from one or more sources. A
shared reservation is used by a “many-to-many” multicast application, and there is a
single reservation, defined with a wildcard filter, such that any sender in the specified
group has access to the reservation.
Subnet Bandwidth Manager (SBM), defined by RFC 2814, is a signaling protocol that deals
with RSVP-based admission control on 802-based networks. Today, SBM is primarily used
in switched Ethernet environments for LAN-based admission control for RSVP flows.
Simply stated, SBM is responsible for handling admission control for resource reservations.
On each managed segment, an election process happens dynamically, and one device
becomes the Designated Subnet Bandwidth Manager (DSBM). The DSBM is responsible
for the admission control on that specific segment. There can be more than one SBM on a
segment, but only one is elected as the DSBM.
The actual process of making a reservation, when a DSBM is present, includes the
following steps:
1 When a DSBM sends an RSVP Path message out an interface that belongs to a
managed segment, the message is sent to the DBSM. If the segment were not
managed, this message would have gone directly to the RSVP session destination.
2 The DSBM builds a Path state for the message, and retains information about the node
from which it received the message.
3 The DSBM forwards the message to the destination.
4 The DSBM then gets the RSVP Resv message and processes the message to
determine what action to take next.
5 If there is bandwidth available for the reservation, the Resv message is sent to the
previous hop. In this case, the local Path state is used for this session.
6 If bandwidth isn’t available for the reservation, the DSBM returns a Resverr message
to the requesting node.
On Cisco IOS routers, you can use the following command to configure SBM:
Router(config-if)# ip rsvp dsbm
candidate [
priority
]
The show ip rsvp sbm detail command can be used to verify the configuration of SBM.
Link Efficiency
Cisco IOS includes more and more features with every release. Some of the features in
Cisco IOS are very specific, and may never need to be used in your network. However, link-
efficiency mechanisms are likely to be of use in any network where there is a mixture of
voice and data running over slower-speed links (T1 speed or less).
48 Chapter 2: End-to-End QoS: Quality of Service at Layer 3 and Layer 2
In general, link-efficiency mechanisms are designed to help maximize efficiency when
voice is present on the network. Although quite a few mechanisms would be considered part
of the group of link-efficiency features, only a few are discussed here; primarily, Real Time
Protocol Header Compression (cRTP) and Link Fragmentation and Interleaving (LFI).
Link Fragmentation and Interleaving (LFI)
Before discussing the specifics of link-efficiency mechanisms, it seems wise to discuss the
need for link efficiency in the first place. Primarily, when conversations take place about
using VoIP, everyone jumps up and screams about the need for QoS or, more specifically,
prioritization of traffic. Although prioritization is certainly necessary in a VoIP
environment, lower-speed links (those under 768 kbps) create problems for VoIP that
simple prioritization cannot solve. In these cases, link-efficiency mechanisms are necessary
to ensure proper QoS for the VoIP traffic.
Serialization delay is the time that it takes to place bits on to the circuit. Table 2-1 shows
the serialization delay for packets of various sizes, by link speed.
As you can see from this table, the serialization delay for a 1500-byte packet on a link
slower than 768 kbps is quite high. The “break point” for a 1500-byte packet happens at
768 kbps or higher speeds. When the link speed is 768 kbps, or greater, the serialization
delay does not have a significant negative impact, so fragmentation is not necessary.
If the serialization delay would otherwise be greater than 15 ms, however, fragmentation is
needed. Specifically, LFI is needed. All forms of LFI have the same function, but there are
several types of LFI:
• MLP Interleaving—LFI on multilink PPP links
• FRF.12—LFI for Frame Relay data permanent virtual circuits (PVCs)
• FRF.11 Annex C—LFI for Frame Relay Voice over Frame Relay (VoFR) PVCs
Table 2-1 Serialization Delay of Various Packet Sizes on Links of Various Speeds
Link Speed Packet Size
64 bytes 128 bytes 256 bytes 512 bytes 1024 bytes 1500 bytes
56 kbps 9 ms 18 ms 36 ms 72 ms 144 ms 214 ms
64 kbps 8 ms 16 ms 32 ms 64 ms 128 ms 187 ms
128 kbps 4 ms 8 ms 16 ms 32 ms 64 ms 93 ms
256 kbps 2 ms 4 ms 8 ms 16 ms 32 ms 46 ms
512 kbps 1 ms 2 ms 4 ms 8 ms 16 ms 23 ms
768 kbps 0.640 ms 1.28 ms 2.56 ms 5.12 ms 10.24 ms 15 ms
Link Efficiency 49
The function of all of these types of LFI is to fragment large data packets and interleave the
much smaller data packets. Figure 2-2 illustrates the basic concept.
Figure 2-2 Link Fragmentation and Interleaving
Configuring MLP Interleaving is as simple as using the following three commands:
Router(config-if)#encapsulation ppp
Router(config-if)#ppp multilink
Router(config-if)#ppp multilink interleave
Optionally, you can manually change the default fragmentation delay from 30 using the
following command:
Router(config-if)#ppp multilink fragment-delay
milliseconds
Table 2-2 shows the recommended settings for fragmentation
Shaded values indicate that fragmentation is not needed.
Configuring Frame Relay Fragmentation (FRF.12 or FRF.11 Annex C) requires only one
command; note that the following command is entered within a Frame Relay map class, not
under the interface directly:
Router(config-map-class)#frame-relay fragment
fragment_size
Table 2-2 Recommended Settings for Fragmentation
Link
Speed
10 ms 20 ms 30 ms 40 ms 50 ms 100 ms 200 ms
56 kbps 70
bytes
140
bytes
210
bytes
280
bytes
350
bytes
700
bytes
1400
bytes
64 kbps 80
bytes
160
bytes
240
bytes
320
bytes
400
bytes
800
bytes
1600
bytes
128 kbps 160
bytes
320
bytes
480
bytes
640
bytes
800
bytes
1600
bytes
3200
bytes
256 kbps 320
bytes
640
bytes
960
bytes
1280
bytes
1600
bytes
3200
bytes
6400
bytes
512 kbps 640
bytes
1280
bytes
1920
bytes
2560
bytes
3200
bytes
6400
bytes
12800
bytes
768 kbps 1000
bytes
2000
bytes
3000
bytes
4000
bytes
5000
bytes
10000
bytes
20000
bytes
1536 kbps
2000
bytes
4000
bytes
6000
bytes
8000
bytes
10000
bytes
20000
bytes
40000
bytes
Data 5
Without LFI
With LFI Data 4 Data 3 Data 2 Voice Data 1
Voice Data
50 Chapter 2: End-to-End QoS: Quality of Service at Layer 3 and Layer 2
You can verify the configuration of LFI for Frame Relay with the show frame-relay
fragment command. These commands are, at present, only applicable to the FlexWAN
module for the Catalyst 6500 Family of switches.
Real Time Protocol Header Compression (cRTP)
Real Time Protocol (RTP) is the standard protocol for the transport of real-time data, and is
defined in RFC 1889. As defined, an RTP packet includes the payload plus an RTP/UDP/
IP header. The total header is 40 bytes and breaks down as follows: The RTP header is 12
bytes, the UDP header is 8 bytes, and the IP header is 20 bytes. Depending on the appli-
cation, the payload is typically between 20 bytes and 160 bytes. That means that it’s
possible that the header would be twice the size of the payload! Clearly, that is not efficient,
so the folks at the IETF came up with a way to take advantage of similarities between
successive packets and reduce the 40-byte header to somewhere between 2 and 5 bytes. For
VoIP, this header compression can yield an overall reduction in packet size on the order of
200 percent or more.
Although the idea of using cRTP everywhere sounds good at first glance, the trade-off, in
terms of performance, on link speeds higher than T1 are not desirable. Therefore, use of
cRTP should be limited to links with speeds of T1 or less. Speaking of performance, prior
to Cisco IOS 12.0(7)T, cRTP happened in the process switching path, which often slowed
the processing of packets to the point that it was not desirable to use cRTP. As of 12.0(7)T,
however, cRTP will use the Cisco Express Forwarding (CEF) switching path, or fast
switching path (if CEF is not enabled). Only if both CEF and fast switching are disabled
will cRTP packets be process switched.
The configuration of cRTP on a serial interface is simple, as shown in the following
example:
Router(config-if)#ip rtp header-compression [passive]
The passive keyword tells the routers to compress outgoing RTP packets only if the
incoming RTP packets on that interface are compressed.
For Frame Relay PVCs, the configuration of cRTP is as follows:
router(config-if)#frame-relay map ip
ip-address dlci
[broadcast] rtp header-
compression [active | passive]
To verify the configuration and operation of cRTP, use the following commands for Frame
Relay and non-Frame Relay interfaces, respectively:
Router#show frame-relay ip rtp header-compression [interface
type number
]
Router#show ip rtp header-compression [
type number
] [detail]
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.