home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dcom / isdn / 1198 < prev    next >
Encoding:
Text File  |  1993-01-21  |  3.2 KB  |  66 lines
  1. Newsgroups: comp.dcom.isdn
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!cos!cos!bob1
  3. From: bob1@cos.com (Bob Blackshaw)
  4. Subject: Re: BONDING and T1 Letter Ballot 317
  5. Message-ID: <bob1.727625771@cos>
  6. Organization: Corporation for Open Systems
  7. References: <Kevin.Kershaw.3@StPaul.NCR.COM> <1993Jan19.075543.16763W@lumina.edb.tih.no> <1993Jan19.135401.21097@cbfsb.cb.att.com> <1993Jan20.132319.10075W@lumina.edb.tih.no>
  8. Distribution: world 
  9. Date: Thu, 21 Jan 1993 14:16:11 GMT
  10. Lines: 54
  11.  
  12. In <1993Jan20.132319.10075W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
  13.  
  14. >In article <1993Jan19.135401.21097@cbfsb.cb.att.com>, deej@cbnewsf.cb.att.com 
  15. >(david.g.lewis) writes:
  16.  
  17. >> [...] There's a feeling among some in the industry, however,
  18. >>that (a) for a BRI, 2B is a useful bandwidth that is not supported by any H
  19. >>channel, and (b) limiting to 384 and 1536 kb/s is insufficiently flexible
  20. >>for user applications, and allowing NxDS0 where N is any integer from 2 to
  21. >>24 or 30/31 (on PRI, at least) is a useful and necessary capability.
  22.  
  23. >In the bluebooks, there IS a 2*64 kbit option (table 4-6 and 4-8/Q.931). 
  24. >Yes, I know that there is a difference between 1*128 and 2*64, but for many
  25. >purposes the existing standard would be good enough, and the justification
  26. >for inventing a different wheel rather weak.
  27.  
  28. >Disclaimer: I do not know anything about the '92 edition, so things may
  29. >have changed there. Further, I am not sufficiently deep into the lower 
  30. >layers to see all the consequences of the "Restricted Differential Time 
  31. >Delay" (which allows the two 64 kbit streams to be out of synchronization 
  32. >by a certain amount).
  33.  
  34. I'm always tempted to call this R2D2 :-), however, not being in the
  35. meetings (I got out of that back in 87), a look at the S/T Layer 1
  36. frame structure leads me to believe that the ~50 ms factor in RDTD
  37. is simply a result of the separation of the B-channel octets in
  38. each frame. You will see that the greatest separation occurs between
  39. the first pair of B-channel octets and amounts to 5 bits. Now a 48
  40. bit frame at 125 ms approximates a bit time of 5 ms, ergo 5x5=25.
  41. Given a frame at either end of any connection 2x25=50. At least
  42. that's how I believe it works.
  43.  
  44. Now, whatever type of state machine you are using at layer 2 should
  45. be able to accomodate this slight out of sync condition with some
  46. form of simple buffering (or elastic store, if you prefer that term).
  47. If I'm wrong will someone who was at the meetings please correct me.
  48.  
  49. >Yet, many wheels have been invented simply because the inventor overlooked
  50. >existing solutions. Basing a 2B solution on existing standards may be a
  51. >good idea. I don't think it is essential to provide 3B, 4B, 5B,...29B -
  52. >after all, we manage with modem speeds in doubling steps, and with TDM
  53. >channels in quadrupling steps (in Europe - US is more irregular), with
  54. >noone claiming that eg. a 7200 baud modem standard would "increase
  55. >flexibility", now that we got 4800 and 9600.
  56.  
  57. Also, this thread seems to have overlooked the H10 rate here in NA.
  58. H10 allows use of 22 channels just in case you only have a single
  59. PRI. If you used H11 on a single PRI you would kill your D-channel
  60. and would then be in a bit of trouble.
  61.  
  62. Glad to hear you are a convert.
  63.  
  64. Bob.
  65.  
  66.