Commit 3e908bf3 authored by cedgar's avatar cedgar
Browse files

small updates

parent ea8c631a
......@@ -555,31 +555,30 @@ allocated as you expected.
## Part 2: Rate Limiting and Priorities
At this point, you have competed a basic implementation of RSVP.
Congratulations!
At this point, you have completed a basic implementation of centralized RSVP. Congratulations!
As you may have noticed, even tough that the controller takes into account the
bandwidth hosts request when computing the reservations, switches do not perform
any rate limiting. Thus, a host making a 1Mbps reservation is still able to get
full bandwidth. Furthermore, at this point, all the reservations are treated equally.
As you may have noticed, even though the controller takes into account the
bandwidth hosts request when computing the reservations, edge switches do not perform
any rate limiting. In fact, a host making a 1Mbps reservation is able to get
full bandwidth. Furthermore, at this point, all the reservations are treated equally.
In this second part of the exercise, we will improve our implementation and rate
limit host reservations using meters at ingress switches. Also, by extending our
`add_reservation` controller function, we will introduce the sense of priority to
`add_reservation` controller function, we will introduce a sense of priority to
the reservations.
### Task 1: Reservation rate limiting with meters
During the last [lecture](https://polybox.ethz.ch/index.php/s/A7lGH0JQsGSpBob)
you were taught P4 stateful data structures. There, we showed you
you were taught different P4 stateful data structures. There, we showed you
that direct/indirect color `meters` can be used to rate limit traffic.
The `bmv2` software switch implements the so called two-rate three-color marker meters.
The `bmv2` software switch implements the so-called two-rate three-color marker meters.
You can find more details in the corresponding [RFC](https://tools.ietf.org/html/rfc2698).
The figure below shows how two-rate three-color marker meters work. In the figure we use
the packet size as count unit, however `bmv2` supports both bytes and packet-based meters.
These meters are configured using four parameters:
Two-rate three-color meters are configured using four parameters:
* CIR(committed information rate): is the rate per unit of time in bytes or packets at which the CBS bucket is filled.
* PIR(peak information rate): is the rate per unit of time in bytes or packets at which the PBS bucket is filled.
......@@ -598,7 +597,7 @@ If we consider a byte-based meter, a packet of size `B` is colored as follows:
In this task, you will need to extend your `rsvp.p4` program such that each reservation
is metered and all non-green packets get dropped. Furthermore, you will have to extend
your controller code such that after every reservation addition or modification its
your controller code such that after every reservation (addition or modification) its
associated meter is configured properly.
> Hint: in the last lecture there are some slides in which you can find how to define and use meters.
......@@ -608,10 +607,11 @@ associated meter is configured properly.
1. Whenever a meter is executed, the color is saved into a metadata field. Define that field in your metadata structure.
2. Define a direct meter at the beginning of your ingress pipeline. You can find an example in the slides and
some documentation in the [v1model documentation](https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4).
3. Read the meter in all the `mpls_ingress_x_hop` actions to your metadata field.
4. Update your ingress control logic and drop all the packets for which the meter is yellow or red (not green).
3. Associate the direct meter with the table `FEC_tbl`.
4. Read the meter in all the `mpls_ingress_x_hop` actions to your metadata field.
5. Update your ingress control logic and drop all the packets for which the meter is yellow or red (not green).
At this point you have all the P4 logic to rate limit your traffic reservations.
At this point, you have all the P4 logic to rate limit your traffic reservations.
However, you still need to add some small modifications to your controller code such
that associated meters get configured with the desired rate.
......@@ -621,7 +621,7 @@ that associated meters get configured with the desired rate.
meters using our control plane API you will have to use `meter_set_rates(meter_name, handle, rates)`.
`meter_name` is the name you called the meter in `P4`, `handle` is the table handle for the reservation rule and
`rates` is a list of the form `[(CIR, CBS), (PIR, PBS)]`. *IMPORTANT:* in `bmv2` `CIR` and `PIR` are the bucket
filling rate every micro second. For example, if `CIR=1` the bucket is filled at a rate of 1000000/s.
filling rate per microsecond. For example, if `CIR=1` the bucket is filled at a rate of 1000000 Bytes/s (or packets).
2. Implement the function `get_meter_rates_from_bw(self, bw, burst_size)`. This function has to return
`[(CIR, CBS), (PIR, PBS)]`. Use `bw` (Mbps) to compute `CIR` and `PIR` (in bytes).
......@@ -640,7 +640,7 @@ that associated meters get configured with the desired rate.
1. Start the topology and the controller.
2. Make 2 bidirectional reservations from `h1->h5` and `h2->6`. For the
first use `2Mbps`, for the second `8Mbps`.
first one use `2Mbps`, for the second one `8Mbps`.
```
======================================================================
......@@ -707,21 +707,21 @@ still did not use the `priority` attribute when performing the allocations. In t
you will have to modify the `add_reservation` controller function such that some reservations
have a higher priority over others.
When a a high priority reservation comes and there is no space left many different things
When a high priority reservation comes and there is no space left many different things
could be done. For example, previous reservations can be moved to make space, reservations
with lower priority can be deleted to make space, etc. As a guide we propose you one way,
which is the one we will provide as a solution. Our proposed solution is not perfect, but
with lower priority can be deleted to make space, etc. We propose one possible implementation,
which will then be the one we will provide as a solution. Our proposed solution is not perfect, but
does well enough while not needing a major change to the current implementation. In any case,
feel free to implement a different algorithm.
We propose the following algorithm:
1. if the reservation (addition or modification) fits in the current network we do the same than before.
2. if the reservation (addition or modification) does not fit in the network:
1. remove all the reservations with a lower prioiry than the requested one. Hint: you don't need to really remove them from switches, you can just remove its capacities.
2. Check if the requested reservation fits the network without the lower priority ones.
3. if it fits, add or modify it. Now, take all the reservations with lower priority that you `virtually` removed, and allocate them starting with the ones with highest priority. Some will remain in the same path, some will be moved to a new path. If they don't fit anymore, delete them.
4. if it does not fit remove the entry if this is a modification (the entry already existed)
2. if the reservation (addition or modification) does not fit in the current network:
1. remove (`virtually`) all the reservations with a lower priority than the requested one. Hint: you don't need to remove them from switches, you can just remove its capacities.
2. Check if now, (without the low priority reservations) the requested reservation fits the network.
3. if it fits, add or modify it. Now, take all the reservations with lower priority that you `virtually` removed, and allocate them starting with the ones with the highest priority. Some will remain in the same path, some will be moved to a new path, and some, if they don't fit anymore, will be deleted.
4. if it does not fit, if there is an existing entry for this reservation, delete it.
> Hint: make sure `self.links_capacity` is updated properly in each of your steps. Sometimes, when you virtually remove
reservations you will have to add the capacity to links.
......
......@@ -126,7 +126,7 @@ control MyIngress(inout headers hdr,
action mpls_ingress_1_hop(label_t label_1) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -138,7 +138,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_2_hop(label_t label_1, label_t label_2) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -156,7 +156,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_3_hop(label_t label_1, label_t label_2, label_t label_3) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -180,7 +180,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_4_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -210,7 +210,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_5_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -246,7 +246,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_6_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5, label_t label_6) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -288,7 +288,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_7_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5, label_t label_6, label_t label_7) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -336,7 +336,7 @@ control MyIngress(inout headers hdr,
}
action mpls_ingress_8_hop(label_t label_1, label_t label_2, label_t label_3, label_t label_4, label_t label_5, label_t label_6, label_t label_7, label_t label_8) {
// PART 2 TASK 1.3 Read meter
// PART 2 TASK 1.4 Read meter
hdr.ethernet.etherType = TYPE_MPLS;
......@@ -407,7 +407,7 @@ control MyIngress(inout headers hdr,
NoAction;
}
default_action = NoAction();
meters = rsvp_meter;
// PART 2 TASK 1.3 Associate table with meter
size = 256;
}
......@@ -459,7 +459,7 @@ control MyIngress(inout headers hdr,
mpls_tbl.apply();
}
// PART 2 TASK 1.4 Drop all the packets for which the color is not green
// PART 2 TASK 1.5 Drop all the packets for which the color is not green
}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment