SDN Prerequisite: Stateful versus Stateless

#SDN #SDAS #cloud Things you need to know before diving into SDN...

We've talked before about the bifurcation of the network, which is driven as much by the evolution of network services from "nice to have" to "critical" as it is by emerging architectures. The demarcation line in the network stack has traditionally been - and remains - between layers 3 and 4 in the OSI model. The reason for this is that there is a transition as you move from layer 3 to layer 4 from stateless networking to stateful networking.

This is important to emerging architectures like SDN because this characteristic determines what level of participation in the data path is required. 

Stateless networking requires very little participation. It's limited to evaluating network protocol frames and headers for the purpose of determining where to forward any given packet. The information extracted from the packet is not saved; it is not compared to previous packets.This is why it's stateless, because no information regarding the state of the communication is retained. It is evaluated and the packet is forwarded out the appropriate port based on what's in the FIB (Forwarding Information Base) or what's more commonly referred to as the "forwarding table."

Stateful networking,  which begins at layer 4, retains certain information extracting from frames and packets and, as you move up the stack, from the application layer. It does this because protocols like TCP are connection-oriented and try to maintain guaranteed delivery. This is achieved through the use of sequence numbers in the TCP headers that, when out of order or lost cause the network to retransmit the packets.

There is state associated with TCP, i.e. "I have received packet 1 and am waiting for packet 2 in this connection." This is readily seen in the use of ACKnowledgment packets associated with TCP. There is a pre-designated flow associated with TCP that depends on the state of the end-points involved in the connection.

When a networking service operating at layer 4 or higher is inserted into this communication flow, it must also maintain the connection state. This is particularly true of staple stateful services such as security and load balancing, which rely on state to provide stateful failover services (i.e. without simply dropping connections) or to detect attacks based on state, such as SYN floods.

The higher a network service operates in the network stack, the more participation is required. For example, application routing based on HTTP headers (the URI, the hostname, cookie values, etc... ) rely on the ability of an intermediate network device maintaining state as well as extracting data from within the payload of a message (which is not the same as a packet). A message might actually require 2 or 3 or more packets, as data transferred by modern web applications is often larger than the network MTU of 1500 bytes. This means the intermediate device operating at the application layer must be stateful, as it must act as the end point for the connection in order gather all the packets that make up a message before it can extract the data and then execute its policies. This is why we also emphasize that layer 2-3 is "fixed" and layer 4-7 is "variable."

Networking protocols at layer 2-3 are governed by standards that clearly define the layout of Ethernet frames and IP packets. Devices operating at those layers have highly optimized algorithms for extracting the information needed from frames and packet headers in order to determine how to forward the packet. TCP affords the same luxury at layer 4, but as networking moves up the stack the exactly location of information necessary to make a forwarding decision become highly variable.

Even with a clearly defined protocol like HTTP, there is a wide variation in where certain data might be in the header. This is because not all headers are required and unlike Ethernet and IP and even TCP, where options may not be specified, there is still room reserved for those values. HTTP does not require that space be reserved for optional headers. They are simply left out, which can dramatically change the location (and thus the method of extraction by the intermediate device) of the data necessary to formulate a forwarding decision.

Say you had a form to fill out and, depending on the answer to question 2 you might go on to question 3 or skip to question 8. If that form were layer 2 or 3, each question would be clearly numbered. Skipping to question 8 would be quick and easy. But if that form were layer 7, the questions are not labeled, and to get to question 8 you have to count each of the questions manually. That's the difference between "fixed" and "variable". It's why compute resource requirements are more important to layer 7 than they are to layer 2 or 3.

Why this matters to SDN

This matters a great deal to SDN architectures because of how it impacts the control-data plane separation architecture. Stateless networking is perfectly suited to an architecture that places responsibility for making forwarding decisions on a centralized controller because the frequency with which those decisions must be made is relatively low. Conversely, stateful networking requires more participation and more frequent decisions as well as requiring the maintenance of state for each and every connection. This has serious implications for the controller in such a model, as it forces issues of controller scalability and resource requirements into the equation as the controller more actively participates (and stores more information) with stateful networking than it does with stateless networking.

This is not to say that SDN architecture is incompatible with higher order network services. It just means that the SDN solution you choose for stateless networking will almost certain not be the same SDN solution you choose for stateful networking. That means it's important to investigate solutions that address both of your "networks" with an eye toward integration and interoperability.

Published Apr 21, 2014
Version 1.0

Was this article helpful?

1 Comment

  • Hello Lori

     

     

    I partially disagree with your conclusion about SDN vs state(less) as there are a number of cases where controllers have been used to manage large scale states in networks.

     

     

    As you may know, controllers are not new to networking, they have been there in voice networks, ATM networks, optical networks, etc. In the case of cellular networks, all the services from basic phone features to being able to roam is possible because portions of the IMS, acting as a controller, manage state for my mobile device. Considering the number of cellular devices out there, it is safe to conclude the IMS, as a controller, handles large amount of state.

     

     

    Now that being said what you are hinting at is "where" should different type of state be maintained. For instance a firewall rule has no state until implemented on a device and once traffic flow through it, that becomes the only place that state is maintained. Should it report its states to a central controller ? There would have to be some benefits to do so a bit like my IMS example... For instance to possibly solve active / active asynchronous connectivity to 2 DC (a bit like the ASM policy synch between DCs but with state on top...) or some form of active correlation of sessions between diverse enforcement points which currently are acting as "ships in the night" and cannot be coordinated. (not implying these are good use cases).

     

     

    Today we tend to solve these issues by aggregating the traffic to a small set of perimeter devices, reducing the use case to a simpler one as all the state reside on one or few devices. SDN opens the possibility of similar benefits in a distributed architecture.

     

     

    This is not a binary discussion and again, current networking technologies have shown that controllers functions can indeed maintain large scale state if there is a need for it and if this is the case, well we build the appropriate types of controllers for the job.

     

     

    Cheers

     

     

    Bruno