Draft of 14/8/97 Minutes of UniDirectional Link Routing Working Group Meeting of 11/8/97, Munich, 39th IETF Reported by WG Co-Chair, Walid Dabbous [Apologies from other Co-Chair, Yongguang Zhang] 0 Agenda 5 min I. Agenda Bashing 20 min II. Terminology Discussion 30 min III. Presentation on ongoing work concerning tunneling a) INRIA b) WIDE 60 min IV. Discuss tunneling issues IV-1) Receiver is a host case: *) ARP IV-2) Receiver is a router with static IP address *) Support of MAC addresses IV-3) Receiver is a router with dynamic IP address *) Dynamic Configuration Protocol *) Encapsulation (GRE or IP-in-IP) 10 min V. Documents 5 min VI. AOB - ------------------ 1 Introduction Walid Dabbous gave a brief history and remind the WG focus. UDLR WG chartered to discuss a solution for the support of dynamic routing over unidirectional links with the assumption that there exists a bidirectional path between "receivers" and the corresponding "feeds" (a backchannel). Multiple Unidirectional Links (UDLs) could exist, but a bidirectional "back channel" is assumed to exist for all UDLs. The solution of this problem is called "short term" solution. Two approaches had been discussed to solve this problem, namely routing protocol modification and tunneling. Routing protocol modification (presented in the three INRIA I-D referenced hereafter) was considered as non necessary to solve the short term problem. It was decided in Memphis meeting to focus on tunneling. Both INRIA and WIDE are implementing a tunneling mechanism. W. Dabbous slides are in ftp://zenon.inria.fr/rodeo/udlr/slides/general.ps.gz 2 Terminology Discussion It was decided to use the following terminology Non Commutative Link: denotes a Link between two nodes A and B, where A can reach B does not mean that B can reach A. A UniDirectional Link is a special case of NCL. Focus should be made on the Unidirectionality of the receive-only interface. It will be called Unidirectional Receive-only Interface, or Receive-only Interface. The term Feed (resp. Receiver) designates a node connected to a NCL with a send-capable interface (resp. receive-only interface). It was decided not to use a specific term to designate the networks considered by the udlr working groups, but to deiscribe the topology at the beginnign of the draft. (i.e. not to use terms such as alternative unidirectional network). Scott Michel will post soon a draft section on terminology to be added to the common I-D. 3 Presentations Emmanuel Duros from INRIA presented his current work on implementing a tunneling solution. As the receiver needs to send a routing message to the feed (the destination address is either the feed's send-capable interface or the broadcast address of the corresponding subnet) it is tunneled via the receiver's bidirectional interface. The packet is encapsulated (using GRE)in an IP packet whose IP destination address is the feed bidirectional interface. The datagram is then sent to the end point of the tunnel via the back channel. As it is received by the feed, the payload of the datagram is decapsulated. The new IP packet that is obtained is routed according it its destination address which is the IP address of the feed's send-capable interface or the broadcast address of corresponding subnetwork. The packet is then delivered ``locally'' and not forwarded since the destination address is the feed itself. The IP stack passes the packet to higher level, in our case the routing protocol. A mechanism to dynamically discover feeds and set up tunnels is also being implemented. When a receiver boots up it must discover the presence of feeds dynamically and creates a tunnel with each of them. The tunnel end points are the bidirectional interfaces of the receiver .and the feed. In order to allow the receiver to learn the tunnel end point (i.e. a feed interface belonging to the bidirectional network) a new simple protocol is needed. Feeds periodically advertise their tunnel end point over the NCL. As a receiver gets this message, it checks if the tunnel exists, if not it creates a tunnel and uses it. A time-out mechanism is used to clear the tunnel entry if no advertisement messages are received. This protocol is very close to DTPC (proposed by WIDE) and a common protocol will be described in the I-D. The work is ongoing and it is expetec to experiment RIP and DVMRP operation soon over the Eutelsat satellite link using INRIA uplink station. The slides of Emmanuel's presentation are in: ftp://zenon.inria.fr/rodeo/udlr/slides/inria39.ps.gz Hidetaka Izumiyama from JCSAT/WIDE project presented their implmentation work on tunneling. The WIDE project has been working on tunneling since San Jose meeting. The proposed solution is based either on static or dynamic configuration of tunnels. Regular keep-alive messages are used to "refresh" the MAC/IP address mapping. No ARP mechanism is needed. Therefore IP in IP encapsulation is used (no need for GRE). RIP, OSPF and DVMRP had already been tested on the JCSAT satellite. Ongoing work concerns the design and implementation of the Dynamic Tunneling Path Configuration protocol. This work will be carried on in close collaboration with INRIA, while still keeping two distinct implementations (hopefully interoperable!). The slides if Izu's presentation are in: ftp://zenon.inria.fr/rodeo/udlr/slides/wide39.ps.gz 4 Discussion Several points were discussed during and after the presentations. The first question concerns the "receiver is a host" case, i.e. when no routing protocol is running on the receiver. The question is whether we should have an "on-demand" ARP mechanism or should we have regular keep-alive messages. In fact, in this case, the "tunnel" will not be used to send any traffic from the receiver to the feed, and no "implicit refresh" messages are received. (If there were a routing protocol "using" the tunnel the routing messages would behave as implicit refresh for the MAC/IP address mapping). Christian Huitema pointed out that an on-demand ARP mechanism is needed. Regular keep-alive messages from receivers to feeds may be used, but one cannot expect the feed to keep all the information. A combination of both techniques should be used. Steeve Deering also expressed his preference to support an ARP mechanism. The second question concerns the "receiver is a router" case. In this case, there is no need for keep-alive messages. However, for scalability resons, one cannot expect that all the MAC/IP mappings will be kept by the feeds. Therefore a combination of implicit refresh and on-demand ARP resquest should be supported. The third question is related to the two above: which encapsulation mechaism to use. If ARP is to be supported GRE is needed. Otherwise, IP in IP is sufficient. Chrisitan Huitema proposed to use IP in DTCP encapsulation i.e. a new mechanism specific to UDLR. There were a rough consensus about GRE, but this should be confirmed on the mailing list. Please give any feedback on this subject as soon as possible as the common I-D should be edited soon and it SHOULD propose the use of ONE encapsualtion mechanism. 5 Documents Seven documents were already submitted to the udlr working group. d1) VIPRE -- Virtual Internet Packet Relay An Encapsulation Architecture for Unidirectional Links by James Stepanek (The Aerospace Corporation) and Stephen Schwab (Twin Sun Inc). February 1997. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-vipre-00.txt d2) An IP tunneling approach for Uni-directional Link routing by Hidetaka Izumiyama, Akihiro Tosaka and Akira Kato (WIDE project). July 1997. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-wide-tunnel-00.txt d3) Dynamic Tunneling Path Configuration for Uni-directional Link Routing by Hidetaka Izumiyama and Akihiro Tosaka (WIDE project). July 1997. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-dtpc-00.txt d4) Supporting Unidirectional Paths in the Internet by Emmanuel Duros and Walid Dabbous, INRIA. June 1996. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-general-00.txt d5) Handling of unidirectional links with RIP by E. Duros and C. Huitema, INRIA, March 1996. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-rip-00.txt d6) Handling of unidirectional links with OSPF by E. Duros, INRIA, March 1996. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-ospf-00.txt d7) Handling of unidirectional links with DVMRP by E. Duros and W. Dabbous, INRIA, March 1996. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-dvmrp-00.txt These documents will be sent to the IETF as UDLR I-Ds, to be put on the I-D directory. 6 Action points Scott Michel to prepare a draft section on terminology. Emmanuel Duros and Walid Dabbous to prepare a draft on the common solution (that will integrate the terminology). Put the draft I-D on the list for discussion. Walid Dabbous to forward the above documents to IETF. ------- End of Forwarded Message