Network Working Group Emmanuel Duros Internet-Draft INRIA Sophia-Antipolis November 1997 A Link Layer Tunneling Mechanism for Unidirectional Links Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes a mechanism to emulate bidirectional connectivity between nodes that are directly connected by an unidirectional link. The "receiver" uses a link layer tunneling mechanism to forward datagrams to "feeds" through a bidirectional network. 1. Introduction Internet routing and upper layer protocols assume that links are bidirectional, i.e. directly connected hosts can communicate with each other on the same link. This Internet Draft describes a link layer tunneling mechanism which allows nodes that are directly connected by an unidirectional link (feeds and receivers) to send datagrams as if they were connected to a bidirectional link. The document presents a generic topology with a tunneling mechanism that supports multiple feeds and receivers. Duros [Page 1] Internet Draft LL tunneling mechanism Expiration date The tunneling mechanism is implemented at the link layer of unidirectional interfaces on every feed and every receiver. The aim is to hide to higher layers, i.e. network layer and above, the unidirectional feature of the link. The tunneling mechanism also includes an automatic tunnel configuration protocol which allows feeds and receivers to come up/down at any time. The tunneling mechanism uses Generic Routing Encapsulation [rfcGRE] and provides a means for carrying IP and ARP datagrams from receivers to feeds. The tunneling mechnism described in this Internet Draft was discussed and agreed upon by the UDLR working group. 2. Terminology Unidirectional link: A zero return bandwidth link, e.g. a satellite link with a receive only hardware. Feed: A router connected to an unidirectional link through a send- only interface. Receiver: A router connected to an unidirectional link through a receive-only interface. 3. Topology Feeds and receivers are connected via an undirectional link. Feeds can only send data over this unidirectional link, and receivers can only receive data from it. In the case of non transitive links, the feeds have both send and receive capabilities, and receivers have receive only capabilities. We focus in the rest of this document on unidirectional links only. A receiver has several interfaces, a receive-only interface and one or more added communication interfaces. A receiver is a router. A feed has several interfaces, a send-only interface and one or more added communication interfaces. A feed is a router. In the entire document we assume that feeds and receivers are connected to the Internet. A receiver and a feed can then communicate with each other using their bidirectional interface (Ethernet interface, PPP connection, etc.). Figure 1 depicts a generic topology with several feeds and several Duros [Page 2] Internet Draft LL tunneling mechanism Expiration date receivers. Unidirectional Link ---->---------->------------------->------ | | | | |f1u |f2u |r2u |r1u -------- -------- -------- -------- ---------- |Feed 1| |Feed 2| |Recv 2| |Recv 1|---|subnet A| -------- -------- -------- -------- ---------- |f1b |f2b |r2b |r1b | | | | | | ---------------------------------------------------- | Internet | ---------------------------------------------------- Figure 1: Generic topology f1u (resp. f2u) is the IP address of the 'Feed 1' (resp. Feed 2) unidirectional interface (send-only). f1b (resp. f2b) is the IP address of a 'Feed 1' (resp. Feed 2) bidirectional interface connected to the Internet. r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 2) unidirectional interface (receive-only). r1b (resp. r2b) is the IP address of a 'Receiver 1' (resp. Receiver 2) bidirectional interface connected to the Internet. 4. Problems related to unidirectional links Most protocols in the Internet assume that links are bidirectional. In particular, routing protocols used by directly connected routers no longer behave properly in the presence of an unidirectional link. Indeed, receivers cannot send requests/responses or routing messages to feeds through their receive-only interface. The network layer has no knowledge of the underlying transmission technology except, it considers its access as bidirectional. Basically, for outgoing datagrams, the network layer selects the correct first hop on the connected network according to a routing table and passes the packet(s) to the appropriate link-layer driver. Duros [Page 3] Internet Draft LL tunneling mechanism Expiration date Referring to Figure 1, Recv 1 considers Feed 1 (IP address f1u) as belonging to a connected network. However, initiating a 'ping f1u' on Recv 1 cannot get a response from Feed 1. Recv 1 network layer delivers the packet to the driver of the receive-only interface, which obviously cannot send it to the feed. More generally, a datagram of any protocol which passes from the network layer to the driver of a receive-only interface is simply discarded. 5. Link layer tunneling mechanism This document describes a link layer tunneling mechanism allowing bidirectional communication between feeds and receivers in the presence of an unidirectional link. This mechanism has been designed to work for any topology regardless of the number of feeds and receivers. In particular, the special case of a single feed and multiple receivers is among the topologies supported. This link layer tunneling mechanism operates underneath the network layer. Its aim is to emulate a bidirectional link. It is transparent to the network layer: the link appears and behaves to the network layer as if it was bidirectional. 5.1. Tunneling mechanism at the receiver The tunneling mechanism is inserted at the link layer of the receive-only interface. As a datagram is delivered to the link layer from the network layer, it is encapsulated. This encapsulation can be performed in user space if a daemon can read the datagram from the link layer. The datagram is encapsulated behind an IP packet whose destination is the IP address of a feed bidirectional interface (f1b or f2b). The mechanism for a receiver to learn these addresses is explained in Section 5.3. The type of encapsulation is described in Section 6. The new datagram is passed to the network layer, which forwards it according to its destination address. The destination address is a feed bidirectional interface which is reachable via the Internet. The datagram is then routed via a receiver bidirectional interface. The We have to distinguish several cases as the datagram is to be tunneled according to its destination address. If the destination address is: 1) the IP address of a feed unidirectional interface: the datagram Duros [Page 4] Internet Draft LL tunneling mechanism Expiration date is encapsulated, the destination address of the new datagram is the feed tunnel end-point. 2) the broadcast address of the unidirectional link or the "all feeds" multicast address: a copy of the datagram is encapsulated and sent to every feed tunnel end-point. 3) an IP address that belongs to the unidirectional network but is not a feed address: the datagram is encapsulated and sent to the tunnel end-point of the default feed. The default feed the one with the smallest IP number on the satellite link. This allows, for instance, for receivers to ping each other. 4) an IP address different from the previous cases (any IP address): the datagram is discarded, see Section 8.1. At this point, the network layer passes a datagram to the link layer of the unidirectional interface, which is encapsulated and sent to one or all the feeds. 5.2. Tunneling mechanism at the feed The feed listens to incoming encapsulated datagrams on its tunnel end-point. A packet is received from the bidirectional interface, traverses the IP stack, and goes into a decapsulation process. The original datagram is decapsulated and passed to link layer driver of the feed unidirectional interface. As a result, the datagram is processed as if it was coming from the send-only interface. If the datagram is an IP packet, it is delivered to the feed network layer. Since the datagram was encapsulated, its IP header has not been modified by intermediate routers. To the network layer, the datagram appears as coming from the send-only interface. The network layer forwards the datagram according to its destination address. If the destination address is: 1) the IP address of the feed send-only interface or the unidirectional link broadcast IP address: the datagram is kept and delivered locally. 2) otherwise it is forwarded according the feed routing tables. A receiver may ping another receiver on the unidirectional link, its request is forwarded by the feed to the destination. 5.3. Dynamic tunneling configuration: the HELLO protocol Duros [Page 5] Internet Draft LL tunneling mechanism Expiration date A receiver has to know the feed tunnel end-points in order to forward encapsulated datagrams. Tunnels must be configured and maintained dynamically in order to cope with the following events: 1) as a new feed comes up, every receiver should create a tunnel to enable a bidirectional communication with it. Static tunneling configuration is not appropriate, as new feeds can be connected to the unidirectional link at any time. 2) as the unidirectional link is down, receivers must disable their tunnels. The tunneling mechanism emulates bidirectional connectivity between a feed and a receiver. Therefore, if the unidirectional link is down, a feed should not receive datagrams from the receivers. Indeed there are protocols which consider a link as operational if they receive datagrams from it (e.g. the RIP protocol [rfcRIP]). 3) as a feed is suddenly down, receivers must disable the corresponding tunnel. This prevents unecessary datagrams from being tunneled which would overload the Internet. For instance, there is no need for receivers to forward a broadcast message through a tunnel whose end-point is down. The HELLO protocol provides a means for receivers to dynamically discover the presence of feeds and maintain a list of operational tunnel end-points. It is based on periodical feed announcements over the unidirectional link which contain tunnel end-point addresses. Receivers listen to these announcements, discover the presence of feeds, and maintain a list of tunnel end-points. 5.3.1. The HELLO message The HELLO protocol is a 'unidirectional protocol', messages are only sent from feeds to receivers. The packet format is shown in Figure 2. Field sizes are given in octect. Fields contain binary integers, in normal Internet order with the most significant octet first. Each tick mark represents one bit. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version (1) | command (1) | must be zero (2) | +---------------+---------------+-------------------------------+ | Feed unidirectional IP address (4) | +---------------------------------------------------------------+ | Feed bidirectional IP address (4) | +---------------------------------------------------------------+ Duros [Page 6] Internet Draft LL tunneling mechanism Expiration date Figure 2: Packet Format Every datagram contains a version number, a command and two IP addresses. The version number of the HELLO protocol is HELLO_VERSION (constant definitions are given in Section 5.3.5). The command field is used to specify the purpose of this datagram. Possible values of the command field implemented in the version HELLO_VERSION of the protocol are: 1 - JOIN A message announcing that the feed sending this message is up and running. 2 - LEAVE A message announcing that the feed sending this message is being shut down. The last two fields must be set regardless of the command (JOIN or LEAVE). The feed unidirectional IP address (FUIP) field is the IP address of the outgoing unidirectional interface of the feed which sends the HELLO packet. The feed bidirectional IP address (FBIP) field is the IP address of a feed bidirectional interface reachable via the Internet. A feed may have several bidirectional interfaces connected to the Internet, but only one is selected as FBIP. The choice of this interface is outside the scope of this Internet Draft. It is the feed administrator who selects the most suitable interface to announce. This address will be used by receivers as the tunnel end-point. 5.3.2. The HELLO protocol at the feed The HELLO protocol runs on top of UDP. Packets are sent to the broadcast address of the unidirectional link on port HELLO_PORT. The source address of HELLO packet is set to the IP address of the feed outgoing unidirectional interface. The process in charge of sending HELLO packets fills every field of the datagram according to the description given in Section 5.3.1. As long as a feed is up and running, it periodically announces its presence and bidirectional interface to receivers. It MUST send HELLO packets containing a JOIN command every HELLO_INTERVAL on the unidirectional link. Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO messages with the FUIP field set to f1u (resp. f2u) and the FBIP Duros [Page 7] Internet Draft LL tunneling mechanism Expiration date field set to f1b (resp. f2b). Note that all FUIPs should have the same network prefix: the unidirectional network address. When a feed is about to be shut down, or when routing over the unidirectional link is about to be intentionally interrupted, it is recommended to: 1) stop sending HELLO messages containing a JOIN command. 2) send a HELLO message containing a LEAVE command to inform receivers that the feed is no longer performing routing over the unidirectional link. 5.3.3. The HELLO protocol at the receiver Based on the reception of HELLO messages, receivers discover the presence of feeds and keep trace of their corresponding tunnel end- points. Every receiver maintains a list of active feeds which contains pairs of (FUIP,FBIP). When a receiver is started, it MUST run a process which listens to incoming broadcast packets on port HELLO_PORT from its unidirectional interface. The list of active feeds is initially empty. Upon reception of a HELLO message, the process checks the version number of the protocol. If it is different from HELLO_VERSION, the packet is discarded and the process waits for the next incoming packet. After successfully checking the version number it is recommended to check that the FUIP contained in the packet is the same as the source address of the HELLO packet. Further action depends on the type of command: - JOIN: The process verifies if the pair (FUIP,FBIP) contained in the HELLO packet already belongs to the list of active feeds. If it does not, the pair (FUIP,FBIP) is added to the list of active feeds. A timer set to HELLO_LEAVE is associated with this pair. If it does, the timer associated with this pair is reset to HELLO_LEAVE. Referring to Figure 1 in Section 3, both receivers (recv 1 and recv 2) have a list of active feeds containing two pairs which are Duros [Page 8] Internet Draft LL tunneling mechanism Expiration date (f1u,f1b) and (f2u,f2b). - LEAVE: The process checks if the pair (FUIP,FBIP) contained in the HELLO packet belongs to the list of active feeds. If it does, it is deleted the list the corresponding timer is disabled. The LEAVE message provides a means of quickly updating the list of active feeds. A timout can have two reasons: 1) a feed went down without sending a LEAVE message. As JOIN messages are not sent from this feed anymore, a timemout expires HELLO_LEAVE after receiving the last JOIN message. 2) the unidirectional link is down. Thus, no more JOIN messages are received from the feeds. All the timeouts associated with pairs (FUIP,FBIP) will have expired HELLO_LEAVE after receiving the last JOIN message from the unidirectional link. In both cases, the associated (FUIP,FBIP) pair is removed from the list of active feeds. As either the feed does not route datagrams over the unidirectional link or the link is down, bidirectional connectivity cannot be ensured any longer between the receiver and the feed (FUIP). As a result, the list only contains operational tunnel end-points. The HELLO protocol provides receivers with the list of usable tunnel end-points (FBIP). In the following section, we describe how to integrate the HELLO protocol into the tunneling mechanism described in Sections 5.1 and 5.2. 5.3.4. Tunneling mechanism using the list of active feeds This section explains how the tunneling mechanism uses the list of active feeds to handle datagrams which are to be tunneled. Referring to Section 5.1, it shows how feed tunnel end-points are selected. Several cases are enumerated in Section 5.1 to determine where to forward a datagram according to its destination address. If the destination address is: 1) the IP address of a feed unidirectional interface: this is TRUE if the address matches with a FUIP in the list of active feeds. The datagram is encapsulated and sent to the corresponding FBIP. 2) the broadcast address of the unidirectional link or a multicast Duros [Page 9] Internet Draft LL tunneling mechanism Expiration date address: a copy of the datagram is encapsulated and sent to every FBIP in the list of active feeds. If the list is empty, the datagram is discarded. 3) an IP address that belongs to the unidirectional network but is not a feed address (i.e., it does not match any FUIP in the list of active feeds): the datagram is encapsulated and sent to the smallest FUIP found in the list. If the list is empty, the datagram is discarded. 4) an IP address different from cases 1), 2) and 3): the datagram is discarded. 5.3.5. Constant definitions HELLO_VERSION is 1. HELLO_INTERVAL is 10 seconds. HELLO_PORT is 620. It is a reserved port, no other traffic must be allowed. HELLO_LEAVE is 3*HELLO_INTERVAL, i.e. 30 seconds. 6. Generic Routing Encapsulation The encapsulation format is determined by the type of data which is to be tunneled. It must support the encapsulation of IP datagrams in order to tunnel IP datagrams from receivers to feed tunnel end- points. The unidirectional network may support hardware addressing. Before sending an IP datagram to a receiver, the feed must obtain the hardware address of the receiver unidirectional interface. The Address Resolution Protocol [rfcARP] is a 'method of Converting Protocol Addresses (e.g. IP addresses) to Local Network Addresses (e.g. Ethernet Addresses)'. It is a link layer protocol which assumes that links are bidirectional. If the link is unidirectional, a receiver cannot respond to an ARP request generated by a feed. Using the tunneling mechanism described in the previous sections, a receiver should be able to tunnel ARP responses to feeds. The encapsulation format must also support the encapsulation of the ARP protocol. The Generic Routing Encapsulation (GRE) [rfcGRE1702] specifies a protocol for encapsulating arbitrary packets within IP as the Duros [Page 10] Internet Draft LL tunneling mechanism Expiration date delivery protocol. GRE suits well our requirements, as it allows encapsulation of both the ARP and the IP protocol within IP. 6.1. Encapsulation format A GRE packet is composed of a header in which a type field specifies the encapsulated protocol (ARP, IP, IPX, etc.). See [rfcGRE1701] for details about the encapsulation. In our case only the support of ARP and IP MUST be implemented. A packet tunneled with a GRE encapsulation has the following format: the delivery header is an IP header whose destination is the tunnel end-point (FBIP), followed by a GRE header indicating if the payload is either an ARP message or an IP datagram. Figure 3 presents the entire encapsulated packet. ---------------------------------------- | IP delivery header | | destination addr = FBIP | | IP proto = GRE (0x47) | ---------------------------------------- | GRE Header | | type = ARP (0x806) or IP (0x800) | ---------------------------------------- | Payload packet | | ARP or IP | ---------------------------------------- Figure 3: Encapsulated packet 6.2. GRE at the receiver The link layer driver of the receive-only interface can pass two types of datagrams to the encapsulation process. The link layer datagram format is as follow: ---------------------------------------- | type | | ARP (0x806) or IP (0x800) | ---------------------------------------- | data | | ARP or IP | ---------------------------------------- Figure 4: Link Layer encapsulation An IP datagram delivered from the network layer to the link layer is encapsulated behind an IP type header. The link layer sending an ARP Duros [Page 11] Internet Draft LL tunneling mechanism Expiration date response to a feed encapsulates the response behind an ARP type header. The encapsulation process checks the type of protocol of the datagram read from the link layer. According to this, it obtains the destination address from the datagram, encapsulates the datagram behind a GRE header, and tunnels it following the requirements in Section 5.3.4. 6.3. GRE at the feed The decapsulation process receives the GRE packet and extracts the original datagram. The process passes the datagram (type+data) to the link layer driver of the send-only interface. The link layer determines what type of data it received (IP or ARP) and queues the packet for processing. The tunneling mechanism using a GRE encapsulation provides a mean for carrying IP and ARP datagrams from receivers to feeds. However the ARP protocol as described in [rfcARP] cannot work efficiently in spite of the link layer tunneling. 7. Address Resolution Protocol The ARP protocol has been designed originally for 10MBits Ethernet hardware where delays between directly connected hosts are very small. A host can get a response to an ARP request within a millisecond. For this reason, ARP is an on-demand mechanism, the ARP protocol requests a hardware address as it needs it. Our link layer mechanism emulates a bidirectional network in the presence of an unidirectional link. However, there are asymmetric delays between every (feed, receiver) pair. The back-channel between a receiver and a feed has varying delay because packets go through the Internet. Furthermore, a typical example of unidirectional link is a GEO satellite link whose constant delay is 250 milliseconds. As a result, a feed may get a response to an ARP request at least 250 ms later in some cases. If a feed has to forward packets at high data rates to a receiver whose hardware address is unknown, it will drop part of the packets. Indeed, the stream of packets is passed to the link layer driver of the feed send-only interface. When the first packet arrives, the link layer realizes it does not have the corresponding hardware address of the next hop, and sends an ARP Duros [Page 12] Internet Draft LL tunneling mechanism Expiration date request. While the link layer is waiting for the response (at least 250 ms), IP packets are buffered by the feed. If it runs out of space before the ARP response arrives, IP packets will be dropped. Therefore, the ARP protocol has to be modified to take into account high latencies, as a simple on demand approach is not sufficient. 7.1. ARP at the receiver It is interesting to note that the link layer of the receive-only interface does not maintain an ARP cache table. The receiver always tunnels datagrams which are sent to feeds via the Internet. The receiver must be able to reply to ARP requests sent by feeds. As the link layer receives the request, it prepares the ARP response and passes it to the encapsulation process as described in Section 6.2. An on-demand ARP mechanism is not sufficient because feeds cannot get receiver hardware addresses quickly enough. Thus, ARP cache tables at feeds should be then constantly updated/refreshed. For that purpose, every receiver periodically sends encaspulated ARP responses to the list of active feeds. The interval is ARP_INTERVAL (constant definitions are given in Section 7.3). This mechanism can be implemented in the encapsulation process. 7.2. ARP at the feed A feed refreshes its ARP table every time it receives an ARP response from a receiver. If the entry does not exist, it is created, otherwise the ARP timer is reset to ARP_CLEAR. An ARP entry in the cache table is deleted after ARP_CLEAR. This happens when a receiver suddenly goes down and no longer sends periodical ARP responses. In spite of its possibly high latency, the classical on-demand ARP mechanism is still necessary. After a feed comes up it may need to forward a packet to a receiver. It is better to immediately initiate an ARP request and obtain the response short after 250 ms rather than within ARP_INTERVAL. 7.3. Constant definitions ARP_INTERVAL is 1 minute. ARP_CLEAR is 3*ARP_INTERVAL, i.e. 3 minutes. Duros [Page 13] Internet Draft LL tunneling mechanism Expiration date 8. Issues 8.1. Routing protocols The link layer tunneling mechanism hides from the network layer and above layers the fact that feeds and receivers are connected by an unidirectional link. Communication is bidirectional but asymmetric in bandwidths and delays. In order to incorporate unidirectional links in the Internet, feeds and receivers have to run routing protocols. They will work fine because feeds and receivers consider themselves as directly connected, and can exchange routing messages over the unidirectional link. However, routing protocols MUST be configured to take into account the link unidirectionality. IP routing must match the real topology of the Internet at network level. It is not the aim of the tunneling mechanism to forward the IP traffic, it MUST only be used to forward routing protocol messages from receivers to feeds. Routing protocols at the receivers MUST prevent IP traffic from being forwarded to their receive-only interface. For example, using RIP [rfcRIP], receivers announce reachable subnets to the feeds, but they must not take into account those announced by the feeds. 8.2. Scalability This Internet Draft does not discuss the case of a very large number of receivers and/or feeds. In case of a large number of feeds, it will probably be necessary to use multicast routing. Indeed, instead of sending a copy of a datagram to every entry of the list of active feeds, a single datagram could be sent on a reserved multicast group the feeds would listen to. However this requires that the receivers and the feeds are connected to the MBone. 9. References [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, November 1982 [rfc1702] 'Generic Routing Encapsulation over IPv4 networks', S. Hanks, NetSmiths, Ltd., T. Li, D. Farinacci, P. Traina, cisco System, October 1994 [rfc1701] 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths, Duros [Page 14] Internet Draft LL tunneling mechanism Expiration date Ltd., T. Li, D. Farinacci, P. Traina, cisco System, October 1994 [rfc1388] 'RIP Version 2 - Carrying Additional Information', G. Malkin, Xylogics, Inc., January 1993 Author's address Emmanuel Duros INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Email : Emmanuel.Duros@sophia.inria.fr Phone : +33 4 93 65 79 42 Duros [Page 15]