Network Working Group Hidetaka Izumiyama Internet-Draft Akihiro Tosaka WIDE project November 1997 Dynamic Tunneling Path Configuration for Uni-directional Link Routing 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, 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]