home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / udlr / udlr-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  9KB  |  228 lines
  1. Draft of 14/8/97
  2. Minutes of UniDirectional Link Routing Working Group Meeting
  3. of 11/8/97, Munich, 39th IETF
  4.  
  5. Reported by WG Co-Chair, Walid Dabbous
  6. [Apologies from other Co-Chair, Yongguang Zhang]
  7.  
  8. 0 Agenda
  9.  
  10. 5 min    I.     Agenda Bashing
  11.  
  12. 20 min    II.    Terminology Discussion
  13.  
  14. 30 min    III.    Presentation on ongoing work concerning tunneling
  15.     a) INRIA 
  16.     b) WIDE
  17.  
  18. 60 min    IV.    Discuss tunneling issues
  19.         IV-1) Receiver is a host case:
  20.             *) ARP
  21.         IV-2) Receiver is a router with static IP address
  22.             *) Support of MAC addresses
  23.         IV-3) Receiver is a router with dynamic IP address 
  24.             *) Dynamic Configuration Protocol
  25.             *) Encapsulation (GRE or IP-in-IP)
  26. 10 min    V.    Documents
  27.  
  28. 5 min     VI.    AOB
  29.  
  30. - ------------------
  31.  
  32. 1 Introduction
  33.  
  34. Walid Dabbous gave a brief history and remind the WG focus.
  35. UDLR WG chartered to discuss a solution for the support
  36. of dynamic routing over unidirectional links with the
  37. assumption that there exists a bidirectional path between
  38. "receivers" and the corresponding "feeds" (a backchannel). 
  39. Multiple Unidirectional Links (UDLs) could exist, but a 
  40. bidirectional "back channel" is assumed to exist for all UDLs.
  41. The solution of this problem is called "short term" solution.
  42. Two approaches had been discussed to solve this problem,
  43. namely routing protocol modification and tunneling.
  44. Routing protocol modification (presented in the
  45. three INRIA I-D referenced hereafter) was considered
  46. as non necessary to solve the short term problem. 
  47. It was decided in Memphis meeting to focus on tunneling.
  48. Both INRIA and WIDE are implementing a tunneling mechanism.
  49. W. Dabbous slides are in
  50. ftp://zenon.inria.fr/rodeo/udlr/slides/general.ps.gz
  51.  
  52.  
  53. 2 Terminology Discussion 
  54.  
  55. It was decided to use the following terminology
  56.  
  57. Non Commutative Link: denotes a Link between two nodes A and B, where
  58. A can reach B does not mean that B can reach A.
  59.  
  60. A UniDirectional Link is a special case of NCL.
  61.  
  62. Focus should be made on the Unidirectionality of the receive-only
  63. interface. It will be called Unidirectional Receive-only Interface,
  64. or Receive-only Interface.
  65.  
  66. The term Feed (resp. Receiver) designates a node
  67. connected to a NCL with a send-capable interface (resp.
  68. receive-only interface).
  69.  
  70. It was decided not to use a specific term to designate
  71. the networks considered by the udlr working groups, but
  72. to deiscribe the topology at the beginnign of the draft.
  73. (i.e. not to use terms such as alternative unidirectional 
  74. network).
  75.  
  76. Scott Michel will post soon a draft section on terminology
  77. to be added to the common I-D.
  78.  
  79. 3 Presentations
  80.  
  81. Emmanuel Duros from INRIA presented his current work
  82. on implementing a tunneling solution. 
  83. As the receiver needs to send a routing message to the feed (the destination
  84. address is either the feed's send-capable interface or the broadcast address 
  85. of the corresponding subnet) it is tunneled via the receiver's
  86. bidirectional interface. The packet is encapsulated (using GRE)in an IP packet 
  87. whose IP destination address is the feed bidirectional interface.
  88. The datagram is then sent to the end point of the tunnel via the back channel. 
  89. As it is received by the feed, the payload of the datagram is decapsulated. 
  90. The new IP packet that is obtained is routed according it its destination 
  91. address which is the IP address of the feed's send-capable interface or 
  92. the broadcast address of corresponding subnetwork. The packet is then 
  93. delivered ``locally'' and not forwarded since the destination address 
  94. is the feed itself. The IP stack passes the packet to higher level, 
  95. in our case the routing protocol.
  96. A mechanism to dynamically discover feeds and set up tunnels is also
  97. being implemented. When a receiver boots up it must discover the 
  98. presence of feeds dynamically and creates a tunnel with each of them.  
  99. The tunnel end points are the bidirectional interfaces of the receiver 
  100. .and the feed. In order to allow the receiver to learn the tunnel 
  101. end point (i.e. a feed interface belonging to the bidirectional network) 
  102. a new simple protocol is needed. Feeds periodically advertise their 
  103. tunnel end point over the NCL. As a receiver gets this message, it checks
  104. if the tunnel exists, if not it creates a tunnel and uses it.
  105. A time-out mechanism is used to clear the tunnel entry if no advertisement
  106. messages are received. This protocol is very close to DTPC (proposed
  107. by WIDE) and a common protocol will be described in the I-D.
  108. The work is ongoing and it is expetec to experiment RIP
  109. and DVMRP operation soon over the Eutelsat satellite link using
  110. INRIA uplink station.
  111. The slides of Emmanuel's presentation are in:
  112. ftp://zenon.inria.fr/rodeo/udlr/slides/inria39.ps.gz
  113.  
  114.  
  115.  
  116. Hidetaka Izumiyama from JCSAT/WIDE project presented their
  117. implmentation work on tunneling.
  118. The WIDE project has been working on tunneling since San Jose
  119. meeting. The proposed solution is based either on static
  120. or dynamic configuration of tunnels. Regular keep-alive 
  121. messages are used to "refresh" the MAC/IP address mapping. 
  122. No ARP mechanism is needed. Therefore IP in IP 
  123. encapsulation is used (no need for GRE). RIP, OSPF and DVMRP
  124. had already been tested on the JCSAT satellite.
  125. Ongoing work concerns the design and implementation of the Dynamic 
  126. Tunneling Path Configuration protocol. This work will be
  127. carried on in close collaboration with INRIA, while still keeping
  128. two distinct implementations (hopefully interoperable!).
  129. The slides if Izu's presentation are in:
  130. ftp://zenon.inria.fr/rodeo/udlr/slides/wide39.ps.gz
  131.  
  132.  
  133. 4 Discussion
  134.  
  135. Several points were discussed during and after the presentations.
  136.  
  137. The first question concerns the "receiver is a host" case, i.e.
  138. when no routing protocol is running on the receiver.
  139. The question is whether we should have an "on-demand" ARP mechanism
  140. or should we have regular keep-alive messages. In fact, in this
  141. case, the "tunnel" will not be used to send any traffic from
  142. the receiver to the feed, and no "implicit refresh" messages 
  143. are received. (If there were a routing protocol "using" the tunnel
  144. the routing messages would behave as implicit refresh for
  145. the MAC/IP address mapping). Christian Huitema pointed out
  146. that an on-demand ARP mechanism is needed. Regular keep-alive
  147. messages from receivers to feeds may be used, but one cannot
  148. expect the feed to keep all the information. A combination
  149. of both techniques should be used. Steeve Deering also expressed
  150. his preference to support an ARP mechanism.
  151.  
  152. The second question concerns the "receiver is a router" case.
  153. In this case, there is no need for keep-alive messages. 
  154. However, for scalability resons, one cannot expect that all the
  155. MAC/IP mappings will be kept by the feeds. Therefore a combination
  156. of implicit refresh and on-demand ARP resquest should be supported.
  157.  
  158. The third question is related to the two above:
  159. which encapsulation mechaism to use. If ARP is to be supported
  160. GRE is needed. Otherwise, IP in IP is sufficient. 
  161. Chrisitan Huitema proposed to use IP in DTCP encapsulation
  162. i.e. a new mechanism specific to UDLR.
  163. There were a rough consensus about GRE, but this should be
  164. confirmed on the mailing list. Please give any feedback on this 
  165. subject as soon as possible as the common I-D should be edited
  166. soon and it SHOULD propose the use of ONE encapsualtion mechanism.
  167.  
  168.  
  169. 5 Documents
  170.  
  171. Seven documents were already submitted to the udlr working group.
  172.  
  173. d1) VIPRE -- Virtual Internet Packet Relay
  174. An Encapsulation Architecture for Unidirectional Links
  175. by James Stepanek (The Aerospace Corporation)
  176. and Stephen Schwab (Twin Sun Inc). February 1997.
  177. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-vipre-00.txt
  178.  
  179. d2) An IP tunneling approach for Uni-directional Link routing
  180. by Hidetaka Izumiyama, Akihiro Tosaka and Akira Kato 
  181. (WIDE project). July 1997.
  182. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-wide-tunnel-00.txt
  183.  
  184. d3) Dynamic Tunneling Path Configuration for Uni-directional 
  185. Link Routing
  186. by Hidetaka Izumiyama and Akihiro Tosaka (WIDE project). 
  187. July 1997.
  188. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-dtpc-00.txt
  189.  
  190. d4) Supporting Unidirectional Paths in the Internet
  191. by Emmanuel Duros and Walid Dabbous, INRIA. June 1996.
  192. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-general-00.txt
  193.  
  194. d5) Handling of unidirectional links with RIP 
  195. by E. Duros and  C. Huitema, INRIA, March 1996.
  196. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-rip-00.txt
  197.  
  198. d6) Handling of unidirectional links with OSPF 
  199. by E. Duros, INRIA, March 1996.
  200. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-ospf-00.txt
  201.  
  202. d7) Handling of unidirectional links with DVMRP 
  203. by E. Duros and W. Dabbous, INRIA, March 1996.
  204. http://www.inria.fr/rodeo/udlr/documents/draft-udlr-dvmrp-00.txt
  205.  
  206.  
  207. These documents will be sent to the IETF as UDLR I-Ds, to be
  208. put on the I-D directory.
  209.  
  210.  
  211. 6 Action points
  212.  
  213. Scott Michel to prepare a draft section on terminology.
  214.  
  215. Emmanuel Duros and Walid Dabbous to prepare a draft on the
  216. common solution (that will integrate the terminology).
  217. Put the draft I-D on the list for discussion. 
  218.  
  219. Walid Dabbous to forward the above documents to IETF.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. ------- End of Forwarded Message
  227.  
  228.