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]