[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New ID: draft-ietf-udlr-llencap-01.txt
A new ID concerning the Link layer tunneling mechanism for supporting
unidirectional links is available.
You can find it at the following url:
http://www.inria.fr/rodeo/udlr/documents/draft-ietf-udlr-lltunnel-00.txt
All comments are welcome. Discussions during next IETF in Los Angeles
will be focussed on this ID.
Emmanuel
--
http://www.inria.fr/rodeo/personnel/eduros/
------------------ draft-ietf-udlr-llencap-01.txt ----------------------
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-00.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 uses 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: A zero return bandwidth link, e.g. a satellite
link.
Feed: A router connected to an unidirectional link through a
unidirectional or a bidirectional interface.
Unidirectional feed: A router connected to an unidirectional link
through a send-only interface.
Receiver: A router connected to an unidirectional link through a
receive-only interface.
Bidirectional feed: A router connected to an unidirectional link
through a bidirectional interface.
3. Topology
In general, feeds and receivers are connected via an undirectional
link. Unidirectional 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 bidirectional feeds have both send and receive capabilities,
and receivers have receive only capabilities.
A receiver has several interfaces, a receive-only interface and one
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 2]
Internet Draft LL tunneling mechanism March 1998
or more bidirectional additional communication interfaces. A receiver
is required to be a router.
A feed has several interfaces, a send-only or a bidirectional
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)
unidirectional interface (send-only).
f1b (resp. f2b) is the IP address of a 'Feed 1' (resp. Feed 2)
bidirectional interface connected to the Internet.
r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver
2) unidirectional interface (receive-only).
r1b (resp. r2b) is the IP address of a 'Receiver 1' (resp. Receiver
2) bidirectional interface connected to the Internet.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 3]
Internet Draft LL tunneling mechanism March 1998
4. Problems related to unidirectional links
Most protocols in the Internet assume that links are bidirectional.
In particular, routing protocols used by directly connected routers
no longer behave properly in the presence of an unidirectional link.
Indeed, receivers cannot send requests/responses or routing messages
to feeds through their receive-only interface.
The network layer has no knowledge of the underlying transmission
technology except, it considers its access as bidirectional.
Basically, for outgoing datagrams, the network layer selects the
correct first hop on the connected network according to a routing
table and passes the packet(s) to the appropriate link-layer driver.
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 another feed.
A link layer tunneling mechanism which allows to emulate 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
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 4]
Internet Draft LL tunneling mechanism March 1998
unidirectional link heard by 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 an unidirectional 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. 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 unidirectional
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.
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.
The datagram is encapsulated behind an IP header whose destination is
the IP address of a feed bidirectional interface (e.g. f1b or f2b),
also called the tunnel end-point. The mechanism for a receiver or a
bidirectional feed 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
feed bidirectional interface which is reachable via the Internet. The
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 5]
Internet Draft LL tunneling mechanism March 1998
datagram is then routed via the bidirectional interface.
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.
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 unidirectional 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 (IP forwarding) and
encapsulated packets it receives which need particular processing.
6.2.1. Forwarding packets over the unidirectional link
We need to distinguish serveral cases according to the next hop IP
destination address of the packet, it can be:
1) the IP address of a receiver or a bidirectional 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 unidirectional feed (Scenario 4). The packet
is encapsulated and sent to the feed tunnel end-point.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 6]
Internet Draft LL tunneling mechanism March 1998
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. A
copy of this packet is encapsulated behind an IP header whose
destination address is the "Send-Only Feeds" multicast group. It
is then sent via its bidirectional interface.
6.2.2. Receiving encapsulated packets
Feeds listen to incoming encapsulated datagrams on their tunnel end-
point. An unidirectional feed must join the "Send-Only Feed"
multicast group on its bidirectional interface and process incoming
encapsulated packets.
An encapsulated packet is received from the bidirectional interface,
traverses the IP stack and goes into a decapsulation process. 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 IP 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 IP 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. 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 to the tunnel end-point of the feed (A) or the
unidirectional feed received it via the "Send-Only Feed"
multicast group (B):
A- the feed was designed as default feed by a receiver to
forward the broadcast/multicast packet. The feed is then in
charged of sending the multicast packet to all node. The
process encapsulates the packets and sends it to the "Send-
Only Feed" multicast group, thus all feeds will receive it.
The packet is also passed to the link layer of the interface
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 7]
Internet Draft LL tunneling mechanism March 1998
which forwards it directly over the unidirectional link.
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). Tunnels
must be configured and maintained dynamically in order to cope with
the following events:
1) as a new feed comes up, every receiver and feed should create a
tunnel to enable a bidirectional communication with it. Static
tunneling configuration is not appropriate, as new feeds can be
connected to the unidirectional link at any time.
2) as the unidirectional link is down, receivers and feeds 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]).
3) as a feed is down, receivers and feeds must disable their
corresponding tunnel. This prevents unecessary datagrams from
being tunneled which would overload the Internet. For instance,
there is no need for receivers to forward a broadcast message
through a tunnel whose end-point is down.
The DTCP protocol provides a means for receivers and feeds to
dynamically discover the presence of feeds and maintain a list of
operational tunnel end-points. It is based on feed periodical
announcements over the unidirectional link and on the "Send-Only
Feeds" multicast group which contain tunnel end-point addresses.
Receivers listen to these announcements, discover the presence of
feeds, and maintain a list of tunnel end-points.
6.3.1. The HELLO message
The DTCP protocol is a 'unidirectional protocol', messages are only
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 8]
Internet Draft LL tunneling mechanism March 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Res. |Command| Res. | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence | Tunnel Proto | ARP type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed UDL IP addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed BDL IP addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Packet Format
Every datagram contains the following fields:
Version (4 bits): DTCP version number. MUST be 1.
Res.: MUST be zero.
Command (4 bits): 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.
Res. (4 bits): MUST be zero.
Interval (16 bits unsigned integer): Interval in seconds between
HELLO messages. The recommended value is HELLO_INTERVAL (see
section 6.3.5 for constant definitions). This field MUST not be
changed while sending.
Sequence (16 bits unsigned integer): Sequence number of HELLO
messages. A feed assigns an initial random number when it is
started and remains the same until it reboots. Receivers can thus
detect reboots and reset tunnel configuration.
Tunnel Proto (4 bits): tunneling protocols supported by feed:
1 = GRE [rfc1701] (recommended)
2 = IP in IP [rfc2003]
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 9]
Internet Draft LL tunneling mechanism March 1998
ARP type (4 bits): Address Resolution Protocol supported by feed
1 = ARP [rfc826]
Feed UDL IP addr (32 bits): The IP address of the feed interface
connected to the unidirectional link which sends the HELLO packet.
Feed BDL IP addr (32 bits): 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 may have several
bidirectional interfaces connected to the Internet, but only one is
selected as FBIP. The choice of this interface is outside the scope
of this document. It is the feed administrator who selects the most
suitable interface to announce. This address will be used by
receivers and feeds as the 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
announcement" multicast address on the unidirectional link on port
HELLO_PORT, and on the "Send-Only Feed" multicast group on the
bidirectional interface.
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 and feeds. It MUST
send HELLO packets containing a JOIN command every HELLO_INTERVAL on
the unidirectional link and encapsulates a copy which is sent to the
"Send-Only Feed" multicast group on the bidirectional interface.
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
field set to f1b (resp. f2b). Note that all FUIPs should have the
same network prefix: the unidirectional network address.
When a feed is about to be shut down, or when routing over the
unidirectional link is about to be intentionally interrupted, it is
recommended to:
1) stop sending HELLO messages containing a JOIN command.
2) send a HELLO message containing a LEAVE command to inform
receivers that the feed is no longer performing routing over the
unidirectional link.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 10]
Internet Draft LL tunneling mechanism March 1998
6.3.3. DTCP at the receiver and at the feed: receiving HELLO packets
Based on the reception of HELLO messages, nodes discover the presence
of feeds and keep trace of their corresponding tunnel end-points.
Every node maintains a list of active feeds which contains pairs of
(FUIP,FBIP). The list of active feeds is initially empty.
When a node is started, it MUST run a process which joins the "DTCP
announcement" multicast group and listens to incoming packets on port
HELLO_PORT from its unidirectional interface. Unidirectional feeds
receive the HELLO messages via the "Send-Only Feed" multicast group.
These messages are decapsulated and delivered locally as described in
Section 6.2.2.
Upon reception of a HELLO message, the process checks the version
number of the protocol. If it is different from HELLO_VERSION, the
packet is discarded and the process waits for the next incoming
packet.
After successfully checking the version number it is recommended to
check that the FUIP contained in the packet is the same as the source
address of the HELLO packet. Further action depends on the type of
command:
- JOIN:
The process verifies if the address FUIP contained in the HELLO
packet already belongs to the list of active feeds.
If it does not, the pair (FUIP,FBIP) is added to the list of
active feeds. A timer set to HELLO_LEAVE is associated with this
pair.
If it does, the 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 the pair (FUIP,FBIP) contained in the HELLO
packet belongs to the list of active feeds. If it does, it is
deleted from the list and the corresponding timer is disabled. The
LEAVE message provides a means of quickly updating the list of
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 11]
Internet Draft LL tunneling mechanism March 1998
active feeds.
A timout can have two reasons:
1) a feed went down without sending a LEAVE message. As JOIN
messages are not sent from this feed anymore, a timemout expires
HELLO_LEAVE after receiving the last JOIN message.
2) the unidirectional link is down. Thus, no more JOIN messages are
received from the feeds. All the timeouts associated with pairs
(FUIP,FBIP) will have expired HELLO_LEAVE after receiving the
last JOIN message from the unidirectional link.
In both cases, the associated (FUIP,FBIP) pair is removed from the
list of active feeds. As either the feed does not route datagrams
over the unidirectional link or the link is down, bidirectional
connectivity cannot be ensured any longer between the node and the
feed (FUIP). As a result, the list only contains operational tunnel
end-points.
The HELLO protocol provides receivers with the list of usable tunnel
end-points (FBIP). In the following section, we describe how to
integrate the HELLO protocol into the tunneling mechanism described
in Sections 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 could be, for instance, the closest feed to the
receiver.
Several cases are enumerated in Section 6.1 to determine where to
forward a datagram according to its destination address. If the
destination address is:
1) the IP address of a feed 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.
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.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 12]
Internet Draft LL tunneling mechanism March 1998
3) an IP address that belongs to the unidirectional network but is
not a feed address (i.e., it does not match any FUIP in the list
of active feeds): the datagram is encapsulated and sent to the
default feed if it belongs to the listof active feeds. Otherwise
the packets is discarded.
4) an IP address different from cases 1), 2) and 3): the datagram
is discarded.
6.3.5. Constant definitions
HELLO_INTERVAL is 10 seconds.
"DTCP announcement" multicast group is XXX.YYY.ZZZ.WWW.
"Send-Only Feed" multicast group is ttt.eee.iii.lll
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. Generic Routing Encapsulation
The encapsulation format is determined by the type of data which is
to be tunneled. It must support the encapsulation of IP datagrams in
order to tunnel IP datagrams from receivers and feeds to feed tunnel
end-points.
The unidirectional network may support hardware (MAC) addressing.
Before sending an IP datagram to a receiver, the feed must obtain the
hardware address of the receiver unidirectional interface. The
Address Resolution Protocol [rfc826] is a 'method of Converting
Protocol Addresses (e.g. IP addresses) to Local Network Addresses
(e.g. Ethernet Addresses)'. It is a link layer protocol which assumes
that links are bidirectional. If the link is unidirectional, a
receiver cannot respond to an ARP request generated by a feed.
Using the tunneling mechanism described in the previous sections, a
receiver should be able to tunnel ARP responses to feeds. The
encapsulation format must also support the encapsulation of the ARP
protocol.
The Generic Routing Encapsulation (GRE) [rfc1701] specifies a
protocol for encapsulating arbitrary packets within IP as the
delivery protocol. GRE suits well our requirements, as it allows
encapsulation of both the ARP and the IP protocol within IP.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 13]
Internet Draft LL tunneling mechanism March 1998
7.1. Encapsulation format
A GRE packet is composed of a header in which a type field specifies
the encapsulated protocol (ARP, IP, IPX, etc.). See
[rfc1701][rfc1702] for details about the encapsulation. In our case
only the support of ARP and IP MUST be implemented.
A packet tunneled with a GRE encapsulation has the following format:
the delivery header is an IP header whose destination is the tunnel
end-point (FBIP), followed by a GRE header indicating if the payload
is either an ARP message or an IP datagram. Figure 3 presents the
entire encapsulated packet.
----------------------------------------
| IP delivery header |
| destination addr = FBIP |
| IP proto = GRE (0x47) |
----------------------------------------
| GRE Header |
| type = ARP (0x806) or IP (0x800) |
----------------------------------------
| Payload packet |
| ARP or IP |
----------------------------------------
Figure 3: Encapsulated packet
7.2. GRE at the receiver
The link layer driver of the receive-only interface can pass two
types of datagrams to the encapsulation process. The link layer
datagram format is as follow:
----------------------------------------
| type |
| ARP (0x806) or IP (0x800) |
----------------------------------------
| data |
| ARP or IP |
----------------------------------------
Figure 4: Link Layer encapsulation
An IP datagram delivered from the network layer to the link layer is
encapsulated behind an IP type header. The link layer sending an ARP
response to a feed encapsulates the response behind an ARP type
header.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 14]
Internet Draft LL tunneling mechanism March 1998
The encapsulation process checks the protocol type of the datagram
read from the link layer. According to this, it obtains the
destination address from the datagram, encapsulates the datagram
behind a GRE header, and tunnels it following the description in
Section 6.3.4.
8. Issues
8.1. Hardware address resolution
Regardless of unidirectional or bidirectional links, if a node 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
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.
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 15]
Internet Draft LL tunneling mechanism March 1998
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
announced by the feeds.
8.3. Scalability
This Internet Draft does not discuss the case of a very large number
of receivers and feeds.
10. Security Considerations
[to be discussed]
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
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 16]
Internet Draft LL tunneling mechanism March 1998
[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
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
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 17]
Internet Draft LL tunneling mechanism March 1998
Email : ygz@isl.hrl.hac.com
Duros, Dabbous, Izumiyama, Fujii & Zhang [Page 18]