[e2e] Admission Control and Policing in MPLS

[Jon Crowcroft]

on a more general point...

personally , i could never see the fundamental different between
packet drop mechanis and congestion control
and 
call admission control with call blocking

in both cases, you have to look at the provisioning of buffers - 
based on some model of the traffic source, and make decisions about
which packet/flow to drop/block based on the specific source model and
the multiplexing and aggregate behaviours...its just a
timescale/granualrity difference in the end

we dont just have to call block, we could do pre-emption, or re-routng
of calls, and we dont just have to drop-tail in a fifo queue, we could
do RED, or fair dropping or whatever...


anyhow, as you say, as the edge/core system evolves right, no qos/cac
is needed it seems...although one could imagine a world where the net
moves back to a regime where it might be..

In missive <418CE1B1.6040908 at cs.columbia.edu>, Ping Pan typed:

 >>Hi,
 >>
 >>Traffic provisioning at network edge seems to be largely depending on 
 >>carriers. Some of the existing networks maintain traditional (ATM/frame) 
 >>connections with almost static configuration. However, this is likely to 
 >>change as they all move toward higher bandwidth (GigE) and offer more 
 >>services.
 >>
 >>But if the bandwidth is high enough at access/edge, it becomes a simple 
 >>over-provisioning model, thus no QoS/CAC needed....
 >>
 >>Another observation, most deployed MPLS networks in metro area use LDP 
 >>to setup LSP's. LDP does not have QoS awareness by design.
 >>
 >>- Ping
 >>
 >>
 >>Sudeep Goyal wrote:
 >>> Hi Ping Pan,
 >>> 
 >>>    Thanks for the information. But, you say that CAC would make sense at 
 >>> the edge.  Would you please tell what are the mechanisms used in real 
 >>> ISP networks to find out the explicit paths that meet certain QoS flow 
 >>> requirement. Or are the paths are statically (manually) set without any 
 >>> dynamic traffic engineering ?
 >>>  I am presently working on algorithms on admission control on MPLS (and 
 >>> MPLS over DiffServ network) and have worked out few algorithms in 
 >>> theory. But, I donot yet know how and what actually ISPs are doing in 
 >>> reality for admission control ? Does it make sense commercially to come 
 >>> up with good TE techniques or algorithms that would help us find 
 >>> explicit paths in MPLS network at the edge that would meet certain QoS 
 >>> requirements. Or may be, given a LSP path, it makes more sense going for 
 >>> a DiffServ admission control rather than finding explicit path.
 >>> 
 >>> Thanks for anticipated help.
 >>> 
 >>> warm regards,
 >>> Sudeep
 >>> 
 >>> 
 >>> On Thu, 4 Nov 2004, Ping Pan wrote:
 >>> 
 >>>> First, in the (MPLS) backbone networks, most of the links are
 >>>> over-provisioned, so not sure CAC and many QoS enforcement would make 
 >>>> much
 >>>> use there.
 >>>>
 >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP,
 >>>> that can be used to carry DiffServ class. The LSP's that carry such
 >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can 
 >>>> run the
 >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the
 >>>> packets within the LSP. This function becomes more important during flow
 >>>> aggregation.
 >>>>
 >>>> There are a bunch of drafts from Cisco on this topic over the years.
 >>>>
 >>>> - Ping
 >>>>
 >>>>> -----Original Message-----
 >>>>> From: end2end-interest-bounces at postel.org
 >>>>> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Fahad Dogar
 >>>>> Sent: Wednesday, October 20, 2004 12:12 AM
 >>>>> To: end2end-interest at postel.org
 >>>>> Subject: [e2e] Admission Control and Policing in MPLS
 >>>>>
 >>>>>
 >>>>> Hi,
 >>>>>
 >>>>> I would like to know the mechanism employed in MPLS networks
 >>>>> for admission control and the process of subsequently
 >>>>> policing the flow in order to ensure that it does not violate the SLA.
 >>>>>
 >>>>> Any help or pointers to any standardized requirements would
 >>>>> be greatly appreciated.
 >>>>>
 >>>>> Thanks in advance,
 >>>>> Fahad
 >>>>>
 >>>>
 >>>>
 >>> 

 cheers

   jon