[e2e] How can the VPN service level agreement be enforced crossing ASs?

Andrew Smith ah_smith at pacbell.net
Thu Apr 5 21:30:14 PDT 2001

I don't hold out too much hope that this is soluble just by monitoring and
intelligent re-routing of traffic. The conventional approach would be to
"engineer" the solution using preprovisioned resources (link-, memory-,
scheduling-bandwidth) to provide QoS across the switching points and the
links connecting them. The only missing piece, I think, is the control plane
to set this all up (somewhat non-trivial of course) - the data plane
mechanisms needed to do this are well documented and, I believe, widely


-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org]On Behalf Of Yingfei Dong
Sent: Thursday, April 05, 2001 8:02 PM
To: end2end-interest at postel.org; Ping Pan
Subject: Re: [e2e] How can the VPN service level agreement be enforced
crossing ASs?

Hi, Ping,

Thanks for your fast response. Actually, you make a more clear description
of the issue. When VPN across more than two ASs, the issue is even harder.
It is my pleasure to read the BGRP work.

For RFC 2547 BGP/MPLS VPNs, since BGP only covers the connectivity issue,
I guess, no service requirements can be descriped using BGP/VPN. (I need
to double check the BGP extension for this.)

For the "private NAP", it is proposed by InterNAP at


They don't give too much info about how they implement it. But it seems
not like a route reflector.

For the 'intelligent optimized routing' at their private NAP,
they monitor the congestion in different ASs (or across ASs),
and try to direct the traffic to get around the congestion part.
Similar ideas have been proposed in many projects, such as UW Detour, MIT
RON, Berkeley SPAND, AT&T RaDaR, etc.

I am not sure how they monitor the congestion at a generic NAP (not their
private NAP). (Obtaining this info on a private peering link should be
easy because it only involves one or two ISPs.)

Here comes another question:

-- how to get the congestion or loss info at a public NAP?

   Can we do it through some kind of tools like SNMP? I guess it must
   be an authentication process, or sth.

I hope someone from InterNAP here can give us a more clear description.



On Thu, 5 Apr 2001, Ping Pan wrote:

> Hi,
> We had described a new signaling going over multiple AS's using
> reservation aggregation. Here is the WEB pointer (we also had an expired
> draft there too.)
> http://www.cs.columbia.edu/~pingpan/projects/bgrp.html
> Setting up tunnels between two neighboring AS's is not too difficult.
> The problem is to set up tunnels over several transit AS's, where you
> need to control signaling overhead, states (N**2 problem, has anyone
> seen the latest AS growth chart? ;-)) and security (that is, you need to
> be able to block transit guys to sniff the end user information.) That's
> why you need to have aggregation.
> RFC2547 is also a good way to take care this....
> BTW, what's "intelligent optimzed routing" at private NAP's? Route
> reflectors?
> 2 cents.
> - Ping
> Yingfei Dong wrote:
> >
> > The service guarantee in a single domain is not too difficult to
> > However, if a src and a des of a VPN pipe are in two different ASs, how
> > the VPN is implemented? We can buy bandwidth guarantee from two
> > ISPs, but how to connect the two separarted pipe as a whole VPN pipe at
> > the edge of ASs?
> >
> > The whole VPN pipe either crosses a NAP or goes through a private
> > link between the two ASs. If it crosses a NAP, there is no control for
> > VPN pipe at the NAP. If it crosses a private peering link, are there
> > service agreements (e.g., bandwidth provision) on the private peering
> > between two ISPs?  (Most likely, the agreement is only about
> > through BGP policies.) If no service provision on the peering link, the
> > SLA of the VPN pipe is broken at the link.
> >
> > So, it is not clear how the SLA of a crossing-domian VPN is achieved
> > Could anyone point out some references about this?
> >
> > One possible example I know is InterNAP, but they don't give any details
> > about their implementation.
> > InterNAP sets up service agreements with ISPs and builds their own
> > NAPs. They claim that using their Private NAPs (which run their
> > intelligent optimzed routing algorithms) can direct the traffic to
> > a proper AS to achieve certain service quality.
> > How to implement the private NAPs is very interesting.
> >
> > Looking forward to your comments or references. thanks a lot,
> >
> > yingfei
> >
> > ===================================================
> > Yingfei Dong
> > Ph.D student, U of Minnesota,
> > 4-192 EECS Building,
> > 200 Union Street, SE            Tel: 612-626-7526
> > Minneapolis, MN 55455           FAX: 612-625-0572
> > ===================================================
> -- Ping Pan

Yingfei Dong
4-192 EECS Building,
200 Union Street, SE            Tel: 612-626-7526
Minneapolis, MN 55455           FAX: 612-625-0572

More information about the end2end-interest mailing list