요약

  • RFC 3077은 위성 피드를 물리적으로 일방향으로 유지하면서, 수신기가 방송 매체를 통해 보낼 수 없는 링크 계층 통화를 별도의 양방향 인터페이스를 통한 터널로 에뮬레이션했다.
  • 일방향 DTCP 공지는 수신기가 피드를 발견하고 오래된 터널 엔드포인트를 만료하는 데 도움을 주었지만, 피드를 인증하거나 보편적인 최적 경로를 선택하거나 링크 계층 위의 전달을 증명하지는 않았다.

2001년 3월에 발표된 RFC 3077은 공유된 방송 링크에서 대화를 완성할 수 없는 두 장치에서 시작한다. 피드는 단방향 링크를 통해 전송할 수 있지만, 수신기는 들을 수만 있고 보낼 수는 없다. 반대 방향에서 전송 전용 피드는 "귀가 먹은" 상태, 즉 그 인터페이스에서 아무것도 받을 수 없다. 한편 인터넷 프로토콜은 패킷을 양쪽으로 운반할 수 있는 링크를 전제로 설계되었다. 라우터는 패킷을 다음 홉으로 보내고 응답이나 라우팅 업데이트가 돌아오기를 기대할 수 있다.

이 규격의 답은 위성 수신기를 송신기로 바꾸는 것이 아니었다. 각 수신기와 피드는 IP를 통해 연결된 기존 양방향 인터페이스도 갖추어야 했다. 수신기가 피드를 향해 링크 계층 프레임을 보낼 때, 그 프레임을 캡슐화하여 피드의 인터넷 측 엔드포인트로 이어지는 터널을 통해 전달했다. 피드는 이를 역캡슐화하여 링크 계층 측에 넘겼다. 위성 방송은 순방향 경로로 남았고, 터널은 선택된 노드들 사이의 복귀 경로를 제공했다.

왜 새로운 IP 계층 네트워크만 만들지 않고 링크를 에뮬레이션했을까? 링크 계층 네트워크는 위성의 일방향 물리성에 대해 알려 주지 않고도 기존 네트워크 계층 프로토콜을 운반할 수 있었다. RFC 3077은 양방향 방송 네트워크에서 가능한 여섯 가지 통신 사례를 정리했다. 피드에서 수신기로의 전달은 이미 물리적 방송을 통해 동작했고, 터널 메커니즘은 수신기에서 피드로, 수신기에서 수신기로의 트래픽, 그리고 브로드캐스트와 멀티캐스트 동작을 포함한 나머지 다섯 가지를 복원하려 했다. 이를 통해 ARP나 직접 연결된 라우팅 같은 프로토콜이 스택에서 익숙한 위치에서 동작할 수 있었다. 이것이 물리적 링크에 복귀 송신기가 생겼다는 의미는 아니었다.

터널 운반체로는 이 문서가 다양한 내부 패킷 유형을 IP 위에서 운반할 수 있는 GRE(Generic Routing Encapsulation)를 권장한다. 기술된 형식에서 외부 IP 패킷은 피드의 양방향 주소에 도달하고, GRE 헤더가 링크 계층 프로토콜을 식별하며, 페이로드는 원래 MAC 패킷이다. 다른 터널 유형도 피드와 수신기가 선택된 유형의 의미에 대해 합의하는 경우에만 가능하다. RFC 3077은 터널을 둘러싼 적응을 정의할 뿐, GRE를 인가나 보안 시스템으로 재정의하지 않는다.

덜 자명한 설계 선택은 수신기가 어느 피드로 터널링할지 학습하는 방식이다. DTCP(Dynamic Tunnel Configuration Protocol)는 발견에 인터넷 역방향 채널을 사용하지 않는다. HELLO 메시지는 피드에서 수신기로 같은 일방향 링크를 통해 이동한다. JOIN은 피드가 동작 중임을 알리고, LEAVE는 정지 중임을 알릴 수 있다. HELLO는 또한 간격, 시퀀스 값, 터널 유형과 하나 이상의 피드 양방향 IP 주소(FBIP)를 실어 보낸다. 수신기는 DTCP 멀티캐스트 공지를 청취하고 엔드포인트 세부사항과 타이머를 갖춘 활성 피드 목록을 유지한다.

LEAVE가 도착하면 수신기는 해당 피드를 즉시 제거할 수 있다. HELLO가 끊기면 항목이 결국 시간 초과된다. 이것은 의도적으로 제한된 신호다. 피드가 다운되었거나 일방향 링크가 다운되었을 수 있다. 어느 경우든 수신기는 더 이상 그 피드를 통한 양방향 연결을 가정할 수 없다. 타이머는 수신기가 시도해야 할 행동을 바꾸지만, 실패한 구성 요소를 진단하거나 어떤 애플리케이션 패킷이 통과했는지 증명하지 않는다.

피드 선택은 여전히 로컬 문제다. 각 수신기는 자체 기본 피드를 선택하며, RFC는 더 낮은 왕복 지연 시간을 하나의 가능한 정책으로 제시할 뿐 강제하지 않는다. 관리자는 더 도달 가능한 다른 목록 터널 엔드포인트를 선호할 수 있다. 심지어 필요한 피드 측 MAC 주조도 RFC에서 보편적인 발견 방법으로 제공되지 않는다. 공유 형식이 교환을 조율할 뿐, 어떤 광고된 경로가 유용한지는 여전히 로컬 구성이 결정한다.

이 아키텍처는 "양방향"이라는 말이 감출 수 있는 비용도 드러낸다. 정지 궤도 위성 링크는 편도 약 250밀리초의 지연을 더할 수 있고, 인터넷 복귀 경로에는 자체적으로 가변적인 지연이 있다. RFC 3077은 ARP 같은 반응형 주소 확인이 패킷이 쌓이면서 피드가 응답을 기다리게 만들고, 결국 버퍼 고갈과 손실 위험에 이를 수 있다고 경고한다. 이것은 특정 서비스에서 측정한 값이 아니라 실제로 작성된 엔지니어링 우려다. 경로들은 결합되어 있지만 지연, 용량, 소유권에서 대칭적이지 않다.

따라서 RFC는 일방향 링크가 다운되면 수신기가 터널을 비활성화하도록 요구한다. 이 규칙이 없으면 라우터는 터널을 통해 계속 패킷을 수신하며 이를 기본 링크가 여전히 동작한다는 증거로 오인할 수 있다. 예컨대 수신 트래픽으로 이웃을 판단하는 라우팅 프로토콜에서 그렇다. 피드 손실 역시 불필요한 터널 트래픽을 멈추어야 한다. 역캡슐화된 패킷은 이 연쇄에서 하나의 사건일 뿐, 안정적인 경로나 성공적인 서비스의 증명이 아니다.

신뢰는 또 하나의 별개 계층이다. RFC 3077은 ARP나 IP 스푸핑이 인가되지 않은 노드에 서비스 접근을 줄 수 있다고 경고한다. 터널은 인증될 수 있다고 밝히지만 인증 메커니즘은 명시하지 않은 채로 둔다. 라우팅 프로토콜은 인가되지 않은 수신기의 거짓 라우팅 정보를 막기 위해 가용할 때 자체 인증을 사용해야 한다. DTCP의 JOIN과 엔드포인트 필드는 공지이지 자격 증명이 아니다.

표준 문서는 플러그 앤 플레이 상호운용성도 약속하지 않는다. 배포 프로필은 여전히 어떤 MAC 형식을 사용하고 어느 터널 유형을 양쪽이 해석할지 정해야 한다. 확장성과 멀티캐스트 라우팅 구성은 다른 작업에 맡겨졌다. 이 설계는 복귀 네트워크와 결합하여 일방향 매체를 사용 가능하게 만들지만, 결합된 경로를 균일하게 만들거나 기본적으로 신뢰할 수 있게 하거나 스스로 설명되게 하지는 않는다.

1차 출처