Computer Networks QUIC Intro PDF

CS 6250/4251 Computer Networks Alberto Dainotti A QUIC INTRO...

CS 6250/4251 Computer Networks Alberto Dainotti A QUIC INTRO 10/22/2024 2 What is QUIC? What is HTTP/3? A new transport protocol HTTP/3 is HTTP over QUIC built for needs of today’s Internet and the modern web not what TCP was built for Feature-parity with HTTP/2 request multiplexing, header compression, push UDP-based, because UDP gets through most networks QUIC re-creates TCP services from scratch … except for priorities (loss recovery, congestion control, flow control, etc.) which is being dropped in HTTP/2 by HTTP working group a common scheme is being devised for HTTP/2 and /3 Has encryption baked in, data/metadata are protected combines transport and crypto handshakes for latency uses TLS/1.3 for key negotiation Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Why does industry care? Site performance reduces page load latency, improves video QoE Userspace transport offers control, agility enables architecture exploration, such as “Direct Server Return” Deployment agility of new features ossification protection with versioning, encryption, GREASEing Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Why QUIC Motivation: “built for needs of today’s Internet and the modern web not what TCP was built for” Issues with transport protocols evolution (TCP or entirely new ones) Protocol Entrenchment Implementation Entrenchment Handshake Delay Head-of-line blocking Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 14 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Protocol Entrenchment Protocol Entrenchment: middle boxes Rise of the Middle While new transport protocols (e.g., DCCP, SCTP) have been specified to meet evolving application demands beyond TCP’s sim- mid 1990s: the network started to change ple service, they have not seen wide deployment Network Address Translators (NATs): IP address scarcity Firewalls: Protection and policy Protocol accelerators (PEPs): Improve transfer perf “Accidental architectural control points of the Internet” Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 16 Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf  Protocol Entrenchment: Middleboxes Protocol Entrenchment – Solution: build on top of UDP Middleboxes UDP is (obviously) already supported by middleboxes Incapable of allowing traffic from new transports without adding explicit support for Not much that a middlebox can do to a UDP header … them Firewalls tend to block anything unfamiliar for security reasons Network Address Translators (NATs) rewrite the transport header, Any packet content not protected by end-to-end security, such as the TCP packet header, has become fair game for middleboxes to inspect and modify. As a result, even modifying TCP remains challenging due to its ossification by middleboxes. Deploying changes to TCP has reached a point of diminishing returns, where simple protocol changes are now expected to take upwards of a decade to see significant deployment. Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Protocol Entrenchment – Solution: build on top of UDP Protocol Entrenchment – Solution: build on top of UDP … and most of the UDP payload is encrypted, so no opportunity to … and most of the UDP payload is encrypted, so no opportunity to alter it alter it Protocol design maxim "the ultimate defense of the end to end mode is end to end encryption" David Clark, J. Wroclawski, K. Sollins, and R. Braden, Tussle in Cyberspace: Defining Tomorrow’s Internet. IEEE/ACM ToN, 2005. Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Implementation Entrenchment Implementation Entrenchment — Solution: UDP! Coupling of the transport implementation to the OS! RTP is the first widely used transport protocol that runs over UDP, TCP is commonly implemented in the OS kernel - > This limits the resulting in RTP implementation being outside the kernel deployment and iteration velocity of even simple networking changes UDP can be viewed as a NO-OP transport protocol other than using Pushing changes to TCP stacks typically requires OS upgrades port numbers to demultiplex incoming packets to intended application OS upgrades have system-wide impact and the upgrade pipelines and mechanisms processes, and an optional checksum are appropriately cautious UDP allows applications to control what data to be packaged into each Even with increasing mobile OS populations that have more rapid upgrade cycles, IP packet, thus enabling the realization of the application data unit sizeable user populations often end up several years behind (ADU). This user space implementation allows RTP to be tightly OS upgrades at servers tend to be faster by an order of magnitude but can still take many months because of appropriately rigorous stability and performance integrated with the application implementations to utilize ADU testing of the entire OS. QUIC does the same … 22 Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 Slide material from: J. Dellaverson et al., “A Quick Look at QUIC” Implementation Entrenchment – Solution: build on top of UDP Protocol & Implementation Entrenchment QUIC is implemented in the user space The deployment of transport modifications for the web requires changes to web servers and clients, to the transport stack in server and/or client OSes, and often to intervening middleboxes. Deploying changes to all three components requires incentivizing and coordinating between application developers, OS vendors, middlebox vendors, and the network operators that deploy these middleboxes. QUIC encrypts transport headers and builds transport functions atop UDP, avoiding dependence on vendors and network operators and moving control of transport deployment to the applications that directly benefit from them. Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 Handshake Delay Low-latency handshake The generality of TCP and TLS: the costs of layering have become First connection to server increasingly visible with increasing latency demands on the HTTPS TCP + TLS/1.3 stack SYN TCP connections commonly incur at least one round-trip delay of CK connection setup time before any application data can be sent, and SYN/A handshake Hello TLS adds two round trips to this delay n Cert, Fi While network bandwidth has increased over time, the speed of light Hello, Fin, G ET / remains constant. Most connections on the Internet, and certainly data K most transactions on the web, are short transfers and are most 200 O impacted by unnecessary handshake round trips client server Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf  QUIC Connection establishment Low-latency handshake First connection to server QUIC uses UDP as an underlying protocol and its implementation runs TCP + TLS/1.3 QUIC in the user space Initial, QUIC combines transport and cryptographic handshakes together, acquiring the information SYN Hello handshake necessary for both in 1-RTT. QUIC uses the combination of two numbers, one selected by each CK Cert, Fi n SYN/A Hello, handshake end, to form a pair of connection IDs. Initial, Hello Fin, G ET / This entails doing an authenticated TLS 1.3 key exchange along with an authenticated transport The connection ID (CID) acts as a unique identifier for the Cert, Fin 200 O K data parameters exchange at the same time. Hello, connection, which is used to ensure that changes in addressing at Fin, G ET / lower protocol layers will not cause packets to be delivered to a data K 200 O wrong recipient. By using the connection ID, QUIC supports the demultiplexing client server client server ability similar to the functionality provided by TCP. Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Low-latency handshake QUIC Handshake Subsequent connection to the same server TCP + TLS/1.3 QUIC Transport options exchanged in Transport Parameters Flow control limits, etc Initial, SYN Hello, Sent as extension to TLS handshake handshake GET / handshake data CK - QUIC allows a client to send 0-RTT encrypted SYN/A OK ello, Fi n, 200 application data in its first packet to the server Connection IDs exchanged during handshake Hello, itial, H GET / In by reusing the negotiated parameters from a Each endpoint chooses CID (and length) to be used towards it 0 OK previous connection and a TLS 1.3 pre-shared Fin, 20 data Hello, key (PSK) identity issued by the server, TLS handshake carried in QUIC packets - 0-RTT data are not protected against replay attack. Ultimately, QUIC packets flow on wire Carrying TLS messages, including QUIC options client server client server Why? So that QUIC options are protected Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf Head-of-line blocking delay Head-of-line blocking delay Applications commonly multiplex units of data within TCP’s single- Since TCP assures sequential delivery of data byte streams, the loss bytestream abstraction of 1 packet will block the delivery of all subsequent packets until the lost packet has been recovered. E.g., to reduce transaction latency, HTTP/2 multiplexes multiple Fig. 1 shows an example where pkt 1 has been delivered to the receiver but packet 2 is lost during transit. The data objects and recommends using a single TCP connection to any server of packets 3-9 has been received but cannot be delivered to the application until packet 2 has been retransmitted and received, and passed to the application first, to assure sequential delivery of all data to the application process. TCP’s bytestream abstraction, however, prevents applications from Figure 1 and Figure 2 look similar, with the former reflecting an issue also at the sender (which is blocked from sending more packets), and the latter an issue at the receiver (already received data gets blocked inside the controlling the framing of their communications and imposes a kernel) "latency tax" on application frames whose delivery must wait for retransmissions of previously lost TCP segments. Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 Slide material from: J. Dellaverson et al., “A Quick Look at QUIC” Head-of-line blocking delay QUIC: Streams To avoid head-of-line blocking, QUIC supports multiple independent Streams are identified by stream IDs, which are statically allocated as streams within a connection odd IDs for client-initiated streams and even IDs for server-initiated When a packet is lost, only the streams with data frames contained streams to avoid collisions. in the packet will need to wait for the retransmission of the lost A QUIC packet is composed of a common header followed by one or frames more frames. QUIC stream multiplexing is implemented by It will not block other streams from moving forward. Subsequent data encapsulating stream data in one or more stream frames, and a single received on other streams can continue to be reassembled and QUIC packet can carry stream frames from multiple streams. delivered to the application E.g., HTTP -> web pages / components [Important for a CP] Slide material from: J. Dellaverson et al., “A Quick Look at QUIC” Slide material from: A.Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2020 Head-of-line blocking delay — QUIC Solution QUIC: Packet and Frame formats Streams and Flow Control Streams are a lightweight abstraction QUIC Packet Format each is a separate “ordered stream of bytes” streams are independent wrt ordering/retransmission ⇒ QUIC “removes” Head-of-Line blocking data needs to be multiplexed onto underlying connection Long header Two Four types of stream unidirectional stream server initiated bidirectional stream client initiated Receiver applies flow control to limit data sent in streams stream flow control limits bytes sent on a stream Short header connection flow control limits bytes sent across all streams stream count flow control limits amount of streams Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf  STREAM Frame Frames Each stream resembles a TCP connection, providing ordered byte-stream delivery. The byte stream is cut to data frames, analogous to TCP segments Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf QUIC Packetization: Example QUIC Packetization: Example QUIC Packet QUIC Packet Header = 0b01 STREAM Frame Spin Bit Header = 0b01 Stream ID: 5 STREAM Frame STREAM Frame ACK Frame Offset: 1123 Dest Conn ID Spin Bit Length: 500 Fin: False STREAM Frame ACK Frame Key Phase Dest Conn ID Packet Number Key Phase Application Data PN = 56 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf frame: each of which can be considered analogous to an IP packet. QUIC: Reliable Delivery service QUIC Packetization: Example QUIC Packet ACK Frame STREAM Frame STREAM Frame Header = 0b01 Stream ID: 5 Stream ID: 8 Offset: 1123 Length: 300 Spin Bit Length: 500 Highest Packet Fin: False Number seen so far Fin: False ACK Frame Dest Conn ID Time since Largest Key Phase Acked was received Application Application Data Data PN = 56 Contiguous from Largest Acked Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 Slide material from: Jana Iyengar, Ian Swett, Robin Marx, QUIC Tutorial @ SIGCOMM 2020 https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf https://qlog.edm.uhasselt.be/sigcomm/files/QUICTutorial_SIGCOMM2020.pdf QUIC: Reliable Delivery service QUIC: Reliable Delivery service QUIC Packetization: Ack Example QUIC Packetization: Example Packets received: 1 … 125 QUIC Packet Time since largest received: 25ms STREAM Frame STREAM Frame ACK Frame represented as a shifted value (default 3, negotiable) Header = 0b01 Stream ID: 5 25ms = 3125us flexibility, automation, … Network Virtualization Network Virtualization https://sdn.systemsapproach.org/netvirt.html https://sdn.systemsapproach.org/netvirt.html 26 27  SDN Challenges Scale Stability & Correctness Timeliness Challenges Inter-domain 31 SDN: selected challenges ▪ hardening the control plane: dependable, reliable, performance- scalable, secure distributed system robustness to failures: leverage strong theory of reliable distributed system for control plane Generalized dependability, security: “baked in” from day one? ▪ networks, protocols meeting mission-specific requirements Forwarding: e.g., real-time, ultra-reliable, ultra-secure ▪ Internet-scaling: beyond a single AS Open Flow API ▪ SDN critical in 5G cellular networks 33 34 Generalized forwarding: match plus action ▪ Generalized Forwarding, SDN values in arriving Match+action packet header 0111 1 OpenFlow: match+action in action 3 2 forwarding table (aka: flow table) 35 36 Generalized forwarding: match plus action Flow table abstraction ▪ flow: defined by header field values (in link-, network-, transport-layer fields) Review: each router contains a forwarding table (aka: flow table) ▪ generalized forwarding: simple packet-handling rules ▪ “match plus action” abstraction: match bits in arriving packet, take action match: pattern values in packet header fields destination-based forwarding: forward based on dest. IP address actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller generalized forwarding: priority: disambiguate overlapping patterns many header fields can determine action counters: #bytes and #packets many action possible: drop/copy/modify/log packet Flow table Router’s flow table define match action router’s match+action rules 38 Flow table abstraction OpenFlow: flow table entries ▪ flow: defined by header fields Match Action Stats ▪ generalized forwarding: simple packet-handling rules match: pattern values in packet header fields Packet + byte counters actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller 1. Forward packet to port(s) 2. Drop packet priority: disambiguate overlapping patterns 3. Modify fields in header(s) counters: #bytes and #packets 4. Encapsulate and forward to controller Flow table src = *.*.*.*, dest=3.4.*.* forward(2) match action src=1.2.*.*, dest=*.*.*.* drop Header fields to match: src=10.1.2.3, dest=*.*.*.* send to controller Ingress Src Dst Eth VLAN VLAN IP IP TCP/UDP TCP/UDP IP Src IP Dst Src Port Dst Port * : wildcard Port MAC MAC Type ID Pri Proto ToS 1 4 3 Link layer Network layer Transport layer 2 39 40  OpenFlow-style data plane OpenFlow: examples Destination-based forwarding: Packet + Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP Packet Packet Packet Execute Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action In Metadata Out Table Table... Table 51.6.0.8 port6 Action * * * * * * * * * * * Action 0 Action 1 n Action IP datagrams destined to IP address 51.6.0.8 should be forwarded to router output port 6 (MAC) (VLAN) (IP) Set Set = {} Set Set OpenFlow Switch Firewall: Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP MAC Header IP Header TCP/UDP Header Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action * * * * * * * * * * * 22 drop Dst Addr Src Addr Type … Proto … Src Addr Dst Addr … Src Port Dst Port … … Payload … Block (do not forward) all datagrams destined to TCP port 22 (ssh port #) Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action Type Ctl VLAN ID * * * * * * 128.119.1.1 * * * * * drop Block (do not forward) all datagrams sent by host 128.119.1.1 Optional 802.1Q VLAN Tag 42 OpenFlow: examples OpenFlow abstraction Layer 2 destination-based forwarding: ▪ match+action: abstraction unifies different kinds of devices Switch MAC MAC Eth VLAN VLAN IP IP IP IP TCP TCP Port src dst type ID Pri Src Dst Prot ToS s-port d-port Action Router Firewall 22:A7:23: port3 match: longest match: IP addresses and * * 11:E1:02 * * * * * * * * * layer 2 frames with destination MAC address 22:A7:23:11:E1:02 should be forwarded to destination IP prefix TCP/UDP port numbers output port 3 action: forward out a action: permit or deny link Switch NAT match: destination MAC match: IP address and port address action: rewrite address and action: forward or flood port 43 44 OpenFlow example OpenFlow example match action Host h6 Orchestrated tables can create IP Src = 10.3.*.* Host h6 Orchestrated tables can create 10.3.0.6 IP Dst = 10.2.*.* forward(3) 10.3.0.6 1 s3 controller network-wide behavior, e.g.,: 1 s3 controller network-wide behavior, e.g.,: 2 2 4 ▪ datagrams from hosts h5 and 4 ▪ datagrams from hosts h5 and 3 3 Host h5 h6 should be sent to h3 or h4, Host h5 h6 should be sent to h3 or h4, 10.3.0.5 via s1 and from there to s2 10.3.0.5 via s1 and from there to s2 1 s1 1 s2 1 s1 1 s2 Host h1 2 Host h4 Host h1 2 Host h4 10.1.0.1 4 2 4 10.1.0.1 4 2 4 10.2.0.4 10.2.0.4 3 3 3 3 match match action Host h3 action Host h3 Host h2 Host h2 ingress port = 2 10.2.0.3 ingress port = 1 10.2.0.3 forward(3) 10.1.0.2 10.1.0.2 IP Dst = 10.2.0.3 IP Src = 10.3.*.* forward(4) IP Dst = 10.2.*.* ingress port = 2 IP Dst = 10.2.0.4 forward(4) 45 46 Generalized forwarding: summary ▪ “match plus action” abstraction: match bits in arriving packet header(s) in Software-Defined Networks any layers, take action matching over many fields (link-, network-, transport-layer) A Systems Approach local actions: drop, forward, modify, or send matched packet to controller “program” network-wide behaviors ▪ simple form of “network programmability” Bruce Davie programmable, per-packet “processing” Systems Approach, LLC historical roots: active networking today: more generalized programming: P4 (see p4.org). https://sdn.systemsapproach.org/ 47  OpenFlow-style data plane Packet Packet + Packet In Metadata Packet Execute Out Table Table... Table Beyond Action Action 0 Action 1 n Action (MAC) (VLAN) (IP) Set Set = {} Set Set OpenFlow Switch OpenFlow Dst Addr MAC Header Src Addr Type … Proto … IP Header Src Addr Dst Addr … Src Port TCP/UDP Header Dst Port … … Payload … Type Ctl VLAN ID Optional 802.1Q 51 VLAN Tag Protocol Independent Switch Architecture (PISA) for high-speed programmable packet forwarding Ingress Egress Match-Action Pipeline Match-Action Pipeline Parser Switching logic Deparser crossbar, shared buffers, … Protocol Independent Switch Architecture (PISA) for Programming a P4 target involves a few key elements high-speed programmable packet forwarding Headers and standard metadata Code Target Ingress Egress P4 Program Compiler Control Plane Match-Action Pipeline Match-Action Pipeline Architecture Model CPU port Data Plane Tables Externs target-specific binary Parser Switching logic Deparser User supplied crossbar, shared buffers, … Vendor supplied Protocol Independent Switch Architecture (PISA) for high-speed programmable packet forwarding Ingress Egress Match-Action Pipeline Match-Action Pipeline Parser Switching logic Deparser crossbar, shared buffers, … The parser uses a state machine to map packets into headers and metadata Packet Headers and metadata a:b:c:d → 1:2:3:4 meta {ingress_port: 1, …} ethernet {srcAddr: a:b:c:d, …} 1.2.3.4 → 5.6.7.8 ipv4 {srcAddr: 1.2.3.4, …} 1234 → 56789 tcp {srcPort: 12345, …} Payload  How to program a Ingress Pipeline Egress Pipeline Sequence of Match-Action Tables Sequence of Match-Action Tables match-action table Parser Switching logic Deparser crossbar, shared buffers, … 73 Match-Action Table Control Plane Headers and Key Match Action Metadata Key ID Data Hit ID Action Code Headers Data Headers Default & Meta & Meta Example: IP forwarding table Control Plane Destination IP address Headers and Key Match Action Metadata 1.2.3.4 1.2.3.5 1.2.3.254 5.6.7.1 5.6.7.2 5.6.7.200 Key ID Data...... Hit LAN 1 LAN 2 router router router 1.2.3.0/24 ID Action 5.6.7.0/24 Code … forwarding table Headers Data Headers Default & Meta & Meta Control Plane 1: ipv4_forward(mac,port) Control Plane Longest prefix match 2: drop() Headers and Headers and Key Match Action Metadata Key Match Action Metadata Key ID Data Key ID Data Hit Hit ID Action ID Action Code Code Headers Data Headers Headers Data Headers Default Default & Meta & Meta & Meta & Meta Example: IP forwarding table 1.2.3.4 1.2.3.5 1.2.3.254 5.6.7.1 5.6.7.2 5.6.7.200...... LAN 1 1 2 LAN 2 router router router 01:01:01:01:01:01 02:02:02:02:02:02 action ipv4_forward(macAddr_t dstAddr, egressSpec_t port) { hdr.ethernet.srcAddr = hdr.ethernet.dstAddr;