e service path is set up correctly; the traffic traverses service S1, S2, and S3 in this order. 2) There is no failure at the forwarding path, that is, switches F0-F4 function correctly to forward the packets. 3) There is no failure in the services, that is, services S1-S3 are alive and send/receive packets correctly. What it does not imply is that services S1-S3 perform the right action to the packet. That is, we do not test if the service is functioning correctly, since this highly depends on the service logic and the knowledge of the service. From the description above, we can see that some services may dis- card packets as a part of their functions, for example, firewalls to stop flows, rate limiters to drop packets, which may require more careful interpretation to the monitoring results. We propose that the moni- toring system analysis module should be aware of the functional logic of each service and take this into consideration when interpreting the results. Similarly, it is possible that some services modify the packet header fields, such as NAT. If the controller can accurately know the modification, it can create a mapping of the flows before and after a 5.2 Service Function Chaining service and still capture the packets for the same flow. If not, then the controller can use a combination of packet headers and payloads as the key to capture packets. 5.2.2.1 Handling Multiple Monitoring Tasks In the second step, we tested that the chain has been implemented correctly. In the third step, we need to continuously monitor the chain to make sure there is no failure in any component of the network. Our key idea is that in this step, we do not need to monitor after every service in the chain in the second step. Instead, we can monitor a small number of points in the service chain, or even just monitor the two ends of a service chain. For example, as shown in Figure 5.10, there are two service chains, the grey one and the black one. We define a monitor point to be the point where we install mirroring rules. Figu