Summary

  • RFC 3077 kept the satellite feed physically one-way and used tunnels over separate bidirectional interfaces to emulate the link-layer conversations that receivers could not send over the broadcast medium.
  • Its one-way DTCP announcements helped receivers discover feeds and expire stale tunnel endpoints; they did not authenticate a feed, select a universal best route, or prove delivery above the link layer.

RFC 3077, published in March 2001, starts with two devices that cannot complete a conversation on their shared broadcast link. The feed can transmit across a unidirectional link; the receiver can listen but not send. From the other direction, a send-only feed is “deaf”: it cannot receive anything on that interface. Internet protocols, meanwhile, were built around links that can carry packets both ways. A router may send a packet to a next hop and expect replies or routing updates to return.

The specification’s answer was not to turn a satellite receiver into a transmitter. Each receiver and feed also needed a conventional bidirectional interface connected through IP. When a receiver sent a link-layer frame toward a feed, it encapsulated that frame and carried it over a tunnel to the feed’s Internet-facing endpoint. The feed decapsulated it and handed it to the link-layer side. The satellite broadcast remained the forward path; the tunnel supplied a return path between selected nodes.

Why emulate a link rather than build only a new IP-layer network? A link-layer network could carry existing network-layer protocols without teaching them about the satellite’s one-way physics. RFC 3077 set out six communication cases available on a bidirectional broadcast network. Feed-to-receiver delivery already worked over the physical broadcast; the tunnel mechanism sought to restore the other five, including receiver-to-feed and receiver-to-receiver traffic, plus broadcast and multicast behavior. That let protocols such as ARP and directly connected routing operate in a familiar place in the stack.

It did not mean the physical link had acquired a return transmitter.

For the tunnel carrier, the document recommends Generic Routing Encapsulation (GRE), which can carry different inner packet types over IP. In the described format, an outer IP packet reaches a feed’s bidirectional address, a GRE header identifies the link-layer protocol, and the payload is the original MAC packet. Other tunnel types are possible only if the feed and receiver agree on what the selected type means. RFC 3077 defines the adaptation around the tunnel; it does not redefine GRE as an authorization or security system.

The less obvious design choice is how receivers learn which feed to tunnel toward. The Dynamic Tunnel Configuration Protocol (DTCP) does not use the Internet backchannel for discovery. Its HELLO messages travel from feeds to receivers over the same one-way link. A JOIN announces that a feed is operating; a LEAVE can announce that it is stopping. HELLO also carries an interval, sequence value, tunnel type and one or more feed bidirectional IP addresses (FBIPs). Receivers listen to the DTCP multicast announcement and keep an active-feed list with endpoint details and a timer.

If a LEAVE arrives, a receiver can remove the feed promptly. If HELLOs stop, the entry eventually times out. That is a deliberately limited signal: the feed may be down, or the one-way link may be down. In either case, the receiver can no longer assume bidirectional connectivity through that feed. The timer changes what the receiver should attempt; it does not diagnose the failed component or prove that any application packet got through.

Feed selection remains local. Each receiver chooses its own default feed; the RFC offers a lower round-trip time as one possible policy but does not mandate it. An administrator may prefer a different listed tunnel endpoint if it is more reachable. Even a required feed-side MAC address is not supplied by a universal discovery method in the RFC. The shared format coordinates the exchange; local configuration still decides which advertised path is useful.

The architecture also exposes a cost that “bidirectional” can conceal. A geostationary satellite link may add roughly 250 milliseconds of one-way delay, while the Internet return path has its own variable latency. RFC 3077 warns that reactive address resolution such as ARP may make a feed wait for a response as packets accumulate, eventually risking buffer exhaustion and drops. This is a worked engineering concern, not a measurement from a named service. The paths are coupled, but not symmetric in delay, capacity or ownership.

The RFC therefore requires receivers to disable tunnels when the one-way link is down. Without that rule, a router might continue receiving packets over a tunnel and mistake them for evidence that the underlying link still works—for example, in a routing protocol that uses received traffic to judge the neighbor. Feed loss should likewise stop unnecessary tunneled traffic. A decapsulated packet is one event in this chain, not proof of a stable route or successful service.

Trust is another separate layer. RFC 3077 warns that ARP or IP spoofing could give unauthorized nodes access to the service. It says tunnels can be authenticated but leaves the authentication mechanism unspecified. Routing protocols must use their own authentication when available to guard against false routing information from an unauthorized receiver. DTCP’s JOIN and endpoint fields are announcements, not credentials.

The standards text also declines to promise plug-and-play interoperability. A deployment profile still has to settle which MAC format it uses and which tunnel type both ends interpret. Scalability and multicast-routing configuration are left to other work. The design makes a one-way medium usable by composing it with a return network; it does not make the composite path uniform, trusted by default or self-explanatory.

Primary sources