Internet DRAFT - draft-wide-udlr-dtpc
draft-wide-udlr-dtpc
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:11:02 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 01 Aug 1997 10:49:40 GMT
ETag: "2e797e-173d-33e1bf44"
Accept-Ranges: bytes
Content-Length: 5949
Connection: close
Content-Type: text/plain
Network Working Group Hidetaka Izumiyama
Internet-Draft Akihiro Tosaka
WIDE project
July 1997
Dynamic Tunneling Path Configuration for Uni-directional Link Routing
<draft-wide-udlr-dtpc-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
The idea to use unidirectional link(UDL) routing without any
modifications of current routing protocols is described in [1], but
any dynamic tunneling path configuration technique was not
described. This document describe the dynamic tunneling path
configuration for UDL routing.
1.Approach
In the UDLR tunneling approach[1], any tunnel mechanism can be used
for the back path to emulate a BDL in combination with the UDL under
consideration. In the case when the UDL down due to, for example,
transmitter failure, Receiver (not Receiver site) failure, or
satellite failure, the back path should be shutdown when a dynamic
routing protocol is in use. Otherwise, any packets whose
destinations are around the Receiver are routed to the Feed and then
sent it to the tunnel. This may result sub-optimal routing (also
introduce the header overhead).
In order to avoid this, the Feed have to send some control packet
periodically (link-level hello) to the Receiver. The packet is
delivered to the VIF layer and not delivered to its upper layer.
When the VIF does not receive the hello from the Feed, for example a
few minutes, the VIF should be declared down to its upper layer. In
this state, any packets should not be send over the VIF tunnel.
H.Izumiyama & A.Tosaka [Page 1]
Internet-Draft DTPC for UDLR July 1997
In order to realize such a issue, we would propose to use two type
of tables :
Address Assign Table(AAT)
This table is used to maintain the Receiver's UDL IP address and
UDL MAC address. Feed can also use this table to get UDL MAC
address of each Receiver.
Feed IP address on UDL
Netmask of UDL
Number(n) of Receivers
n * [BDL IP address,UDL IP address,UDL MAC address]
Tunneling Path Table(TPT)
This table is used to maintain the tunnel path information.
src BDL IP address
Number(n) of tunnels(Feed: n >= 1, Receiver: n = 1)
n * [dst BDL IP address,dst UDL IP address,Dead Interval]
Feed holds a AAT and its TPT. Each Receive holds its TPT.
2.Messages
2.1.Hello message
The Feed sends the hello message via UDL when hello interval timer
expires. Proposed hello interval for several kilo-bps or higher UDR
is 10 sec and corresponding dead interval is 40 sec.
Hello message has following information :
Feed IP address on UDL
Netmask of UDL
Dead Interval
Number of IP address on BDL at Feed
n * [Feed BDL IP address]
When a Receiver get a hello message from the Feed, the Receiver can
establish a backchannel tunnel to the one of the BDL IP addresses
shown in the hello. The criteria of choosing IP address is out of
scope of this document, however, it is likely to choose nearest one
if the VIF can access the routing table metrics.
When a Receiver does not listen the hello packet from particular
Feed for more than dead-interval period specified in the last hello
message, the VIF in the Receiver has to declare the VIF "down" and
any packets directed to the VIF should be discarded. The VIF respond
the sender with ICMP host unreachable.
2.2.Reply message
H.Izumiyama & A.Tosaka [Page 2]
Internet-Draft DTPC for UDLR July 1997
When Feed get reply message through BDL interface from a Receiver,
Feed update the record of AAT. Feed also update his TPT and
establish the tunnel to the Receiver.
Reply message has following information :
Receiver BDL IP address
Receiver UDL MAC address
Feed BDL IP address
(Receiver wants to use this as the end point of tunnel)
3.Security Issues
Security issues are not discuss in this memo.
4. Bibliography
[1] Hidetaka Izumiyama,Akihiro Tosaka,Akira Kato
"Uni-directional Link Routing with IP tunneling approach"
Intenet Draft<draft-wide-udlr-tunnel-00.txt>,
April 1997.
Author's Address
Hidetaka Izumiyama Phone:+81-3-5511-7568
Japan Satellite Systems Inc. Email:izu@jcsat.co.jp
Toranomon 17 Mori Bldg.5F
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 [Page 3]
