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
<draft-ietf-udlr-lltunnel-02.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.
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]
