Network Working Group                                Hidetaka Izumiyama
Internet-Draft                                        Akihiro Tosaka
                                                          Akira Kato
                                                        WIDE project
                                                           November 1997

        An IP tunneling approach for Uni-directional Link routing

                  <draft-ietf-udlr-wide-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]