Summary

  • Wesley Eddy는 Marc Blanchet, Tony Li와 함께 2026년 10월 31일 IETF TIPTOP의 심우주 IP 구조 초안을 냈다. 예시 명령 경로에는 특수 종단 두 곳과 저장 기능을 가진 전달 장치 두 곳이 있고, 일반 IP 노드도 최소 다섯 곳이 남는다.
  • 간헐적 링크가 끊기고 우회 경로가 없으면 전달 장치는 패킷을 용량 제한이 있는 대기열에 둘 수 있다. 가득 차면 정해진 순서에 따라 버리며, 재부팅이나 메모리 오류로도 잃는다. 오래 보관한 뒤에는 지정했던 나머지 경로가 무효가 될 수 있다.

기다리는 동안에도 결정은 쌓인다

IETF 원문 초안은 지구에서 화성까지 편도 전파 시간이 거리에 따라 4분에서 24분이라고 적는다. 자전과 행성 합 때문에 링크 자체가 닫히는 때도 있다. 따라서 다음 접촉까지 패킷을 몇 시간, 길게는 며칠 동안 전달 장치에 보관하는 설계를 제시한다. 이 문제는 우주용 새 패킷 형식보다 운영자가 마련한 저장 공간에 더 가깝다.

IPv4의 TTL은 이름과 달리 사실상 홉 수로 쓰인다. IPv6에서는 아예 Hop Count라고 부른다. 메모리 안에서 흐른 시간은 이 값을 깎지 않는다. 특수한 작업은 끊기는 링크와 안정적인 내부망 사이의 TIPTOP 전달 장치가 맡는다. 인터페이스가 내려가고 목적지로 갈 다른 길이 없을 때, 바로 폐기하는 대신 보관한다. 같은 링크나 다른 링크에 경로가 다시 생기면 내보낸다.

문제는 보관함이 언젠가 찬다는 사실이다. 초안은 깊은 대기열에도 상한과 폐기 정책을 두도록 한다. 트래픽 등급, 출발지와 목적지 주소, 흐름 레이블이 버릴 순서를 정할 수 있다. 재부팅으로 버퍼가 지워지거나 복구할 수 없는 메모리 오류가 나도 패킷이 사라진다. 전달 장치는 최선형 서비스를 제공하고, 신뢰성은 종단 간 전송 계층이 처리한다. 용량을 정하고 우선순위를 매기는 사람이 다음 교신 기회를 얻을 메시지를 고른다.

구조도에서는 임무 통제실과 우주선에 각각 조정된 종단 장치가 있다. 통신 사업자 쪽과 우주선 쪽에는 대기열을 가진 전달 장치가 놓인다. 그 사이의 LAN과 WAN에는 일반 IP 노드가 최소 다섯 개 있다. 별도의 조정 시스템이 안테나 지향, 모뎀 설정, 라우팅 항목을 접촉 계획에 맞춘다. 이 그림은 설치 위치를 설명하는 예시이며 실제 화성 임무의 전송 기록은 아니다.

링크가 돌아와도 옛 지도가 돌아오지는 않는다

보통 라우팅 프로토콜은 이웃과 주기적으로 신호를 주고받아 살아 있는지 확인한다. 지연이 길고 접촉이 끊기는 링크에서는 그 확인 자체가 부담이다. 초안은 그런 구간에 제어기와 예정된 라우팅 갱신을 제안한다. 도메인 사이에는 BGP를 쓸 수 있지만, 느린 링크를 건너 도달 가능한 프리픽스는 대리 광고가 필요하다.

명시적 경로도 시간이 지나면 달라진다. 패킷이 중간 노드에 도착해 오래 잠들었다면, 뒤따를 길은 더 이상 유효하지 않을 수 있다. 패킷마다 예비 경로를 실으면 좁은 무선 대역을 잡아먹는다. 작성자들은 중간 노드가 남은 길을 다시 계산하는 쪽을 택한다. 패킷을 살린 저장 장치가 결국 전송 방향도 새로 결정해야 한다.

초안에는 배치된 TIPTOP 전달 장치의 대기열 기록이 없다. 실제 접촉 시간과 적재량, 폐기 사유, 재계산 결과를 함께 기록해야 도달 여부를 알 수 있다.

원본 기록