Dial-up connectivity is easier when the operating system knows the score
Jeffrey Fritz and Salvatore Salamone
Remote LAN access is wonderful. It allows access to Internet and LAN resources no matter where the user is located. However, remote LAN access has been hindered because computer operating systems and network operating systems (NOSes) have not been made fully aware of the wide-area network connection.
WANs have peculiarities not found in LANs. For example, to reduce communications charges, it is preferable to not keep a connection in place when the user is not accessing the network. Therefore, network devices are customarily programmed to drop calls when there is no user data to send acr
oss a WAN l
ink. However, network traffic, such as keep-alives and routing updates, must still pass over the WAN even when no user data is present.
WAN equipment vendors attempting to deal with this dilemma have met with only limited success. Spoofing, a technique used by network devices to trick a NOS into thinking that a connection is in place when it really is not, is far from the ultimate WAN solution (see
"Network Spoofing,"
December '94 BYTE). The reason is that the right place to deal with WAN-related issues is not in network hardware devices, such as bridges or routers, but in the OS or the NOS. If the operating system is smart enough to realize it is dealing with WAN connections, it can then control the calling patterns and adjust keep-alives and updates accordingly.
Wanting to support WANs in a better fashion, vendors such as Microsoft and Novell have begun incorporating ISDN into their OS and NOS. Users should benefit from both vendors' efforts. Specifically, remote user
s dialing into a network or the Internet over an ISDN link should be able to more easily set up the connection. And managers who are connecting LAN-based users in remote offices to corporate backbones will not have to worry about interoperability problems arising from incompatible, proprietary spoofing implementations.
A Window of Opportunity
Microsoft wants to make ISDN as easy to use as installing a modem. "By making ISDN an integral part of the operating system, we will remove another barrier for ISDN adoption," says Bill Shaughnessy, ISDN product manager.
Last year, the company developed a related architecture for Windows NT. It's called the network driver interface specification (NDIS) packet driver WAN Miniport ISDN architecture. Now, the company has ported this to Windows 95 (see the figure
"Windows 95 Remote Access Support with ISDN"
). Win 95 users can get ISDN capability by downloading free software from on-line locations, such as Microsoft's Web
site (
http://www.microsoft.com/support/
). The upgrade software will also be bundled with ISDN products from several vendors.
Windows 95 supports the Internet Engineering Task Force's Point-to-Point Protocol (PPP). PPP allows network protocols, such as TCP/IP, IPX/SPX (Novell), and NetBEUI to operate over ISDN WAN links. Microsoft has developed PPPMAC, an NDIS 3 PPP driver that installs in the network control panel. To network protocols, PPPMAC looks like a network (LAN) driver. However, behind the scenes it is responsible for getting bits to the other side of the ISDN remote connection.
Windows 95's ISDN support is relatively transparent. From an application or user point of view, nothing changes except for the connection speed. Applications continue to create connections, using Remote Acce
ss Service (RAS), an API, or a Winsock. When the user creates a new connection in the Dial-Up Networking folder, he or she simply chooses the ISDN adapter instead of a modem in the dialog box.
Third-party product integration is relatively straightforward. Using the built-in ISDN protocol stack, the vendor's driver talks directly to the WAN Miniport architecture. This eliminates the need to use third-party IP protocol stacks, like Chameleon or LAN Workplace for Windows. Native ISDN support also means vendors will be able to release products in shorter development cycles. This will result in ISDN products coming to market faster and at lower cost than would be possible if vendors had to write their own device drivers.
That's because an independent hardware vendor needs to create only an ISDN WAN Miniport driver for its product. The driver uses the Windows API to send information to the RAS. The RAS makes the telephony API (TAPI) calls to create the connection. A TAPI Service Provider, called the N
DIS WAN, then passes the TAPI calls to an NDIS WAN Miniport via the NDIS Wrapper. Once the connection is made, PPPMAC sends and receives data to the NDIS WAN Miniport. Therefore, the RAS becomes the interface for all ISDN remote LAN access.
Unfortunately, the first Windows 95 ISDN release leaves out some features usually found in ISDN network devices. Multilink PPP (MP), for example, is not supported. MP aggregates multiple B channels for increased WAN bandwidth. This means that, at least initially, Windows 95's ISDN is limited to a bandwidth of 64 Kbps (the bandwidth supported by one ISDN B channel). However, Microsoft says it intends to include MP in a future release.
Additionally, the first Windows 95 ISDN release supports only Microsoft's proprietary compression algorithm. Users can access devices that do not use Microsoft's compression technology, but the connection will default to no compression. However, Microsoft is likely to support any future Internet Engineering Task Force standard co
mpression algorithm for PPP over ISDN. Spoofing is also missing from the initial release. Microsoft says it plans to incorporate a similar feature, called suspend/resume, in a future version of Windows 95 ISDN.
Managing WAN Links Novell Style
Novell is relying on the NetWare Link Services Protocol (NLSP) and APIs to make a tighter integration between NetWare and ISDN. NLSP was designed to reduce the bandwidth consumption of IPX Routing Information Protocol (RIP) and Service Advertising Protocol (SAP) broadcasts over a network. Instead of the traditional updates every 30 seconds as is common with RIP and the constant SAP broadcasts, NLSP sends out a "hello" packet once every 10 minutes. When changes in a network do occur, routers running NLSP pass along only the changes instead of sending all the information about the state of the network.
Novell's approach--which combines few updates with the passing of fewer bits of information in each update--saves bandwidth over any network
link, be it a backbone Ethernet network, an internetwork with sites connected by dedicated lines, or a network where sites are connected by dial-up ISDN links.
While NLSP is a significant improvement over traditional RIP and SAP, you still don't want to pay phone charges just to pass along "hello" packets when nothing has changed. Bringing up a link every 10 minutes translates into 144 calls every day. For that reason, Novell still relies on third-party vendors for spoofing to summarize the topology behind a link and to propagate the changes once a connection is made by a user's initiative (see the figure
"Reducing Transmissions"
).
NLSP will evolve to be more ISDN-aware, according to Mark dela Vega, a product line manager in Novell's Internetworking Products Group. He sees NLSP keeping an ISDN link down until some type of synchronization between sites is necessary.
Another area where Novell helps integrate ISDN with the NOS is through its Open Data-Link Interface for
Wide-Area Networks (ODI WAN) specification. This specification gives WAN adapter developers a way to tap Novell's configuration and connection-management software.
ODI WAN plays a role similar to that of a driver for a traditional network adapter card except that it works for WAN connections. Basically, ODI WAN is an interface layer between a WAN adapter, the LAN communications protocols (IPX/SPX), and the WAN protocols. To integrate with the NetWare environment using ODI WAN, a developer need only write a driver and a configuration database module for its WAN adapter.
Such steps by Novell, and Microsoft's introduction of ISDN support into Windows 95, will eventually lead to full WAN integration into their operating systems. Over time, this will reduce the complexity and cost of ISDN products.
WHERE TO FIND
Microsoft Corp.
Redmond, WA
Phone: (800) 426-9400 or (206) 882-8080
Fax: (206) 936-7329
Internet:
http://www.microsoft.com
Novell
Orem, UT
Phone: (800) 453-1267 or (801) 222-6000
Fax: (800) 668-5329
Internet:
http://www.novell.com
HotBYTEs
- information on products covered or advertised in BYTE
illustration_link (36 Kbytes)
Microsoft's Windows 95 ISDN support is relatively transparent when compared to a modem connection. The only difference to a user or an application is the speed of the connection.
illustration_link (17 Kbytes)
Novell relies on the NetWare Link Services Protocol's reduced updates and third-party vendors' spoofing to keep traffic off dial-up ISDN links.
Jeffrey Fritz is a telecommunications engineer at West Virginia University and author of Sensible ISDN Data Ap
plications (West Virginia University Press) and The Compleat Remote LAN Access Handbook (Prentice-Hall). You can reach him by sending E-mail to
jfritz@wvnvm.wvnet.edu
. Salvatore Salamone is BYTE's news editor in New York and author of Reducing the Cost of LAN Ownership (Van Nostrand Reinhold). You can reach him at
ssalamone@bix.com
.
Marrying ISDN to the OS
