Browse Prior Art Database

Virtual Private Networks on Vendor Independent Networks

IP.com Disclosure Number: IPCOM000109611D
Original Publication Date: 1992-Sep-01
Included in the Prior Art Database: 2005-Mar-24
Document File: 4 page(s) / 244K

Publishing Venue

IBM

Related People

Doeringer, W: AUTHOR [+6]

Abstract

When interconnecting a set of networks sharing a common networking protocol across a Vendor Independent Network (VIN), the requirement may arise to limit the potential connectivity to selected collections of these networks. Such requirements are put forth by customers who, for example, need to restrict the interconnection to the networks under their control for reasons of data security or competitiveness. Other restrictions of the connectivity are inherent to the very networking technology, such as in the case of interconnected LANs or MANs.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 37% of the total text.

Virtual Private Networks on Vendor Independent Networks

       When interconnecting a set of networks sharing a common
networking protocol across a Vendor Independent Network (VIN), the
requirement may arise to limit the potential connectivity to selected
collections of these networks.  Such requirements are put forth by
customers who, for example, need to restrict the interconnection to
the networks under their control for reasons of data security or
competitiveness.  Other restrictions of the connectivity are inherent
to the very networking technology, such as in the case of
interconnected LANs or MANs.  The interconnection of such
shared-medium networks with protocols using flat address spaces, such
as the NetBIOS protocol (1) and other LAN protocols based on the
unstructured 48-bit IEEE MAC addresses, faces the problem that these
protocols rely on all-station broadcast discovery procedures.  Hence,
it is not possible to efficiently route frames of a particular
protocol to arbitrary recipients in any sizeable network.  A static
decision must be made as to where the frames from this protocol are
to be distributed to limit the scope of broadcast searches and the
dissemination of address and routing information.  In either case, a
network administrator must identify collections of external networks
which are to be interconnected across the VIN, thus forming what we
call a Virtual Private Network (VPN).

      This article describes how such Virtual Private Networks may be
built on a Vendor Independent Network with the group management and
multicast features.  The procedure is designed to require minimal
configuration information and to provide a high degree of
flexibility.  The disclosed ideas may also be implemented on other
networks with functions as described in (2) at the risk of
insufficient performance in a high-speed environment.  The
applicability of the disclosed ideas to the interconnection of
existing networks is illustrated in several examples with special
focus on the increased mobility of users of such VPNs.

      The idea of Virtual Private Networks (VPNs) is not new.  The
CCITT X.25 recommendation (3) supports the concept of (closed) user
groups, and vendors offer customizing features for their networks,
such as described in (4).  However, this invention goes well beyond
prior art in building such Virtual Private Networks on the group
management and multicast infrastructure of a Vendor Independent
Network (VIN) in such a way that transparent interconnection of even
high-speed networks becomes viable.  In addition, the described
procedure requires extremely little a priori information and permits
network administrators to dynamically reconfigure existing VPNs on a
given VIN.  Fig. 1 gives a pictorial representation of the principal
structure of such VPNs.

      This invention describes a procedure to:
      *    Establish and manage Virtual Private Networks on a Vendor
Independent Networ...