|
|
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:
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 End-to-end FRF.12 fragmentation should not be used with Voice over Frame Relay (VoFR). FRF.11 Annex C fragmentation or Cisco proprietary fragmentation are the recommended types of fragmentation for use with VoFR. For more information about VoFR, see the Cisco IOS Multiservice Applications Configuration Guide, Release 12.1. |
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.
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.
When Frame Relay fragmentation is configured, the following conditions and restrictions apply:
More information about end-to-end FRF.12 fragmentation can be found in the following related documents:
End-to-end FRF.12 fragmentation is supported on the following platforms:
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.
The following prerequisites apply to end-to-end FRF.12 fragmentation:
See the following sections for configuration tasks for FRF.12 fragmentation. Each task in the list is identified as optional or required.
To configure the map class to support FRF.12 fragmentation, use the following map-class configuration command:
| Command | Purpose |
|---|---|
Router(config-map-class)# frame-relay fragment fragment_size | Configures Frame Relay fragmentation for the map class. The fragment_size argument defines the payload size of a fragment; it excludes the Frame Relay headers and any Frame Relay fragmentation header. The valid range is from 16 to 1600 bytes, and the default is 53. The value of fragment_size should be less than or equal to the MTU size. Set the fragmentation size such that the largest data packet is not larger than any voice packets. |
|
NoteWhen Frame Relay fragmentation is configured, WFQ or LLQ is mandatory. If a map class is configured for Frame Relay fragmentation and the queueing type on that map class is not WFQ or LLQ, the configured queueing type is automatically overridden by WFQ with the default values. |
To verify FRF.12 fragmentation, use one or more of the following commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
Router#show frame-relay fragment [interface interface] [dlci] | Displays Frame Relay fragmentation information. |
Router#show frame-relay pvc [interface interface] [dlci] | Displays statistics about PVCs for Frame Relay interfaces. |
This section provides a configuration example for FRF.12 fragmentation.
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 40 bytes. The "frag" map class is associated with DLCI 100 on serial interface 1.
router(config)#interface serial 1 router(config-if)# frame-relay traffic-shaping router(config-if)# frame-relay interface-dlci 100 router(config-fr-dlci)# class frag router(config-fr-dlci)# exitrouter(config)#map-class frame-relay frag router(config-map-class)# frame-relay cir 128000 router(config-map-class)# frame-relay bc 1280 router(config-map-class)# frame-relay fragment 40 router(config-map-class)# frame-relay fair-queue
This section documents the command that configures FRF.12 fragmentation.
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
Syntax Description
fragment_size Specifies the number of payload bytes from the original Frame Relay frame that will go into each fragment. This number excludes the Frame Relay header of the original frame. All the fragments of a Frame Relay frame except the last will have a payload size equal to fragment_size; the last fragment will have a payload less than or equal to fragment_size. Valid values are from 16 to 1600 bytes; the default is 53.
Defaults
Disabled.
Command Modes
Map-class configuration
Command History
12.0(3)XG This command was introduced. 12.0(4)T This command was implemented in Cisco IOS Release 12.0 T. 12.1(2)T This command was modified to extend end-to-end FRF.12 fragmentation support to additional platforms.
Release
Modification
Usage Guidelines
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.
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.
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 40 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/0 router(config-if)# frame-relay traffic-shaping router(config-if)# frame-relay interface-dlci 100 router(config-fr-dlci)# class frag router(config-fr-dlci)# exitrouter(config)#map-class frame-relay frag router(config-map-class)# frame-relay cir 128000 router(config-map-class)# frame-relay bc 1280 router(config-map-class)# frame-relay fragment 40 router(config-map-class)# frame-relay fair-queue
FRF.11 Annex C Fragmentation Configuration Example
The following example shows how to enable FRF.11 Annex C fragmentation for data on a CiscoMC3810 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 40 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/1 router(config-if)# frame-relay traffic-shaping router(config-if)# frame-relay interface-dlci 101 router(config-fr-dlci)# vofr router(config-fr-dlci)# class frag router(config-fr-dlci)# exitrouter(config)#map-class frame-relay frag router(config-map-class)# frame-relay cir 128000 router(config-map-class)# frame-relay bc 1280 router(config-map-class)# frame-relay fragment 40 router(config-map-class)# frame-relay fair-queue router(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 40 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/0 router(config-if)# frame-relay traffic-shaping router(config-if)# frame-relay interface-dlci 102 router(config-fr-dlci)# vofr cisco router(config-fr-dlci)# class frag router(config-fr-dlci)# exitrouter(config)#map-class frame-relay frag router(config-map-class)# frame-relay cir 128000 router(config-map-class)# frame-relay bc 1280 router(config-map-class)# frame-relay fragment 40 router(config-map-class)# frame-relay fair-queue
Related Commands
class (virtual circuit) Associates a map class with a specified DLCI. frame-relay fragment Enables weighted fair queueing for one or more Frame Relay PVCs. frame-relay interface-dlci Assigns a DLCI to a specified Frame Relay subinterface on the router or access server. frame-relay traffic-shaping Enables traffic shaping and per-virtual circuit queueing for all PVCs and SVCs on a Frame Relay interface. map-class frame-relay Specifies a map class to define QoS values for an SVC.
Command
Description
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.
Posted: Tue Jun 27 14:40:15 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.