[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IP tunneling I-D for UDLR-WG
Dear Internet-Draft editors,
I would like to submit an internet-draft attached to this mail.
This is the update version of my previous I-D.
I would like to use "draft-izumiyama-udlr-tunnel-01.txt"
as its filename.
Network Working Group H.Izumiyama JSAT
Internet-Draft H.Asaeda ITS/IBM-Japan
N.Fujii Sony
J.Takei JSAT
N.Demizu SonyCSL
November 1997
An IP tunneling approach for Unidirectional Link routing
<draft-izumiyama-udlr-tunnel-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 a
unidirectional link. The "receiver" uses a link layer tunneling
mechanism to forward datagrams to "feeds" through a bidirectional
network. This document based on the Internet Draft written by
Emmanuel Duros[INRIA].
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
(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 requirement of the tunneling mechanism is just carrying IP
datagrams. So, this system employ any tunneling mechanism which can
H.Izumiyama [Page 1]
Internet-Draft An IP tunneling approach for UDLR November 1997
carry IP datagram, e.g. IPonIP[IPIP], GRE[GRE], etc..
2. Terminology(c.f. [INRIA] Section 2)
This document uses the words defined in [INRIA].
3. Topology(c.f. [INRIA] Section 3)
This document uses the topology defined in [INRIA]. Figure 1 depicts
a generic topology with several feeds and several receivers[INRIA].
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
Figure 2 shows the network topology seeing from above IP layer. The
nodes connect to the one network segment which is a virtual segment
called Yoke link. Yoke Link is a virtual bidirectional link consist
of unidirectional link and tunnel link. This link act as a
bidirectional broadcast network seeing from higher layer(network
layer and above).
Yoke Link(Broadcast network consist of UDL and Tunnel)
-------------------------------------------------
A A A A
| | | |
V V V V
+---+---+ +---+---+ +---+---+ +---+---+
|Fdr 1 |...|Fdr 2 | |Rcv 1 |...|Rcv n |
+-------+ +-------+ +-------+ +-------+
Figure 2 Yoke Link
4. Problems related to unidirectional links(c.f. [INRIA] Section 4)
This document has same problems described in [INRIA].
5. Link Layer Tunneling Mechanism(c.f. [INRIA] Section 5)
Figure 3 shows the protocol stack from physical layer to IP layer on
H.Izumiyama [Page 2]
Internet-Draft An IP tunneling approach for UDLR November 1997
the Feed and the Receiver. This tunnel mechanism require special
function in Datalink layer which provides the emulation of virtual
interface(Yoke Interface).
Feed Receiver
------------ +---------+ +---------+
IP Layer | IP | | IP |
------------ +---------+ +---------+
------------ +---------+ +---------+
Datalink |Yoke | |Yoke |
Layer |Interface| |Interface|
+---------+ +---------+
|Broadcast| |Broadcast|
|Emulation| |Emulation|
+----+----+ +----+----+
|SOI |TUN | |ROI |TUN |
|UDL | | |UDL | |
------------ +----+----+ +----+----+
------------ +----+----+ +----+----+
PHY |PHY1|PHY2| |PHY1|PHY2|
------------ +----+----+ +----+----+
Figure 3
Yoke Interface(Broadcast type Interface)[YKI]: This layer works as a
broadcast network interface(e.g. ethernet interface) seeing from
IP layer.
Broadcast Emulation[BCE]: This function is a part of link layer. The
aim of this function is to provide broadcast network
functionality for IP layer using UDL and TUN(tunnel).
UDL: The interface which handles unidirectional link
TUN: The interface which handles tunnel link and it has a part of
upper layer(eg. IP layer) functions.
Yoke Link has following characteristics;
- Basically, Yoke Link provides broadcast network functions.
- Except cases described below,
Unicast packets will be delivered to the destination node.
Broadcast and Multicast packets will be delivered to all nodes.
(this memo does not preclude packet filtering under
the membership control of multicast group using
IGMP packet)
- The any transit of unicast packets can go through the
BDL directly without tunnel. So the cost of
routing protocol must be set effectively in order to
prevent the transit of unicast through the tunnel.
If these transits of unicast packets try to go through the
tunnels , these packets SHOULD be filtered out,
and ICMP destination unreachable (i.e. code=13)
SHOULD be returned.
H.Izumiyama [Page 3]
Internet-Draft An IP tunneling approach for UDLR November 1997
- Unicast routing protocol packets(e.g. RIP,RIP2,OSPF, etc.)
from any receivers SHOULD NOT be forwarded to other
receivers via UDL, but SHOULD be forwarded towards
other Feeds via tunnels(if exists).
- Packets MUST NOT be duplicated over Yoke Link.
5.1.Broadcast emulation(BCE) mechanism at the receiver
This mechanism is similar to the tunneling mechanism at the receiver
in [INRIA]. The major difference from [INRIA] is that a receiver is
not need to set up the tunnel to all feeds. Normally a receiver
sets up a tunnel to one of feeds.
The BCE mechanism is inserted at the link layer on 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 packet whose destination
is the IP address of a feed bidirectional interface (f1b or
f2b). The mechanism for a receiver to learn these addresses is
explained in Section 5.3.
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 datagram is then routed via a receiver bidirectional
interface.
We have to distinguish several cases as the datagram. Detail of this
behavior describe in Appendix.1.
5.2.Broadcast emulation(BCE) mechanism at the feed
This mechanism is similar to the tunneling mechanism at the feed
in [INRIA]. The major difference from [INRIA] is that feeds set up
the tunnel each other as mesh topology. Feeds can use these
tunnels for communication among themselves.
The feed listens incoming encapsulated datagrams on its tunnel
end-point. A packet is received from the bidirectional interface,
traverses the IP stack, and goes into a decapsulation process.
The original datagram is decapsulated and passed to link layer
driver of the feed unidirectional interface. As a result, the
datagram is processed as if it was coming from the send-only
interface.
If the datagram is an IP packet, it is delivered to the feed
network layer. Since the datagram was encapsulated, its IP header
has not been modified by intermediate routers. To the network layer,
the datagram appears as coming from the send-only interface.
We have to distinguish several cases as the datagram. Detail of this
H.Izumiyama [Page 4]
Internet-Draft An IP tunneling approach for UDLR November 1997
behavior describe in Appendix.1.
5.3.DTCP
The main roles of our DTCP there are:
- to notify the availability of a Feed to Receivers.
- to exchange node information that is necessary to transfer packets
through a UDL (e.g. MAC addresses of Receivers to forward unicast
packets)
- to establish and to release tunnels dynamically, including dynamic
IP address allocation if necessary.
The detail function of DTCP is described in[DEMIZU].
6. Tunnel mechanism(c.f. [INRIA] Section 6)
The requirement of the tunneling mechanism discussed on this
document is just carrying IP datagrams. So, this system can employ
any tunneling mechanism which can carry IP datagram(eg. IPonIP,
GRE, etc.).
7. Address Resolution Protocol(c.f. [INRIA] Section 7)
For receiver's hardware address resolution mechanism, periodical update
of hardware address and IP address(ARP) table and sharing
newest ARP table in feeders are provided by DTCP mechanism[DEMIZU].
When the tunnel has been established between a Feed and a Receiver,
the Feed knows the Receiver's hardware address in any time
by DTCP mechanism.
When a Feed loses the hardware address information of a Receiver
accidentally and some nodes want to send packets via this Feed to the
Receiver using UDL, the Feed has to know Receiver's hardware address
by on-demand ARP mechanism.
(1)It can only happens when the Feed goes down suddenly and comes up
quickly. This is a rare case.
(2)Even in this case, the Feed knows the Receiver's hardware
address by DTCP mechanism in a bit period.
Therefore, on-demand ARP mechanism is not required.
8. Issue(c.f. [INRIA] Section 8)
8.1. Routing Protocol
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 path, bandwidths and delays. Because of using such a special link
as a communication link, there are some requirements for setting up
H.Izumiyama [Page 5]
Internet-Draft An IP tunneling approach for UDLR November 1997
dynamic routing protocol. Followings are the requirement.
1) The cost of routing packets from receiver to feed MUST set
high.
2) The cost of routing packets from receiver to receiver MUST set
high.
3) The cost of routing packets from feed to feed MUST set high.
8.2. Scalability
This Internet Draft consider that the system will be used with
current routing protocol. These protocol assume that the number of
routers which is the sum of feeds and receivers, are not so
large(eg.100). In case of large number of feeds, it will probably
discuss as a long term solution.
9. References
[UDLR] Internet-Draft(work in progress)'A Link Layer Tunneling
Mechanism for Unidirectional Links',Emmanuel Duros,INRIA
Sophia-Antipolis,November 1997
[GRE] RFC1701 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths,
Ltd., T. Li, D. Farinacci, P. Traina, cisco System, October
1994
[IPIP] RFC2003 'IP Encapsulation within IP', C. Perkins IBM,
October 1996
[DEMIZU] Internet-Draft(work in progress)'Dynamic Tunnel
Configuration Protocol',Noritoshi Demizu, Sony CSL,
H.Izumiyama, JSAT, November 1997
Author's Address
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
Hitoshi Asaeda
Information Technology Solutions Co.,Ltd.
IBM Japan Ltd.
1623-14 Shimotsuruma, Yamato-shi
Kanagawa-ken 242, Japan
voice:+81-462-73-4542
fax :+81-462-72-6951
email:asaeda@yamato.ibm.co.jp
Noboru Fujii
H.Izumiyama [Page 6]
Internet-Draft An IP tunneling approach for UDLR November 1997
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
Jun Takei
Japan Satellite Systems Inc.
Toranomon 17 Mori Bldg.5F
1-26-5 Toranomon, Minato-ku
Tokyo 105 Japan
voice:+81-3-5511-7638
fax :+81-3-5512-7181
email:takei@jcsat.co.jp
Noritoshi Demizu
Sony Computer Science Laboratory, Inc.
Takanawa Muse Bldg.
3-14-13, Higashigotanda,
Shinagawa-ku, Tokyo, 141 Japan
Phone: +81-3-5448-4380
E-mail: demizu@csl.sony.co.jp
E-mail: nori-d@is.aist-nara.ac.jp
Appendix.1 Detailed survey of the function on BCE layer
[The story of survey]
0.We assume that Yoke Link is pure broadcast network, that is, yoke
link has bidirectional capability. But actually, it has just
unidirectional capability, therefore we must realize it by using
broadcast emulation(BCE).
1.Therefore we indicate what is needed for realizing pure broadcast
network at first.
2.However, when we think about actual network topology, it is clear
that BCE doesn't have to emulate all the functions of broadcast
network because of some reasons. Therefore, we indicate what kind
of functions aren't needed for BCE with some concrete reasons.
3.Finally,we will indicate the conclusion and BCE function which
must be implemented on feeds and receivers. At this point, we
note that it must not have bad influence upon all networks if new
routing protocol which isn't taken into account now will appear.
(Terminology)
Fdr:BCE requirement for BCE function of feed.
Fdr:OTR requirement for other function of feed.
Rcv:BCE requirement for BCE function of receiver.
Rcv.OTR requirement for other function of receiver.
H.Izumiyama [Page 7]
Internet-Draft An IP tunneling approach for UDLR November 1997
%%% %%%
1.Requirement for emulation of complete broadcast network
1-1 Packets sent from a receiver must reach a feed.
1-2 Packets sent from a receiver must reach a receiver.
1-3 Packets sent from a feed must reach all receivers.
1-4 Packets sent from a feed must reach all feeds.
1-5 Packets sent from a receiver must reach receivers just once,
that is, the duplicated same packets must not reach the same
receivers.
1-6 Packets sent from a feed must reach feeds just once, that
is, the duplicated same packets must not reach the same feeds.
%%% %%%
1-1 Packets sent from a receiver must reach a feed.
(1)Fdr:BCE All packets which come through receiver's tunnel are
decapsulated. And they must be passed to IP layer if
they are addressed to feed itself.
(2)Rcv:BCE Receiver creates tunnel to a feed, and sends packets
via this tunnel.
1-2 Packets sent from a receiver must reach a receiver.
(1)Fdr:BCE All packet which come through the receiver's tunnel are
decapsulated and are sent to UDL. At this point, the
content of IP datagram must not be changed.
(2)Rcv:BCE Packets which is received from UDL and is sent from
receiver itself must be discarded. And other packets
must be passed to IP layer.
1-3 Packets sent from a feed must reach all receivers.
(1)Fdr:BCE All packets passed from IP layer must be sent to UDL.
1-4 Packets sent from a feed must reach all feeds.
(1)Fdr:BCE Feed must create tunnels to all feeds and send to
packets to all feeds.
1-5 Packets sent from a receiver must reach receivers just once,
that is, the duplicated same packets must not reach the same
receivers.
(1)Rcv:BCE Receiver must select only one feed which has the end
H.Izumiyama [Page 8]
Internet-Draft An IP tunneling approach for UDLR November 1997
point of tunnel, and send to all packets. In addition,
Packets which is received from UDL and is sent from
receiver itself must be discarded.
(2)Fdr:BCE All packets which come through the receiver's tunnel
must be sent to all feeds via the feeds's tunnel.
1-6 Packets sent from a feed must reach feeds just once, that
is, the duplicated same packets must not reach the same
feeds.
(1)Fdr:BCE Packets which come through the feed's tunnel must not
be forwarded.
%%% %%%
2.When we think about actual network topology, it is clear that BCE
doesn't have to emulate all the functions of broadcast network
because of some reasons. Therefore, we indicate what kind of
functions aren't needed for BCE with some concrete reasons.
In a generic term for any unicast and multicast routing protocols
used with no Uni-directional links,
1. every Feed and Receiver can communicate with unicast packets
via unicast routing path, and
2. every Feed and Receiver can or cannot communicate with
multicast packets via multicast routing path.
When we consider the UDL's characteristics described in this
document, we can propose that a yoke link should not be used in
following states;
2-1. A Receiver receives unicast IP datagrams towards a Feed.
2-2. A Receiver receives unicast IP datagrams towards a Receiver.
2-3. A Feed receives unicast IP datagrams towards a Feeder.
%%% %%%
2-1. Refusing the traffic of unicast IP datagrams from a Receiver to
a Feeder on a Yoke link
When the Receiver receives a unicast IP datagram to
the Feed, the Receiver tries to find the destination path in
its routing table. In this situation, an unicast routing path
from a receiver to a feed is ensured on BDL (i.e. without
tunnel link and UDL), so BDL must be selected as a transmission
path.
(1). Rcv:OTR Configuration of the network cost from a Receiver
to a Feed should be high to avoid to transit via
Yoke link.
(2). Rcv:BCE Only the unicast packet to its Yoke link subnet
can transit via tunnel. Others should be filtered
H.Izumiyama [Page 9]
Internet-Draft An IP tunneling approach for UDLR November 1997
out, and it must return the ICMP destination
unreachable (i.e. code=13).
2-2. Refusing the traffic of unicast IP datagrams from a Receiver to
a Receiver on a Yoke link
When the Receiver receives a unicast IP datagram to
the Receiver, the Receiver tries to find the destination path in
its routing table. In this situation, an unicast routing path
from a Receiver to a Receiver is ensured on BDL, so BDL must
be selected as a transmission path.
(1). Rcv:OTR Configuration of the network cost from a Receiver
to a Receiver should be high to avoid to transit
via Yoke link.
(2). Fdr:BCE Some routing protocol messages come from
Receiver's tunnel should be filtered out not to
transit to another Receiver via UDL. This can not
only fulfill to avoid wasted data traffic but deny
routing flaps or unwilling routing
trees. (e.g. RIP1 announcement, RIP2 All Routers,
OSPF All Routers and OSPF DRs etc.)
(3). Fdr:BCE All packets come from a tunnel whose end point is
a Receiver are decapsulated. The IP headers of
these packets are checked, and if they are the
unicast packets and to a Yoke link, then sent to a
UDL. Others should be filtered out, and it must
return the ICMP destination unreachable
(i.e. code=13).
(4). Rcv:BCE same of 2-1(1).
2-3. Refusing the traffic of unicast IP datagrams from a Feed to a
Feed on a Yoke link
When the Feed receives a unicast IP datagram to the
Feed, the Feed tries to find the destination path in its
routing table. In this situation, an unicast routing path from a
Feed to a Feed is ensured on BDL, so BDL must be selected
as a transmission path.
(1). Fdr:OTR Configuration of the network cost from a Feed to
a Feed should be high to avoid to transit via
Yoke link.
(2). Fdr:BCE All packets come from a tunnel whose end point is
a Feed are decapsulated. The IP headers of these
packets are checked, and if they are the unicast
packets and to a Yoke link, then sent to a
UDL. Others should be filtered out, and it must
return the ICMP destination unreachable
(i.e. code=13).
(3). Fdr:BCE Only the unicast packet to its Yoke link subnet
can transit via tunnel. Others should be filtered
out, and it must return the ICMP destination
unreachable (i.e. code=13).
3.Finally,we will indicate the conclusion and BCE function which
must be implemented on feeds and receivers. At this point, we
H.Izumiyama [Page 10]
Internet-Draft An IP tunneling approach for UDLR November 1997
note that it must not have bad influence upon all networks if new
routing protocol which isn't taken into account now will appear.
H.Izumiyama [Page 11]