NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Walid Dabbous <Walid.Dabbous@sophia.inria.fr>
Yongguang Zhang <ygz@isl.hrl.hac.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
Joel Halpern <jhalpern@newbridge.com>
Mailing Lists:
General Discussion: udlr@sophia.inria.fr
To Subscribe: udlr-request@sophia.inria.fr
Archive: ftp://zenon.inria.fr/rodeo/udlr/archive.txt
Description of Working Group:
Note: An alternate site for UDLR's files is: ftp://irl.cs.ucla.edu/pub/udlr
High bandwidth, unidirectional transmission to low cost, receiver-only hardware is becoming an emerging network fabric, e.g. broadcast satellite links or some cable links.
Two cases for unidirectional links support may be envisaged:
1. unidirectional links on top of bidirectional underlying network (wired Internet) 2. bidirectional islands connected via unidirectional links.
In both cases, the integration of unidirectional links may require changes to the routing protocols in order to preserve dynamic routing across these links. A short term solution (i.e. to solve the first case) is to adopt current protocols with possible modifications. A long term solution (i.e. for the second case) is to propose, design and implement protocols that remove assumed link symmetry (e.g. by supporting 2-way metrics).
There have been several proposed approaches for the short term case. The first is based on the modification of the common routing protocols (RIP, OSPF, DVMRP) in order to support unidirectional links. The second is to add a layer between the network interface and the routing software to emulate bi-directional links through tunnels.
The purpose of the UDLR Working Group, therefore, is to study these approaches and suggest a short term solution to provide dynamic routing (including multicast) in the presence of unidirectional links.
Goals and Milestones:
Apr 97 |
|
Meet at IETF. Finish discussion of the general solution. |
Apr 97 |
|
Post the description of the proposed solutions and the issues for the short term solution as I-D(s). |
Aug 97 |
|
Preliminary experiments results of the short term solution. |
Aug 97 |
|
Post the description of the short term solution as an I-D. |
Dec 97 |
|
Produce Informational RFC on the proposed approach. |
Dec 97 |
|
End WG. |
No Current Internet-Drafts
No Request For Comments
Minutes of UniDirectional Link Routing Working Group Meeting
Reported by WG Co-Chair, Walid Dabbous [Apologies from other Co-Chair, Yongguang Zhang]
Agenda
I. Agenda Bashing (5 min)
II. Terminology Discussion (20 min)
III. Presentation on ongoing work concerning tunneling (30 min)
a) INRIA
b) WIDE
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)
V. Documents (10 min)
VI. AOB (5 min )
I. Introduction
Walid Dabbous gave a brief history and reminds 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 bi-directional path between "receivers" and the corresponding "feeds" (a backchannel). Multiple Unidirectional Links (UDLs) could exist, but a bi-directional "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 the 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
II. 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 describe the topology at the beginning 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.
III. 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 bi-directional interface. The packet is encapsulated (using GRE)in an IP packet whose IP destination address is the feed bi-directional 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 to it its destination address that 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 a 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 bi-directional 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 bi-directional 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 expected 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 implementation work on tunneling. The WIDE project has been working on tunneling since the 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
IV. Discussion
Several points were discussed during and after the presentations.
The first question concerns the "receiver is a host" case, for example, 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. Steve 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 reasons, 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 request should be supported.
The third question is related to the two above: which encapsulation mechanism 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, for example, 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 encapsulation mechanism.
V. 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.
VI. 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.
None Received