While the industry awaits a standard for multi-chassis multi-linking, proprietary methods are beginning to emerge. Many vendors are using a developing IETF tunneling protocol, L2TP, to combine the calls regardless of where they originate, essentially creating a single, virtual machine.
Strategies for combining ISDN B channelsMulti-link PPP and the Bandwidth Allocation Protocol (BAP) lay the groundwork for combining incoming ISDN calls, but they fall short of linking separate B channel calls that get answered by two different devices. In a large network with many relatively small capacity concentrators (120 ports or less), the probability of being able to make the second connection on the same concentrator is problematic. While the industry awaits a standard for multi-chassis multi-linking, proprietary methods are beginning to emerge. Many vendors are using a developing IETF tunneling protocol, L2TP, to combine the calls regardless of where they originate, essentially creating a single, virtual machine. L2TP, an IETF draft proposal for creating a tunnel between two devices, was mainly developed to address virtual private networking applications, yet remote access concentrators can use L2TP to provide a transparent means of connecting ISDN calls that come into different chassis located on the same LAN. What is Multi-link PPP? Multi-link PPP was created to supplement the Point-to-Point Protocol (PPP) and create a more robust and reliable inter-network. Like PPP, which provides simultaneous transmission of multiple protocols across a single serial link, Multi-link PPP, enables data communications equipment to increase bandwidth by combining multiple single links to form a single "logical" link. Multi-link PPP defines how multiple links, such as ISDN B channels, are combined. Unfortunately, Multi-link PPP only works when there is an available channel on the initial box that the call came in on. As defined by RFC 1990, Multi-link is used by bridges, routers, and other remote access devices to provide load sharing and to increase the effective bandwidth along a single path for both bridged and routed data. It also provides a means for redundant connectivity should a physical link fail. With Multi-link enabled, more than one link can be active in data forwarding and the resulting net bandwidth is the combination of the multiple individual path bandwidths in which the multiple links appear as a single logical link. Since only one network address needs to be assigned for the single logical data path, fewer network addresses are required and therefore available for other network devices. Since Multi-link masks the fact that the logical data path is actually the combination of multiple links, if one link fails, the rest of the network does not need to be informed of the change in link status. This eliminates unnecessary route updates on the WAN links. The Multi-link data rate is the combined throughput of all active member links. The current load sharing policy spreads the load equally among the active member links. When the data rate exceeds a congestion to call threshold, additional member links are added for extra bandwidth. When the data rate drops below congestion, one or more member links are cleared to reduce costs. What about the Bandwidth Allocation Protocol? Another ubiquitous method of dynamically controlling bandwidth is the Bandwidth Allocation Protocol (BAP) which manages the addition or deletion of links based on local congestion policies. The Bandwidth Allocation Control Protocol (BACP), as defined by RFC 2125, is the protocol that controls how BAP packets are communicated between PPP peers. If congestion, or the lack of, is detected by either device, they use BAP/BACP to communicate the graceful addition or removal of a link from the Multi-link bundle. The desired result is the dial-in phone number of an additional bandwidth resource. The request would be turned down, however, if there was no additional bandwidth available. The down side to BAP/BACP is that it cannot find additional bandwidth resources located on devices other than the one which holds the original Multi-link bundle head (the original PPP call in the Multi-link bundle). For instance, an ISP may use multiple ISDN access devices at one point-of-presence (POP) to handle incoming traffic. Each device is allocated PRI lines in a hunt group that calls to other access devices in the hunt group. Most initial dial-in calls employ only a single ISDN B channel. Typical login and email applications originate at 56/64 Kbit/s, but once the dial-in user wants to transfer data from a remote site, the user most likely will want to activate the second B Channel to speed the transmission if the link becomes congested. Say the original call comes into Concentrator X, and the second B channel call comes five minutes later. By this time other users have dialed into Concentrator X, consuming its capacity. Calls are being forwarded to Concentrator Z, where unfortunately, the call will be denied because it can not be multi-linked with the originating call ( an all too common scenario. The inherent problems with BAP/BACP are two-fold. If it returns a phone number for a specific access concentrator upon a request for additional bandwidth, it is possible that the user could get a busy signal if all the channels are taken. If BAP/BACP responds with the hunt group phone number, it is likely the second call would be forwarded to a different access concentrator where the call would be rejected because it cannot connect with the original bundle head. How can B Channels be combined across Multiple Chassis? A multi-chassis synchronisation protocol automatically locates the Multi-link bundle head and tunnels it back to that access concentrator using L2TP. If the access concentrators in the previous example employed a multi-chassis synchronisation protocol they would have a way to combine the two ISDN B channels calls, and all the participating access concentrators would appear as a single, virtual concentrator. In another scenario, the same initial B channel is received by Concentrator X and the second B channel call comes into Concentrator Z. In this case, a query request for the originating ISDN bundle is broadcast on the local side. The participating concentrators execute a search to determine if they currently have a connected user matching the description in the request. Since a positive response is returned by Concentrator X, an L2TP tunnel is set up between X and Z so that the dial-in user appears to have "physically" connected to Concentrator X. There are two approaches to running a multi-chassis synchronisation protocol: Timeout Mode and Acknowledge Mode. The choice of which to use should depend on the environment. The Timeout Mode of operation causes the querying access concentrator to wait a specified amount of time before proceeding with the first call in a Multi-link bundle. With Acknowledge Mode, all participating devices acknowledge every query request with a positive or negative indication. After all participants have responded negatively, the access concentrator can proceed with the first call in a Multi-link bundle. Acknowledge Mode significantly decreases the time required before proceeding with the first call in a Multi-link bundle, at the expense of increasing activity on the LAN. In the Acknowledge Mode of operation, a multi-chassis synchronisation protocol must be aware of all active participants. A multi-chassis synchronisation protocol can use a static means of communicating or a dynamic discovery protocol. While Acknowledgment Mode provides quicker call processing than Timeout Mode does, its broadcast application makes it less suitable for large network environments. On average, the first link in a Multi-link bundle will be processed in less than 10 milliseconds, whereas in Timeout Mode this will take 300 milliseconds by default. In both modes, a multi-chassis synchronisation protocol will attempt to piggy-back queries and responses in the same query packet to optimise and reduce traffic. Summary Prevalent in remote access devices, Multi-link PPP and the Bandwidth Allocation Protocol have set the stage for combining incoming ISDN calls while maintaining interoperability. Yet the ISDN community is anticipating a standard for multi-chassis multi-linking to combine the calls regardless of where they originate within a point-of presence. Will Garside