Subnetwork Encapsulation and Adaptation Layer (SEAL) IETF 71 intarea session Fred L. Templin

Subnetwork Encapsulation andAdaptation Layer (SEAL)

IETF 71 intarea session

Fred L. [email protected]

Problem Statement

• Tunnels connect routers across routing regions with heterogeneous links

• In-the-network router-to-router tunneling presents issues for MTU determination

MTU for In-the-Network Tunnels

MTU=64KB

MTU=2KB

MTU=9KB

MTU=9KB

MTU=4KBMTU=9KB

Original Source(MTU=9KB)

Final Destination(MRU=9KB)

Site A

Site B

End-to-End

IngressTunnelEndpoint

MTU=??

EgressTunnelEndpointMRU=4KB

Tunnel

Domains of Application

• Global interdomain routing core (RRG problem space)• Mobile Ad-hoc Networks (MANETs)• Enterprise networks• Unmanaged networks• Mobile IP tunnels• Any routing region bordered by ITRs/ETRs

Requirements

• Detect and dampen in-the-network fragmentation• Avoid reassembly misassociations• Utilize larger MTUs when available• Efficient use of resources• Multi-protocol Operation• Lightweight Duplicate Packet Detection• Generic convergence and adaptation layer

Approach

• Lightweight mid-layer encapsulation• New IP protocol (or embedded sublayer)• Updates existing IP tunnel mechanisms

Outer Headers(IP, UDP/IP, etc.)

Payload

SEAL Header (4 Bytes)

Inner Headers(IP, IP/ESP, etc.)

ICV (2 Bytes) 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ID Extension |M|C|I|CTL| Seg#| Next Header |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ID Extension (16 bits)

M - more segments

C - congestion experienced

I - integrity check vector included

CTL – ’00’(non-probe), ’01’ (FRAGREP), ’1x’ (probe)

Seg# - segment number from 0 - 7

Next Header (8) – same as IP protocol/next header

Problems with Classical Path MTU Discovery

• ICMPs may be lost, erroneous, fabricated• ICMPs may have insufficient information for relaying• ALWAYS drops packets when MTU insufficient • In-the-network tunnels may have 1000’s of packets in-

flight when a routing change hits an MTU restriction:• all packets are dropped• flood of ICMPs returned to ITR• resources wasted

How Does SEAL Solve the Problems?

• Classical path MTU discovery for packets > 2KB• Compatible with end-to-end MTU determination (RFC4821)

• Carefully managed fragmentation for packets <= 2KB:• ITR sends with outer DF=0; listens for FRAGREPs• ETR sends FRAGREPs if fragmentation detected• ITR uses mid-layer segmentation to dampen IP fragmentation• ETR reassembles using 32-bit packet identification

Why 2KB Fragmentation Limit?

• Generous room for extra encapsulations added to original source’s 1500 byte packets on path to ITE

• Generous room for extra encapsulations on path to ETE (for 2x 1KB segments)

• Reasonable minimum MRU for ETEs

Why Use Managed Fragmentation?

• Classical PATH MTU discovery ALWAYS drops pkts; managed fragmentation maximizes packet delivery

• Dampens IPv4 fragmentation (IPv4 fragmentation as pain point to transition out of)

• Gracefully handles routing changes onto smaller MTU paths, as well as multipath routes with diverse MTUs

• Can search upwards to determine if larger MTUs possible w/o exposing data packets to loss

What About Inner Packets with DF=0?

• When necessary, ITE will use inner IP fragmentation• final destination will reassemble

What About Inner Packets with DF=1?

• When necessary, ITE will use SEAL segmentation• ETE will reassemble• It is OK to segment these AS LONG AS THE ETE PUTS

THEM BACK TOGETHER AGAIN before forwarding

What About Links with Tiny MTUs?

• Assume vast majority of links configure an MTU of 256 bytes or larger

• Assume that smaller-than-256 MTU links are also low bandwidth (~10kbps or slower)

• For smaller-than-256 MTUs, allow a small amount of IPv4 fragmentation to match the link MTU

What About Multicast?

• Works exactly the same as for unicast (discovers lowest-common-denominator MTU thru FRAGREPs)

Backups

FFS - Loss Unit Smaller Than Retransmission Unit

• “Fragmentation Considered Harmful” used congestion implications for lost fragments as condemnation of all fragmentation

• Solution – MANAGE CONGESTION• ETE reports “congestion experienced”; ITE backs off

FFS - Integrity

• ITE includes ICV if packet might incur IP fragmentation• ITE omits ICV if the next higher layer already has

strong integrity checks (e.g., IPsec/ESP)• ETE verifies ICV only if packet requires reassembly

(discards packets with incorrect ICV)• ICV sums every N’th byte of the packet (light weight;

splicing error detection)

Brief History of Path MTU Discovery

• 1987 – Report Fragmentation scheme proposed in TCP-IP working group discussions

• 1987 - “Fragmentation Considered Harmful”; proposed IP MTU discovery options (later became RFC1063)

• 1989 – Path MTU Working Group formed:• Report Fragmentation approach favored, but abandoned

because “spare” IP header bit unavailable (the “evil” bit)• Drop and send PTB approach adopted

• 1990 – RFC1191 - Path MTU Discovery• 1993 – IESG Advice on MTU Discovery (RFC1435)• 1995/6 – Tunnel MTU Discovery (RFC1853; 2003)• 1996 – RFC1981 – Path MTU Discovery for IPv6• 1997 – IPv6 minimum MTU changed to 1280 from 576• 2000 – MTU issues first documented (RFC2923)• 2000 onward – tunnel MTU issues documented

Subnetwork Model

SiteSite

SiteSite

SiteSite

SiteSite

SiteSite

SiteSite

SiteSite

SiteSite

SiteSite

SiteSite

Why Not Drop and Send ICMP PTBs?

• Send PTBs only for packets > 2KB known to be too big – NO PTBs UNDER ANY OTHER CIRCUMSTANCES

• PTBs ALWAYS imply loss; source will retransmit• Can’t send PTBs 1-to-1 for dropped packets at high

data rates (ICMP rate-limiting)• Wastes resources (at least 3 transmissions for each

dropped packet) • Original sources might not get the PTBs anyway