background image
4-21
Cisco AVVID Network Infrastructure Enterprise Quality of Service Design
956467
Chapter 4 QoS in an AVVID-Enabled Wide-Area Network
QoS Recommendations for WAN Aggregation Routers
ATM-to-Frame Relay Recommendations
Many enterprises are deploying AVVID over networks that use Frame Relay at the remote sites and
ATM at the central location. The conversion is accomplished through ATM to Frame Relay Service
Interworking (FRF.8) in the carrier network.
FRF.12 cannot be used because currently no service provider supports FRF.12 termination in the Frame
Relay cloud. In fact, there are no Cisco WAN switching devices that support FRF.12. Tunneling FRF.12
through the service provider's network will do no good because there is no FRF.12 standard on the ATM
side. This is a problem because fragmentation is a requirement if any of the remote Frame Relay sites
use a circuit speed of 768 kbps or below. However, MLP over ATM and Frame Relay provides an
end-to-end, Layer 2, fragmentation and interleaving method for low-speed ATM to Frame Relay FRF.8
Service Interworking links.
FRF.8 Service Interworking is a Frame Relay Forum standard for connecting Frame Relay networks
with ATM network. Service Interworking provides a standards-based solution for service providers,
enterprises, and end users. In Service Interworking translation mode, Frame Relay PVCs are mapped to
ATM PVCs without the necessity for symmetric topologies; the paths can terminate on the ATM side.
FRF.8 supports two modes of operation of the IWF for upper-layer user protocol encapsulation:
·
Translation mode--maps between ATM and Frame Relay encapsulation. It also supports
interworking of routed or bridged protocols.
·
Transparent mode--does not map encapsulations but sends them unaltered. This mode is used when
translation is impractical because encapsulation methods do not conform to the supported standards
for Service Interworking.
MLP for LFI on ATM and Frame Relay Service Interworking networks is supported for transparent
mode VCs and translational mode VCs that support PPP translation (FRF 8.1).
To make MLPoFR and MLPoATM interworking possible, the Interworking Switch must be configured
in transparent mode and the end routers must be able to recognize both MLPoFR and MLPoATM
headers. This is enabled with the frame-relay interface-dlci dlci ppp and protocol ppp commands for
Frame Relay and ATM respectively.
When a frame is sent from the Frame Relay side of an ATM to Frame Relay Service Interworking
connection, the following should happen to make interworking possible:
1.
A packet is encapsulated in MLPoFR header by the sending router
2.
The Carrier Switch, in transparent mode, strips off the 2-byte Frame Relay DLCI field and sends the
rest of the packet to its ATM interface
3.
The receiving router examines the header of the received packet. If the first two bytes of the received
packet are 0x03cf, it treats it as a legal MLPoATM packet and sends it to MLP layer for further
processing.
When an ATM cell is sent from ATM side of an ATM to Frame Relay Service Interworking connection,
the following should happen to make interworking possible:
1.
A packet is encapsulated in MLPoATM header by the sending router
2.
The Carrier Switch, in transparent mode, prepends 2-byte Frame Relay DLCI field to the received
packet and sends the packet to its Frame Relay interface
3.
The receiving router examines the header of the received packet. If the first 4 bytes after the 2-byte
DLCI field of the received packet is 0xfefe03cf, it treats it as a legal MLPoFR packet and sends it
to MLP layer for further processing.
Tip
For more information, see Configuring Frame Relay-ATM Interworking.