The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Dec> msg00070



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS VPN SLAs

  • From: "Brijesh Kumar" <bkumar@ennovatenetworks.com>
  • Date: Mon, 4 Dec 2000 15:11:13 -0500
  • Importance: Normal

milos milos writes;
> What kind of SLAs are provided to MPLS VPN customer? If
> there's a VPN with
> three sites - A,B, C- do you get specific SLA for bandwidth
> and latency for
> each link (A-B, A-C, B-C) or do you get a SLA "into the
> cloud" (e.g. A is
> allowed 128K outgoing and 64K incoming, B is allowed 256K
> outgoing and 192K
> incoming, etc..) and so long you don't send more than allowed it's
> guaranteed?

It depends on what a "SLA" tries to measure and control.

SLAs into clouds can only be meaningful when VPN traffic can be deemed
as a commodity (buy x amount of commodity c for  price y). Generally
not a very useful concept for data networking applications. But can be
useful in some circumstances e.g., encrypt all traffic into the cloud
(or encrypt traffic for particular applications regardless of source
and/or destination).

For any SLA to be really useful, a SLA should be closely aligned to
the need of one or more user applications (otherwise, why bother?). As
most data applications are point to point - they need service
provisioning from one end to another end. Therefore, to be of any
great use - VPNs should support SLAs that meet specific application
needs between any two sites. One should be able to provision QoS from
A to B & C, from B to A & C and from C to B & A. As mpls tunnels
between edge nodes (PEs) are likely to be shared by more than one
VPN - traffic engineering becomes a major issue in supporting per VPN
based SLAs. But, this is the right way to provision SLAs in VPNs.

Cheers,

--brijesh
Ennovate Networks Inc.



  • References: