120 5 SDN and NFV in 5G
If there is a miss in this table, the packet is not dropped and the service
set is not modified.
The path status table follows the application table or Microflow
table (will be described in the following section). Its purpose is to
determine which services in the service set have already been applied.
This is important because a packet may traverse the same perimeter
switch multiple times, and it should be treated differently each time.
The ingress port is sufficient to provide this information. If this table
is reached, it means that the packet has arrived on a node port,
connected directly to a service or router. The ingress port then tells us
which service was just applied, if any, and it also tells us the direction.
There is a global ordering of services in each direction (they may or
may not be the exact reverse of each other). Based on the direction
and the previous service, the service set is modified to exclude the
previous service and all other services that precede it.
The final table along the node port path is the next destination table.
It uses the direction and the service set as a key. This is a TCAM-like
table, with arbitrary bitmasks and rule priorities. Based on the direction bit, it essentially scans the bits in the service set according to the
global service ordering in that direction. The first or highest-priority
service it finds will be the next destination. If the service set is empty,
the next destination will be either the upstream or downstream router,
depending on the direction bit. The next destination may be connected
to the current switch or another one. If the destination is connected to
a different switch, then the destination MAC address is set to the value
corresponding to that service or router and the packet is transmitted
out through an appropriate transit port. If the destination is directly
connected, then the MAC addresses are updated as needed and the
packet is transmitted out to the corresponding node port.
5.2.1.3 Handle Dynamics with the Microflow Table
The Microflow table is added to handle dynamically generated rules.
We assume that operators have static policies for the subscribers and
applications. Therefore, the subscriber table and the application table
can be programmed with static rules. But in real time, operators may
want to add policies dynamically, or add more specific policies, or
higher priority policies. Moreover, policies may be added according
to the results of another middlebox, for example, DPI. We add the
Microflow table to accommodate such dynamics.
Précédent

- 140/195

Suivant