Welcome!

SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Related Topics: SDN Journal, Java IoT, Linux Containers, Containers Expo Blog, @CloudExpo, Cloud Security

SDN Journal: Blog Feed Post

SDN Prerequisite: Stateful vs Stateless

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.

bifurcated-network-stateful-statelessThis 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.

tcp-conversation-2

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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
Despite being the market leader, we recognized the need to transform and reinvent our business at Dynatrace, before someone else disrupted the market. Over the course of three years, we changed everything - our technology, our culture and our brand image. In this session we'll discuss how we navigated through our own innovator's dilemma, and share takeaways from our experience that you can apply to your own organization.
Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
Intel is an American multinational corporation and technology company headquartered in Santa Clara, California, in the Silicon Valley. It is the world's second largest and second highest valued semiconductor chip maker based on revenue after being overtaken by Samsung, and is the inventor of the x86 series of microprocessors, the processors found in most personal computers (PCs). Intel supplies processors for computer system manufacturers such as Apple, Lenovo, HP, and Dell. Intel also manufactures motherboard chipsets, network interface controllers and integrated circuits, flash memory, graphics chips, embedded processors and other devices related to communications and computing.
Digital transformation is about embracing digital technologies into a company's culture to better connect with its customers, automate processes, create better tools, enter new markets, etc. Such a transformation requires continuous orchestration across teams and an environment based on open collaboration and daily experiments. In his session at 21st Cloud Expo, Alex Casalboni, Technical (Cloud) Evangelist at Cloud Academy, explored and discussed the most urgent unsolved challenges to achieve full cloud literacy in the enterprise world.
Wasabi is the hot cloud storage company delivering low-cost, fast, and reliable cloud storage. Wasabi is 80% cheaper and 6x faster than Amazon S3, with 100% data immutability protection and no data egress fees. Created by Carbonite co-founders and cloud storage pioneers David Friend and Jeff Flowers, Wasabi is on a mission to commoditize the storage industry. Wasabi is a privately held company based in Boston, MA. Follow and connect with Wasabi on Twitter, Facebook, Instagram and the Wasabi blog.