home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dcom / isdn / 1239 < prev    next >
Encoding:
Text File  |  1993-01-27  |  3.3 KB  |  71 lines
  1. Newsgroups: comp.dcom.isdn
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!mailgzrz.TU-Berlin.DE!math.fu-berlin.de!ira.uka.de!sol.ctr.columbia.edu!spool.mu.edu!torn!nott!hobbit.gandalf.ca!cstorry
  3. From: cstorry@gandalf.ca (Chuck Storry)
  4. Subject: Re: BONDING and T1 Letter Ballot
  5. Message-ID: <1993Jan26.164255.26315@gandalf.ca>
  6. Keywords: BONDING,ISDN
  7. Organization: Gandalf Data Ltd.
  8. References: <C19x6v.CLG@ms.uky.edu> <1993Jan25.054421.22650@scott.skidmore.edu> <Kevin.Kershaw.4@StPaul.NCR.COM>
  9. Date: Tue, 26 Jan 1993 16:42:55 GMT
  10. Lines: 59
  11.  
  12. In <Kevin.Kershaw.4@StPaul.NCR.COM> Kevin.Kershaw@StPaul.NCR.COM (Kevin Kershaw  ) writes:
  13.  
  14.  
  15. >Thanks to all who respoded to my inquiry on BONDING and T1 Multi-
  16. >rate capability.  Your information has been very helpful.  
  17. >As a follow on issue, I would be interested in obtaining more
  18. >information on the BONDING protocols.  I am currently supervising
  19. >a development that provides both BRI and PRI support for devices
  20. >attached to our line of communications processors.  We have
  21. >implemented a proprietary end-to-end protocol between our own
  22. >devices that allows multiple B-channels to be brought into
  23. >service to increase the end-to-end bandwidth.  This capability is
  24. >dynamic (channels are brought into and out of service as needed)
  25. >and can span channels on combinations of BRI and PRI interfaces. 
  26. >This product was designed almost 2 years ago so the BONDING work
  27. >was unknown to us at that time.  I would like examine whether it
  28. >makes sense for us to move to BONDING in future releases. Does
  29. >anyone know where I might obtain the specs for the BONDING
  30. >procedures?
  31.  
  32. There are other "standards" in addition to BONDING to consider (or perhaps
  33. not). They include CCITT H.221 and I belive that Australia has one.
  34.  
  35. I heard a rumour that CCITT rejected the BONDING spec as the basis for
  36. inverse muxing in favour of a revised/modified H.221. Anyone know the 
  37. details or validity on this ?
  38.  
  39.  
  40.  
  41. >The big difference with ISDN on this point is that you are going 
  42. >to pay your service provider for each additional channel you
  43. >bring on line.  If you are running 2 B already (128K) and another
  44. >64K on line will cover your needs, why pay for another 128K?
  45.  
  46. This brings me to BONDING mode 3. Do we really need to add bandwidth on 
  47. 8khz increments ? If you add another B channel why not give all 64K to 
  48. the user ?
  49.  
  50. (For those not in the know BONDING consists of 4 modes:
  51. mode 0 - inband negotiation (no B channel aggregation)
  52. mode 1 - inband negotiation , channel equalization and subsequent aggregation
  53.          (but no monitoring for loss of sync and no end-end com channel)
  54. mode 2 - mode 1 and overhead framing to determine synchronization status
  55.          and an end-end communication channel in order to dynamically
  56.          add and remove channels (and maintenance : loopback, etc)
  57. mode 3 - as per mode 2 but bnadwidth is added in 8k increments rather than 
  58.          "B" channel (56/64k) increments.
  59.  
  60. Note: this is my interpretation of the Spec and is not an officially
  61. sanctioned synopsis of BONDING.
  62.  
  63. >Kevin Kershaw                              DAMN IT'S COLD OUT......
  64. >NCR Network Products Division
  65. >St. Paul, MN.
  66. -- 
  67. Chuck Storry, Principal Designer      CAnet: cstorry@gandalf.ca
  68. Gandalf Data Ltd.                     Voice: (613) 723-6500
  69. 130 Colonnade Rd So, Nepean, Ontario  Fax: (613) 226-1717
  70. Canada  K2E 7M4
  71.