RE: LLC Type 2 [7:8262]
On Fri, 15 Jun 2001, Howard C. Berkowitz wrote: > >-Original Message- > >From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > >Priscilla Oppenheimer > >Sent:Friday, June 15, 2001 11:28 AM > >To: [EMAIL PROTECTED] > >Subject: Re: LLC Type 2 [7:8262] > > > >VMS books were orange, as I recall!? > > Yes, and I still have a shelf full of them. Why not get rid of them? Orange? Hmm, ISTR a grey wall... Are you thinking of VMS5 or OpenVMS, maybe? -- "Someone approached me and asked me to teach a javascript course. I was about to decline, saying that my complete ignorance of the subject made me unsuitable, then I thought again, that maybe it doesn't, as driving people away from it is a desirable outcome." --Me Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8796&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: LLC Type 2 [7:8262]
>-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of >Priscilla Oppenheimer >Sent: Friday, June 15, 2001 11:28 AM >To:[EMAIL PROTECTED] >Subject: Re: LLC Type 2 [7:8262] > >VMS books were orange, as I recall!? Yes, and I still have a shelf full of them. Why not get rid of them? Well, let's see...HSRP is derived from a VaxCluster failover protocol, and there's more than a passing relationship between VMS and Windows NT. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8771&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: LLC Type 2 [7:8262]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Priscilla Oppenheimer Sent: Friday, June 15, 2001 11:28 AM To: [EMAIL PROTECTED] Subject:Re: LLC Type 2 [7:8262] VMS books were orange, as I recall!? Or maybe you are thinking of the convergence concurrence interface facility that mapped the red book to the yellow book. Red and yellow make orange. On the other hand, with electronic colors, we only have RGB, so who knows how you make orange in our industry? By the way, did you know that the first dictionary of the English Language, developed by Samuel Johnson and printed in 1755, defined network. The definition was: CL: one morning, Dr Johnson sat down to breakfast with his wife. He said something. She said something. One word led to another, and next thing they knew, they had a dictionary. :-> "Any thing reticulated, or decussated, at equal distances, with interstices between the intersections." CL: sounds dirty to me ;-> Forgot to use decaf today. The filters won't let this through anyway, probably. ;-) Priscilla At 11:13 AM 6/15/01, Howard C. Berkowitz wrote: > >Final results of some search: > > > >> >For information (using my father's notes) the CCITT > >> >books-of-recommendations' colors were the following: > >> >- green in 1972, > >> >- yellow in 1980, > >> >- red in 1984 > >> >- blue in 1988 (last 4-year-book). > >> > >> mutters because I distinctly remember an Orange Book. 1976? > > >Laughing...and let's not get confused with the NSA Rainbow Books, >where the Orange Book series deals with general and host security, >the Red Books with network security, the Chartreuse Books with >passwords, etc. > > > > >I have missed 1976 - cannot find it in notes and ITU-T site does not > >help either. Let's make it orange??? (Actually none of the recs from > >that book are valid any more, as opposed to recs from Blue, Red and > >Yellow books - which proves Orange simply must be older.) > > > >> > >> You are quite correct that there was evolution, including in the OSI > >> Reference Model itself. Especially important (don't have numbers in > >> front of me) were the Internal Organization of the Network Layer and > >> the OSI Routeing Framework. Once one understands these > >> specifications, many of the arguments over "what layer does XXX go > >> into" disappear, because the definitions of layers have evolved. > >> Look at ISO 8880 and 8881, CONS over Ethernet and CLNP over X.25. > >> > >Is the referred document a technical report?: > >ISO/IEC TR 9575:1995 Information technology -- Telecommunications and > >information exchange between systems -- OSI Routeing Framework > > >That certainly was the title, and it very well might have been a TR. >TR1 on functional profiles certainly is. > > > > >> > > > >> > > >> >> LLC 3 > >My 802.2 document is the original > >> IEEE hard cover specification. There's no question there were MIBs > >> for MAP/Enhanced Performance Architecture/etc.; I worked on > >> conformance testers for them, especially their management. I will > >> observe that most of these MIBs were not written as IETF-style SMI, > >> but OSI GDMO. > >> > >I have downloaded the latest ANSI/IEEE Std 802.2, 1998 Edition - and > >Type 3 is indeed specified there. > > > >Rita Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8752&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: LLC Type 2 [7:8262]
One place to look is Darren Spohn's Data Network Design, if you can find a copy. I bough one used through Amazon, and at that time there were a few more copies available. I have it on good authority that an new edition is on it's way ;-> Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kane, Christopher A. Sent: Wednesday, June 13, 2001 1:20 PM To: [EMAIL PROTECTED] Subject: RE: LLC Type 2 [7:8262] Where can you get manageable copies of the original specifications? I've only been in this environment for 3 1/2 years, I'm trying to grasp as much knowledge as possible as quickly as possible. Reading certification books seems like a good first step. My goal is to someday be precise to the point of being able to quote RFCs and original specs. Does anyone have any book recommendations or do I have to keep downloading RFCs? My reading list right now includes: Various Cisco Press books (taking CID test tomorrow) Computer Networks 3rd edition (Andrew S. Tanenbaum) Designing Routing and Switching Architectures for Enterprise Networks (Berkowitz) IPSEC (Doraswamy) Christopher A. Kane, CCNP/CCDA -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 3:19 PM To: [EMAIL PROTECTED] Subject: Re: LLC Type 2 [7:8262] >"Stephen Skinner" raised the interesting points, >So , > >the answer to your question`s seem to be . > >Yes if your doing a Cisco Exam > >No if your reading info from the CCO > >Yes/No depending on who you are talking too.. > >a Question has just popped into my head..."What else that we quote as >law (given to us from Cisco and other sources )in incorrect". > >now that i would like to know > >steve You've just crystallized in my mind the reason I'm always vaguely uncomfortable about the people that want more and more advanced Cisco certifications, as well as arguing the gospel according to various review books rather than the original specifications. There are definitely errors in Cisco material. In the past, certain training developers simply didn't want to change them "because it would confuse people." There are other reasons, significantly including that the average course or test developer is not a subject matter expert. Indeed, I know of firms to which Cisco outsourced course development which actively did not want subject matter experts writing courses, but instructional methodology people -- even if the subject matter expert was an experienced instructor and course developer. I literally got a downcheck in my performance review at Geotrain because I insisted on being a technical authority rather than managing external experts. If I were hiring someone for a network design role, much less product development, I'd be far less impressed by someone that had nine specialized CCIE certifications, than someone who had published in independent technical forums, could document real network design experience, etc. Nortel's certified architect program, among other things, requires candidates to document five networks they have designed, with their assumptions and design choices. The US military has had a lot of success with intensive training -- train like you fight, fight like you train. But there is a huge difference in correspondence to reality of something like the CCIE lab, and running tank battalions around the National Training Center at Fort Irwin. The CCIE lab has an artificially small number of routers; the NTC consciously outnumbers the US troops with people with home field advantage--but regards the experience first as learning and second as testing. > > >>From: "Priscilla Oppenheimer" >>Reply-To: "Priscilla Oppenheimer" >>To: [EMAIL PROTECTED] >>Subject: LLC Type 2 [7:8262] >>Date: Tue, 12 Jun 2001 19:15:33 -0400 >> >>I found myself writing this paragraph for a new writing project: >> >>When NetBEUI and SNA are used on Ethernet networks, they take advantage of >>the reliability of LLC Type 2. Because NetBEUI and SNA are legacy >>protocols, the use of LLC Type 2 is diminishing. However, it is still >>important to learn LLC Type 2 because WAN protocols, such as High-Level >>Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), >>also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is >>non-standard and is not based on LLC Type 2, however. Cisco's HDLC is >>connectionless.) >> >>Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other >>way around? Any other lies you can pinpoint in my paragraph? I know it's a >>bit awkward still. I will polish it. ;-) Thanks for your help! >> >>Priscilla &
Re: LLC Type 2 [7:8262]
VMS books were orange, as I recall!? Or maybe you are thinking of the convergence concurrence interface facility that mapped the red book to the yellow book. Red and yellow make orange. On the other hand, with electronic colors, we only have RGB, so who knows how you make orange in our industry? By the way, did you know that the first dictionary of the English Language, developed by Samuel Johnson and printed in 1755, defined network. The definition was: "Any thing reticulated, or decussated, at equal distances, with interstices between the intersections." Forgot to use decaf today. The filters won't let this through anyway, probably. ;-) Priscilla At 11:13 AM 6/15/01, Howard C. Berkowitz wrote: > >Final results of some search: > > > >> >For information (using my father's notes) the CCITT > >> >books-of-recommendations' colors were the following: > >> >- green in 1972, > >> >- yellow in 1980, > >> >- red in 1984 > >> >- blue in 1988 (last 4-year-book). > >> > >> mutters because I distinctly remember an Orange Book. 1976? > > >Laughing...and let's not get confused with the NSA Rainbow Books, >where the Orange Book series deals with general and host security, >the Red Books with network security, the Chartreuse Books with >passwords, etc. > > > > >I have missed 1976 - cannot find it in notes and ITU-T site does not > >help either. Let's make it orange??? (Actually none of the recs from > >that book are valid any more, as opposed to recs from Blue, Red and > >Yellow books - which proves Orange simply must be older.) > > > >> > >> You are quite correct that there was evolution, including in the OSI > >> Reference Model itself. Especially important (don't have numbers in > >> front of me) were the Internal Organization of the Network Layer and > >> the OSI Routeing Framework. Once one understands these > >> specifications, many of the arguments over "what layer does XXX go > >> into" disappear, because the definitions of layers have evolved. > >> Look at ISO 8880 and 8881, CONS over Ethernet and CLNP over X.25. > >> > >Is the referred document a technical report?: > >ISO/IEC TR 9575:1995 Information technology -- Telecommunications and > >information exchange between systems -- OSI Routeing Framework > > >That certainly was the title, and it very well might have been a TR. >TR1 on functional profiles certainly is. > > > > >> > > > >> > > >> >> LLC 3 > >My 802.2 document is the original > >> IEEE hard cover specification. There's no question there were MIBs > >> for MAP/Enhanced Performance Architecture/etc.; I worked on > >> conformance testers for them, especially their management. I will > >> observe that most of these MIBs were not written as IETF-style SMI, > >> but OSI GDMO. > >> > >I have downloaded the latest ANSI/IEEE Std 802.2, 1998 Edition - and > >Type 3 is indeed specified there. > > > >Rita Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8738&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
>Final results of some search: > >> >For information (using my father's notes) the CCITT >> >books-of-recommendations' colors were the following: >> >- green in 1972, >> >- yellow in 1980, >> >- red in 1984 >> >- blue in 1988 (last 4-year-book). >> >> mutters because I distinctly remember an Orange Book. 1976? Laughing...and let's not get confused with the NSA Rainbow Books, where the Orange Book series deals with general and host security, the Red Books with network security, the Chartreuse Books with passwords, etc. > >I have missed 1976 - cannot find it in notes and ITU-T site does not >help either. Let's make it orange??? (Actually none of the recs from >that book are valid any more, as opposed to recs from Blue, Red and >Yellow books - which proves Orange simply must be older.) > >> >> You are quite correct that there was evolution, including in the OSI >> Reference Model itself. Especially important (don't have numbers in >> front of me) were the Internal Organization of the Network Layer and >> the OSI Routeing Framework. Once one understands these >> specifications, many of the arguments over "what layer does XXX go >> into" disappear, because the definitions of layers have evolved. >> Look at ISO 8880 and 8881, CONS over Ethernet and CLNP over X.25. >> >Is the referred document a technical report?: >ISO/IEC TR 9575:1995 Information technology -- Telecommunications and >information exchange between systems -- OSI Routeing Framework That certainly was the title, and it very well might have been a TR. TR1 on functional profiles certainly is. > >> > > >> > >> >> LLC 3 >My 802.2 document is the original >> IEEE hard cover specification. There's no question there were MIBs >> for MAP/Enhanced Performance Architecture/etc.; I worked on >> conformance testers for them, especially their management. I will >> observe that most of these MIBs were not written as IETF-style SMI, >> but OSI GDMO. >> >I have downloaded the latest ANSI/IEEE Std 802.2, 1998 Edition - and >Type 3 is indeed specified there. > >Rita Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8704&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
Final results of some search: > >For information (using my father's notes) the CCITT > >books-of-recommendations' colors were the following: > >- green in 1972, > >- yellow in 1980, > >- red in 1984 > >- blue in 1988 (last 4-year-book). > > mutters because I distinctly remember an Orange Book. 1976? I have missed 1976 - cannot find it in notes and ITU-T site does not help either. Let's make it orange??? (Actually none of the recs from that book are valid any more, as opposed to recs from Blue, Red and Yellow books - which proves Orange simply must be older.) > > You are quite correct that there was evolution, including in the OSI > Reference Model itself. Especially important (don't have numbers in > front of me) were the Internal Organization of the Network Layer and > the OSI Routeing Framework. Once one understands these > specifications, many of the arguments over "what layer does XXX go > into" disappear, because the definitions of layers have evolved. > Look at ISO 8880 and 8881, CONS over Ethernet and CLNP over X.25. > Is the referred document a technical report?: ISO/IEC TR 9575:1995 Information technology -- Telecommunications and information exchange between systems -- OSI Routeing Framework > > > > > > >> LLC 3 My 802.2 document is the original > IEEE hard cover specification. There's no question there were MIBs > for MAP/Enhanced Performance Architecture/etc.; I worked on > conformance testers for them, especially their management. I will > observe that most of these MIBs were not written as IETF-style SMI, > but OSI GDMO. > I have downloaded the latest ANSI/IEEE Std 802.2, 1998 Edition - and Type 3 is indeed specified there. Rita Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8638&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
>This is quite interesting discussion going back into the roots of the >current networking (which is in many ways quite a useful exercise, yet >not performed often enough). I wish my father who was quite active in >these network-forming days could add his knowledgeable views here - >unfortunately, it is no more possible. At least I can add some notes >from his publications to (hopefully) enhance the discussion below: > >"Howard C. Berkowitz" wrote: > >> ITU-T didn't exist yet. CCITT was the ancestor, and its first X.25 >> standards were in the 1972 books (I forget the color now--probably >> yellow or orange). > >CCITT was converted to ITU-T in 1993 (March). Recommendations (they have >never used standard for their approved deliverables) before 1993, valid >ones, are still referred as CCITT. The newer ones have the ITU-T >denomination. > >For information (using my father's notes) the CCITT >books-of-recommendations' colors were the following: >- green in 1972, >- yellow in 1980, >- red in 1984 >- blue in 1988 (last 4-year-book). mutters because I distinctly remember an Orange Book. 1976? > >Currently they (ITU-T) may still refer to individual recommendations as >"white books" (which for us locally has very different connotation: "To >join or not to join the EU" ;-) I can't resist...perhaps someone in the Vast Listening Audience remembers the factoid that has been escaping me since my international relations classes 30 years ago. We speak a lot about "white papers." Around the turn of the 20th century, each Great Power issued diplomatic positions with a cover and/or paper of a certain color. White, I believe, was the British Foreign Office. The French might have been green. I simply don't remember the system, but there was one. Presumably any country that issued Black Books, but continued to use black ink, suffered at a significant diplomatic disadvantage. Anyone happen to remember the specific system? Even better yet, a good reference on diplomatic practice -- the differences between demarches, aide-memoires, ultimata, etc.? > >> That used LAP. The first commercial X.25 >> networks deployed in 1972, the first a banking network in Spain and >> then Telenet a few months afterward. >> >> LAP-B was in the X.25 1976 standards. > >At that time X.25 was not in compliance with then worked on OSI model. >But it changed a lot over time, in 1984 X.25 was a source for ISO 8208 >and nowadays it complies fully with bottom OSI reference model. It was much uglier than that. There are features in the OSI definition of the connection-oriented network service that were there simply because they were used in X.25, but they belonged at other OSI layers. The D-bit, for example, is clearly a transport function. You are quite correct that there was evolution, including in the OSI Reference Model itself. Especially important (don't have numbers in front of me) were the Internal Organization of the Network Layer and the OSI Routeing Framework. Once one understands these specifications, many of the arguments over "what layer does XXX go into" disappear, because the definitions of layers have evolved. Look at ISO 8880 and 8881, CONS over Ethernet and CLNP over X.25. > > > >> LLC 3 was developed by the MAP project, primarily General Motors, and >> I don't think it ever became a full IEEE specification. It certainly >> isn't in my copy of 802.2. >> >This is interesting, because there are approved IEEE (and endorsed >ISO/IEC) stnds on management objects and PICS proforma for Type 3. I >will check the latest 802.2 version once I use up the new wave in IEEE >allowing us to download all the 802 standards. Indeed, it might have been added. My 802.2 document is the original IEEE hard cover specification. There's no question there were MIBs for MAP/Enhanced Performance Architecture/etc.; I worked on conformance testers for them, especially their management. I will observe that most of these MIBs were not written as IETF-style SMI, but OSI GDMO. > >BTW looking through the IEEE standards status report, I have come across >even another LLC Type - Type 4 (1991): > >"Supplement to 802.2, Information Processing Systems >- Local Area Networks: Logical Link Control (LLC) Type 4 >High Speed, High Performance Operation " > >But status sweeps my expectations away: >"Status: Withdrawn PAR. Standards project no longer endorsed >by the IEEE. " > > >Rita Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8328&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
This whole conversation rocks.. For the record, I'm not a Cisco zombie. I read and learn what I can using the internet and books for exams, but I in no way take this information to be "law". For that matter I just had a quite interesting discussion with my brother-in-law about science, and how a true scientist is willing to realize that science itself is a chaning, adapting set of rules. (i.e. how Einstein's physics showed the flaws in Newtonian physics, which was "the law" for hundreds of years) Same with ones understanding of networking, especially if a majority of that networking knowledge was gained through study books from one or two sources With something like the history of LLC or SDLC, I can see how it would literally take someone who lived it to give concrete evidence on how things came to be.. Very good discussion! Mike W. "Howard C. Berkowitz" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > My own solutions may not fit all. I have several bookcases full of > hard copies of RFCs, but, these days, I print a hard copy of a draft > or RFC primarily to read it through the first time. When I refer to > it, I most often just download a copy -- with a fast link, it's > actually quicker than digging through directories. I also am on a > number of IETF and operational (e.g., NANOG and RIPE) lists, and get > a lot of the gist of things through constant discussion there. I do > have a large number of books, but I tend to use them either for > business case analysis or getting oriented to the specifications. > > Of course, experience helps. I'm honestly not trying to show off to > say that I can't think when I've used a subnet calculator. For many > routine problems, I can do the subnetting/supernetting in my head, > or, if I need to be more precise, I write the relevant address parts > out in binary, do calculations there, and convert back to dotted > decimal. There are some tricks that help, such as having memorized > certain mask patterns, but the real secret, as many have already > said, is think binary. > > There are tricks to RFC reading. If there is an "applicability > statement" for the protocol, read it before the protocol > specification. Also, expect that the first few chapters of a protocol > specification will be much easier reading than the detailed > specification meant for implementer/programmers. At some point, you > really need a computer science background in data structures, > automata/finite state theory, etc., to internalize the > specifications. You probably also need to have a good sense of > interprocess communication and operating system design to understand > what timers are doing and how failover works. > > There are some wonderful books that are probably out of print, such > as Mike Padlipsky's "The Elements of Networking Style." I'm not > being completely facetious to say that British comedy often puts me > into the right mindset to do protocol design and analysis. > > > >Where can you get manageable copies of the original specifications? > >I've only been in this environment for 3 1/2 years, I'm trying to > >grasp as much knowledge as possible as quickly as possible. Reading > >certification books seems like a good first step. My goal is to > >someday be precise to the point of being able to quote RFCs and > >original specs. Does anyone have any book recommendations or do I > >have to keep downloading RFCs? > > > >My reading list right now includes: > > > >Various Cisco Press books (taking CID test tomorrow) > >Computer Networks 3rd edition (Andrew S. Tanenbaum) > >Designing Routing and Switching Architectures for Enterprise > >Networks (Berkowitz) > >IPSEC (Doraswamy) > > > > > >Christopher A. Kane, CCNP/CCDA > > > > > > > >-Original Message- > >From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, June 13, 2001 3:19 PM > >To: [EMAIL PROTECTED] > >Subject: Re: LLC Type 2 [7:8262] > > > > > > >"Stephen Skinner" raised the interesting points, > > > > > > > > >So , > >> > >>the answer to your question`s seem to be . > >> > >>Yes if your doing a Cisco Exam > >> > >>No if your reading info from the CCO > >> > >>Yes/No depending on who you are talking too.. > >> > >>a Question has just popped into my head..."What else that we quote as > >>law (given to us from Cisco and other sources )in incorrect". > >> > >>now that i would lik
RE: LLC Type 2 [7:8262]
My own solutions may not fit all. I have several bookcases full of hard copies of RFCs, but, these days, I print a hard copy of a draft or RFC primarily to read it through the first time. When I refer to it, I most often just download a copy -- with a fast link, it's actually quicker than digging through directories. I also am on a number of IETF and operational (e.g., NANOG and RIPE) lists, and get a lot of the gist of things through constant discussion there. I do have a large number of books, but I tend to use them either for business case analysis or getting oriented to the specifications. Of course, experience helps. I'm honestly not trying to show off to say that I can't think when I've used a subnet calculator. For many routine problems, I can do the subnetting/supernetting in my head, or, if I need to be more precise, I write the relevant address parts out in binary, do calculations there, and convert back to dotted decimal. There are some tricks that help, such as having memorized certain mask patterns, but the real secret, as many have already said, is think binary. There are tricks to RFC reading. If there is an "applicability statement" for the protocol, read it before the protocol specification. Also, expect that the first few chapters of a protocol specification will be much easier reading than the detailed specification meant for implementer/programmers. At some point, you really need a computer science background in data structures, automata/finite state theory, etc., to internalize the specifications. You probably also need to have a good sense of interprocess communication and operating system design to understand what timers are doing and how failover works. There are some wonderful books that are probably out of print, such as Mike Padlipsky's "The Elements of Networking Style." I'm not being completely facetious to say that British comedy often puts me into the right mindset to do protocol design and analysis. >Where can you get manageable copies of the original specifications? >I've only been in this environment for 3 1/2 years, I'm trying to >grasp as much knowledge as possible as quickly as possible. Reading >certification books seems like a good first step. My goal is to >someday be precise to the point of being able to quote RFCs and >original specs. Does anyone have any book recommendations or do I >have to keep downloading RFCs? > >My reading list right now includes: > >Various Cisco Press books (taking CID test tomorrow) >Computer Networks 3rd edition (Andrew S. Tanenbaum) >Designing Routing and Switching Architectures for Enterprise >Networks (Berkowitz) >IPSEC (Doraswamy) > > >Christopher A. Kane, CCNP/CCDA > > > >-Original Message- >From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, June 13, 2001 3:19 PM >To: [EMAIL PROTECTED] >Subject: Re: LLC Type 2 [7:8262] > > > >"Stephen Skinner" raised the interesting points, > > > > >So , >> >>the answer to your question`s seem to be . >> >>Yes if your doing a Cisco Exam >> >>No if your reading info from the CCO >> >>Yes/No depending on who you are talking too.. >> >>a Question has just popped into my head..."What else that we quote as >>law (given to us from Cisco and other sources )in incorrect". >> >>now that i would like to know >> >>steve > > >You've just crystallized in my mind the reason I'm always vaguely >uncomfortable about the people that want more and more advanced Cisco >certifications, as well as arguing the gospel according to various >review books rather than the original specifications. > >There are definitely errors in Cisco material. In the past, certain >training developers simply didn't want to change them "because it >would confuse people." There are other reasons, significantly >including that the average course or test developer is not a subject >matter expert. Indeed, I know of firms to which Cisco outsourced >course development which actively did not want subject matter experts >writing courses, but instructional methodology people -- even if the >subject matter expert was an experienced instructor and course >developer. I literally got a downcheck in my performance review at >Geotrain because I insisted on being a technical authority rather >than managing external experts. > >If I were hiring someone for a network design role, much less product >development, I'd be far less impressed by someone that had nine >specialized CCIE certifications, than someone who had published in >independent technical forums, could document real network design >
Re: LLC Type 2 [7:8262]
At 03:18 PM 6/13/01, Howard C. Berkowitz wrote: > >"Stephen Skinner" raised the interesting points, > > > > >So , > > > >the answer to your question`s seem to be . > > > >Yes if your doing a Cisco Exam > > > >No if your reading info from the CCO > > > >Yes/No depending on who you are talking too.. > > > >a Question has just popped into my head..."What else that we quote as > >law (given to us from Cisco and other sources )in incorrect". > > > >now that i would like to know > > > >steve > > >You've just crystallized in my mind the reason I'm always vaguely >uncomfortable about the people that want more and more advanced Cisco >certifications, as well as arguing the gospel according to various >review books rather than the original specifications. > >There are definitely errors in Cisco material. In the past, certain >training developers simply didn't want to change them "because it >would confuse people." There are other reasons, significantly >including that the average course or test developer is not a subject >matter expert. Indeed, I know of firms to which Cisco outsourced >course development which actively did not want subject matter experts >writing courses, but instructional methodology people Yuck! I despised this aspect of training at Cisco. It's the number one reason I'm not there any more. Cisco thought a course developer could write on any topic as long as there were SMEs available. That's why we have so many dribble bits in Cisco courses. Now, some of the developers weren't like this, of course, but it was the management philosophy. > -- even if the >subject matter expert was an experienced instructor and course >developer. I literally got a downcheck in my performance review at >Geotrain because I insisted on being a technical authority rather >than managing external experts. > >If I were hiring someone for a network design role, much less product >development, I'd be far less impressed by someone that had nine >specialized CCIE certifications, than someone who had published in >independent technical forums, could document real network design >experience, etc. Nortel's certified architect program, among other >things, requires candidates to document five networks they have >designed, with their assumptions and design choices. > >The US military has had a lot of success with intensive training -- >train like you fight, fight like you train. But there is a huge >difference in correspondence to reality of something like the CCIE >lab, and running tank battalions around the National Training Center >at Fort Irwin. The CCIE lab has an artificially small number of >routers; the NTC consciously outnumbers the US troops with people >with home field advantage--but regards the experience first as >learning and second as testing. > > > > > > >>From: "Priscilla Oppenheimer" > >>Reply-To: "Priscilla Oppenheimer" > >>To: [EMAIL PROTECTED] > >>Subject: LLC Type 2 [7:8262] > >>Date: Tue, 12 Jun 2001 19:15:33 -0400 > >> > >>I found myself writing this paragraph for a new writing project: > >> > >>When NetBEUI and SNA are used on Ethernet networks, they take advantage of > >>the reliability of LLC Type 2. Because NetBEUI and SNA are legacy > >>protocols, the use of LLC Type 2 is diminishing. However, it is still > >>important to learn LLC Type 2 because WAN protocols, such as High-Level > >>Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), > >>also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is > >>non-standard and is not based on LLC Type 2, however. Cisco's HDLC is > >>connectionless.) > >> > >>Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other > >>way around? Any other lies you can pinpoint in my paragraph? I know it's a > >>bit awkward still. I will polish it. ;-) Thanks for your help! > >> > >>Priscilla > >> > >>Thanks for your help! > >> > >>Priscilla > >> > >> > >> > >>Priscilla Oppenheimer > >>http://www.priscilla.com > >_ > >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8401&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: LLC Type 2 [7:8262]
Where can you get manageable copies of the original specifications? I've only been in this environment for 3 1/2 years, I'm trying to grasp as much knowledge as possible as quickly as possible. Reading certification books seems like a good first step. My goal is to someday be precise to the point of being able to quote RFCs and original specs. Does anyone have any book recommendations or do I have to keep downloading RFCs? My reading list right now includes: Various Cisco Press books (taking CID test tomorrow) Computer Networks 3rd edition (Andrew S. Tanenbaum) Designing Routing and Switching Architectures for Enterprise Networks (Berkowitz) IPSEC (Doraswamy) Christopher A. Kane, CCNP/CCDA -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 3:19 PM To: [EMAIL PROTECTED] Subject: Re: LLC Type 2 [7:8262] >"Stephen Skinner" raised the interesting points, >So , > >the answer to your question`s seem to be . > >Yes if your doing a Cisco Exam > >No if your reading info from the CCO > >Yes/No depending on who you are talking too.. > >a Question has just popped into my head..."What else that we quote as >law (given to us from Cisco and other sources )in incorrect". > >now that i would like to know > >steve You've just crystallized in my mind the reason I'm always vaguely uncomfortable about the people that want more and more advanced Cisco certifications, as well as arguing the gospel according to various review books rather than the original specifications. There are definitely errors in Cisco material. In the past, certain training developers simply didn't want to change them "because it would confuse people." There are other reasons, significantly including that the average course or test developer is not a subject matter expert. Indeed, I know of firms to which Cisco outsourced course development which actively did not want subject matter experts writing courses, but instructional methodology people -- even if the subject matter expert was an experienced instructor and course developer. I literally got a downcheck in my performance review at Geotrain because I insisted on being a technical authority rather than managing external experts. If I were hiring someone for a network design role, much less product development, I'd be far less impressed by someone that had nine specialized CCIE certifications, than someone who had published in independent technical forums, could document real network design experience, etc. Nortel's certified architect program, among other things, requires candidates to document five networks they have designed, with their assumptions and design choices. The US military has had a lot of success with intensive training -- train like you fight, fight like you train. But there is a huge difference in correspondence to reality of something like the CCIE lab, and running tank battalions around the National Training Center at Fort Irwin. The CCIE lab has an artificially small number of routers; the NTC consciously outnumbers the US troops with people with home field advantage--but regards the experience first as learning and second as testing. > > >>From: "Priscilla Oppenheimer" >>Reply-To: "Priscilla Oppenheimer" >>To: [EMAIL PROTECTED] >>Subject: LLC Type 2 [7:8262] >>Date: Tue, 12 Jun 2001 19:15:33 -0400 >> >>I found myself writing this paragraph for a new writing project: >> >>When NetBEUI and SNA are used on Ethernet networks, they take advantage of >>the reliability of LLC Type 2. Because NetBEUI and SNA are legacy >>protocols, the use of LLC Type 2 is diminishing. However, it is still >>important to learn LLC Type 2 because WAN protocols, such as High-Level >>Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), >>also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is >>non-standard and is not based on LLC Type 2, however. Cisco's HDLC is >>connectionless.) >> >>Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other >>way around? Any other lies you can pinpoint in my paragraph? I know it's a >>bit awkward still. I will polish it. ;-) Thanks for your help! >> >>Priscilla >> >>Thanks for your help! >> >>Priscilla >> >> >> >>Priscilla Oppenheimer >>http://www.priscilla.com >_ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8402&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
>"Stephen Skinner" raised the interesting points, >So , > >the answer to your question`s seem to be . > >Yes if your doing a Cisco Exam > >No if your reading info from the CCO > >Yes/No depending on who you are talking too.. > >a Question has just popped into my head..."What else that we quote as >law (given to us from Cisco and other sources )in incorrect". > >now that i would like to know > >steve You've just crystallized in my mind the reason I'm always vaguely uncomfortable about the people that want more and more advanced Cisco certifications, as well as arguing the gospel according to various review books rather than the original specifications. There are definitely errors in Cisco material. In the past, certain training developers simply didn't want to change them "because it would confuse people." There are other reasons, significantly including that the average course or test developer is not a subject matter expert. Indeed, I know of firms to which Cisco outsourced course development which actively did not want subject matter experts writing courses, but instructional methodology people -- even if the subject matter expert was an experienced instructor and course developer. I literally got a downcheck in my performance review at Geotrain because I insisted on being a technical authority rather than managing external experts. If I were hiring someone for a network design role, much less product development, I'd be far less impressed by someone that had nine specialized CCIE certifications, than someone who had published in independent technical forums, could document real network design experience, etc. Nortel's certified architect program, among other things, requires candidates to document five networks they have designed, with their assumptions and design choices. The US military has had a lot of success with intensive training -- train like you fight, fight like you train. But there is a huge difference in correspondence to reality of something like the CCIE lab, and running tank battalions around the National Training Center at Fort Irwin. The CCIE lab has an artificially small number of routers; the NTC consciously outnumbers the US troops with people with home field advantage--but regards the experience first as learning and second as testing. > > >>From: "Priscilla Oppenheimer" >>Reply-To: "Priscilla Oppenheimer" >>To: [EMAIL PROTECTED] >>Subject: LLC Type 2 [7:8262] >>Date: Tue, 12 Jun 2001 19:15:33 -0400 >> >>I found myself writing this paragraph for a new writing project: >> >>When NetBEUI and SNA are used on Ethernet networks, they take advantage of >>the reliability of LLC Type 2. Because NetBEUI and SNA are legacy >>protocols, the use of LLC Type 2 is diminishing. However, it is still >>important to learn LLC Type 2 because WAN protocols, such as High-Level >>Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), >>also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is >>non-standard and is not based on LLC Type 2, however. Cisco's HDLC is >>connectionless.) >> >>Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other >>way around? Any other lies you can pinpoint in my paragraph? I know it's a >>bit awkward still. I will polish it. ;-) Thanks for your help! >> >>Priscilla >> >>Thanks for your help! >> >>Priscilla >> >> >> >>Priscilla Oppenheimer >>http://www.priscilla.com >_ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8391&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
So , the answer to your question`s seem to be . Yes if your doing a Cisco Exam No if your reading info from the CCO Yes/No depending on who you are talking too.. a Question has just popped into my head..."What else that we quote as law (given to us from Cisco and other sources )in incorrect". now that i would like to know steve >From: "Priscilla Oppenheimer" >Reply-To: "Priscilla Oppenheimer" >To: [EMAIL PROTECTED] >Subject: LLC Type 2 [7:8262] >Date: Tue, 12 Jun 2001 19:15:33 -0400 > >I found myself writing this paragraph for a new writing project: > >When NetBEUI and SNA are used on Ethernet networks, they take advantage of >the reliability of LLC Type 2. Because NetBEUI and SNA are legacy >protocols, the use of LLC Type 2 is diminishing. However, it is still >important to learn LLC Type 2 because WAN protocols, such as High-Level >Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), >also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is >non-standard and is not based on LLC Type 2, however. Cisco's HDLC is >connectionless.) > >Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other >way around? Any other lies you can pinpoint in my paragraph? I know it's a >bit awkward still. I will polish it. ;-) Thanks for your help! > >Priscilla > >Thanks for your help! > >Priscilla > > > >Priscilla Oppenheimer >http://www.priscilla.com _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8382&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
This is quite interesting discussion going back into the roots of the current networking (which is in many ways quite a useful exercise, yet not performed often enough). I wish my father who was quite active in these network-forming days could add his knowledgeable views here - unfortunately, it is no more possible. At least I can add some notes from his publications to (hopefully) enhance the discussion below: "Howard C. Berkowitz" wrote: > ITU-T didn't exist yet. CCITT was the ancestor, and its first X.25 > standards were in the 1972 books (I forget the color now--probably > yellow or orange). CCITT was converted to ITU-T in 1993 (March). Recommendations (they have never used standard for their approved deliverables) before 1993, valid ones, are still referred as CCITT. The newer ones have the ITU-T denomination. For information (using my father's notes) the CCITT books-of-recommendations' colors were the following: - green in 1972, - yellow in 1980, - red in 1984 - blue in 1988 (last 4-year-book). Currently they (ITU-T) may still refer to individual recommendations as "white books" (which for us locally has very different connotation: "To join or not to join the EU" ;-) > That used LAP. The first commercial X.25 > networks deployed in 1972, the first a banking network in Spain and > then Telenet a few months afterward. > > LAP-B was in the X.25 1976 standards. At that time X.25 was not in compliance with then worked on OSI model. But it changed a lot over time, in 1984 X.25 was a source for ISO 8208 and nowadays it complies fully with bottom OSI reference model. > > LLC 3 was developed by the MAP project, primarily General Motors, and > I don't think it ever became a full IEEE specification. It certainly > isn't in my copy of 802.2. > This is interesting, because there are approved IEEE (and endorsed ISO/IEC) stnds on management objects and PICS proforma for Type 3. I will check the latest 802.2 version once I use up the new wave in IEEE allowing us to download all the 802 standards. BTW looking through the IEEE standards status report, I have come across even another LLC Type - Type 4 (1991): "Supplement to 802.2, Information Processing Systems - Local Area Networks: Logical Link Control (LLC) Type 4 High Speed, High Performance Operation " But status sweeps my expectations away: "Status: Withdrawn PAR. Standards project no longer endorsed by the IEEE. " Rita Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8325&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
>Fresh from reading for my Support exam from Cisco Press CIT SDLC is >the granddaddy of them all. created in the mid-1970's to transport >SNA. ISO modified SDLC to create HDLC. Then ITU-T modified HDLC to create >LAP, then later, LAPB. IEEE modified HDLC to get 802.2, which is also known >as LLC, of which there are 3 types: Type 1 a connectionless version, Type 2 >a connection-oriented version, and Type 3 an acknowledged connectionless >version. Other than for Cisco tests, I'd be hesitant to take Cisco Press as gospel. That time sequence doesn't sound right -- indeed, the organizations are wrong. I do have some personal experience with these. Ideally, one would go back to the original standards documents, or at least some textbooks from the early 70's. Cypser would be one endorsed by IBM, or I have the original IBM Systems Journal issue on SNA somewhere here. An author such as Priscilla could probably check with some of the original authors (at least the ones still around) -- I ran into Hal Folts a couple of months ago. I first installed SNA in 1974, which included SDLC. ITU-T didn't exist yet. CCITT was the ancestor, and its first X.25 standards were in the 1972 books (I forget the color now--probably yellow or orange). That used LAP. The first commercial X.25 networks deployed in 1972, the first a banking network in Spain and then Telenet a few months afterward. I attended Federal Telecommunications Standards Committee meetings in 1976-1980 or so, where we worked on the ADCCP extensions to HDLC. No one particularly assumed an SDLC heritage, and indeed very carefully used different terminology and bit encodings. LAP-B was in the X.25 1976 standards. IEEE originally was going to accept Ethernet, which didn't have an LLC equivalent. IBM's proposal to standardize token ring originally suggested that everything have the equivalent of LLC2, making everything reliable like SDLC. The compromise was to create connectionless LLC1 and connection-oriented LLC2. LLC 3 was developed by the MAP project, primarily General Motors, and I don't think it ever became a full IEEE specification. It certainly isn't in my copy of 802.2. > >NetBEUI and SNA both need the reliability of LLC Type 2. I wouldn't say >"Because NetBEUI and SNA are legacy, the use of LLC Type 2 is >diminishing"..I would say "Because reliability is more frequently left >to higher layer protocols, such as TCP, the need for the reliable LLC Type 2 >is diminishing" hehe =) > >I don't know if NetBEUI is a good choice to use in this example. Perhaps >NetBIOS would be a better choice.. Check out: > >http://ourworld.compuserve.com/homepages/TimothyDEvans/intro.htm >http://www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html >http://www.windowsitlibrary.com/Content/386/10/2.html > >(watch for wrap).. These pages have some info about NetBEUI/BIOS >from the sounds of it NetBEUI *is* a Connection-Oriented transport layer >protocol, in which case it would NOT need the LLC Type 2 reliability, while >the older NetBIOS a Connectionless transport layer procotol that could >indeed benefit from the use of LLC Type 2 But I can't say for sure >=) > >Hope this helps! Good luck on your writing! > >Mike W. > > >"Priscilla Oppenheimer" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> I found myself writing this paragraph for a new writing project: >> >> When NetBEUI and SNA are used on Ethernet networks, they take advantage of >> the reliability of LLC Type 2. Because NetBEUI and SNA are legacy >> protocols, the use of LLC Type 2 is diminishing. However, it is still >> important to learn LLC Type 2 because WAN protocols, such as High-Level >> Data Link Control (HDLC) and Link Access Procedure on the D Channel >(LAPD), >> also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is >> non-standard and is not based on LLC Type 2, however. Cisco's HDLC is >> connectionless.) >> >> Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the >other >> way around? Any other lies you can pinpoint in my paragraph? I know it's a >> bit awkward still. I will polish it. ;-) Thanks for your help! >> >> Priscilla >> >> Thanks for your help! >> >> Priscilla >> >> >> >> Priscilla Oppenheimer >> http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8313&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
Fresh from reading for my Support exam from Cisco Press CIT SDLC is the granddaddy of them all. created in the mid-1970's to transport SNA. ISO modified SDLC to create HDLC. Then ITU-T modified HDLC to create LAP, then later, LAPB. IEEE modified HDLC to get 802.2, which is also known as LLC, of which there are 3 types: Type 1 a connectionless version, Type 2 a connection-oriented version, and Type 3 an acknowledged connectionless version. NetBEUI and SNA both need the reliability of LLC Type 2. I wouldn't say "Because NetBEUI and SNA are legacy, the use of LLC Type 2 is diminishing"..I would say "Because reliability is more frequently left to higher layer protocols, such as TCP, the need for the reliable LLC Type 2 is diminishing" hehe =) I don't know if NetBEUI is a good choice to use in this example. Perhaps NetBIOS would be a better choice.. Check out: http://ourworld.compuserve.com/homepages/TimothyDEvans/intro.htm http://www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html http://www.windowsitlibrary.com/Content/386/10/2.html (watch for wrap).. These pages have some info about NetBEUI/BIOS from the sounds of it NetBEUI *is* a Connection-Oriented transport layer protocol, in which case it would NOT need the LLC Type 2 reliability, while the older NetBIOS a Connectionless transport layer procotol that could indeed benefit from the use of LLC Type 2 But I can't say for sure =) Hope this helps! Good luck on your writing! Mike W. "Priscilla Oppenheimer" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I found myself writing this paragraph for a new writing project: > > When NetBEUI and SNA are used on Ethernet networks, they take advantage of > the reliability of LLC Type 2. Because NetBEUI and SNA are legacy > protocols, the use of LLC Type 2 is diminishing. However, it is still > important to learn LLC Type 2 because WAN protocols, such as High-Level > Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), > also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is > non-standard and is not based on LLC Type 2, however. Cisco's HDLC is > connectionless.) > > Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other > way around? Any other lies you can pinpoint in my paragraph? I know it's a > bit awkward still. I will polish it. ;-) Thanks for your help! > > Priscilla > > Thanks for your help! > > Priscilla > > > > Priscilla Oppenheimer > http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8300&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
First, I'm going to take issue with what I consider an urban legend that HDLC was based on SDLC. SDLC was first available in the first SNA release in 1973. The HDLC family was the basis of the X.25 link standards, including LAP in the 1972 CCITT specifications. But there was quite bitter feeling between IBM and the CCITT group developing the HDLC family. It's fair to say that HDLC and SDLC were based on contemporaneous work on bit-oriented data link protocols. Second, HDLC was never intended as a standalone protocol, but as a family of protocols that could be customized for applications. The fullest standards based HDLC specification I ever saw was ANSI's Advanced Data Communications Control Protocol (ADCCP), which I don't think ever was deployed. The idea of an unreliable link was quite alien to CCITT, and indeed was not part of the original OSI specification, ISO 7498, which was formalized in 1984. George Orwell fans, make whatever observations you wish. Connectionless communications are an annex to ISO 7498. Yes, I know that connectionless doesn't necessarily mean unreliable, as in LLC3 or things that just don't quite fit the model, such as OSI Fast Select or AppleTalk Transaction Protocol. Roughly: IBM CCITT/ISO DIX Ethernet HDLC IEEE 802 | v LAP | SDLC v . LAP-B IBM TR Proposal LLC 1 and 2 LAP-D LLC3 LAP-F >Priscilla, > >The only reading I have done on the LLC2 standard is from a book written by >Roosevelt Giles. From reading the book I got the impression that LLC was a >subset of HDLC and it was based on HDLC standard not the other way around. >I would have to respectfully disagree with the statement that hdlc and lapd >are based on LLC2. But I wouldn't put my career on it. I would also mention >the reliability factor is because it is an acknowledged connection-oriented >service versus LLC type 1 is connectionless. Is this part of the Top down >network design volume 2 edition. If it is please let us know the due date >cuz its gonna sellout fast. > >Hope this helps > >George, Head Janitor, CCNA CCDA >Cisco Systems > > >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> I found myself writing this paragraph for a new writing project: >> >> When NetBEUI and SNA are used on Ethernet networks, they take advantage of >> the reliability of LLC Type 2. Because NetBEUI and SNA are legacy >> protocols, the use of LLC Type 2 is diminishing. However, it is still >> important to learn LLC Type 2 because WAN protocols, such as High-Level >> Data Link Control (HDLC) and Link Access Procedure on the D Channel >(LAPD), >> also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is >> non-standard and is not based on LLC Type 2, however. Cisco's HDLC is >> connectionless.) >> >> Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the >other >> way around? Any other lies you can pinpoint in my paragraph? I know it's a >> bit awkward still. I will polish it. ;-) Thanks for your help! >> >> Priscilla >> >> Thanks for your help! >> >> Priscilla >> >> >> >> Priscilla Oppenheimer >> http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8294&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: LLC Type 2 [7:8262]
Priscilla, The only reading I have done on the LLC2 standard is from a book written by Roosevelt Giles. From reading the book I got the impression that LLC was a subset of HDLC and it was based on HDLC standard not the other way around. I would have to respectfully disagree with the statement that hdlc and lapd are based on LLC2. But I wouldn't put my career on it. I would also mention the reliability factor is because it is an acknowledged connection-oriented service versus LLC type 1 is connectionless. Is this part of the Top down network design volume 2 edition. If it is please let us know the due date cuz its gonna sellout fast. Hope this helps George, Head Janitor, CCNA CCDA Cisco Systems ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I found myself writing this paragraph for a new writing project: > > When NetBEUI and SNA are used on Ethernet networks, they take advantage of > the reliability of LLC Type 2. Because NetBEUI and SNA are legacy > protocols, the use of LLC Type 2 is diminishing. However, it is still > important to learn LLC Type 2 because WAN protocols, such as High-Level > Data Link Control (HDLC) and Link Access Procedure on the D Channel (LAPD), > also known as ITU-T Q.921, are based on LLC Type 2. (Cisco's HDLC is > non-standard and is not based on LLC Type 2, however. Cisco's HDLC is > connectionless.) > > Do I have it backwards? Are HDLC and LAPD based on LLC2, or is it the other > way around? Any other lies you can pinpoint in my paragraph? I know it's a > bit awkward still. I will polish it. ;-) Thanks for your help! > > Priscilla > > Thanks for your help! > > Priscilla > > > > Priscilla Oppenheimer > http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8283&t=8262 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]