Internet DRAFT - draft-wide-udlr-tunnel
draft-wide-udlr-tunnel
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:11:03 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 01 Aug 1997 10:49:16 GMT
ETag: "2e797f-47cc-33e1bf2c"
Accept-Ranges: bytes
Content-Length: 18380
Connection: close
Content-Type: text/plain
Network Working Group Hidetaka Izumiyama
Internet-Draft Akihiro Tosaka
Akira Kato
WIDE project
July 1997
An IP tunneling approach for Uni-directional Link routing
<draft-wide-udlr-tunnel-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.nTermet (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Since digital multichannel TV broadcasting services have been
started in many areas, low cost digital data receivers are
available. They can be used for not only TV broadcasting service but
also any kind of data communication services.
A low cost receiver can receive high bandwidth traffic from a feed,
while no bandwidth from the receiver to the feed is provided.
Therefore the connection between the feed and the receiver is
unidirectional. Current routing protocols stand on a fact that any
links are bidirectional even if the bandwidth in each direction may
be different. They can not handle unidirectional links.
This document defines an idea to use unidirectional links (UDLs)
routing without any modifications of current routing protocols.
1. Terms
UDL -
Uni-directional link. Some kinds of cable net service and a
satellite channel are typical examples.
BDL -
Bi-directional link.
Feed -
H.Izumiyama, A.Tosaka & A.Kato [Page 1]
Internet-Draft IP tunneling approach for UDLR July 1997
A host or a router which sends packets to UDL.
Receiver -
A host or a router which receives packets from the UDL. It can
not send packets to the UDL.
VIF (Virtual Interface) -
An interface which emulates a UDL as a BDL.
NIF (Non-virtual Interface) -
An interface which associates a physical interface. A serial
interface and an ethernet interface are the example of NIF.
Forward-channel -
A path from a Feed to a Receiver over an UDL.
Back-channel -
A path from a Receiver to a Feed. In this draft, this path consists
of a tunnel over the Internet.
2.Type of Hosts
This UDL link comprises two types of hosts : Feeds and Receivers.
In a typical case, one UDL has one Feed and several Receivers.
The UDLR working group has specified the use of UDL as a link on
which the dynamic routing protocols may work.
3. Tunneling Approach
In order to utilize an uni-directional link (UDL) in a regular
internet cloud, there are two major approaches. One way is to modify
the routing protocol. The UDLs in an internet has not well be
studied and we need more experience to define the requirements of
the routing protocols which run also over UDLs. This solution is
considered as a long term solution, and out of scope of this
document.
The other solution is to fake an UDL link as a BDL to the routing
protocol. In this solution, no modification of the current routing
protocols or their implementations is necessary. We propose this
approach to make a BDL by combining an UDL with a back-channel using
IP tunneling. The combined interface is abstracted as a VIF. A VIF
at the Feed dispatches the outbound packets to the UDL while the
inbound traffic is received via the tunnel. On the other hand, a
VIF at a Receiver dispatches the outbound packets to the IP tunnel
while the inbound traffic is received via the UDL.
The VIF at a Feed can be considered as broadcast packets in typical
UDL configuration because typical UDLs(such as cable based and
satellite based networks) are potentially
broadcast-capable. However, a Receiver does not have this
property. Receivers can only send packets over the tunnel to the
H.Izumiyama, A.Tosaka & A.Kato [Page 2]
Internet-Draft IP tunneling approach for UDLR July 1997
Feed. It can not send packets directly to other Receivers on the
same UDL. In a case where the bi-directional multicast is
essentially required, the Receiver send multicast packets to the
Feed across the tunnel and then the Feed can transmit them over the
UDL -- without decrement TTL. The Feed just works as if a layer-2
bridge rather than a router in this case. Necessity of this feature
depends on the application.
In most case, this "layer-2 bridge" feature is not necessary because
for the direct communication between Receivers the normal NIF are
used and VIF tunneling path are not used.
Those routing protocols currently in use, such as RIP and OSPF, run
well over the VIF.
In the case of RIP, routing updates broadcasted from a Feed are
transmitted over an UDL and Receivers may get them. On the other
hand, the routing updates from the Receivers are transferred over
the IP tunnel. It is not necessary that the updates are delivered to
other Receivers and the Feed does not replay the broadcast
packets. RIP Version 2 runs quite similar to this, replacing
broadcast with multicast.
In the case of OSPF, a Feed is required to be a designated router
and all of the Receivers must set priority 0 so that no Receiver
becomes a designated router nor a backup designated router.
4.Design of VIF
Current routing protocols are designed on the premise that
communication between routers over a particular link is
bi-directional.
For example, the Feed and Receiver are connected by one
unidirectional link(UDL) and one BDL link(Fig-1).
The current routing protocols can use only one BDL link (if1). Even
if Feed can send the packets though if0 , if0 never be used(Fig-2).
We design the virtual interface(VIF) to emulate a UDL as a BDL by
using IP tunneling technology on another BDL link. The packets from
Receiver to if0 are encapsulated and send if1 to Feed. Feed receive
the encapsulated packets from if1, the packets are decapsulated and
go around if0 and Feed receive as it come from if0. The tunnel
described here can be uni-directional from the Receiver to the Feed,
however. In order to implement this combined path, we can define a
virtual interface (VIF) on each of the Feed and the Receiver to
provide a pseudo BDL to the routing protocol. Any routing protocol
accesses the VIF as well as regular interfaces rather than accesses
to the tunnel and UDL directly.
When a packet is sent from the Feed to the Receiver, the VIF direct
the packet to the UDL. When a packet is sent from the Receiver to
the Feed on the other hand, the VIF direct the packet to the tunnel
H.Izumiyama, A.Tosaka & A.Kato [Page 3]
Internet-Draft IP tunneling approach for UDLR July 1997
because the Receiver can not transmit the packet over the UDL.
So, current dynamic routing protocols can use if0 and if1(Fig-3).
UDL
------->------------------>-------
| |
|if0 |if0
+--------+ +--------+
| Feed | |Receiver|
+----+---+ +--------+
|if1 |if1
| |
============ Internet=============
BDL
Fig-1 physical connection
Note : the BDL above should not be limited to a single hop link
but can be a cloud, or multihop links.
UDL
------->------------------>-------
+--------+ +--------+
| Feed | |Receiver|
+----+---+ +--------+
|if1 |if1
| |
============ Internet=============
BDL
Fig-2 logical connection for current routing protocols
(only use current technology)
BDL
==================================
| |
|if0(VIF) |if0(VIF)
+--------+ +--------+
| Feed | |Receiver|
+----+---+ +--------+
|if1 |if1
| |
============ Internet=============
BDL
Fig-3 logical connection for current routing protocols
(use VIF technology for if0)
H.Izumiyama, A.Tosaka & A.Kato [Page 4]
Internet-Draft IP tunneling approach for UDLR July 1997
5.Progressive and Conservative of the proposed design
5.1.Progressive
5.1.1. No change in the global internet
It is not necessary to modify other hosts or routers because
modifications are needed only at Feed and Receivers.
5.1.2. No change in the current routing protocols
The current routing protocols can be used without any changes.
5.2.Conservative
5.2.1 Overhead of tunneling Network
If we can configure the cost of the tunneling link infinity, only
the routing information from the Receivers to the Feed pass through
the tunneling network with overhead. We think it is not so major
disadvantage because the overhead is not so big(20 byte per IP
packet) and the routing traffic is smaller than the data traffic.
6.Tunnels
6.1.Protocols
We adapt the IP Encapsulation within IP[RFC-2003] for the tunnels.
Use of IP within IP differs from other tunneling techniques (for
example, [RFC-1241],[RFC-1701],etc.) in that it does not insert its
own special glue header between IP headers. Instead, the original
unadorned IP Header is retained, and simply wrapped in another
standard IP header.
+------------------+
| Outer IP Header |
+------------------+ +------------------+
| IP Header | encapsulation | IP Header |
+------------------+ ===============> +------------------+
| IP Payload | | IP Payload |
+------------------+ +------------------+
An outer IP header is added before the original IP header. The outer
IP header source and destination identify the "endpoints" of tunnel,
Feed and Receiver.
6.2.ICMP messages
To avoid routing loops or other serious error in tunnels, all ICMP
messages in [RFC-2003] must be implemented.
6.3.Tunnel endpoint address
H.Izumiyama, A.Tosaka & A.Kato [Page 5]
Internet-Draft IP tunneling approach for UDLR July 1997
In order to make the path from the Receiver to the Feed look as if
it is directly connected by using tunneling, they both have to know
their own BDL network address and UDL network address, along with
their peer's BDL network address and UDL network address.
When the Feed and Receiver obtain the other's BDL network address
and UDL network address, they record the peer's (UDL network
address, BDL network address) in the kernel and set up the UDL
network interface.
The current implementation employs static configuration, but dynamic
configuration is possible by using the Dynamic Tunneling Path
Configuration(DTPC) described in next section.
The following is an example.
UDL(192.168.140.128/27)
------->------------------>-------
| |
|if0: 192.168.140.129 |if0: 192.168.140.130
+--------+ +--------+
| Feed | |Receiver|
+----+---+ +--------+
|if1: 192.168.141.18 |if1: 192.168.141.196
| |
| +--------+ |
=============| Router |===========
BDL +--------+ BDL
(192.168.141.0/27) (192.168.141.128/27)
Fig. network configuration of example network
At the Feed, the UDL network interface if0 is setup as:
192.168.140.129 netmask 0xffffffe0
the record as:
src bdl address 192.168.141.18,
(dst udl addr 192.168.140.130, dst bdl addr 192.168.141.196)
and the flag indicating the Feed is turned on. The pairs of (dst UDL
addr, dst BDL addr) are provided along the number of Receivers.
At the Receiver, the UDL network interface if0 is also setup as:
192.168.140.130 netmask 0xffffffe0
the record as:
src bdl address 192.168.141.196,
(dst udl addr 192.168.140.129, dst bdl addr 192.168.141.18)
and the flag indicating the Feed is left alone.
7. DTPC(Dynamic Tunneling Path Configuration)
This is an option for more scalable and easy operation of UDL.
The purpose of DTPC has following functions,
H.Izumiyama, A.Tosaka & A.Kato [Page 6]
Internet-Draft IP tunneling approach for UDLR July 1997
- Automatically initialize tunnels between Feed and Receivers.
- Automatically shutdown the tunnels if UDL is down to avoid
conflict or get better convergence of dynamic routing protocols.
- Automatically know the UDL interface datalink address of
Receivers if they have.
The detail of DTPC is described in [2].
8. Datalink Address of UDL
When a Feed transmit an IP unicast packets over a satellite link,
large number of Receivers may receive this packets and forward this
packets to the destination of the packets. This situation may result
a melt-down of the internet.
In order to avoid the situation, datalink address should be
introduced to designate the right Receiver so that other Receivers
can discard the packets.
There are two idea to solve this issue:
- use the IEEE MAC address on UDL interface
- no use the IEEE MAC address on UDL interface
8.1.In case of no IEEE MAC address on UDL interface
Typical implementation to the satellite interface is a serial
interface, in which no IEEE MAC address is factory configured. As
introduction of other addressing system than IP would require ARP or
similar mechanism, IP address encapsulation of MAC address is
proposed:
02-00-AA-BB-CC-DD for IP unicast address of 170.187.204.221
(local bit is on)
01-00-5E-DD-CC-BB for IP multicast address of 238.221.204.187
(group bit on)
The maximum transmission unit depends on each system and may set any
size if the Feed and Receivers agree with it. Otherwise, use default
value of 1500.
8.2.In case of use IEEE MAC address on UDL interface
If the UDL interface have IEEE MAC address, we can use it for
datalink filtering in normal network interface such as ethernet. In
this case Feed must know the all Receiver's datalink MAC
address. The normal ARP can not use on UDL. Instead of ARP we can
use DTPC to get UDL MAC address.
9. Scalability consideration
H.Izumiyama, A.Tosaka & A.Kato [Page 7]
Internet-Draft IP tunneling approach for UDLR July 1997
The factor for scalability of this VIF approach is follows,
- Number of Receivers
The number of tunnels is equal to the number of Receivers. The
number of tunnels on Feed decide the number of Receivers which
can handle simultaneously.
- Automatic configuration for joining and leaving of Receivers
The DTPC[2] can do this matter.
10. Support for IP multicast forwarding
IP multicast packets can be delivered over both the UDL and the
back-channel(tunnel) without any change, IP multicast packets
forwarding is supported.
The "layer-2 bridge" is effective to reduce the number of IGMP
packets from Receivers to Feed.
11. Applicability note to IPv6
If IPv6's IP within IP method specified, this VIF technique can
easily translate on IPv6 network.
12. Security Issues
Security issues are not discussed in this memo.
13.Bibliography
[1] C. Perkins IBM,
"IP Encapsulation within IP",
REC2003, October 1996.
[2] Hidetaka Izumiyama, Akihiro Tosaka / WIDE project
"Dynamic Tunneling Path Configuration",
Internet-Draft, July 1997.
Author's Address
Hidetaka Izumiyama voice:+81-3-5511-7568
Japan Satellite Systems Inc. fax :+81-3-5512-7181
Toranomon 17 Mori Bldg.5F email:izu@jcsat.co.jp
1-26-5 Toranomon, Minato-ku
Tokyo 105 Japan
Akihiro Tosaka voice: +81-446-49-1094
WIDE Project Karigome Internet email: tosaka@sfc.wide.ad.jp
Reserch Center
5862, Endo, Fujisawa-shi,
Kanagawa-ken, 252, Japan.
H.Izumiyama, A.Tosaka & A.Kato [Page 8]
Internet-Draft IP tunneling approach for UDLR July 1997
Akira Kato voice: +81-3-5684-7300
The University of Tokyo, fax : +81-3-5684-7775
Computer Centre email: kato@wide.ad.jp
2-11-16 Yayoi Bunkyo,
Tokyo 113 JAPAN
H.Izumiyama, A.Tosaka & A.Kato [Page 9]
