[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UDLR WG: A Link Layer Tunneling Mechanism for Unidirectional Links
Hi all,
the last I-D "A Link Layer Tunneling Mechanism for Unidirectional Links"
is available at
http://www.inria.fr/rodeo/udlr/documents/draft-ietf-udlr-lltunnel-01.txt
It takes into account:
- comments from the last UDLR session in Los Angeles
- implementation feedback from the Wide project and
INRIA. Interoperability tests on the way...
Comments are welcome !
Emmanuel Duros
http://www.inria.fr/rodeo/personnel/eduros
------
Network Working Group Emmanuel Duros
Internet-Draft Walid Dabbous
March 1998 INRIA Sophia-Antipolis
Hidetaka Izumiyama
Noboru Fujii
WIDE
Yongguang Zhang
HUGHES Research
A Link Layer Tunneling Mechanism for Unidirectional Links
<draft-ietf-udlr-lltunnel-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes a mechanism to emulate bidirectional
connectivity between nodes that are directly connected by an
unidirectional link. The "receiver" uses a link layer tunneling
mechanism to forward datagrams to "feeds" through a bidirectional
network.
1. Introduction
Internet routing and upper layer protocols assume that links are
bidirectional, i.e. directly connected hosts can communicate with
each other on the same link.
This Internet Draft describes a link layer tunneling mechanism which
allows nodes that are directly connected by an unidirectional link
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 1]
Internet Draft LL tunneling mechanism March 1998
(feeds and receivers) to send datagrams as if they were connected to
a bidirectional link. The document presents a generic topology with a
tunneling mechanism that supports multiple feeds and receivers.
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 to higher layers, i.e. network
layer and above, the unidirectional feature of the link. The
tunneling mechanism also includes an automatic tunnel configuration
protocol which allows feeds and receivers to come up/down at any
time.
The tunneling mechanism 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 Internet Draft was discussed
and agreed upon by the UDLR working group.
2. Terminology
Unidirectional link (UDL): A one way transmission link, e.g. a
satellite link.
Receiver: A router that has receive-only connectivity to an UDL.
Send-only feed: A router that has a send-only connectivity to an UDL.
Receive capable feed: A router that has a send-and-receive
connectivity to an UDL.
Feed: A send-only or a receive capable feed.
3. Topology
In general, feeds and receivers are connected via an unidirectional
link. Send-only feeds can only send data over this unidirectional
link, and receivers can only receive data from it. But we also
consider in this document the case of "non transitive links" where
receive capable feeds have both send and receive capabilities, and
receivers have receive-only capabilities.
A receiver has several interfaces, a receive-only interface and one
or more bidirectional additional communication interfaces. A receiver
is required to be a router.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 2]
Internet Draft LL tunneling mechanism March 1998
A feed has several interfaces, a send-only or a send-and-receive
capable interface connected to the unidirectional link and one or
more bidirectional additional communication interfaces. A feed is
required to 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 a 'Feed 1' (resp. Feed 2)
bidirectional interface connected to the Internet.
r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver
2) receive-only interface.
r1b (resp. r2b) is the IP address of a 'Receiver 1' (resp. Receiver
2) bidirectional interface connected to the Internet.
4. Problems related to unidirectional links
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 3]
Internet Draft LL tunneling mechanism March 1998
Most protocols in the Internet assume that links are bidirectional.
In particular, routing protocols used by directly connected routers
no longer behave properly in the presence of an unidirectional link.
Indeed, receivers cannot send requests/responses or routing messages
to feeds through their receive-only interface.
The network layer has no knowledge of the underlying transmission
technology except, it considers its access as bidirectional.
Basically, for outgoing datagrams, the network layer selects the
correct first hop on the connected network according to a routing
table and passes the packet(s) to the appropriate link-layer driver.
Referring to Figure 1, Recv 1 and Feed 1 belong to the same network.
However, initiating a 'ping f1u' on Recv 1 cannot get a response from
Feed 1. Recv 1 network layer delivers the packet to the driver of the
receive-only interface, which obviously cannot send it to the feed.
More generally, a datagram of any protocol which passes from the
network layer to the driver of a receive-only interface is simply
discarded.
5. 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 may also send broadcast
messages. 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 link layer tunneling mechanism which emulates a bidirectional
connectivity in the presence of an unidirectional link will be
described in the next section. We now need to consider what are the
communication scenarios which characterize a broadcast network in
order to define what functionalities the link layer tunneling
mechanism has to perform.
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 heard by all nodes (point to multipoint).
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 4]
Internet Draft LL tunneling mechanism March 1998
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 an unidirectional
link.
These scenarios are possible on a broadcast network, the link layer
tunneling mechanism should provide a means for these scenarios to
happen.
6. Link layer tunneling mechanism
This section describes a link layer tunneling mechanism allowing
bidirectional communication between feeds and receivers in the
presence of an unidirectional link. This mechanism has been designed
to work for any topology regardless of the number of feeds and
receivers. In particular, the special case of a single 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 to the
network layer as if it was bidirectional.
Figure 2 depicts a layered representation of the link layer tunneling
mechanism and shows how Scenario 1 in Section 5 is handled.
[Intentionally left blank]
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 5]
Internet Draft LL tunneling mechanism March 1998
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 |
| \------------>------->------------/ |
\----------------------<------------------------<--------/
Internet
x : IP layer generates a datagram
O : Entry point where the link layer tunneling mechanism is
triggered
Figure 2: Link Layer Tunneling Mechanism (Corresponds to Scenario 1)
6.1. Tunneling mechanism at the receiver
The tunneling mechanism is inserted at the link layer of the
receive-only interface. As a datagram is delivered to the link layer
from the network layer, it is encapsulated (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 is explained in Section 6.3.3. The type of
encapsulation is described in Section 7.
The new datagram is passed to the network layer which forwards it
according to its destination address. The destination address is a
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 6]
Internet Draft LL tunneling mechanism March 1998
feed bidirectional interface which is reachable via the Internet. The
datagram is then routed via the receiver bidirectional interface
(r1b).
We have to distinguish several cases as the datagram is to be
tunneled according to its destination address. If the destination
address is:
1) the IP address of a feed 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.
4) an IP address different from the previous cases (any IP
address): the datagram is discarded. Packets whose destination
does not belong to the unidirectional link are discared. Routing
is not allowed, see Section 8.2.
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 at the feed
A feed processes packets in two different ways: packets which have to
be routed over the unidirectional link (e.g. packets generated by a
local application or a packet routed by the IP layer) and
encapsulated packets it receives which need particular processing.
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 maintains a list of send-only feed tunnel end-points. For
reasons of administrative simplicity, this list of tunnel end-points
is configured manually at the feed by the local administrator. How to
use this list is detailed in the next section.
6.2.1. Forwarding packets over the unidirectional link
We need to distinguish serveral cases according to the next hop IP
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 7]
Internet Draft LL tunneling mechanism March 1998
destination address of the packet, it can be:
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 is received from the bidirectional interface,
traverses the IP stack and goes into 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 its
destination address, it 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 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 the encapsulated packet
was sent from a receiver (A) or from a feed (e.g. case of
Section 6.2.1. item 3) (B):
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 8]
Internet Draft LL tunneling mechanism March 1998
A- the feed was designed as 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. The
process 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 must be applied.
B- 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).
This configuration is performed manually at the feed. The admnistator
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) as 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) as 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 which 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 March 1998
3) as a feed is down, receivers must disable their corresponding
tunnel. This prevents unnecessary datagrams from being tunneled
which would overload the Internet. For instance, there is no
need for receivers to forward a broadcast message through a
tunnel whose end-point is down.
The DTCP protocol provides a means for receivers to dynamically
discover 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 which 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 an '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 octet
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 (FBIP 1) (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed BDL IP addr (FBIP n) (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet Format
Every datagram contains the following fields (see section 6.3.5 for
constant definitions):
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 March 1998
2 - LEAVE A message announcing that the feed sending this message
is being shut down.
Interval (8 bits unsigned integer): Interval in seconds between HELLO
messages. The recommended value is HELLO_INTERVAL. This field MUST
not be changed while sending.
Sequence (16 bits 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 = MAC level type of the unidirectional link (MAC type over IP)
or other tunnel type supported by the feed
Nb of FBIP (8 bits): Number of feed bidirectional IP 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 feed bidirectional IP
address FBIP field 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 be preference order. FBIP 1 being the most
suitable tunnel end-point.
6.3.2. DTCP at 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 March 1998
announcement" multicast address on the unidirectional link on port
HELLO_PORT with a ttl of 1.
The source address of 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 and bidirectional interface to receivers. It MUST send HELLO
packets containing a JOIN command every HELLO_INTERVAL on the
unidirectional link.
Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO
messages with the FUIP field set to f1u (resp. f2u) and the FBIP 1
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 at 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 trace of
their tunnel end-points. This is list is composed of pairs of
(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 port HELLO_PORT from the unidirectional link.
Upon reception of a HELLO message, the process checks the version
number of the protocol. If it is different from HELLO_VERSION, the
packet is discarded and the process waits for the next incoming
packet.
After successfully checking the version number it is recommended to
check that the FUIP contained in the packet is the same as the source
address of the HELLO packet. Further actions depend on the type of
command:
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 12]
Internet Draft LL tunneling mechanism March 1998
- 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 pair (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 pair 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 pairs 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 timout can have two reasons:
1) a feed went down without sending a LEAVE message. As JOIN
messages are not sent from this feed anymore, a timemout expires
HELLO_LEAVE after receiving the last JOIN message.
2) the unidirectional link is down. Thus, no more JOIN messages are
received from the feeds. All the timeouts associated with pairs
(FUIP,(FBIP1,..., FBIPn)) will have expired HELLO_LEAVE after
receiving the last JOIN message from the unidirectional link.
In both cases, the associated (FUIP,(FBIP1,..., FBIPn)) pair is
removed from the list of active feeds. As either the feed does not
route datagrams over the unidirectional link or the link is down,
bidirectional connectivity cannot be ensured any longer between the
receiver and the feed (FUIP). As a result, the list only contains
operational tunnel end-points.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 13]
Internet Draft LL tunneling mechanism March 1998
The HELLO protocol provides receivers 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 out of scope in this document.
However the default feed might be the closest feed to the receiver
which, in any case, must belong to the list of active feeds.
Several cases are enumerated in Section 6.1 to determine where to
forward an IP datagram according to its destination address. If the
destination address is:
1) the IP address of a feed interface connected to the
unidirectional link: this is TRUE if the address matches with a
FUIP in the list of active feeds. The datagram is encapsulated
and sent to the corresponding FBIP 1. 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 packets 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 packets is discarded. The encapsulation type
depends on the tunnel type required by the default feed.
4) an IP address different from cases 1), 2) and 3): the datagram
is discarded.
6.3.5. Constant definitions
DTCP_VERSION is 1.
HELLO_INTERVAL is 10 seconds.
"DTCP announcement" multicast group is XXX.YYY.ZZZ.WWW.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 14]
Internet Draft LL tunneling mechanism March 1998
HELLO_PORT is XXX. It is a reserved port, no other traffic must be
allowed.
HELLO_LEAVE is 3*HELLO_INTERVAL, i.e. YY seconds.
7. Tunnel encapsulation format
The tunneling mechanism operates at link layer level and emulates
bidirectional connectivity between receivers and feeds. We assume
that hardware connected the unidirectional link supports broadcast
and unicast MAC addressing. I.e., a feed can send a packet to a
particular receiver using a unicast MAC destination address or to a
set of receiver 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 assumption of the
encapsulated data type.
In a similare 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. Note, other encapsultions can be chosen.
It is the feed local administrator who decides what encapsulation to
use 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 the
MAC level of the unidirectional link within IP (other tunnel type
should be possible).
7.1. Generic Routing Encapsultation at 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. Note, this MAC level packet can carry an IP
packet or an ARP packet.
A packet tunneled with a GRE encapsulation has the following format:
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 15]
Internet Draft LL tunneling mechanism March 1998
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. MAC level packet of the UDL within IP
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 encapsulted
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 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 March 1998
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 unidirectional link
is a GEO satellite link whose delay is about 250 milliseconds.
For these reasons, current address resolution protocol such as
[rfc826] are not efficient. A feed will get a response to an ARP
request at least 250 ms later in some cases. If a feed has to forward
packets at high data rates to a receiver whose hardware address is
unknown, it will drop part of the packets. Indeed, the stream of
packets is passed to the link layer driver of the feed send-only
interface. When the first packet arrives, the link layer realizes it
does not have the corresponding hardware address of the next hop, and
sends an ARP request. While the link layer is waiting for the
response (at least 250 ms), IP packets are buffered by the feed. If
it runs out of space before the ARP response arrives, IP packets will
be dropped.
The aim of this document is not to define a new address resolution
specific to the unidirectional link which would sort out, for
instance, the latency problem. It only provides a means for receivers
and feeds with receive capability to send hardware addresses via the
tunnel.
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 an
unidirectional link. Communication is bidirectional but asymmetric in
bandwidths and delays.
In order to incorporate unidirectional links in the Internet, feeds
and receivers have to run routing protocols. They will work fine
because feeds and receivers consider themselves as directly
connected, and can exchange routing messages over the unidirectional
link.
However, routing protocols MUST be configured to take into account
the link unidirectionality. IP routing must match the real topology
of the Internet at network level. It is not the aim of the tunneling
mechanism to forward the IP traffic, it MUST only be used to forward
routing protocol messages from receivers to feeds. Routing protocols
at the receivers MUST prevent IP traffic from being forwarded to
their receive-only interface.
For example, using RIP [rfc1388], receivers announce reachable
subnets to the feeds, but they must not take into account those
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 17]
Internet Draft LL tunneling mechanism March 1998
announced by the feeds.
8.3. Scalability
The DTCP protocol does not generate large traffic whatever the number
of nodes. The problem of 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 in this
document.
9. Acknowledgments
We would like to thank the following people for their valuable
inputs: 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).
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 CEDEX France
Phone : +33 4 92 38 79 42
Fax : +33 4 92 38 79 78
Email : Emmanuel.Duros@inria.fr
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 18]
Internet Draft LL tunneling mechanism March 1998
Walid Dabbous
INRIA Sophia Antipolis
2004, Route des Lucioles BP 93
06902 Sophia Antipolis CEDEX 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
Hughes Research Laboratories
RL-96, 3011 Malibu Canyon Road
Malibu, CA 90265, USA
Phone : 310-317-5147
Fax : 310-317-5695
Email : ygz@isl.hrl.hac.com
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 19]