BOD protocols can also save you money when configuring a network or workstation for Internet access. Many ISPs charge fees for "per channel hour" usage, or more appropriately "per channel minute." The ability to regulate your use of additional channel uptime is key to economizing your bandwidth usage, while ensuring that you're not starving for access or bit traffic.

BOD Concepts
Before focusing on the hows and whys of BACP/ BAP (Bandwidth Allocation Control Protocol/ Bandwidth Allocation Protocol) deployment, let's review some fundamentals of bandwidth on demand and the typical use of MLPPP (Multilink Point-to-Point Protocol, also referred to as MP, MLP or MLPP, depending on the vendor).

MLPPP was introduced to the world as "The PPP Multilink Protocol" (IETC RFC 1717), a response to the need for judiciously allocating bandwidth by bonding multiple channels to create larger aggregated pipes. It is not limited to ISDN and supports many differing connection types, including simple analog dial-up lines. Its essential definition as a means of leveraging the original PPP RFC can be described in a single, though somewhat inaccessible, snippet: "a method for splitting, recombining and sequencing datagrams across multiple logical data links." This boils down to the ability to use separate connections as if they were one big one, even with different types of circuits. As if our lives weren't already complicated enough, according to the specification you can even bond a synchronous T1 circuit with an asynchronous POTS line if you so desire. If you ever find yourself wanting to do that, though, you should reconsider how you're spending your spare time.

Here's an example of how a correctly configured BOD-optioned router can reduce your operational costs: Suppose your ISP gives you 100 hours of usage per month for a low monthly rate, but any "channel" time after that is metered. Remembering that 100 hours means total usage, if you were to connect with both ISDN B channels all the time, that would give you 50 hours of actual usage uptime, or little more than one and a half hours of connectivity per day! Let's say you need to provide for eight hours of uptime per day for your end user. That would eat up the allotted amount of time in little more than a week, and then you'd be subject to the (typically) high per-minute charges.

So how do you keep your router from emptying your wallet? By configuring BOD, you not only restrict your access to a single channel as necessary, but you also turn off that channel during periods of inactivity. This saves small increments of time here and there throughout the workday, which quickly add up.

To give your router the intelligence to determine when it needs to have a channel up or down, you must configure its tolerance level based on the amount of data being passed, and look for periods of inactivity or high data rates. These tolerance levels are calculated by entering anticipated thresholds that you want the protocol to observe when configuring MLPPP. For tearing down a single channel, the commonly presented option is configured via an "inactivity" parameter. You usually will see these set at a default as low as five minutes, which means when the router has not passed any external traffic outside your network (in or out), it simply closes the remaining open channel. When new outgoing traffic arrives at the router's internal Ethernet interface, it brings the line back up again by redialing. This is digital technology (in the case of ISDN), so the connection, authentication and configuration of the link take only seconds. From your users' perspective, this process will be seamless; many won't even realize that the router has idled the connection at all.

The reverse of this process is when the router exceeds the predetermined threshold of activity on a single channel. These levels are governed by calculations based on the amount of traffic driven through the primary and secondary B channels, and for a sustained period of time. For the purposes of explanation, assume that MLPPP has been configured to bring up a second channel if the throughput of the primary channel has exceeded 40 Kbps for longer than 30 seconds, and to tear it down if usage of the second channel drops to nothing and the primary channel's throughput also drops below 40 Kbps for longer than 30 seconds. For example, say a user is FTP-ing a large patch from a nearby site at 50 Kbps, and it streams in for more than one minute. MLPPP will bring up the second channel and bond it to the first. After the user has completed the download and MLPPP senses a lack of traffic on the second channel and decreased traffic on the primary one, MLPPP will tear down the secondary (see "Determining Bandwidth" below).

BACP was introduced as "The PPP Bandwidth Allocation Control Protocol." In fact, its first practical implementation was via Ascend Communications' proprietary "MP+," which it developed independently. Although Ascend allowed open access and use by other players, at some point it was determined that a jointly expressed industry standard should be developed in cooperation with key players in the router segment. So in conjunction with Bay Networks, Cisco Systems, 3Com Corp., US Robotics and Xylogics, Ascend and Shiva Corp. introduced RFC 2125 to meet this need. You can read more about it at the IETF's Web site (www.ietf.org/rfc/ rfc2125.txt).