Network Working Group Hidetaka Izumiyama Internet-Draft Akihiro Tosaka Akira Kato WIDE project November 1997 An IP tunneling approach 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 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]