Downloads |
Table Of Contents
FRF.12 Support on Additional Platforms
Supported Standards, MIBs, and RFCs
Configuring End-to-End FRF.12 Fragmentation in a Frame Relay Map Class
Verifying the Configuration of End-to-End FRF.12 Fragmentation
FRF.12 Fragmentation Configuration Example
FRF.12 Support on Additional Platforms
This feature module describes the FRF.12 Support on Additional Platforms feature. It includes information about the benefits of this feature, supported platforms, related documents, and more.
This document includes the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
The end-to-end FRF.12 fragmentation functionality that was introduced in Cisco IOS Release 12.0(4)T is now extended to the Cisco 805, 1600, 1700, 2500, 4500, and 4700 router platforms.
The purpose of end-to-end FRF.12 fragmentation is to support real-time and non-real-time data packets on lower-speed links without causing excessive delay to the real-time data. FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. This standard was developed to allow long data frames to be fragmented into smaller pieces (fragments) and interleaved with real-time frames. In this way, real-time and non-real-time data frames can be carried together on lower-speed links without causing excessive delay to the real-time traffic.
End-to-end FRF.12 fragmentation is recommended for use on permanent virtual circuits (PVCs) that share links with other PVCs that are transporting voice and on PVCs transporting Voice over IP (VoIP). Although VoIP packets should not be fragmented, they can be interleaved with fragmented packets.
Note
FRF.12 is configured on a per-PVC basis. You will configure FRF.12 fragmentation in a Frame Relay map class using the frame-relay fragment command, and you will associate that map class with specific data-link connection identifiers (DLCIs). In addition, you must enable Frame Relay traffic shaping on the interface in order for fragmentation to work.
Benefits
End-to-end FRF.12 fragmentation enables real-time and non-real-time traffic to be carried over the same Frame Relay links without compromising quality of service for the delay-sensitive traffic.
Restrictions
When Frame Relay fragmentation is configured, the following conditions and restrictions apply:
•
•
•
•
Related Documents
More information about end-to-end FRF.12 fragmentation can be found in the following related documents:
•
•
•
•
Supported Platforms
End-to-end FRF.12 fragmentation is supported on the following platforms:
•
•
•
•
•
•
•
•
•
•
Supported Standards, MIBs, and RFCs
Standards
Frame Relay Fragmentation Implementation Agreement (FRF.12), Frame Relay Forum, December, 1997
MIBs
No new or modified MIBs are supported by this feature.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on Cisco Connection Online (CCO) at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
No new or modified RFCs are supported by this feature.
Prerequisites
The following prerequisites apply to end-to-end FRF.12 fragmentation:
•
•
Configuration Tasks
See the following sections for configuration tasks for FRF.12 fragmentation. Each task in the list is identified as optional or required.
•
•
Configuring End-to-End FRF.12 Fragmentation in a Frame Relay Map Class
To configure the map class to support FRF.12 fragmentation, use the following map-class configuration command:
Note
Verifying the Configuration of End-to-End FRF.12 Fragmentation
To verify FRF.12 fragmentation, use one or more of the following commands in privileged EXEC mode:
Configuration Examples
This section provides a configuration example for FRF.12 fragmentation.
FRF.12 Fragmentation Configuration Example
The following example shows the configuration of pure end-to-end FRF.12 fragmentation and weighted fair queueing in the map class called "frag." The fragment payload size is set to 160 bytes. The "frag" map class is associated with DLCI 100 on serial interface 1.
router(config)# interface serial 1router(config-if)# frame-relay traffic-shapingrouter(config-if)# frame-relay interface-dlci 100router(config-fr-dlci)# class fragrouter(config-fr-dlci)# exitrouter(config)# map-class frame-relay fragrouter(config-map-class)# frame-relay cir 128000router(config-map-class)# frame-relay bc 1280router(config-map-class)# frame-relay fragment 160router(config-map-class)# frame-relay fair-queueCommand Reference
This section documents the command that configures FRF.12 fragmentation.
frame-relay fragment
To enable fragmentation of Frame Relay frames for a Frame Relay map class, use the frame-relay fragment map-class configuration command. To disable Frame Relay fragmentation, use the no form of this command.
frame-relay fragment fragment_size
no frame-relay fragment
Syntax Description
Defaults
Fragmentation is disabled.
Command Modes
Map-class configuration
Command History
Usage Guidelines
You should enable fragmentation for low-speed links (meaning those operating at less than 768 kbps).
Frame Relay fragmentation is enabled on a per-PVC basis. Before enabling Frame Relay fragmentation, you must first associate a Frame Relay map class with a specific data-link connection identifier (DLCI), and then enter map-class configuration mode and enable or disable fragmentation for that map class. In addition, you must enable Frame Relay traffic shaping on the interface in order for fragmentation to work.
Selecting a Fragmentation Format
Frame Relay frames are fragmented using one of the following formats, depending on how the PVC is configured:
•
•
•
Cisco recommends pure end-to-end FRF.12 fragmentation on PVCs that are carrying VoIP packets and on PVCs that are sharing the link with other PVCs carrying Voice over Frame Relay (VoFR) traffic.
In pure end-to-end FRF.12 fragmentation, Frame Relay frames having a payload less than the fragment size configured for that PVC are transmitted without the fragmentation header.
FRF.11 Annex C and Cisco proprietary fragmentation are used when VoFR frames are transmitted on a PVC. When fragmentation is enabled on a PVC, FRF.11 Annex C format is implemented when vofr is configured on that PVC; Cisco proprietary format is implemented when vofr cisco is configured.
In FRF.11 Annex C and Cisco proprietary fragmentation, VoFR frames are never fragmented, and all data packets (including VoIP packets) contain the fragmentation header regardless of the payload size.
Selecting a Fragment Size
You should set the fragment size based on the lowest port speed between the routers. For example, for a hub-and-spoke Frame Relay topology where the hub has a T1 speed and the remote routers have 64 kbps port speeds, the fragmentation size must be set for the 64 kbps speed on both routers. Any other PVCs that share the same physical interface must use the same fragmentation size used by the voice PVC.
With pure end-to-end FRF.12 fragmentation, you should select a fragment size that is larger than the voice packet size.
Table 1 shows the recommended fragmentation sizes for a serialization delay of 10 ms.
Examples
End-to-End FRF.12 Fragmentation Configuration Example
The following example shows how to enable pure end-to-end FRF.12 fragmentation for the "frag" map class. The fragment payload size is set to 160 bytes. Frame Relay traffic shaping is required on the PVC; the only queueing type supported on the PVC when fragmentation is configured is weighted fair queueing (WFQ).
router(config)# interface serial 1/0/0router(config-if)# frame-relay traffic-shapingrouter(config-if)# frame-relay interface-dlci 100router(config-fr-dlci)# class fragrouter(config-fr-dlci)# exitrouter(config)# map-class frame-relay fragrouter(config-map-class)# frame-relay cir 128000router(config-map-class)# frame-relay bc 1280router(config-map-class)# frame-relay fragment 160router(config-map-class)# frame-relay fair-queueFRF.11 Annex C Fragmentation Configuration Example
The following example shows how to enable FRF.11 Annex C fragmentation for data on a Cisco MC3810 PVC configured for VoFR. Note that fragmentation must be configured if a VoFR PVC is to carry data. The fragment payload size is set to 160 bytes. Frame Relay traffic shaping is required on the PVC; the only queueing type supported on the PVC when fragmentation is configured is weighted fair queueing (WFQ).
router(config)# interface serial 1/1router(config-if)# frame-relay traffic-shapingrouter(config-if)# frame-relay interface-dlci 101router(config-fr-dlci)# vofrrouter(config-fr-dlci)# class fragrouter(config-fr-dlci)# exitrouter(config)# map-class frame-relay fragrouter(config-map-class)# frame-relay cir 128000router(config-map-class)# frame-relay bc 1280router(config-map-class)# frame-relay fragment 160router(config-map-class)# frame-relay fair-queuerouter(config-map-class)#Cisco Proprietary Fragmentation Configuration Example
The following example shows how to enable Cisco proprietary Frame Relay fragmentation for the "frag" Frame Relay map class on a Cisco 2600 series, 3600 series, or 7200 series router, starting from global configuration mode. The fragment payload size is set to 160 bytes. Frame Relay traffic shaping is required on the PVC; the only queueing type supported on the PVC when fragmentation is configured is weighted fair queueing (WFQ).
router(config)# interface serial 2/0/0router(config-if)# frame-relay traffic-shapingrouter(config-if)# frame-relay interface-dlci 102router(config-fr-dlci)# vofr ciscorouter(config-fr-dlci)# class fragrouter(config-fr-dlci)# exitrouter(config)# map-class frame-relay fragrouter(config-map-class)# frame-relay cir 128000router(config-map-class)# frame-relay bc 1280router(config-map-class)# frame-relay fragment 160router(config-map-class)# frame-relay fair-queueRelated Commands
Glossary
FRF—Frame Relay Forum. An association of corporate members consisting of vendors, carriers, users, and consultants committed to the implementation of Frame Relay in accordance with national and international standards. Refer to the Web site http://www.frforum.com.
FRF.11—Frame Relay Forum implementation agreement for Voice over Frame Relay (v1.0 May 1997). This specification defines multiplexed data, voice, fax, DTMF digit-relay, and CAS/Robbed-bit signalling frame formats, but does not include call setup, routing, or administration facilities. Refer to the Web site http://www.frforum.com.
FRF.11 Annex C—An agreement that describes a standard transfer syntax used to support transport of data frames between two VoFR service users.
FRF.12—Frame Relay Fragmentation Implementation Agreement. The FRF.12 standard was developed to allow long data frames to be fragmented into smaller pieces and interleaved with real-time frames. In this way, real-time voice and non-real-time data frames can be carried together on lower-speed links without causing excessive delay to the real-time traffic.
VoFR—Voice over Frame Relay.
Voice over Frame Relay—A protocol that enables a router to carry voice traffic (for example, telephone calls and faxes) over a Frame Relay network. When voice traffic is sent over Frame Relay, it is segmented and encapsulated for transit across the Frame Relay network using FRF.12 encapsulation.
Voice over IP—A protocol that enables a router to carry voice traffic (for example, telephone calls and faxes) over an IP network. In Voice over IP, the DSP segments the voice signal into frames, which are then coupled in groups of two and stored in voice packets. These voice packets are transported using IP in compliance with ITU-T specification H.323.
VoIP—Voice over IP.
Weighted Fair Queueing—Congestion management algorithm that identifies conversations, separates packets that belong to each conversation, and ensures that capacity is shared fairly among those individual conversations.
WFQ—weighted fair queueing.
