not suitable for the inline service setting. In traditional network, the loss of ping/traceroute packets indicates the path problem. However, in our setting, the ping/traceroute packet may not be recognized by the service (middlebox) in the middle of the path, and thus got dropped. Thus, we cannot simply say the symptom of lost measurement packets is due to the path reachability problem. Therefore, we need a different method to measure the path reachability for inline service chaining. We define the reachability problem of inline service chaining as fol- lows. Assuming that a flow f traverses service chain (S1, S2, and S3) in order, the network topology is shown in Figure 5.9. In this example, the services are connected to switches F1, F2, and F3, respectively. The flow enters from the ingress switch FO and exits the network from 5.2 Service Function Chaining direction table table [in _port] [dmac] set dir forward microflow table path status table [dir, sip, dip, proto, sport, dport] serv_set [in_port] modify serv_set dir == up? sub_ip = dip sub_ip = sip next destination app_ip = sip app_ip = dip table app_port = sport app_port = dport [dir, serv_set] forward subscriber table [dir, sub_ip] ABBREVIATIONS: in_port: ingress port dmac: destination MAC address sip: source IP address set serv_set dip: destination IP address proto: IP protocol field sport: source TCP/UDP port dport: destination TCP/UDP port dir: direction of traffic application serv_set: inline service set table sub_ip: subscriber IP address [dir, app_ip, proto, app_port] app_ip: application IP address app_port: application port NOTE: "forward" means output to a port and possibly modify source and destination MAC addresses modify serv_set Figure 5.8 Data path lookup diagram. 5 SDN and NFV in 5G Controller Service Figure 5.9 Example to show service chain reachability. egress switch F4. The goal is to test that flow f has traversed the path (FO -F1-S1-F1-F2-S2-F2 - - - - - - F3 - S3 - F3 - F4). The reach- ability implies three dimensions as follows: 1) Th