Network Working Group E. Duros Internet-Draft W. Dabbous June 1999 INRIA Sophia-Antipolis H. Izumiyama N. Fujii WIDE Y. Zhang HRL A Link Layer Tunneling Mechanism for Unidirectional Links Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A version of this draft document is intended for submission to the RFC editor as a Proposed Standard for the Internet Community. Abstract This document describes a mechanism to emulate bidirectional connectivity between nodes that are directly connected by a unidirectional link. The "receiver" uses a link layer tunneling mechanism to forward datagrams to "feeds" over a bidirectional network. As it is implemented at link layer, other protocols than IP may also use this tunneling mechanism. Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 1] Internet Draft LL tunneling mechanism June 1999 1. Introduction Internet routing and upper layer protocols assume that links are bidirectional, i.e., directly connected hosts can communicate with each other over the same link. This document describes a link layer tunneling mechanism that allows nodes which are directly connected by a unidirectional link (feeds and receivers, see section 2 for terminology) to send datagrams as if they were connected to a bidirectional link. We present a generic topology with a tunneling mechanism that supports multiple feeds and receivers. The tunneling mechanism is implemented at the link layer of the interface connected to the unidirectional link on every feed and every receiver. The aim is to hide from higher layers, i.e. network layer and above, the unidirectional feature of the link. The tunneling mechanism also includes an automatic tunnel configuration protocol that allows feeds and receivers to come up/down at any time. The tunneling mechanism proposes to use Generic Routing Encapsulation [rfc1701] and provides a means for carrying IP, ARP datagrams and any layer-3 protocol from receivers to feeds. The tunneling mechanism described in this document was discussed and agreed upon by the UDLR working group. 2. Terminology Unidirectional link (UDL): A one way transmission link, e.g. a broadcast satellite link. Receiver: A router that has receive-only connectivity to an UDL. Send-only feed: A router that has send-only connectivity to an UDL. Receive capable feed: A router that has send-and-receive connectivity to an UDL. Feed: A send-only or a receive capable feed. Node: A receiver or a feed. 3. Topology In general, feeds and receivers are connected via a unidirectional Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 2] Internet Draft LL tunneling mechanism June 1999 link. Send-only feeds can only send data over this unidirectional link, and receivers can only receive data from it. Receive capable feeds have both send and receive capabilities. In this document, we consider the case of several feeds (send-only and/or receive capable) and many receivers. A receiver has several interfaces, a receive-only interface and one or more additional bidirectional communication interfaces. A receiver is required to be a router. A feed has several interfaces, a send-only or a send-and-receive capable interface connected to the unidirectional link and one or more additional bidirectional communication interfaces. A feed MUST be a router. In the entire document we assume that feeds and receivers are connected to the Internet via one of their bidirectional interfaces. A receiver and a feed can then communicate with each other using this specific bidirectional interface (Ethernet interface, PPP connection, etc.). Figure 1 depicts a generic topology with several feeds and several 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) send-only interface. f1b (resp. f2b) is the IP address of the 'Feed 1' (resp. Feed 2) bidirectional interface connected to the Internet. Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 3] Internet Draft LL tunneling mechanism June 1999 r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 2) receive-only interface. r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 2) bidirectional interface connected to the Internet. Subnet A is a local area network connected to recv1 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 a 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 that 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. Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. However, if Recv 1 initiates a 'ping f1u', it 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 that passes from the network layer to the driver of a receive-only interface is simply discarded. 5. Emulating a broadcast bidirectional network Some unidirectional links (e.g., satellite links) allow by nature communication from a feed to a set of receivers: a feed can send packets to a particular receiver and it can send broadcast packets. However, any other communication is simply impossible: a receiver cannot send packets to a receiver or a feed, a feed cannot send a packet to a send-only feed. A solution to this problem based on a link layer (LL) tunneling mechanism which emulates a bidirectional connectivity in the presence of a unidirectional link will be described in the next section. We first consider the various communication scenarios which characterize a broadcast network in order to define what functionalities the link layer tunneling mechanism has to perform to emulate a bidirectional Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 4] Internet Draft LL tunneling mechanism June 1999 broadcast link. Here follows the scenarios which would be feasible on a broadcast network, i.e if feeds and receivers were connected by a bidirectional broadcast link: Scenario 1: A receiver can send a packet to a feed (point-to-point communication between a feed and a receiver). Scenario 2: A receiver can send a broadcast/multicast packet on the unidirectional link to all nodes (point-to-multipoint). Scenario 3: A receiver can send a packet to another receiver (point- to-point communication between two receivers). Scenario 4: A feed can send a packet to a send-only feed (point-to- point communication between two feeds). Scenario 5: A feed can send a broadcast/multicast packet on the unidirectional link to all nodes (point-to-multipoint). Scenario 6: A feed can send a packet to receiver or a receive capable feed. This is the default communication over a unidirectional link. These scenarios are possible on a broadcast network. Scenario 6 is already feasible on the unidirectional link. The link layer tunneling mechanism should therefore provide the functionalities to permit scenarios 1 to 5 to happen. Note that the scenarios above allow a node to send a packet to any destination IP address on the Internet. The next hop address at the receiver will be in this case the address of another router (a feed or a receiver) which will relay the packet. 6. Link layer tunneling mechanism This section describes a link layer tunneling mechanism allowing bidirectional communication between feeds and receivers in the presence of a unidirectional link. This mechanism has been designed to work with any topology regardless of the number of feeds and receivers. In particular, the special case of a single send-only 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 connectivity. It is transparent to the network layer: the link appears and behaves with the network layer as if it was bidirectional. Figure 2 depicts a layered representation of the link layer tunneling Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 5] Internet Draft LL tunneling mechanism June 1999 mechanism in the case of Scenario 1. Send-only Feed Receiver decapsulation encapsulation /-----***************----\ /-->---***************--\ | | | | | | | | --|---------------------- | | ---------------------|--- | | f1b | f1u | | | | x r1u | r1b | | | | | ^ | | IP | | | | v | | ^ | | | v | | | | | | | | | | | | | | v | | | |-|---------|-------|---| | | |----|------|--------|--| | | | | | | ^ | | | | | | | | | | | LL | | | | | | | | | | | | | | | | | | | | | O------/ \<------O | | | |-|---------|-----------| |-----------|--------|--| | | | | | | | | | | | | PHY | | | | | | | | | | v | | | | | | | | | | | --|-----------|---------- ----------|----------|--- | Bidir | Send-Only Recv-Only | Bidir | ^ Interf | Interf UDL Interf | Interf | | \------------>------->------------/ | \----------------------<------------------------<--------/ Bidirectional network x : IP layer at the receiver generates a datagram to be forwarded on the receive-only interface. O : Entry point where the link layer tunneling mechanism is triggered. Figure 2: Scenario 1 using the LL Tunneling Mechanism 6.1. Tunneling mechanism on the receiver A datagram is delivered from the network layer to the link layer of the unidirectional interface (see Figure 2). It is then encapsulated behind a MAC header corresponding to the unidirectional link. This packet cannot be sent over the link and is then processed by the tunneling mechanism. The packet is encapsulated behind an IP header whose destination is the IP address of a feed bidirectional interface (f1b or f2b), also Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 6] Internet Draft LL tunneling mechanism June 1999 called the tunnel end-point. The mechanism for a receiver to learn these addresses and to choose the feed is explained in Section 6.3. The type of encapsulation is described in Section 7. The new datagram is passed to the network layer that forwards it according to its destination address. The destination address of the encapsulated datagram is a feed bidirectional interface which is reachable via the Internet. The datagram is then forwarded via the receiver bidirectional interface (r1b). We have to distinguish several cases as the datagram is to be tunneled according to the destination MAC address. If the destination MAC address is: 1) the MAC address of a feed interface connected to the unidirectional link (scenario 1): the datagram is encapsulated, the destination address of the new datagram is the feed tunnel end-point (f1b referring to Figure 2). 2) a MAC broadcast/multicast address (Scenario 2): the datagram is encapsulated, the destination address of the new datagram is the default feed tunnel end-point. See Section 6.3.4 for further details on the default feed. 3) a MAC address that belongs to the unidirectional network but is not a feed address (Scenario 3): the datagram is encapsulated and sent to the tunnel end-point of the default feed. At this point, the network layer passes a datagram to the link layer of the receive-only interface, it is encapsulated and sent to a feed via its bidirectional interface. 6.2. Tunneling mechanism on the feed A feed processes packets in two different ways: packets must be forwarded over the unidirectional link (e.g. packets generated by a local application or a packet routed by the IP layer, see section 6.2.1) and encapsulated packets received from one of the receivers or the feeds that need particular processing (section 6.2.2). A feed cannot send directly over the unidirectional link a packet to a send-only feed. In order to emulate this type of communication, a feed MUST maintain a list of send-only feed tunnel end-points. This is configured manually at the feed by the local administrator. In fact, as stated in Section 3, the number of feeds is expected to be relatively small, therefore a manual configuration can be envisaged. How to use this list is detailed in the next section. Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 7] Internet Draft LL tunneling mechanism June 1999 6.2.1. Forwarding packets over the unidirectional link The way a packet is forwarded depends on its destination MAC address, if it is: 1) the MAC address of a receiver or a receive capable feed (Scenario 6). The packet is sent over the unidirectional link. This is the classical "forwarding". 2) the MAC address of a send-only feed (Scenario 4). The packet is encapsulated and sent to the send-only feed tunnel end-point. The type of encapsulation is described in Section 7. 3) a broadcast/multicast destination (Scenario 5). The packet is sent over the unidirectional link with a link layer header corresponding to the broadcast/multicast addressing scheme. Currently, a copy of this packet is encapsulated and sent to every feed of the list of send-only feed tunnel end-points. 6.2.2. Receiving encapsulated packets Feeds listen to incoming encapsulated datagrams on their tunnel end- point. An encapsulated packet which is received from the bidirectional interface, traverses the IP stack and enters a decapsulation process (See Figure 2). Note that the original datagram was encapsulated and therefore its payload (especially MAC and IP header) has not been modified by intermediate routers. It is decapsulated and further actions depend on the destination MAC address which can be: 1) the MAC address of the feed interface connected to the unidirectional link, this corresponds to Scenarios 1 and 4. The packet is passed to the link layer of the interface connected to the unidirectional link which then delivers it to the network layer. As a result, the datagram is processed as if it was coming from the unidirectional link. At this point, Scenarios 1 and 4 are now feasible, a receiver or a feed can send a packet to a feed. 2) a receiver address, this corresponds to Scenario 3. The packet is passed to the link layer of the interface connected to the unidirectional link. It is directly sent over the unidirectional link with the proper link layer encapsulation to the receiver (note, the packet must not be delivered to the network layer). Scenario 5 is now feasible, a receiver can send a packet to another receiver. 3) a broadcast/multicast address, this corresponds to Scenario 2. Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 8] Internet Draft LL tunneling mechanism June 1999 We have to distinguish two cases, either (i) the encapsulated packet was sent from a receiver or (ii) from a feed (encapsulated broadcast/multicast packet sent to a send-only feed): i) the feed was designed as a default feed by a receiver to forward the broadcast/multicast packet. The feed is then in charge of sending the multicast packet to all nodes. An encapsulation process at the feed encapsulates the packet and sends a copy to the list of send-only feed tunnel end-points. The packet is also passed to the link layer of the interface which forwards it directly over the unidirectional link (all receivers and receive capable feeds receive it). The link layer also delivers it locally to the network layer. Caution: a receiver which sends an encapsulated broadcast/multicast packet to a default feed will receive its own packet via the unidirectional link. Correct filtering as described in [rfc1112] must be applied. ii) the feed receives the packet and keeps it for local delivery. The packet is passed to the link layer of the interface connected to the unidirectional link which delivers it to the network layer. Scenario 2 is now feasible, a receiver can send a broadcast/multicast packet over the unidirectional link and it will be heard by all nodes. 6.3. Dynamic Tunnel Configuration Protocol (DTCP) Receivers and feeds have to know the feed tunnel end-points in order to forward encapsulated datagrams (e.g, Scenarios 1 and 4). The configuration of the send-only feeds list is performed manually at the feed. The administrator sets up tunnels to all send-only feeds. A tunnel end-point is an IP address of a send-only feed. For scalability reasons this cannot be done at the receivers. Tunnels must be configured and maintained dynamically in order to cope with the following events: 1) when a new feed comes up, every receiver must 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) when the unidirectional link is down, receivers must disable their tunnels. The tunneling mechanism emulates bidirectional Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 9] Internet Draft LL tunneling mechanism June 1999 connectivity between nodes. Therefore, if the unidirectional link is down, a feed should not receive datagrams from the receivers. Indeed there are protocols that consider a link as operational if they receive datagrams from it (e.g., the RIP protocol [rfc2453]). 3) when a feed is down, receivers must disable their corresponding tunnel. This prevents unnecessary datagrams from being tunneled which would overload Internet. For instance, there is no need for receivers to forward a broadcast message through a tunnel whose end-point is down. Note that these tunnels have no existence at the IP layer and are not considered as tunnel interfaces. The DTCP protocol provides a means for receivers to discover dynamically the presence of feeds and to maintain a list of operational tunnel end-points. It is based on feed periodical announcements over the unidirectional link that contain tunnel end-point addresses. Receivers listen to these announcements and maintain a list of tunnel end-points. 6.3.1. The HELLO message The DTCP protocol is a 'unidirectional protocol', messages are only sent from feeds to receivers. The packet format is shown in Figure 2. Fields contain binary integers, in normal Internet order with the most significant byte first. Each tick mark represents one bit. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Com | Interval | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Feed BDL IP addr (FBIP1) (32/128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Feed BDL IP addr (FBIPn) (32/128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Packet Format Every datagram contains the following fields, note that constants are written in uppercase and are defined in section 6.3.5: Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 10] Internet Draft LL tunneling mechanism June 1999 Vers (4 bits): DTCP version number. MUST be DTCP_VERSION. Com (4 bits): Command field, possible values 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. Interval (8 bit unsigned integer): Interval in seconds between HELLO messages for the same layer-3 protocol. The recommended value is HELLO_INTERVAL. This field MUST not be changed while sending. Sequence (16 bit unsigned integer): Random value initialized at boot time and incremented by 1 every time a value of the HELLO message is modified. res (3 bits): Reserved/unused field, MUST be zero. F (1 bit): bit indicating the type of feed: 0 = Send-only feed 1 = Receive-capable feed IP Vers (4 bits): IP protocol version of the feed bidirectional IP addresses (FBIP): 4 = IP version 4 6 = IP version 6 Tunnel Type (8 bits): tunneling protocol supported by feed, corresponds to the type of encapsulation used by receivers to encapsulate packets which are tunneled: 47 = GRE [rfc1701] (recommended) x = any other tunneling supporting the UDL MAC packets. Nb of FBIP (8 bits): Number of bidirectional IP feed addresses which are enumerated in the HELLO message reserved (8 bits): Reserved/unused field, MUST be zero. Feed BDL IP addr: 32 or 128 bit field. The feed bidirectional IP address is the IP address of a feed bidirectional interface (tunnel end-point) reachable via the Internet. A feed has 'Nb of FBIP' IP addresses which are operational tunnel end-points. They are enumerated in preferred order. FBIP1 being the most suitable tunnel end-point. 6.3.2. DTCP on the feed: sending HELLO packets The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 11] Internet Draft LL tunneling mechanism June 1999 announcement" multicast address over the unidirectional link on port HELLO_PORT with a TTL of 1. The source address of the HELLO packet is set to the IP address of the feed interface connected to the unidirectional link. In the rest of the document, this value is called FUIP (Feed Unidirectional IP address). The process in charge of sending HELLO packets fills every field of the datagram according to the description given in Section 6.3.1. As long as a feed is up and running, it periodically announces its presence to receivers. It MUST send HELLO packets containing a JOIN command every HELLO_INTERVAL over the unidirectional link. Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO messages with the FBIP1 field set to f1b (resp. f2b). 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. 6.3.3. DTCP on the receiver: receiving HELLO packets Based on the reception of HELLO messages, receivers discover the presence of feeds, maintain a list of active feeds, and keep track of the tunnel end-points. The list of tunnel end-points is the entries (FUIP,FBIP1,...,FBIPn) and is initially empty. When a receiver is started, it MUST run a process which joins the "DTCP announcement" multicast group and listens to incoming packets on the HELLO_PORT port from the unidirectional link. Upon the 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, further action depends on the type of command: - JOIN: Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 12] Internet Draft LL tunneling mechanism June 1999 The process verifies if the address FUIP already belongs to the list of active feeds. If it does not, the entry (FUIP,FBIP1,...,FBIPn) is added to the list of active feeds. The number of feed bidirectional IP addresses to read is deduced from the 'Nb of FBID' field. The tunnel type is also read and recorded for this FUIP. A timer set to HELLO_LEAVE is associated with this entry. If it does, the sequence number is compared to the sequence number contained in the previous HELLO packet sent by this feed. If it is equal the timer associated with this entry is reset to HELLO_LEAVE. Otherwise all the information corresponding to FUIP is reset. Referring to Figure 1 in Section 3, both receivers (recv 1 and recv 2) have a list of active feeds containing two entries which are (f1u,(f1b)) and (f2u,(f2b)). - LEAVE: The process checks if there is an entry with the value FUIP that belongs to the list of active feeds. If it does, the entry (FUIP,FBIP1,...,FBIPn) is deleted from the list and the corresponding timer is disabled. The LEAVE message provides a means of quickly updating the list of active feeds. A timeout occurs for two reasons: 1) a feed went down without sending a LEAVE message. As JOIN messages are no longer sent from this feed, a timeout occurs at HELLO_LEAVE after 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 entries (FUIP,FBIP1,...,FBIPn) expire at HELLO_LEAVE after the last JOIN message from the unidirectional link. In both cases, the associated (FUIP,FBIP1,...,FBIPn) entries are 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 can no longer be ensured between the receiver and the feed (FUIP). As a result, the list only contains operational tunnel end-points. The HELLO protocol provides the receivers with the list of usable tunnel end-points (FBIP1,..., FBIPn) per feed. In the following section, we describe how to integrate the HELLO protocol into the Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 13] Internet Draft LL tunneling mechanism June 1999 tunneling mechanism described in Sections 6.1 and 6.2. 6.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 6.1, it shows how feed tunnel end-points are selected. The choice of the default feed is done by the receiver administrator according to a local policy. This policy is out of scope of in this document. However, as an example, the default feed may be the feed that has the lowest round trip time to the receiver. When a receiver sends a packet to a feed it chooses the tunnel end- point within the FBIP list. The 'preferred FBIP' is generally FBIP1 (see 6.3.1). However, for some reasons, a receiver may have a better connectivity to another FBIPi of this feed. In that case, it is possible to use FBIPi instead of FBIP1 as tunnel end-point. This decision is taken by the receiver administrator. Several cases are enumerated in Section 6.1 to determine where to forward a MAC packet according to its destination address. If the destination address is: 1) the MAC address of a feed interface connected to the unidirectional link: this is TRUE if the address matches with the MAC address of an FUIP in the list of active feeds. The datagram is encapsulated and sent the preferred FBIP of the feed. The encapsulation type depends on the tunnel type required by the feed FUIP. 2) the broadcast address of the unidirectional link or a multicast address: a copy of the datagram is encapsulated and sent to the preferred FBIP of the default feed. The encapsulation type depends on the tunnel type required by the default feed. 3) an address that belongs to the unidirectional network but is not a feed address (i.e., it does not match a MAC address of any FUIP in the list of active feeds): the datagram is encapsulated and sent to the preferred FBIP of the default feed. The encapsulation type depends on the tunnel type required by the default feed. 6.3.5. Constant definitions DTCP_VERSION is 1. HELLO_INTERVAL is 5 seconds. Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 14] Internet Draft LL tunneling mechanism June 1999 "DTCP announcement" multicast group is 224.0.1.124. HELLO_PORT is 652. It is a reserved system port, no other traffic must be allowed. HELLO_LEAVE is 3*HELLO_INTERVAL, i.e. 15 seconds. 7. Tunnel encapsulation format The tunneling mechanism operates at the link layer level and emulates bidirectional connectivity between receivers and feeds. We assume that hardware connected to the unidirectional link supports broadcast and unicast MAC addressing. That is, a feed can send a packet to a particular receiver using a unicast MAC destination address or to a set of receivers using a broadcast/multicast destination address. The hardware (or the driver) of the receiver can then filter the incoming packets sent over the unidirectional links without any assumption of the encapsulated data type. In a similar way, a receiver should be capable of sending unicast and broadcast MAC packets over the unidirectional link via its tunnels. The encapsulation process should encapsulate link layer level packets. As a result, after decapsulating an incoming packet, the feed can perform link layer filtering as if data was directly coming from the unidirectional link (See Figure 2). The Generic Routing Encapsulation (GRE) [rfc1701] suits our requirements because it specifies a protocol for encapsulating arbitrary packets within IP as the delivery protocol. Alternatively, we can also encapsulate directly a MAC level packet within an IP datagram. It is the feed's local administrator who decides what encapsulation is used by a receiver to send a packet via a tunnel to this feed. The tunnel type field in the HELLO message is either set to GRE or to any other encapsulation supporting UDL MAC level packets. 7.1. Generic Routing Encapsulation on the receiver A GRE packet is composed of a header in which a type field specifies the encapsulated protocol (ARP, IP, IPX, etc.). See [rfc1701][rfc1702] for details about the encapsulation. In our case, only the support of the MAC addressing scheme of the unidirectional link MUST be implemented. A packet tunneled with a GRE encapsulation has the following format: Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 15] Internet Draft LL tunneling mechanism June 1999 the delivery header is an IP header whose destination is the tunnel end-point (FBIP), followed by a GRE header specifying the link layer type of the unidirectional link. Figure 4 presents the entire encapsulated packet. ---------------------------------------- | IP delivery header | | destination addr = FBIP | | IP proto = GRE (47) | ---------------------------------------- | GRE Header | | type = MAC level of the UDL | ---------------------------------------- | Payload packet | | MAC packet | ---------------------------------------- Figure 4: Encapsulated packet 7.2. Encapsulation of UDL MAC level packets An alternative is to encapsulate the MAC level packet within IP. The protocol field in the IP datagram is then set to the MAC level type of the unidirectional link. Figure 5 presents the entire encapsulated packet. ---------------------------------------- | IP delivery header | | destination addr = FBIP | | IP proto = MAC level of the UDL | ---------------------------------------- | Payload packet | | MAC packet | ---------------------------------------- Figure 5: Encapsulated packet 8. Issues 8.1. Hardware address resolution Regardless of unidirectional or bidirectional links, if a feed sends a packet over a broadcast type network it requires the data link address of the destination. ARP [rfc826] is used on an Ethernet network for that purpose. The link layer mechanism emulates a bidirectional network in the Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 16] Internet Draft LL tunneling mechanism June 1999 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 delays because packets go through the Internet. Furthermore, a typical example of a unidirectional link is a GEO satellite link whose delay is about 250 milliseconds. Because of long round trip delays, current address resolution such as [rfc826] may not be efficient. E.g., a feed has to forward packets at high data rates to a receiver whose hardware address is unknown. 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 request. While the link layer is waiting for the response (at least 250 ms for GEO satellite), IP packets are buffered by the feed. If it runs out of space before the ARP response arrives, IP packets will be dropped. The inefficiency of address resolution protocols is not addressed in this document. An ad-hoc solution is proposed when the MAC address is configurable (which is the case in some satellite receiver cards). It consists in mapping the IP address on a MAC address. In this case, no address resolution protocol is required. 8.2. Routing protocols The link layer tunneling mechanism hides from the network layer and above layers the fact that feeds and receivers are connected by a 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. The tunneling mechanism allows one to forward all the IP traffic, and not only routing protocol messages from receivers to feeds. Receivers can route datagrams on the Internet using the most suitable feed or receiver as a next hop. Feeds and receivers can run multicast routing daemon and therefore dynamic multicast routing can be performed over the unidirectional link. However issues related to multicast routing (e.g. protocol configuration) are not addressed in this document. 8.3. Scalability Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 17] Internet Draft LL tunneling mechanism June 1999 The DTCP protocol does not generate a lot of traffic whatever the number of nodes. The problem with a large number of nodes is not related to this protocol but to a more general issue such as the maximum number of nodes which can be connected to a link. This is out of scope of this document. 9. Security Considerations Receivers send packets through tunnels to feeds. Because of scalability reasons, there is no specific mechanism in this document to ensure that a receiver is allowed to set a tunnel to a feed. Any malicious individual that gains access to the unidirectional link can get full connectivity to feeds. Therefore it is highly recommended on the feed site to have some firewall capabilities. 10. Acknowledgments We would like to thank Patrick Cipiere (INRIA) for his valuable input concerning the design of the encapsulation mechanism. We would like also to thank for their participation: Akihiro Tosaka (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu (Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri Hakulinen (Nokia). 11. References [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, November 1982. [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford University, August 1989 [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, Ltd., T. Li, D. Farinacci, P. Traina, Cisco System, October 1994. [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 18] Internet Draft LL tunneling mechanism June 1999 Author's address Emmanuel Duros INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis France Phone : +33 4 92 38 79 42 Fax : +33 4 92 38 79 78 Email : Emmanuel.Duros@inria.fr Walid Dabbous INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis France Phone : +33 4 92 38 77 18 Fax : +33 4 92 38 79 78 Email : Walid.Dabbous@inria.fr Hidetaka Izumiyama Japan Satellite Systems Inc. Toranomon 17 Mori Bldg.5F 1-26-5 Toranomon, Minato-ku Tokyo 105 Japan Voice : +81-3-5511-7568 Fax : +81-3-5512-7181 Email : izu@jcsat.co.jp Noboru Fujii Sony Corporation 2-10-14 Osaki, Shinagawa-ku Tokyo 141 Japan Voice : +81-3-3495-3092 Fax : +81-3-3495-3527 Email : fujii@dct.sony.co.jp Yongguang Zhang HRL RL-96, 3011 Malibu Canyon Road Malibu, CA 90265, USA Phone : 310-317-5147 Fax : 310-317-5695 Email : ygz@hrl.com Duros, Dabbous, Izumiyama, Fujii, Zhang [Page 19]