Talk:Frame Relay

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

But do you know what the consequences of using Frame Relay are and in what scenarios it is good to use it?

Is the key to Frame Relay the utilization of existing telephone wires and infrastructure? After reading this page I fail to grasp the principal reason for its existence.

Descriptive Image of Protocol[edit]

It would be nice if someone included an image or a table layout of what the Frame Relay header/protocol looks like. Having a text only description of the header makes undestanding or even just imagining it quite hard. The type of switching used for frame relay should be included here.

+++

Here is a good link to the cisco site (NO PREFERNCE FOR THIS VENDOR INDICATED)

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm

This article needs help![edit]

This article needs a basic description of the technology upfront. For those with low to medium knowledge needing a basic techincal description, there is no jumping-off point. A good, basic description of how it works and how it varies from other models would help clarify. —Preceding unsigned comment added by 216.68.204.87 (talk) 02:29, 14 October 2007 (UTC)[reply]

I second that. It's repetitive and not clear, especially in the first section. Also I endorse the idea of a simple diagram. maxcelcat. —Preceding undated comment was added at 01:01, 18 August 2008 (UTC)[reply]

Speed vz X.25[edit]

The X.25 standard was upgraded in 1992 to accomodate 2 Mbps speeds. If FR is 20 times faster, where is the info that says FR is available at 80 Mbps?--itpastorn (talk) 09:09, 28 February 2008 (UTC)[reply]

FR is typically provided over T3 at 44 Mbps (and 20 x 2 = 40 != 80). Dgtsyb (talk) 13:58, 8 June 2008 (UTC)[reply]

Fair comparison?[edit]

I heard Frame Relay mentioned as the "Poor man's ATM". Is that assertion practically correct? 82.131.210.162 (talk) 10:53, 23 May 2008 (UTC)[reply]

This article needs help![edit]

This article needs help. Frame relay is quite important.--MrBobla (talk) 13:30, 14 December 2008 (UTC)[reply]

Frame Relay Origins[edit]

Frame relay is a the y un substitutional relay to the one hop to another hop for substinated by he naturale atomicaly sercumtances to delivered of send the data packets any instance.this should be prefered to managed of atomicaly undeclorated of that time prefered by the frame relay process.


My recollection from the time is that AT&T and Sprint and others were offering proprietary modifications to X.25. The modifications were not so involved with throwing away error correction as in removing the hop-by-hop store-and-forward nature of X.25 that mostly impacted performance. These proprietary networks (I believe AT&T's version was called Accunet) performed end-to-end acknowledgement rather than hop-by-hop store-and-forward acknowledgement increasing the performance of network switches dramatically. As I recall, the standardization effort was primarily to provide a common basis for these and other advances over X.25 (such as dynamic multiplexing with fast-packet techologies). Fast-packet technologies went further than reducing the cost of hop-by-hop store-and-forward, which basically removed layer 3 and half of layer 2 at interior switches, by having the terminating switch simply discard errors. However, this was not due to the high cost of requesting end-to-end retransmissions, but rather because ISDN clear-channel requirements had increased the accuracy of networks from 10E-03 to 10E-05 or 10E-06, meaning that retransmissions were seldom required anyway. (I don't think that one can really call this best-effort, particularly as the term is used in Internet Protocol routers.) Although I am sure that AT&T and Sprint and others patented their is a un substitu individual approaches, I don't know that Sprint was first or could be attributed with "inventing" frame relay. Recent changes to the article including such claims need to be substantiated with proper references. Also, I have references that indicate that Sprint was late out of the chute in deploying frame-relay, even though Nortel (a major supplier of Sprint at the time) was offering it on their DMS SuperNodes earlier. — Dgtsyb (talk) 00:28, 5 February 2010 (UTC)[reply]

My first job out of undergrad was working on the Frame Relay service at AT&T Bell Labs in 1989. It was falling out of favor at the time due to changing economic forecasts and I was moved over to SONET. However, I'm a bit surprised to see a patent issued to Nortel some 15 years later. My manager was supposedly deeply involved in bringing it along. It was definitely related to X.25, which was also run out of our team. Ronnotel (talk) 17:48, 31 July 2020 (UTC)[reply]

loom[edit]

What is the contextual meaning of the word 'loom' in this sentence from the article?: "the end may loom for the frame relay protocol and encapsulation". From dictionary.com the verb definition of loom says this: "to appear indistinctly; come into view in indistinct and enlarged form". (http://dictionary.reference.com/browse/loom?s=t). Would the referenced article sentence using loom be correct if written as follows?: "the end may [appear indistinctly] for the frame relay protocol and encapsulation". Thanks in advance for clarification. — Preceding unsigned comment added by Dbudge1 (talkcontribs) 21:32, 11 April 2015‎ (UTC

The Oxford dictionary of American English says it can mean "Appear as a shadowy form, especially one that is large or threatening" or "(Of an event regarded as ominous or threatening) seem about to happen"; the latter of those two is presumably what's intended.
But if you are really saying "that's not exactly encyclopedic writing", you are correct - it's not. Guy Harris (talk) 21:47, 11 April 2015 (UTC)[reply]

What does this sentence mean?[edit]

What does this sentence mean? Specifically, the words "the end may loom". "the end may loom for the frame relay protocol and encapsulation". Thanks in advance for clarification. — Preceding unsigned comment added by Dbudge1 (talkcontribs) 22:08, 11 April 2015 (UTC

As per the OED's answer to your previous question, it means "the end of [the use of] the frame relay protocol and encapsulation may seem about to happen"; what they presumably meant was that it may be the case that the use of Frame Relay will come to an end soon. AT&T still seems to offer it in the US, although the "Plan" tab on that page says that a VPN might be better for some (many?) customers, and their Network Services page doesn't mention Frame Relay (or ATM) unless you hover over "Network Services" in the page's menu. In addition, https://www.broadband-forum.org/about/forumhistory.php the Frame Relay Forum got merged into other forums several times], and the resulting group is now "the central organization driving broadband wireline solutions and empowering converged packet networks worldwide to better meet the needs of vendors, service providers and their customers.", and more IP and MPLS oriented, using ATM mainly as an IP transport in some cases (such as ADSL). Guy Harris (talk) 23:02, 11 April 2015 (UTC)[reply]

Plagiarism/Failure to Cite[edit]

The second paragraph of this article (beginning with "Network providers commonly implement Frame Relay for voice and data as an encapsulation..." is a word-for-word copy of a passage from page 128 of the book "Accessing the WAN. CCNA Exploration Companion Guide" by Bob Vachon and Rick Graziani, isbn: 978-1-58713-349-7, published 2008 by Cisco Press. — Preceding unsigned comment added by 75.134.224.214 (talk) 02:49, 21 August 2017 (UTC)[reply]

Proposed merge[edit]

Oppose. Delete instead. User:Kvng has proposed merging FRF.12 into this article, removing the WP:PROD placed there by User:Piotrus. However, there is nothing to merge. The FRF.12 article has no sources and is obviously original research. We don't merge content that is not according to policy. Delete FRF.12. —Prhartcom 23:07, 16 June 2016 (UTC)[reply]

There doesn't seem to be a policy as you describe. The best I could find is this discussion. Let me know if I'm missing something. I have always taken care to make sure that the material I merge in to an article is of similar or better quality. I think the strongest deletionist argument you can make make is that the material involved in the merge needs to be verifyable which is critically different form a demand that it be cited. Is the material cited? No. Can we find citations? Yes [1], [2], [3], [4]. I didn't actually mean to start an argument about whether this merge should be done, I thought it was a no-brainer. I put up the banners mostly as a reminder to myself to do the merge at some point. ~Kvng (talk) 23:23, 16 June 2016 (UTC)[reply]
Considering that this article has only two inline refs, merge would require substantial effort for verification. It is unlikely someone will do it. I have no problem leaving the merge notice for now, but if no action is taken for few months, AfD for this mess would be the next step. If User:Prhartcom where to start an AfD soon, I'd vote delete; this article does not meet criteria for stand alone articles in our project. PS. User:Kvng, what sources? You cite 4 manfucaturer documents, including a support forum and a manual. Those are primary/self-published at best. PPS. Actually, I got confused and thought about the Frame Relay article, which is pretty poor, lol. I realize we are talking about FRF.12. Dude, seriously, there are limits to the kind of garbage we can try to save, and once again I am concerned about you wasting community efforts through making me and others spend AfD time on such trash. For now I am going to be bold and redirect this here. Nothing to salvage from merge as the source has no references, and yours do not meet our requirements for WP:CITE/WP:RS. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:31, 17 June 2016 (UTC)[reply]
Primary sources are fine for this sort of thing and the Cisco sources are not exactly primary because Cisco didn't invent the technology, they implemented it and have a role teaching their users about it. As I said above, If you consider this to be a mess or garbage or whatever, you really need to get out more - a lot of articles on technical topics are in this shape or worse. That does not mean we should WP:DEMOLISH them. The disrespect you show to others work really annoys me. I am reverting your redirect. I routinely wait a year before acting on merge proposals - WP:NODEADLINE. I suspect you'll take this to AfD and then complain again that I'm wasting your time. ~Kvng (talk) 14:13, 17 June 2016 (UTC)[reply]
Kvng, it's okay. You don't appear to want the existance of the separate article, you proposed the merge, so go ahead and merge the few FRF.12 sentences into a new section of this article, providing cited sources. —Prhartcom 14:19, 17 June 2016 (UTC)[reply]
I intend to but, it may be next year. I have other merges to do. ~Kvng (talk) 14:32, 17 June 2016 (UTC)[reply]
Burying the material under a redirect is not helpful to readers or other editors who may have time to take care of this before I get back to it. Please leave FRF.12. If you are impatient about this, please do the merge yourself or take it to AfD. ~Kvng (talk) 14:38, 17 June 2016 (UTC)[reply]
We have a 2:1 editor majority opinion here that FRF.12 can be left as a redirect. Edit history is preserved there for you to merge it when you get around to it. I think it's a better compromise that wasting people's time on AfD. --Piotr Konieczny aka Prokonsul Piotrus| reply here 15:25, 17 June 2016 (UTC)[reply]

Thanks Prhartcom for performing the merge. I'm not sure why you also nominated FRF.12 for deletion though. ~Kvng (talk) 14:49, 19 June 2016 (UTC)[reply]

US specific information[edit]

This sentence is not true for the UK at least, probably not any of Europe as far as I know: "However many rural areas remain lacking DSL and cable modem services. In such cases, the least expensive type of non-dial-up connection remains a 64-kbit/s Frame Relay line."

Frame relay is out there in the Asia-Pacific Region and in Canada. Additionally, some ISPs might provide you with an MPLS network, but the local transport might still be frame relay. Bananabananabanana (talk) 02:36, 25 August 2019 (UTC)[reply]

What are the specific physical layers?[edit]

AFAICT, Frame Relay doesn't define the physical layers, only data link layer. However, the article says that F.R. operates on Layer 1 and 2 (physical and data link).

Perhaps some mention of where F.R. defines the physical layers, otherwise best just to say it operates on layer 2 only (Data Link). Chris Fletcher (talk) 05:07, 17 February 2019 (UTC)[reply]

I'm not sure what standards specify what "Frame Relay" is, but I.233 "Integrated Services Digital Network, General Structure and Service Capabilities, Frame Mode Bearer Services", says in section 4.2 "Normal procedures" that "On the user side of the S or T reference point, Recommendation I.430 or I.431 provides the layer 1 protocol for the U (user) and C (control) planes. The C-plane uses the D-channel with Recommendations Q.921 and Q.933 as the layer 2 and 3 protocols respectively", and in section 3.1 "General description" that "The U-plane procedures at layer 1 are based on Recommendations I.430/I.431. Layer 2 procedures are based on the core functions of Recommendation Q.922 (see § 3.1.1). These layer 2 core functions allow for the statistical multiplexing of user information flows immediately above layer 1 functions. This bearer service provides the bidirectional transfer of service data units (frames) from one S or T reference point to another with the order preserved."
I.430 and I.431 are ISDN BRI and PRI, respectively. Q.921 and Q.922 are what might be thought of as the "Frame Relay" protocol (at least by those of us who are developers for protocol analyzers :-)).
Q.921/Q.922 can probably run over any lower-level service that provides a bit stream, so it could probably be run over one or more time slots on a T-carrier or E-carrier line.
So I guess you could say it can run over ISDN's layer 1, and was perhaps originally specified to run over BRI or PRI but can run over other bit-stream services. While, in theory, the full set of specs for "Frame Relay" specify level 1 standards (ISDN), it's probably best to think of Frame Relay as a layer 2 standard running atop various layer 1 mechanisms, not all of which were specified by the original ITU-T "Frame Mode" recommendations. Guy Harris (talk) 09:38, 17 February 2019 (UTC)[reply]