Americas

  • United States
by Steve Taylor and Joanie Wexler

Finally! A multilink frame relay service makes its debut

Opinion
Feb 06, 20032 mins
Networking

* Deutsche Telekom readies MFR for German market

Over the past couple of months we’ve been writing about some recent advances in multilink frame relay and the expected resurgence of interest in frame relay due to these developments.  We’ve also written about MFR as a “stealth frame relay” service, which is the basis of WorldCom’s higher-speed Internet access offering.  However, the missing link has been the availability of a public frame relay service that offers MFR as MFR.  Until now.

It might be surprising to some of our readers that the first service provider to offer MFR as a service isn’t based in the U.S. – surprising because frame relay has often been portrayed as a service that was first deployed primarily in the U.S.  Instead, the service will be offered by Germany’s Deutsche Telekom. 

The service is based on FRF.16, providing a single logical frame relay user-to-network interface (UNI) that is deployed using multiple physical access facilities.  In the case of the Deutsche Telekom service, 4M-bit/sec frame relay service is offered via dual 2M bit/sec (E-1) access facilities.

The service being deployed as FRF.16 is significant.  FRF.16 refers to the Frame Relay Forum’s implementation agreement that specifies MFR as an UNI, such that service may be used on a location-by-location basis.  One end of the MFR connection is at the customer premises, and the other is at the service provider’s offices.  In the case of the Deutsche Telekom MFR service, the customer premises equipment is standardized as the Quick Eagle 4250 Multilink Frame Relay Access Device. 

This use of FRF.16 is significant in contrast with FRF.15.  FRF.15 specifies end-to-end MFR, whereby a user may implement MFR between two sites.  The good news about FRF.15 is that there is no action needed by the service provider, but the bad news is that FRF.15 is really useful only for providing high bandwidth between two sites.  The more likely need for MFR is where you have a large number of remote sites with moderate bandwidth demands and a few sites that need large bandwidth.  This is exactly what FRF.16 is designed for.

When will this trend come to the U.S.?  The technology is ready, and we’re hearing rumors that there may be some major announcements soon.  We’ll keep you informed.