__________________________  
                                           {                          }
									       {      SDN Controller      }   
                                           {__________________________}

                       +---------1:C:2----------+
                       |           |            |
                       2           |            2
          A:1--------1:B:3-------1:E:2--------1:D:3-----------1:F
		               4           |            4
				       |           |            |
			           +---------1:G:2----------+

Figure 1: Topology Example

Assumptions in the above network diagram: An SDN controller is connected to the network and is able to retrieve the topology and traffic information. Based on the information and their policies, an SDN controller calculates path from a source to a destination. In an SDN architecture, Datapath ID (DPID) and port number are used to distinguish a path. In Figure.1, Nodes A, B, C, D, E, F, and G are switches. A number betwen a node and a link represents a port number.

Assume that A wants to send a packet to F, A first sends a packet to B, which is directly connected to A. When B receives the packet, it requests the SDN controller to handle the packet. The SDN controller extract a flow from the packet by inspecting packet header, such as MAC, IP addresses, protocol, etc. Then the SDN controller calculates a path based on its own policy. For example, path (B, E, D, F) is chosen by the policy. The SDN Controller encodes output port numbers (2, 3) of nodes in path (E, D) and insert them into the flow entry of B. SDN Controller adds a flow entry to B. The flow entry specifies the output port 3 for the flow from A to F and includes the encoded path information to establish the path to F. After the SDN controller adds the flow entry to B, B inserts the encoded path to the packet header and forwards the packet to the port 3 as instructed in its flow entry. E receives the packet and gets its output port number 2 in the packet header. Then, E removes the port number in the encoded path it consumes. E adds the flow entry which specifies output port as 3 to its flow table and forwards the packet to the port 2. D receives the packet, adds its flow entry, and forwards the packet to the port 3. The packet is sent from A to F and the path (A, B, E, D, F) is successfully set.

4. Failure Recovery

Source routing offers benefits to failure recovery in SDN in terms of recovery speed. If failures occur, such as link or port failures, some flows have been delivered through them will be failed. These flows should be redirected to healthy paths as fast as possible.

A path protection mechanism prepares backup paths in case of failure and provides fast failure recovery as it provides a backup path in advance. However, if backup paths are not set, an SDN controller redirects all the affected flows sequentially, which is called restoration. In this section, we illustrate how source routing can be applied to protection and restoration for fast failure recovery in SDN.

4.1. Path Protection

In order to recover from failures fast, path protection can be implemented in SDN using the source routing mechanism. An SDN controller inserts backup path information, as well as a working path. If a failure occurs in the working path, then the affected flows is redirected to the backup path.

For example, in Figure 1, when a flow path from A to F is set, the SDN controller extracts a flow of the packet. Then, it calculates the working path (B, E, D, F) and the backup path (B, G, D, F). The working path (B, E, D, F) is established using the existing flow setup mechanism or our method shown in section 3. The SDN controller extracts output port numbers of nodes along the path. The backup path (B, G, D, F) is encoded to (2, 3) which includes output port numbers of node G and D and inserted to the flow entry of B. During the network is healthy, packets from A to F are delivered through (B, E, D, F). Assume that the link B-E fails, B detects that the port 3 is unavailable and redirects the packet to the port 4 after inserts the encoded path to the packet header. G receives the packet and obtains the output port 2 for the packet by inspecting the packet header. G adds a flow entry which instructs G to forward matched flows to the port 2. After G obtains the output port, it removes its output port number in the encoded path (2, 3), so G puts (2) to the packet header and forwards the packet to port 2. D receives the packet, obtains the output port 3, and sends the packet to the port 3.

4.2. Restoration

Unlike the path protection, a restoration mechanism does not prepare for failure cases in advance. No additional actions are required during flow setup. If failures occur, SDN nodes detect failures and notify them to a SDN controller. The SDN controller first identifies flows affected by the failures with the failure notification. Then, the controller redirects the affected flows to alternative paths.

For example, in Figure 1, let us assume that link B-E fails, then B and D detect the port 3 and 1 are unavailable, respectively. B and D send notification messages to the SDN Controller, then it extracts flows from flow tables of B and D, which are directly affected by the failure. The SDN controller then calculates alternative paths for the affected flows and sets alternative paths for the flows. When the SDN controller redirects each affected flow, source routing is used to recover failures fast. Redirection process of each affected flow is same as the flow setup shown in section 3. If 10 flows are affected by the failure, then the SDN controller should redirect these flows sequentially.

5. Security Considerations

One of the most important security issues of source routing in SDN is that malicious users may change paths. To prevent this, switches in a network domain should ignore encoded path information. By deleting encoded path information in packets from ports connected to external networks, we can prevent malicious users from altering paths.

6. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses