the importance of Service Level Agreements (SLA’s)

It is worthwhile at this point to briefly examine the importance of Service Level Agreements (SLA's) in regards to the deployment of

VPN's.  SLA's are negotiated contracts between VPN providers and their subscribers, which contain the service criteria to which the

subscriber expects specific services to be delivered.  The SLA is arguably the only binding tool at the subscriber's disposal with which to

ensure that the VPN provider delivers the service(s) to the level and quality as agreed, and it is in the best interest of the subscribers to

monitor the criteria outlined in the SLA for compliance.  However, Service Level Agreements present some challenging technical issues

both for the provider and the subscriber.  For the subscriber, the challenge is to devise and operate service measurement tools which can

provide a reasonable indication as to what extent the SLA is being honored by the provider.  Also, it should be noted that a subscriber

may use a SLA to bind one or more providers to a contractual service level, but if the subscriber's VPN spans multiple provider's

domains, the SLA must also encompass the issue of provider interconnection and the end-to-end service performance.  For the provider,

the challenge lies in honoring multiple SLA's from a number of service providers.  In the case of an Internet PDN provider, the common

mode of best effort service levels, is not conducive to meeting SLA's, given the unpredictable nature of the host's resource allocation

mechanisms.  In such environments, the provider either has to ensure that the network is very generously engineered in terms of the ratio

of subscriber access capacity to internal switching capacity, or the provider can deploy service differentiation structures to  ensure that

minimum resource levels are allocated to each SLA subscriber.  It must be noted that the former course of action does tend to reduce the

benefit of aggregation of traffic, which in turn does have an ultimate cost implication, while the latter course of action does have

implications in terms of operational management complexity and scalability of the network.

The alternative to using the Internet as a VPN today is to lease circuits, or similar dedicated communications services, from the public

network operators (the local telephone company in most cases), and create a completely private network.  It is a layering convention

which allows us to label this as "completely private," as these dedicated communications services are (at the lower layers of the protocol

stack) again instances of virtual private communications systems constructed atop a common transmission bearer system.  Of course,

this is not without precedent, and it must be noted that the majority of the early efforts in data networking, and many of the current data

networking architectures, do not assume a deployment model of  ubiquitous public access.

As an aside, it should be noted that this is quite odd, when you consider that the inherent value of an architecture where ubiquitous public

access over a chaotic collection of closed private networks had been conclusively demonstrated in the telephony marketplace since the start of

the 20th century.  While the data communications industry appears to be moving at a considerable technological pace, the level of experiential

learning, and consequent level of true progress as distinct from simple motion, still leaves much to be desired!

Instead of a public infrastructure deployment, the deployment model used has been that of a closed (or private) network environment

where the infrastructure, addressing scheme, management, and services were dedicated to a closed set of subscribers.  This model

matched that of a closed corporate environment, where the network was dedicated to serve a single corporate entity as the sole client.

This precursor to the VPN can be called the private data network, and was physically constructed using dedicated local office wiring and

dedicated leased circuits (or private virtual circuits from an underlying switching fabric such as X.25) to connect geographically diverse

sites

the importance of Service Level Agreements (SLA’s)

It is worthwhile at this point to briefly examine the importance of Service Level Agreements (SLA's) in regards to the deployment of

VPN's.  SLA's are negotiated contracts between VPN providers and their subscribers, which contain the service criteria to which the

subscriber expects specific services to be delivered.  The SLA is arguably the only binding tool at the subscriber's disposal with which to

ensure that the VPN provider delivers the service(s) to the level and quality as agreed, and it is in the best interest of the subscribers to

monitor the criteria outlined in the SLA for compliance.  However, Service Level Agreements present some challenging technical issues

both for the provider and the subscriber.  For the subscriber, the challenge is to devise and operate service measurement tools which can

provide a reasonable indication as to what extent the SLA is being honored by the provider.  Also, it should be noted that a subscriber

may use a SLA to bind one or more providers to a contractual service level, but if the subscriber's VPN spans multiple provider's

domains, the SLA must also encompass the issue of provider interconnection and the end-to-end service performance.  For the provider,

the challenge lies in honoring multiple SLA's from a number of service providers.  In the case of an Internet PDN provider, the common

mode of best effort service levels, is not conducive to meeting SLA's, given the unpredictable nature of the host's resource allocation

mechanisms.  In such environments, the provider either has to ensure that the network is very generously engineered in terms of the ratio

of subscriber access capacity to internal switching capacity, or the provider can deploy service differentiation structures to  ensure that

minimum resource levels are allocated to each SLA subscriber.  It must be noted that the former course of action does tend to reduce the

benefit of aggregation of traffic, which in turn does have an ultimate cost implication, while the latter course of action does have

implications in terms of operational management complexity and scalability of the network.

The alternative to using the Internet as a VPN today is to lease circuits, or similar dedicated communications services, from the public

network operators (the local telephone company in most cases), and create a completely private network.  It is a layering convention

which allows us to label this as "completely private," as these dedicated communications services are (at the lower layers of the protocol

stack) again instances of virtual private communications systems constructed atop a common transmission bearer system.  Of course,

this is not without precedent, and it must be noted that the majority of the early efforts in data networking, and many of the current data

networking architectures, do not assume a deployment model of  ubiquitous public access.

As an aside, it should be noted that this is quite odd, when you consider that the inherent value of an architecture where ubiquitous public

access over a chaotic collection of closed private networks had been conclusively demonstrated in the telephony marketplace since the start of

the 20th century.  While the data communications industry appears to be moving at a considerable technological pace, the level of experiential

learning, and consequent level of true progress as distinct from simple motion, still leaves much to be desired!

Instead of a public infrastructure deployment, the deployment model used has been that of a closed (or private) network environment

where the infrastructure, addressing scheme, management, and services were dedicated to a closed set of subscribers.  This model

matched that of a closed corporate environment, where the network was dedicated to serve a single corporate entity as the sole client.

This precursor to the VPN can be called the private data network, and was physically constructed using dedicated local office wiring and

dedicated leased circuits (or private virtual circuits from an underlying switching fabric such as X.25) to connect geographically diverse

sites