[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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).


    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.


    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.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]