Tip:
Highlight text to annotate it
X
So now let us take a step back and see how we would apply this information in order to
do policy enforcement, which is a combination of quality-of-service, access control and
firewalls for the traffic coming from different users. So typically, the way traffic goes
through the Meru system is that it first goes over a wireless edge from a device to an access
point, and then it goes over a back-end tunnel from an access point to a controller, and
then logically it goes not long from the controller to the wired system. And while it hits the
controller, this is where the policy enforcement then hits it. Now what is visible in terms
of user traffic at this point? We have the source IP, we have the destination IP, we
have the source port, destination port, we have the protocol. And we have the filter
ID.
If you remember from the previous discussion, once a user logs in, they get a filter ID
depending on which user is transmitting, this filter ID is also gleamed in the controller
from the traffic that they send. So this six-tuple, the source and destination IP, source and
destination port, protocol and filter ID are used for classification. So notice that this
now adds two additional dimensions, IP-based and application-based.
To summarize then, the way packets are classified is based on user, service, location, IP and
application. This is the first step of the policy enforcement which is classification.
And of course you can define classification rules based on any combination of these six
parameters. Once the traffic gets classified, we identified a particular session ID and
now it goes to the second phase which is the flow-mapping phase. In the flow-mapping phase,
a particular session might retain itself as an individual flow or multiple session can
get aggregated into a single flow. So step one, classification.
Step two, flow-mapping where you can treat each session, in other words, each of these
sessions -- five tuples or six tuples -- each TCP connection individually, or you can map
and aggregate them all to one. One instance of aggregation would be if the policy of the
customer here is that all guest users, in aggregate, will get a maximum of one megabit
per second, in that case what you do is you classify the packets, and of course you assign
the filter ID based on the SSID the users connect to, and all the sessions that map
this filter ID will get aggregated into a single flow. Once that happens, we then go
to the action side. In the action, there are essentially three operations once can do.
You can either forward the packet or you can drop it, or there's a third element in our
system which is called capture, and I'm going to get to that in a second.
So when you forward packets, you might forward the packet preserving its original QoS tags,
in other words quality-of-service tags, or it is possible for the system to actually
overlay these quality-of-service tags by writing some additional or overwriting it with configured
tags based on the policy rules. In addition to QoS tagging, we also support rate limiting,
and this is token-bucket based rate limiting, which is a concept which should be familiar
to pretty much anybody in the field who understands networking.
The idea here is you classify and then you aggregate, then you can rate limit on a per-session
or aggregate basis. So when I was giving you the example of all the guest users being rate
limited, first sessions come in, they get aggregated into a single flow, then we apply
the rate limit on that particular flow. So at this point, I hope it's clear how the forwarding,
dropping and the changing of the parameters during the forwarding phase works. For the
remaining aspect is how to deal with capture, and this is interesting because in the Meru
system we actually have application-aware packet classification entry.
So let's take an example. If you're running a voice call, in the application itself, the
signaling protocol SIP is completely decoupled from the actual packet transmission which
happens over the RTP stream. So what we do is write rules to capture SIP packets, capture
meaning that there is a local process in the controller, so we can forward, drop or capture.
So we capture the SIP packet, we will parse it by doing stateful deep packet inspection,
we figure out the source and destination phone numbers, we will figure out the P-time, which
is the periodicity of packet transmission, we will figure out the data rates and essentially
we will figure out the total resources that are called. And on that basis, we can do call-admission
control, we can do more sort of enhanced voice-management capabilities which will be dealt with in a
companion video.
So the point here is that the quality-of-service and firewall policy framework allows us to
capture packets and then instantiate application modules or application-aware modules that
then provide treatment on the packets, and at that point they may throw the packet or
they may forward it. In the SIP case, for example, the SIP flow-detector module parses
it, figures out whether you can support call-admission for that particular call or not, and if so
simply forwards the packet, transmitting it. So devices not bound never know that these
packets have actually been opened and peered into and action has been taken on them.
So at this point, let me step back and summarize all the capabilities of the system. There's
classification, flow mapping and action. The action combines firewall, such as dropping,
along with quality-of-service which is tagging and rate limiting, along with application-aware
treatment of flows which is through packet capture. Thank you.