[e2e] Admission Control and Policing in MPLS
Satish Raghunath
rsatish at yahoo.com
Sun Nov 7 15:23:24 PST 2004
I would like to point to recent related work we did at
AT&T Labs Research and RPI, regarding admission
control, traffic matrices and provisioning when we are
dealing with MPLS based IP VPNs.
In our upcoming paper in INFOCOM 2005, we examine the
question of admitting VPNs (point-to-multipoint
aggregates in general) and how it is impacted by
admission control choices and presence of Traffic
matrix estimates:
http://networks.ecse.rpi.edu/~rsatish/vpn_resmgmt.pdf
The above simulation study is based on a large-scale
measurement study we did to estimate IP VPN traffic
matrices. As Dr. Crowcroft notes, this is not a
trivial question. Our paper in IMC 2004 sheds more
light on state-of-the-art in Carrier measurement for
VPNs and how best to glean traffic matrices from them:
http://networks.ecse.rpi.edu/~rsatish/vpn_tm.pdf
In combination, the papers above deal with the
question of how to obtain traffic matrices in a
realistic carrier scenario; given TMs we then look at
what impact such information has in the presence of
statistical admission and/or signaling-based admission
control choices.
Best,
Satish
-------- Original Message -------- Subject:
Re: [e2e] Admission Control and Policing in MPLS
Date: Sun, 07 Nov 2004 12:04:59
+0000 From: Jon Crowcroft
<Jon.Crowcroft at cl.cam.ac.uk> To:
Ping Pan
<pingpan at cs.columbia.edu>,end2end-interest at postel.org,
Jon.Crowcroft at cl.cam.ac.uk
I can't stress how much I agree about the evolution of
carrierbusiness - this is an area that is extremely
interesting, bothcommercially to vendors and service
providers, but also to researchersas we need to
consider how to provision for aggregates
oftraditional traffic, but flowing over VPNs and
current work onprovisioning has tended to assume the
traffic matrix is transparent,whereas its partially
opaque in a vpn....plus the "arrival process" for a
network provider is of entire legacyenterprise nets
(previously provisioned using frame relay or atm )
moving over to the IP core...it would be interesting
to get estimatesfrom the large teleco/isps (at&t
obviously, but on a smaller scale alot of european
outfits - certinly BT, FT and DT and telecom italia)of
the amount of legacy net that we might expect to
migrate...also agree about voip..In missive
<418D5B98.9050103 at cs.columbia.edu>, Ping Pan typed:
>>> what i mean is that the _algorithms and framework_
to do congestion >>> control and to do CAC are related
and similar - the timescales are >>> different - one
is per packet or rtt, the other is per session or flow
>>> or call or forwarding equiv. class or diff serve
class or whatever >>> aggregate you want but as the
system gets very big, the differences >>> get very
small indeed actually. >>> >> >>Agree 100%. With the
advance in silicon, per-flow policing/shaping,
>>queuing and scheduling for various traffic types,
dropping... can be >>done at very high speed. Not
sure there much magic in this area. The >>issue
becomes where to apply all this. >> >>> i wasnt
suggesting that all video/voice/game traffic should be
>>> converted to be elastic adaptive behaviour
(although its not so hard >>> for many of them) -
conversely one can argue that limiting the number >>>
of TCP flows through CAC might give a good (near
guaranteed ) response >>> time to web users too - sure
- two sides of same coin.... >>> In missive
<Pine.LNX.4.61.0411062150050.15463 at mars.cse.iitb.ac.in>,
Sudeep Goya >>> l typed: >>> >> >>Maybe. There are a
couple of exceptions here. >> >>Since the beginning of
commercial data networking, carrier's business
>>model has been selling guaranteed bandwidth to
individual users. Much of >>the telecom operation has
been built around this model (accounting, >>planning,
restoration, OAM...). And this is not likely to change
in the >>near future, even when you have GigE all
over the place. Thus, per-flow, >>per-customer,
per-call, per-whatever policing will still be in place
at >>edge. However, this does not impact how e2e
applications suppose to work >>- long live TCP. ;-)
>> >>Another issue is the method of migrating traffic
from the existing >>networks to new ones, while still
making money for the carriers. This is >>likely
taking place at the edge. During the migration, the
entire suite >>of QoS must be in place for many
business users. This is where some >>DiffServ type of
conditioning would be useful. This is the reason why
>>you see a number of proposals on ATM-MPLS
interworking in recent months. >>Again, you may find
them from IETF MPLS/PWE3/L2VPN WG drafts.... >> >>As
for the traffic types. VoIP traffic is not CBR, and
never will be. >>;-) In fact, the entire VoIP looks
like an enterprise/end-user >>application to me. The
switches/routers have no way of knowing what it >>is
from the packet itself. One deployment scenario I have
seen is to map >>VoIP traffic onto a VLAN, and
provisioning BW on that VLAN from network >>edge. In
this case, a simple priority queue or a half decent
WFQ would >>do the job. >> >>- Ping >> >>> >>On Sat,
6 Nov 2004, Jon Crowcroft wrote: >>> >> >>> >>> 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 >>> >> >>> >>Jon. In my humble opinion,
there is a big difference depending on the >>>
>>kind of traffic that is being injected into the
network. >>> >> >>> >>Say, for example you have a
CBR (constant bit rate) traffic for VoIP, >>>
>>video-conferencing and you need to provide stringent
qos requirements. >>> >>You donot bring congestion
in the network and here, CAC plays important >>>
>>role. Because any implementation of congestion
control mechanism at the >>> >>core nodes would
produce delay etc which we donot want for CBR kind of
>>> >>traffic. The schedulling in this case at each
node would also be highest. >>> >>In above traffic,
delay and jitter are important qos parameters. >>> >>
>>> >>But, for elastic traffic (like FTP) which is
also greedy and built over >>> >>TCP we need to be
careful about the throughput because here throughput
is >>> >>more important than delay and hence, we
need to deploy proper RED >>> >>mechanism and
maintain high throughput and admit more flows.
Dropping of >>> >>packets and little delay is
accpetable. But, throughput should be high. >>>
>>Therefore, CAC algorithm should consider this and
accept such elastic >>> >>traffic accordingly,
fulling knowing that RED and congestion control >>>
>>(TCP) is used for such traffic. >>> >> >>> >>For
CBR traffic, CBR algorithm cannot take the chance for
congestion and >>> >>most importantly, delay and
loss of packets, therefore, never >>>
>>overprovision any flow (flows are also more
UDP-oriented). Then there can >>> >>be other kinds
of flows like VBR, elastic short-lived flows and
best-effort. >>> >> >>> >> Thanks Ping Pan for the
information again :) But, plz help me clarify >>>
>>following: >>> >> >>> >>> >> >>> >>> >>Another
observation, most deployed MPLS networks in metro area
use LDP >>> >>> >>to setup LSP's. LDP does not have
QoS awareness by design. >>> >> >>> >>This is
informative. But, could you plz tell if coming up with
good MPLS >>> >>over DiffServ CAC algorithms that
would help the incoming traffic meet its >>>
>>requested QoS be useful (commercially). From what
you have said, it feels >>> >>that ISPs are not
doing it and may not need it at present, but future
could be a >>> >>possiblity. Am i right? >>> >> If
people have already done some work, can you plz refer
some links to me >>> >>(from where I can know the
state-of-art of MPLS over DiffServ admission >>>
>>control algorithms)? >>> >> >>> >>Thanks a lot
Again. >>> >> >>> >>Warm Regards, >>> >>Sudeep >>>
>> >>> >> >>> >> >>> >> >>> >> >>> >>> >>- 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 >>> >>> >>> >>> >>> >> >>> >>-- >>> >>>
cheers >>> >>> jon cheers jon
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
More information about the end2end-interest
mailing list