[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 rfc3077                                  
Network Working Group                                           E. Duros
Internet-Draft                                                W. Dabbous
February 1999                                     INRIA Sophia-Antipolis
                                                            H. Izumiyama
                                                                N. Fujii
                                                                    WIDE
                                                                Y. Zhang
                                                                     HRL



       A Link Layer Tunneling Mechanism for Unidirectional Links
                   <draft-ietf-udlr-lltunnel-00.txt>


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.


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.


1. Introduction




Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 1]


Internet Draft           LL tunneling mechanism             January 1999


   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 and ARP datagrams from
   receivers to feeds.

   The tunneling mechnism 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
   link. Send-only feeds can only send data over this unidirectional
   link, and receivers can only receive data from it. Receive capable



Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 2]


Internet Draft           LL tunneling mechanism             January 1999


   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.

   r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver



Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 3]


Internet Draft           LL tunneling mechanism             January 1999


       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
   broadcast link.



Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 4]


Internet Draft           LL tunneling mechanism             January 1999


   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
   mechanism in the case of Scenario 1.




Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 5]


Internet Draft           LL tunneling mechanism             January 1999


            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

   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 (See Figure 2).

   The datagram is encapsulated behind an IP header whose destination is
   the IP address of a feed bidirectional interface (f1b or f2b), also
   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



Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 6]


Internet Draft           LL tunneling mechanism             January 1999


   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 next hop address. If the next hop address
   is:

     1) the IP 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 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) an IP 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.

6.2.1. Forwarding packets over the unidirectional link

   The way a packet is forwarded depends on its next hop IP address, if
   it is:




Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 7]


Internet Draft           LL tunneling mechanism             January 1999


     1) the IP address of a receiver or a receive capable feed (Scenario
        6). The packet is encapsulated behind a link layer header with
        the corresponding MAC address of the destination. It is then
        sent over the unidirectional link.

     2) the IP address of a send-only feed (Scenario 4). The packet is
        encapsulated and sent to the send-only feed tunnel end-point.

     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 IP header has not been modified by
   intermediate routers. It is decapsulated and further actions depend
   on the next hop IP address which can be:

     1) the 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.
        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



Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 8]


Internet Draft           LL tunneling mechanism             January 1999


           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 administator sets up tunnels to all send-only feeds.
   A tunnel end-point is an IP address (FBIP) 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
        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 [rfc1388]).




Duros, Dabbous, Izumiyama, Fujii, Zhang                         [Page 9]


Internet Draft           LL tunneling mechanism             January 1999


     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.

   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  UDL IP addr          (32/128 bits) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   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:

   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.



Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 10]


Internet Draft           LL tunneling mechanism             January 1999


      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. 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,
     correponds 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 UDL IP addr: 32 or 128 bit field. The value is the IP address of
     the feed interface connected to the unidirectional link which sends
     the HELLO packet.


   Feed BDL IP addr: 32 or 128 bit field. The bidirectional IP address
     feed 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 prefered 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             January 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.

   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 FUIP field set to f1u (resp. f2u) and 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 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:




Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 12]


Internet Draft           LL tunneling mechanism             January 1999


   - JOIN:

      The process verifies if the address FUIP contained in the HELLO
      packet 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
      contained in the HELLO packet 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 occure 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 occures 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.




Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 13]


Internet Draft           LL tunneling mechanism             January 1999


   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
   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 this
   document.

   Several cases are enumerated in Section 6.1 to determine where to
   forward an IP datagram according to the next hop address. If the next
   hop address is:

     1) the IP address of a feed interface connected to the
        unidirectional link: this is TRUE if the address matches with an
        FUIP in the list of active feeds.  The datagram is encapsulated
        and sent to the corresponding FBIP1. 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
        default feed if it belongs to the list of active feeds.
        Otherwise the packet is discarded. 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 any FUIP in the list of
        active feeds): the datagram is encapsulated and sent to the
        default feed if it belongs to the list of active feeds.
        Otherwise the packet is discarded. 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.

   "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.



Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 14]


Internet Draft           LL tunneling mechanism             January 1999


   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. Other encapsultion mechanisms can be chosen.

   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 encapsulaton supporting UDL MAC level packets.


7.1. Generic Routing Encapsultation 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:
   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.




Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 15]


Internet Draft           LL tunneling mechanism             January 1999


           ----------------------------------------
           |           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 encapsultate 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
   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.



Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 16]


Internet Draft           LL tunneling mechanism             January 1999


   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.

8.3. Scalability

   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. Acknowledgments

   We would like to thank Patrick Cipiere (INRIA) for his valuable input
   concerning the design of the encapsulation mechanism.



Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 17]


Internet Draft           LL tunneling mechanism             January 1999


   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.

   [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.

   [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
   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



Duros, Dabbous, Izumiyama, Fujii, Zhang                        [Page 18]


Internet Draft           LL tunneling mechanism             January 1999


   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]