may get complicated by the consideration of whether some sort of metadata is needed to be implanted in the flow. The answer to the above-cited question may depend on the vision of the role of the controller and its service chaining application, specifically whether they will be charged with creating a chain that precludes any inter-block knowledge. It may also depend on whether the virtualization point of view limits function decomposition to the same virtual device or composite and thus separates an internal chain that uses some IPC mechanism allowing internal embedded metadata from the external chain. Metadata can be both- the implicit or the explicit. The explicit alternative, to embed the metadata, may result in extensions in packets to pass metadata from one chain member to another that will almost certainly require standardization to promote an open environment and may bring on collateral concerns about the transparency of such augmented flows to the existing network infrastructure. Networking an Application Level Approach A solution can be explored, by using application-based protocol. The network construct view requires tunneling because data flows have intrinsic routing that needs to be obscured. This view assumes manipulation of the network protocols to direct the flows as well as to manage metadata, with the aid of a controller. Data flow in treated as application input and output in the application construct view. Applications are made to run on servers using discrete sockets where servers have resolvable names (DNS). The service instance name to IP address binding identifies the load balancer (or an any cast address for a bank of ADC/load balance capacity-the assumption of a load balancer is quite common) for a set of components that run the service and potentially multiple input and output ports representing different application personalities (i.e., configurations or behaviors). Bidirectional flows use two personalities. (Monge et al., 2015) The mapping from internal service ports to external trans