`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`September 1998
`
`Volume 1, Number 2
`
`A Quarterly Technical Publication for
`Internet and Intranet Professionals
`
`F r o m T h e E d i t o r
`
`In This Issue
`
`From the Editor .......................1
`
`What Is a VPN?–Part II ...........2
`
`Reliable Multicast Protocols
`and Applications....................19
`
`Layer 2 and Layer 3
`Switch Evolution....................38
`
`Book Review..........................44
`
`Fragments ..............................47
`
`Missed the first issue of IPJ?
`Download your copy in
`PDF format from:
`www.cisco.com/ipj
`
`We begin this issue with Part II of “What Is a VPN?” by Paul Ferguson
`and Geoff Huston. In Part I they introduced a definition of the term “Vir-
`tual Private Network” (VPN) and discussed the motivations behind the
`adoption of such networks. They outlined a framework for describing
`the various forms of VPNs, and examined numerous network-layer VPN
`structures, in particular, that of controlled route leakage and tunneling. In
`Part II the authors conclude their examination of VPNs by describing vir-
`tual private dial networks and network-layer encryption. They also
`examine link-layer VPNs, switching and encryption techniques, and
`issues concerning Quality of Service and non-IP VPNs.
`
`IP Multicast is an emerging set of technologies and standards that
`
`allow many-to-many transmissions such as conferencing, or one-to-
`many transmissions such as live broadcasts of audio and video over the
`Internet. Kenneth Miller describes multicast in general, and reliable
`multicast protocols and applications in particular. Although multicast
`applications are primarily used in the research community today, this
`situation is likely to change as the demand for Internet multimedia
`applications increases and multicast technologies improve.
`
`Successful deployment of networking technologies requires an under-
`standing of a number of technology options ranging from wiring and
`transmissions systems via switches, routers, bridges and other pure net-
`working components, to networked applications and services.
`The
` (IPJ) is designed to look at all aspects of these
`Internet Protocol Journal
`“building blocks.” This time, Thayumanavan Sridhar details some of
`the issues in the evolution of Layer 2 and Layer 3 switches.
`
`Interest in the first issue of IPJ has exceeded our expectations, and hard
`copies are almost gone. However, you can still view and print the issue
`. The current
`in PDF format on our Web site at
`www.cisco.com/ipj
`edition is also available on the Web. If you want to receive our next
`issue, please complete and return the enclosed card.
`
`We welcome your comments, questions and suggestions regarding any-
`thing you read in this journal. We are also actively seeking authors for
`new articles. The Call for Papers and Author Guidelines can be found
`on our Web page. Please send your comments to
`ipj@cisco.com
`
`—Ole J. Jacobsen, Editor and Publisher
`ole@cisco.com
`
`Petitioner RPX Corporation - Ex. 1024, p. 1
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`What Is a VPN? — Part II
`by Paul Ferguson, Cisco Systems
`and Geoff Huston, Telstra
`
`I
`
`n Part I we introduced a working definition of the term “Virtual
`Private Network” (VPN), and discussed the motivations behind the
`adoption of such networks. We outlined a framework for describ-
`ing the various forms of VPNs, and then examined numerous network-
`layer VPN structures, in particular, that of controlled route leakage and
`tunneling techniques. We begin Part II with examining other network-
`layer VPN techniques, and then look at issues that are concerned with
`
`non-IP VPNs and Quality-of-Service (QoS) considerations.
`
`Types of VPNs
`This section continues from Part I to look at the various types of VPNs
`using a taxonomy derived from the layered network architecture
`model. These types of VPNs segregate the VPN network at the net-
`work layer.
`
`Network-Layer VPNs
`A network can be segmented at the network layer to create an end-to-
`end VPN in numerous ways. In Part I we described a controlled route
`leakage approach that attempts to perform the segregation only at the
`edge of the network, using route advertisement control to ensure that
`each connected network received a view of the network (only peer net-
`works). We pick up the description at this point in this second part of
`the article.
`
`Tunneling
`As outlined in Part I, the alternative to a model of segregation at the
`edge is to attempt segregation throughout the network, maintaining the
`integrity of the partitioning of the substrate network into VPN compo-
`nents through the network on a hop-by-hop basis. Part I examined
`numerous tunneling technologies that can achieve this functionality.
`Tunneling is also useful in servicing VPN requirements for dial access,
`and we will resume the description of tunnel-based VPNs at this point.
`
`Virtual Private Dial Networks
`Although several technologies (vendor-proprietary technologies as well
`as open, standards-based technologies) are available for constructing a
`
`Virtual Private Dial Network (VPDN), there are two principal meth-
`ods of implementing a VPDN that appear to be increasing in
`
`
`popularity—Layer 2 Tunneling Protocol (L2TP) and
`Point-to-Point
` (PPTP) tunnels. From an historical perspective,
`Tunneling Protocol
`L2TP is the technical convergence of the earlier Layer 2 Forwarding
` protocol specification and the PPTP protocol. However, one
`(L2F)
`[1]
`might suggest that because PPTP is now being bundled into the desk-
`top operating system of many of the world’s personal computers, it
`stands to be quite popular within the market.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`2
`
`Petitioner RPX Corporation - Ex. 1024, p. 2
`
`

`

`
`
`
`
`
`
`
`
`
`
`At this point it is worthwhile to distinguish the difference between “cli-
`ent-initiated” tunnels and “NAS-initiated” (Network Access Server,
`otherwise known as a Dial Access Server) tunnels. The former is com-
`monly referred to as “voluntary” tunneling, whereas the latter is com-
`monly referred to as “compulsory” tunneling. In voluntary tunneling,
`the tunnel is created at the request of the user for a specific purpose; in
`compulsory tunneling, the tunnel is created without any action from the
`user, and without allowing the user any choice in the matter.
`
`L2TP, as a compulsory tunneling model, is essentially a mechanism to
`“off-load” a dialup subscriber to another point in the network, or to
`another network altogether. In this scenario, a subscriber dials into a
`NAS, and based on a locally configured profile (or a NAS negotiation
`with a policy server) and successful authentication, a L2TP tunnel is
`dynamically established to a predetermined endpoint, where the sub-
`
`
`scriber’s Point-to-Point Protocol (PPP) session is terminated (Figure 1).
`
`Figure 1:
`PPP Tunnel
`Termination Model
`of L2TP
`
`PPP Access Protocol
`
`V.x modem protocol
`
`L2TP
`
`Client Host
`
`Non-routed
`forwarding path
`
`Dial Access
`Server
`
`L2TP Access
`Server
`
`Dial Access Provider
`
`Internet or VPN Service
`
`PPTP, as a voluntary tunneling model, on the other hand, allows end
`systems (for example, desktop computers) to configure and establish
`individual discrete point-to-point tunnels to arbitrarily located PPTP
`servers, without the intermediate NAS participating in the PPTP
`negotiation and subsequent tunnel establishment. In this scenario, a
`subscriber dials into a NAS, but the PPP session is terminated on the
`NAS, as in the traditional Internet access PPP model. The layered PPTP
`session is then established between the client end system and any
`upstream PPTP server that the client desires to connect to. The only
`caveats on PPTP connectivity are that the client can reach the PPTP
`server via conventional routing processes, and that the user has been
`granted the appropriate privileges on the PPTP server (Figure 2).
`
`Figure 2:
`PPP Tunnel
`Termination Model
`of PPTP
`
`PPTP Virtual
`Interface
`
`PPP Access Protocol
`
`Dial IP Access
`
`Client Host
`
`Serial
`Interface
`
`Dial Access
`Server
`
`PPTP Access
`Server
`
`Dial Access Provider
`
`VPN Service
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`3
`
`Petitioner RPX Corporation - Ex. 1024, p. 3
`
`

`

`What Is a VPN? — Part II:
`continued
`
`
`
`
`
`
`
`
`
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`4
`
`Although L2TP and PPTP may sound extraordinarily similar, there are
`subtle differences that deserve further examination. The applicability of
`both protocols is very much dependent on what problem is being
`addressed. It is also about control—who has it, and why it is needed. It
`also depends heavily on how each protocol implementation is
`deployed—in either the voluntary or the compulsory tunneling models.
`
`With PPTP in a voluntary tunneling implementation, the dial-in user
`can choose the PPTP tunnel destination (the PPTP server) after the ini-
`tial PPP negotiation has completed. This feature is important if the
`tunnel destination changes frequently, because no modifications are
`needed to the client’s view of the base PPP access when there is a
`change in the server and the transit path to the server. It is also a
`significant advantage that the PPTP tunnels are transparent to the ser-
`vice provider, and no advance configuration is required between the
`NAS operator and the overlay dial access VPN. In such a case, the ser-
`vice provider does not house the PPTP server, and simply passes the
`PPTP traffic along with the same processing and forwarding policies as
`all other IP traffic. In fact, this feature should be considered a
`significant benefit of this approach. The configuration and support of a
`tunneling mechanism within the service provider network would be
`one less parameter that the service provider has to operationally man-
`age, and the PPTP tunnel can transparently span multiple service
`providers without any explicit service provider configuration. How-
`ever, the economic downside to this feature for the service provider, of
`course, is that a “VPDN-enabled” network service can be marketed to
`yield an additional source of revenue. Where the client undertakes the
`VPDN connection, there is no direct service provider involvement and
`no consequent value added to the base access service.
`
`From the subscriber’s perspective, this is a “win-win” situation, because
`the user is not reliant on the upstream service provider to deliver the
`VPDN service—at least no more than any user is reliant for basic IP-
`level connectivity. The other “win” is that the subscriber does not have
`to pay a higher subscription fee for a VPN service. Of course, the situa-
`tion changes when the service provider takes an active role in providing
`the VPDN, such as housing the PPTP servers, or if the subscriber resides
`within a subnetwork in which the parent organization wants the ser-
`vice provider’s network to make the decision concerning where tunnels
`are terminated. The major characterization of PPTP-based VPDN is one
`of a roaming client base, where the clients of the VPDN use a local con-
`nection to the public Internet data network, and then overlay a private
`data tunnel from the client’s system to the desired remote service point.
`Another perspective is to view this approach as “on-demand” VPDN
`virtual circuits.
`
`With L2TP in a “compulsory” tunneling implementation, the service
`provider controls where the PPP session is terminated. This setup can be
`extremely important in situations where the service provider to whom
`
`Petitioner RPX Corporation - Ex. 1024, p. 4
`
`

`

`
`
`
`
`
`
`
`
`
`
`the subscriber is actually dialing into (let’s call it the “modem pool pro-
`vider” network) must transparently hand off the subscriber’s PPP
`session to another network (let’s call this network the “content pro-
`vider”). To the subscriber, it appears as though the local system is
`directly attached to the content provider’s network, when in fact the
`access path has been passed transparently through the modem pool pro-
`vider’s network to the subscribed content service. Very large content
`providers, for instance, may outsource the provisioning and mainte-
`nance of thousands of modem ports to a third-party access provider,
`who in turn agrees to transparently pass the subscribers’ access sessions
`back to the content provider. This setup is generally called “wholesale
`dial.” The major motivation for such L2TP-based wholesale dial lies in
`the typical architecture of the
`Public Switched Telephone Network
`(PSTN), where the use of wholesale dial facilities can create a more
`rational PSTN call load pattern with Internet access PSTN calls termi-
`nated in the local Central Office.
`
`Of course, if all subscribers who connect to the modem pool provider’s
`network are destined for the same content provider, then there are cer-
`tainly easier ways to hand this traffic off to the content provider’s
`network—such as simply aggregating all the traffic in the local Central
`Office and handing the content provider a “big fat pipe” of the aggre-
`gated session traffic streams. However, in situations where the modem
`pool provider is providing a wholesale dial service for multiple
`upstream “next-hop” networks, the methods of determining how each
`subscriber’s traffic must be forwarded to his/her respective content pro-
`vider are somewhat limited. Packet forwarding decisions could be made
`at the NAS, based on the source address of the dialup subscriber’s com-
`puter. This scenario would allow for traffic to be forwarded along the
`appropriate path to its ultimate destination, in turn intrinsically provid-
`ing a virtual connection. However, the use of assigning static IP
`addresses to dial-in subscribers is highly discouraged because of the
`inefficiencies in IP address utilization policies, and the critical success of
`
`Dynamic Host Configuration Protocol (DHCP).
`the
`
`There are, however, some serious scaling concerns in deploying a large-
`scale L2TP network; these concerns revolve around the issue of
`whether large numbers of tunnels can actually be supported with little
`or no network performance impact. Since there have been no large-
`scale deployments of this technology to date, there is no empirical evi-
`dence to support or invalidate these concerns.
`
`In some cases, however, appearances are everything—some content
`providers do not wish for their subscribers to know that when they
`connect to their service, they have instead been connected to another
`service provider’s network, and then passed along ultimately to the ser-
`vice to which they have subscribed. In other cases, it is merely designed
`to be a matter of convenience, so that subscribers do not need to log
`into a device more than once.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`5
`
`Petitioner RPX Corporation - Ex. 1024, p. 5
`
`

`

`What Is a VPN? — Part II:
`continued
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Regrettably, the L2TP draft does not detail all possible implementa-
`tions or deployment scenarios for the protocol. The basic deployment
`scenario is quite brief when compared to the rest of the document, and
`is arguably biased toward the compulsory tunneling model. Nonethe-
`less, there are implementations of L2TP that follow the voluntary
`tunneling model. To the best of our knowledge, there has never been
`any intent to exclude this model of operation. In addition, at various
`recent interoperability workshops, several different implementations of
`a voluntary L2TP client have been modeled. Nothing in the L2F proto-
`col would prohibit deploying it in a voluntary tunneling manner, but
`to date it has not been widely implemented. Further, PPTP has also
`been deployed using the compulsory model in a couple of specific ven-
`dor implementations.
`
`In summary, consideration of whether PPTP or L2TP is more appro-
`priate for deployment in a VPDN depends on whether control needs to
`lie with the service provider or with the subscriber. Indeed, the differ-
`ence can be characterized with respect to the client of the VPN, where
`the L2TP model is one of a “wholesale” access provider who has
`numerous configured client service providers who appear as VPNs on
`the common dial access system, whereas the PPTP model is one of dis-
`tributed private access where the client is an individual end user and
`the VPN structure is that of end-to-end tunnels. One might also sug-
`gest that the difference is also a matter of economics, because the L2TP
`model allows service providers to actually provide a “value-added”
`service, beyond basic IP-level connectivity, and charge their subscribers
`accordingly for the ability to access it, thus creating new revenue
`streams. By contrast, the PPTP model enables distributed reach of the
`VPN at a much more basic level, enabling corporate VPNs to extend
`access capabilities without the need for explicit service contracts with a
`multitude of network access providers.
`
`Network-Layer Encryption
`Encryption technologies are extremely effective in providing the seg-
`mentation and virtualization required for VPN connectivity, and they
`can be deployed at almost any layer of the protocol stack. The evolv-
`ing standard for network-layer encryption in the Internet is
`IP Security
`. (IPSec is actually an architecture—a collection of proto-
`(IPSec)
`[3, 4]
`cols, authentication, and encryption mechanisms. The IPSec security
`architecture is described in detail in [3].)
`
`While the
`Internet Engineering Task Force (IETF) is finalizing the
`
`architecture and the associated protocols of IPSec, there is relatively lit-
`tle network-layer encryption being done in the Internet today.
`However, some vendor proprietary solutions are currently in use.
`
`Whereas IPSec has yet to be deployed in any significant volume, it is
`worthwhile to review the two methods in which network-layer encryp-
`tion is predominantly implemented. The most secure method for network-
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`6
`
`Petitioner RPX Corporation - Ex. 1024, p. 6
`
`

`

`
`
`
`
`
`
`
`
`
`
`layer encryption to be implemented is end-to-end, between participating
`hosts. End-to-end encryption allows for the highest level of security. The
`alternative is more commonly referred to as “tunnel mode,” in which the
`encryption is performed only between intermediate devices (routers), and
`traffic between the end system and the first-hop router is in plaintext. This
`setup is considerably less secure, because traffic intercepted in transit
`between the first-hop router and the end system could be compromised.
`
`As a more general observation on this security vulnerability, where a
`VPN architecture is based on tunnels, the addition of encryption to the
`tunnel still leaves the tunnel ingress and egress points vulnerable,
`because these points are logically part of the host network as well as
`being part of the unencrypted VPN network. Any corruption of the
`operation, or interception of traffic in the clear, at these points will
`compromise the privacy of the private network.
`
`In the end-to-end encryption scheme, VPN granularity is to the individ-
`ual end-system level. In the tunnel mode scheme, the VPN granularity
`is to the subnetwork level. Traffic that transits the encrypted links
`between participating routers, however, is considered secure. Network-
`layer encryption, to include IPSec, is merely a subset of a VPN.
`
`Link-Layer VPNs
`One of the most straightforward methods of constructing VPNs is to
`use the transmission systems and networking platforms for the physi-
`cal and link-layer connectivity, yet still be able to build discrete
`networks at the network layer. A link-layer VPN is intended to be a
`close (or preferably exact) functional analogy to a conventional pri-
`vate data network.
`
`ATM and Frame Relay Virtual Connections
`A conventional private data network uses a combination of dedicated
`circuits from a public carrier, together with an additional private com-
`munications infrastructure, to construct a network that is completely
`self-contained. Where the private data network exists within private
`premises, the network generally uses a dedicated private wiring plant
`to carry the VPN. Where the private data network extends outside the
`private boundary of the dedicated circuits, it is typically provisioned
`for a larger public communications infrastructure by using some form
`of time-division or frequency-division multiplexing to create the dedi-
`cated circuit. The essential characteristic of such circuits is the
`synchronization of the data clock, such that the sender and receiver
`pass data at a clocking rate that is fixed by the capacity of the dedi-
`cated circuit.
`
`A link-layer VPN attempts to maintain the critical elements of this self-
`contained functionality, while achieving economies of scale and opera-
`tion, by utilizing a common switched public network infrastructure.
`Thus, a collection of VPNs may share the same infrastructure for con-
`nectivity, and share the same switching elements within the interior of
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`7
`
`Petitioner RPX Corporation - Ex. 1024, p. 7
`
`

`

`What Is a VPN? — Part II:
`continued
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Discrete Layer 3
`Network
`
`Layer 2
`Infrastructure
`(e.g., Frame
`Relay, ATM)
`
`Discrete Layer 3
`Network
`
`Discrete Layer 3
`Network
`
`the network, but explicitly must have no visibility, either direct or
`inferred, of one another. Generally, these “networks” operate at Layer
`3 (the network layer) or higher in the OSI Reference Model, and the
`“infrastructure” itself commonly consists of either a
`
`Frame Relay or
`
`Asynchronous Transfer Mode (ATM) network (Figure 3). The essen-
`tial difference here between this architecture of virtual circuits and that
`of dedicated circuits is that there is now no synchronized data clock
`shared by the sender and receiver, nor necessarily is there a dedicated
`transmission path that is assigned from the underlying common host
`network. The sender generally has no a priori knowledge of the avail-
`able capacity of the virtual circuit, because the capacity varies in
`response to the total demand placed on it by other simultaneous trans-
`mission and switching activity. Instead, the sender and receiver can use
`adaptive clocking of data, where the sender can adjust the transmis-
`sion rate to match the requirements of the application and any
`signaling received from the network and the receiver. It should be
`noted that a dedicated circuit system using synchronized clocking can-
`not be oversubscribed, whereas the virtual circuit architecture (where
`the sender does not have a synchronized end-to-end data clock) can
`indeed be oversubscribed. It is the behavior of the network when it
`transitions into this oversubscribed state that is of most interest here.
`
`Figure 3:
`Conceptualization of
`Discrete Layer 3
`Networks on a
`Common Layer 2
`Infrastructure
`
`One of the nice things about a public switched wide-area network that
`provides virtual circuits is that it can be extraordinarily flexible. Most
`subscribers to Frame Relay services, for example, have subscribed to
`the service for economic reasons—it is cheap, and the service provider
`usually adds a
`
`Service-Level Agreement (SLA) that “guarantees” some
`percentage of frame delivery in the Frame Relay network itself.
`
`The remarkable thing about this service offering is that the customer is
`generally completely unaware of whether the service provider can actu-
`ally deliver the contracted service at all times and under all possible
`conditions. The Layer 2 technology is not a synchronized clock block-
`ing technology in which each new service flow is accepted or denied
`based on the absolute ability to meet the associated resource demands.
`Each additional service flow is accepted into the network and carried
`on a best-effort basis. Admission functions provide the network with a
`simple two-level discard mechanism that allows a graduated response
`to instances of overload; however, when the point of saturated over-
`load is reached within the network, all services will be affected.
`
`This situation brings up several other important issues: The first con-
`cerns the engineering practices of the Frame Relay service provider. If
`the Frame Relay network is poorly engineered and is constantly con-
`gested, then obviously the service quality delivered to the subscribers
`will be affected. Frame Relay uses a notion of a per-virtual circuit
`Com-
` (CIR), which is an ingress function associated
`mitted Information Rate
`with Frame Relay that checks the ingress traffic rate against the CIR.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`8
`
`Petitioner RPX Corporation - Ex. 1024, p. 8
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`Frames that exceed this base rate are still accepted by the Frame Relay
`network, but they are marked as
`
`discard eligible (DE). Because the net-
`work can be oversubscribed, the data rate within a switch will at times
`exceed both the egress transmission rate and the local buffer storage.
`When this situation occurs, the switch will begin to discard data
`frames, and will do so initially for frames with the DE marker present.
`This scenario is essentially a two-level discard precedence architecture.
`It is an administrative decision by the service provider as to the relative
`levels of provisioning of core transmission and switching capacity, and
`the ratio of network ingress capacity used by subscribers. The associ-
`ated CIRs of the virtual circuits against this core capacity are critical
`determinants of the resultant deliverable quality of performance of the
`network and the layered VPNs.
`
`For example, at least one successful (and popular) Frame Relay service
`provider provides an economically attractive Frame Relay service that
`permits a zero-rate CIR on PVCs, combined with an SLA that ensures
`that at least 99.8 percent of all frame-level traffic presented to the
`Frame Relay network will be delivered successfully. If this SLA is not
`met, then the subscriber’s monthly service fee will be appropriately
`prorated the following month. The Frame Relay service provider pro-
`vides frame level statistics to each subscriber every month, culled from
`the Frame Relay switches, to measure the effectiveness of this SLA
`“guarantee.” This particular Frame Relay service provider is remark-
`ably successful in honoring the SLAs because they conduct ongoing
`network capacity management on a weekly basis, provisioning new
`trunks between Frame Relay switches when trunk utilization exceeds
`50 percent, and ensuring that trunk utilization never exceeds 75 per-
`cent. In this fashion, traffic on PVCs with a zero-rate CIR can generally
`avoid being discarded in the Frame Relay network.
`
`Having said that, the flexibility of PVCs allows discrete VPNs to be
`constructed across a single Frame Relay network. And in many
`instances, this scenario lends itself to situations where the Frame Relay
`network provider also manages each discrete VPN via a telemetry PVC.
`Several service providers have
`
`Managed Network Services (MNS) that
`provide exactly this type of service.
`
`Whereas the previous example revolves around the use of Frame Relay
`as a link-layer mechanism, essentially the same type of VPN mechan-
`ics hold true for ATM. As with Frame Relay, there is no data clock
`synchronization between the sender, the host network, and the
`receiver. In addition, the sender’s traffic is passed into the ATM net-
`work via an ingress function, which can mark cells with a
`Cell Loss
` (CLP) indication. And, as with Frame Relay, where a switch
`Priority
`experiences congestion, the switch will attempt to discard marked
`(CLP) cells as the primary load shedding mechanism, but if this step is
`inadequate, the network must shed other cells that are not so marked.
`Once again, the quality of the service depends on proper capacity engi-
`neering of the network, and there is no guarantee of service quality
`inherently in the technology itself.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`9
`
`Petitioner RPX Corporation - Ex. 1024, p. 9
`
`

`

`What Is a VPN? — Part II:
`continued
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The generic observation is that the engineering of Frame Relay and
`ATM common carriage data networks is typically very conservative.
`The inherent capabilities of both of these link-layer architectures do
`not permit a wide set of selective responses to network overload, so
`that in order for the network to service the broadest spectrum of
`potential VPN clients, the network must provide high-quality carriage
`and very limited instances of any form of overload. In this way, such
`networks are typically positioned as a high-quality alternative to dedi-
`cated circuit private network architectures, which are intended to
`operate in a very similar manner (and, not surprisingly, are generally
`priced as a premium VPN offering). Technically, the architecture of
`link-layer VPNs is almost indistinguishable from the dedicated circuit
`private data network—the network can support multiple protocols,
`private addressing, and routing schemes, because the essential differ-
`ence between a dedicated circuit and a virtual link-layer circuit is the
`absence of synchronized clocking between the sender and the receiver.
`In all other aspects, the networks are very similar.
`
`These approaches to constructing VPNs certainly involve scaling con-
`cerns, especially with regard to configuration management of pro-
`
`Virtual Connections (VCs) and routing issues. Configura-
`visioning new
`tion management still tends to be one of the controversial points in VPN
`management—adding new subscribers and new VPNs to the network
`requires VC path construction and provisioning, a tedium that requires
`ongoing administrative attention by the VPN provider. Also, as already
`mentioned, full mesh networks encounter scaling problems, in turn
`resulting in construction of VPNs in which partial meshing is done to
`avoid certain scaling limitations. The liabilities in these cases need to be
`examined closely, because partial meshing of the underlying link-layer
`network may contribute to suboptimal routing (for example, extra hops
`caused by hub-and-spoke issues, or redirects).
`
`These problems apply to all types of VPNs built on the “overlay”
`model—not just ATM and Frame Relay. Specifically, the problems also
`
`
`apply to Generic Routing Encapsulation (GRE) tunnels.
`
`MPOA and the “Virtual Router” Concept
`Another unique model of constructing VPNs is the use of
`Multiproto-
` (MPOA)
`, which uses RFC 1483 encapsulation
`. This
`col over ATM
`[6]
`[5]
`VPN approach is similar to other “cut-through” mechanisms in which
`a particular switched link layer is used to enable all “Layer 3” egress
`points to be only a single hop away from one another.
`
`In this model, the edge routers determine the forwarding path in the
`ATM switched network, because they have the ability to determine
`which egress point packets need to be forwarded to. After a network-
`layer reachability decision is made, the edge router forwards the packet
`onto a VC designated for a particular egress router. However, since the
`
`Address Resolution Protocol (ARP) for
`egress routers cannot use the
`destination address across the cloud, they must rely on an external
`server for address resolution (ATM address to IP address).
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`1 0
`
`Petitioner RPX Corporation - Ex. 1024, p. 10
`
`

`

`
`
`
`
`
`
`
`
`The first concern here is a sole reliance on ATM—this particular model
`does not encompass any other types of data link layer technologies,
`rendering the technology less than desirable in a hybrid network.
`Whereas this scenario may have some domain of applicability within a
`homogenous ATM environment, when looking at a broader VPN envi-
`ronment that may encompass numerous link-layer technologies, this
`approach offers little benefit to the VPN provider.
`
`Secondly, there are serious scaling concerns regarding full mesh mod-
`els of connectivity, where suboptimal network-layer routing may result
`because of cut-through. And the reliance on address resolution servers
`to support the ARP function within the dynamic circuit framework
`brings this model to the point of excessive complexity.
`
`The advantage of the MPOA approach is the use of dynamic circuits
`rather than more cumbersome, statically configured models. The tradi-
`tional approach to supporting private networks involves extensive
`manual design and operational support to ensure that the various
`configurations on each of the bearer switching elements are mutually
`consistent. The desire within the MPOA environment is to attempt to
`use MPOA to govern the creation of dynamically controlled, edge-to-
`edge ATM VCs. Although this setup may offer the carrier operator
`some advantages in reduced design and operational overhead, it does
`require the uniform availability of ATM, and in many heterogeneous
`environments this scenario is not present.
`
`In summary, this model is another overlay