Ethernet II + IPv4 + UDP 프레임 구조

Published on 9월 22, 2025

1) 전체 레이어

[Ethernet II]

Byte0–5 Byte6–11 Byte12–13 Byte14–(n) 마지막 4바이트
Destination MAC (6B) Source MAC (6B) EtherType (2B, 0x0800=IPv4) Payload (IPv4 Packet …) FCS CRC32 (4B)

Payload = [IPv4]

Byte0 Byte1 Byte2–3
Version / IHL (1B) TOS (1B) Total Length (2B)
Byte4–5 Byte6–7
Identification (2B) Flags (3b) + Fragment Offset (13b)
Byte8 Byte9 Byte10–11
TTL (1B) Protocol (1B, 17=UDP) Header Checksum (2B)
Byte12–15
Source IP (4B)
Byte16–19
Destination IP (4B)
옵션 (0~40B)

IPv4 Payload = [UDP]

Byte0–1 Byte2–3 Byte4–5 Byte6–7
Source Port (2B) Destination Port (2B) Length (2B) Checksum (2B)
Byte8 ~ (8+N-1)
Data (N = UDP Length – 8)
  • 물리 계층의 Preamble(7) + SFD(1), 그리고 IPG(Inter-Packet Gap) 는 PHY/ MAC 레벨에서 처리되며, 일반적으로 사용자 스트림에는 노출되지 않습니다.
  • 많은 MAC IP는 FCS(4B) 를 자동으로 붙이고/검사하며, 사용자 스트림에서 FCS를 제거해 줍니다(옵션).

2) Ethernet II 프레임 (Data Link)

  • 오프셋 기준(프레임 시작)
    • 0–5 : Dest MAC (6B)
    • 6–11: Src MAC (6B)
    • 12–13: EtherType (2B) — IPv4는 0x0800
    • 14–...: Payload (여기서는 IPv4 패킷)
    • 마지막 4B: FCS(CRC-32)
  • 최소 길이: 헤더(14) + 페이로드(최소 46) + FCS(4) = 64B
    → IP/UDP가 짧으면 MAC이 패딩(0x00) 을 삽입하여 46B 페이로드를 맞춥니다.
  • FCS(CRC-32) 요약
    • 다항식: 0x04C11DB7, 초기값 0xFFFFFFFF, 최종 XOR 0xFFFFFFFF
    • 계산 범위: Dest MAC부터 마지막 페이로드/패딩 바이트까지(FCS 제외)
    • PHY 선로 비트 순서는 바이트 내 LSB-first(표준 이더넷 규칙), 스트림에서는 바이트 단위 Big-Endian 순서로 보는 것이 일반적
    • RTL: TX 쪽은 스트리밍 계산 후 부착, RX 쪽은 MAC이 검사/드롭 을 맡기면 상위 RTL은 단순화

3) IPv4 헤더 (Network)

  • 시작 오프셋: 이더넷 헤더 14B 뒤 → offset 14
  • 일반(옵션 없음) 길이: 20B (IHL=5)
오프셋(프레임 기준)길이필드비고
141Version(4) + IHL(4)보통 4/5 (20B 헤더)
151TOS(DSCP/ECN)QoS 필요 시 DSCP 사용
16–172Total LengthIP 헤더+데이터 총길이
18–192Identification(조각화 시) 식별자
20–212Flags(3) + Frag Offset(13)DF=1 권장(조각화 금지)
221TTL보통 64/128
231Protocol17(UDP)
24–252Header ChecksumIP 헤더만 대상
26–294Src IP네트워크 바이트 오더
30–334Dst IP″
  • 조각화(Fragments)
    • 머신 비전 스트리밍은 성능/신뢰성 이유로 반드시 DF=1 을 권장(라우터가 조각화하지 않도록).
    • 조각화되면 첫 조각만 UDP 헤더를 포함, 나머지는 데이터 조각 → 구현 복잡/손실 시 전체 무효.

4) UDP 헤더 (Transport)

  • 시작 오프셋: 14 + (IHL*4) → 보통 offset 34
  • 길이: 8B (고정)
오프셋(프레임 기준)길이필드비고
34–352Src Port발신 포트
36–372Dst Port수신(애플리케이션) 포트
38–392LengthUDP 헤더+데이터 길이
40–412ChecksumIPv4에서 0=비사용 허용
  • UDP Length 일관성: UDP Length == (IP TotalLen - IP HeaderLen)
  • UDP Checksum
    • 계산 대상: 의사 헤더(pseudo-header)(SrcIP, DstIP, 0x00, Protocol=17, UDP Length) + UDP 헤더+데이터(홀수 길이면 1B 패딩)
    • IPv4에서는 0으로 비활성화 가능(고속 스트리밍에서 종종 사용), 신뢰성 중시 시 사용 권장

5) 계층별 바이트 맵(옵션/VLAN 없음, IHL=5)

  • 0–5 : Dest MAC
  • 6–11: Src MAC
  • 12–13: EtherType = 0x0800 (IPv4)
  • 14–33: IPv4 헤더(20B)
  • 34–41: UDP 헤더(8B)
  • 42–(41+N): UDP 데이터(N = UDP Length-8)
  • (필요 시) 패딩 → 이더넷 페이로드가 최소 46B 되도록
  • (MAC 설정에 따라) 마지막 4B FCS

예시(표준 MTU 1500)

  • 최대 UDP 페이로드 = 1500 - 20(IP) - 8(UDP) = 1472B
  • 자주 쓰는 값: 1440~1472B(여유/헤더 추가 고려)
  • 프레임 총 길이(헤더+FCS 포함)는 MAC 설정(FCS 포함/제거)에 따라 스트림에서 달리 보일 수 있음

점보 프레임(예: MTU 9000)

  • 최대 UDP 페이로드 ≈ 9000 - 20 - 8 = 8972B
  • 스위치/ NIC/ 호스트가 모두 동일 MTU 지원해야 함

6) 엔디안/정렬/버스 매핑(AXI-Stream 관점)

  • 네트워크 바이트 오더 = Big-Endian
    • 16/32비트 필드는 MSB 바이트가 먼저 옴 (예: EtherType 0x0800 → 08 00)
  • AXI-Stream 정렬
    • 프레임 시작이 데이터 버스의 lane 0 에 정렬되는 모드가 일반적
    • 이더넷 헤더 14B는 4/8B 경계에 걸쳐짐 → 필드가 비트/바이트 경계를 넘어갈 수 있음
    • tkeep(유효 바이트 마스크), tlast(프레임 종단) 처리 필수
  • 실무 팁
    • 바이트 카운터 기반 파서: 특정 오프셋(12~13 EtherType, 23 Protocol, 38~39 UDP Len…)에서 바이트를 집계해 필드 완성
    • 또는 소형 버퍼로 16/32비트 정렬 후 추출
    • 메모리에 쓰는 경우 IP 헤더 시작이 +14B 로 2B 미정렬 → 임베디드 SW가 접근 시 유의

7) CRC(FCS) & 체크섬 구현 포인트

Ethernet FCS (CRC-32)

  • TX: 스트리밍 계산(LFSR) → 프레임 끝에 4B FCS 부착(대부분 MAC이 자동)
  • RX: MAC이 에러 프레임을 드롭/표시 하면 상층은 단순화
  • 직접 구현 시: 마지막 비트까지 포함해 계산 후 최종 XOR 적용, 마지막 워드 tkeep 반영

IPv4 Header Checksum

  • 대상: IP 헤더만(20B)
  • 1’s complement sum(16비트 단위, end-around carry) → 1’s complement
  • 라우터가 TTL 감소 시 재계산된다는 점만 이해하면 됨

UDP Checksum

  • Pseudo-header + UDP 헤더/데이터 대상
  • 고속 스트리밍에서 0(비활성화) 선택 가능(IPv4 한정)
  • 사용 시: 16비트 누산기 파이프라인으로 라인레이트 대응 가능
  • TX에서 헤더 내 2바이트 위치에 값을 넣어야 하므로 버퍼링 또는 2-패스 고려(복잡하면 0 사용)

8) MTU, 조각화, 점보 프레임 전략 (비전 스트리밍 최적화)

  • 권장: DF(Don’t Fragment)=1 + 애플리케이션 레벨 세그멘테이션(프레임을 다수 UDP 패킷으로 분할)
  • 이유
    • 조각화 시 한 조각 손실 = 전체 UDP 손실
    • 리어셈블 비용/지연 증가
  • 표준 MTU(1500) 에서 1472B 이내 페이로드로 패킷화
  • 점보 MTU(예: 9000) 지원 시 8972B까지 활용해 헤더/인터럽트 오버헤드 감소
  • GigE Vision(GVSP 등)은 페이로드 안에 시퀀스/블록 ID를 넣어 재조립/손실 검출(애플리케이션 레벨) → RTL 수신기가 이 페이로드 헤더를 파싱해 프레임 버퍼에 주소 배치 가능

9) RTL 구현 체크리스트

파서/상태기계

  • 상태: ETH → IP → UDP → PAYLOAD
  • 검사: EtherType=0x0800, Ver=4/IHL, Protocol=17, (선택) IP 헤더 체크섬
  • 필터: Dst MAC/IP/Port 매칭(목적지 미스매치 시 드롭)
  • 길이 일관성: UDP Len == IP TotalLen - IPHdrLen 확인

AXI-Stream 인터페이스

  • tvalid/tready 백프레셔 설계, tlast/tkeep 처리
  • 패딩 여부: MAC이 패딩 제거/유지 여부 문서 확인(많은 MAC은 페이로드만 내보냄)
  • 연속 프레임 처리: 프레임 경계 카운터 초기화 타이밍 주의

버퍼링/메모리

  • 수신 페이로드를 DDR/URAM/BRAM 으로 DMA 저장
  • 점보 대응: 카운터/ FIFO 폭 충분(≥ 9KB)
  • 프레임 재조립: 페이로드 내 시퀀스/오프셋으로 프레임 버퍼 주소 산출

성능/신뢰성

  • Throughput: MTU/점보, 연속 패킷 사이 IPG 고려
  • 에러 처리: FCS 불일치, IP/UDP 길이 불일치 즉시 드롭
  • 검증: Wireshark 캡처, 트래픽 제너레이터(iperf/Scapy 등)로 가장자리 케이스(홀수 길이, 작은 패킷, 최대 페이로드)

10) 머신 비전 특화 팁

  • 타임스탬프/트리거: 카메라 입력 전단에서 PTP(IEEE 1588) 타임스탬프 삽입/추출 블록을 두면 지연 측정/동기에 유리
  • 멀티 스트림: 여러 센서 샤딩 시 포트/멀티캐스트 MAC로 분리, 수신기 쪽에서는 포트 기반 라우팅
  • 손실 처리: 애플리케이션(예: GVSP) 헤더의 패킷 ID 누락 감지→프레임 드롭 또는 요청 재전송(하드웨어만으로는 재전송 어려움)
  • 페이로드 크기 튜닝: 호스트 NIC/OS 드라이버, CPU/GPU 경로에서 최적의 패킷당 바이트를 실험으로 결정(1440~1472, 혹은 점보 환경에서 8~9KB)

11) 설계자가 바로 쓰는 요약

  • EtherType=0x0800, Protocol=17, DF=1, UDP Length = IP TotalLen – IPHdrLen
  • 최대 UDP 페이로드: 1472B(MTU 1500), ~8972B(MTU 9000)
  • FCS(CRC-32): 이더넷 헤더~페이로드에 대해 계산(보통 MAC이 처리)
  • UDP 체크섬: IPv4에서는 0 허용(고속 스트림에서 단순화), 사용 시 pseudo-header 포함
  • AXI-Stream: tkeep/tlast 철저 처리, 14B 이더넷 헤더로 인한 정렬 어긋남 대응
  • 파서 FSM: 바이트 카운터로 필드 분리·필터링·일관성 체크, 에러 즉시 드롭

Previous

Next

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다