| ★ wanayoo — archive 1999 http://data.com/tutorials/multilink_ppp.html | Nouvelle recherche | Portail wanayoo |
![]() |
![]() |
|
|
Figure 1: The Multiprotocol LinkMLPPP-the multilink point-to-point protocol-is a data link protocol that sits between PPP and network-layer protocols. It creates a single logical link by combining multiple PPP links, which can be either separate physical links or distinct channels in a multichannel network like ISDN or frame relay.
|
MLPPP is independent of the actual physical links and the WAN services that run over them. That means MLPPP traffic can traverse a mix of physical and logical connections from multiple WAN services-a frame relay virtual circuit, multiple ISDN channels, and an X.25 connection, for instance. MLPPP functions as a logical link layer that dynamical ly adds or removes links between two communicating devices as bandwidth needs change. The MLPPP standard does not dictate how traffic is balanced over these member PPP links, leaving net managers free to determine how to use the available links or channels.
MLPPP's ability to combine separate PPP links into one logical data pipe is one of the most important features of the protocol. It allows additional WAN bandwidth or new WAN services to be added as needed without disrupting the existing WAN infrastructure. With MLPPP, different WAN services like ISDN, frame relay, and ATM can be used together. For instance, a network manager can establish a frame relay connection to serve as the primary link between a central site and a branch office, with ISDN serving as an adjunct when bandwidth demand rises (see Figure 2).
Figure 2: Many Circuits, One PipeA single MLPPP logical link can contain a mix of connections f rom different WAN services, such as frame relay and ISDN. With MLPPP, channels can be added or removed from the logical pipe as bandwidth requirements change.
|
Through the dynamic addition and deletion of PPP links, MLPPP enables dynamic bandwidth allocation, or "rubber bandwidth," between two peer systems. During the LCP option negotiation, all PPP links in an MLPPP group identify themselves as belonging to the same group, or bundle. To add a new link or WAN service to the bundle, all that's required is to attach to the link the appropriate MLPPP group identifier. Likewise, when a member PPP link is terminated, it is automatically removed from its parent MLPPP bundle by eliminating the identifier.
Because PPP is WAN service-independent, the member links of an MLPPP bundle can be associated with either permanent virtual circuits (PVCs), which have fixed end points, or sw itched virtual circuits (SVCs), which are dialed up on demand.
MLPPP's ability to create different groups of WAN links produces some intriguing possibilities for network managers. For instance, net managers could use MLPPP to segregate traffic according to the network-layer protocol. This approach would enable net managers to separate expedited control messages from normal data traffic or to queue data into separate MLPPP bundles based on some application-specific requirements.
Here's an example of how MLPPP's segregated packet queuing works. Suppose a central site is connected to a remote site via two 64-kbit/s frame relay links and two ISDN basic-rate interface (BRI) connections. Two types of traffic traverse these links: IP traffic from Unix operations and DECnet traffic from a Digital Equipment Corp. VAX network. If the frame relay and ISDN channels are treated as one MLPPP bundle, then both traffic types have access to the full bandwidth of the link at any given time.
The single-p ipe approach makes for easier network management, but it could create problems if one traffic type starts dominating the pipe. In this example, if the Unix IP traffic started bursting beyond 60 percent of the overall link rate, it would begin to eat into bandwidth available for DECnet, slowing performance for users on the VAX network.
With MLPPP, this problem can be avoided. The net manager can not only combine various physical interfaces to create one large pipe but also allocate channels within that virtual pipe as needed. For instance, the network manager can create two 128-kbit/s MLPPP bundles, each consisting of a single ISDN B channel and a 64-kbit frame relay link. Those bundles could then be dedicated to each type of traffic.
One big problem with using routers for switched WAN services isn't activating a link but shutting it down when data transfer is done. Most LAN protocols and client-server applications are chatty, carrying on almost incessant messaging to sy nchronize routing databases and maintain client-server sessions.
Left unchecked, these processes can keep an ISDN link up indefinitely without passing a single byte of application data. Needless to say, all this uptime quickly adds up, especially where charges are based on call duration. Considering that more than 35 percent of WAN costs are related to line costs, the ability to control activation and deactivation of member links in an MLPPP group is crucial.
MLPPP offers two solutions to this problem: usage thresholds and spoofing. In the usage threshold scheme, once a circuit becomes idle or the traffic it carries falls below a level predefined by the network manager, MLPPP will automatically remove that circuit from its bundle until demand rises. The problem with the usage threshold approach is that it can be difficult to define threshold levels effectively in bursty environments using chatty protocols. For instance, in Novell IPX environments, it can be difficult to gauge the requirements of SAP (Service Advertising Protocol) and RIP (Router Information Protocol) messages.
Spoofing helps address this problem. It's a technique used by routers to filter network traffic. Spoofing keeps unnecessary traffic like session keep-alive messages from traversing the WAN link. Rather than send these messages over the WAN, the router acts as a proxy and responds to these messages locally. Once the router takes over the polling and responses for the application, the WAN link can be shut down until it's really needed.
MLPPP's WAN service independence means users and net managers can be insulated from network service changes. As new WAN services like frame relay and ATM become available, MLPPP can be used to incorporate them into logical bundles. To routers, MLPPP looks like a data link protocol; the router doesn't have to deal with the complexity of the various physical connections and switched circuits that MLPPP draws together in its logical pipes. This helps reduce route r reconfiguration costs, since a new router interface isn't required when a new WAN service is added.
To net managers, the difference between adding a new circuit or virtual circuit to an MLPPP bundle and adding a router interface is significant. Adding a circuit to a preexisting MLPPP logical pipe is transparent to the network, particularly in switched environments like ISDN, frame relay, or ATM. It simply adds bandwidth to the pipe; no additional interfaces or path information is required. In contrast, any change to a physical router interface triggers an update to the routing table of every router involved in the change. In environments where circuits are frequently activated and deactivated, this could generate excessive amounts of network topology changes-and excessive extra work for net managers.
Not only can MLPPP save net managers time and effort, but it also offers an important tactical tool for network designers. It can be used to simplify fault management and build redundancy into t he network at low cost.
Along with making use of WAN services already in place, MLPPP is positioned to work with technologies that are just making it to the real world. The most prominent of these technologies, of course, is ATM.
ATM SVCs can be activated and deactivated on demand much like ISDN circuits. ATM circuits can be included in an MLPPP circuit group as more bandwidth is required. Bundling will become especially useful if lower-speed ATM ports (T1 or T3) become widely deployed.
In the long run, as ATM takes over the enterprise network backbone, things could get more complicated. ISDN, frame relay, and ATM will dominate the WAN landscape, with ISDN and frame relay functioning as a feeder technology and ATM serving as the enterprise backbone aggregating ISDN and frame relay circuits over faster pipes. An ATM pipe at Sonet OC3 speed (155 Mbit/s) can aggregate more than 2,400 64-kbit/s ISDN B channels.
That's a lot of bandwidth by today's standar ds, but thanks to the rise of LAN switching and high-speed LANs, aggregate throughput requirements for the LAN will escalate at an even more rapid rate, reaching tens of gigabits per second in the next few years. To reduce the disparity between the LAN and WAN worlds, net managers will need to aggregate B channels and frame relay circuits. Inverse multiplexing using MLPPP offers a flexible way to do this.
[ Home ]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|||||||||||
![]() |
|