NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97
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. |
Internet-Drafts:
· Handling of unidirectional links with DVMRP
· Supporting Unidirectional Paths in the Internet
· VIPRE -- Virtual Internet Packet Relay An Encapsulation Architecture for Unidirectional Links
· Domain Wide Multicast Group Membership Reports
· An IP tunneling approach for Uni-directional Link routing
· Dynamic Tunneling Path Configuration for Uni-directional Link Routing
· Handling of unidirectional links with RIP
· Handling of unidirectional links with OSPF
No Request For Comments
Minutes of the Unidirectional Link Routing (UDLR) Working Group
Reported by Yongguang Zhang
I. Introduction
Yongguang Zhang gave an introduction of the UDLR WG and the progress so far. UDLR WG addresses the problem of dynamic routing in the present of UDL (Uni-Directional Link) in the Internet. During the previous meetings, the WG has established four premises for our work:
· Architecture (where UDL is a multi-access, boardcast-capable, and unidirectional subnet technology for the Internet)
· Broadcast satellite as a particular example, but not the only application,
· Tunnels being used only for routing protocols, ARP, or other protocols that do not use the route table,
· WG will result in an information RFC for tunneling mechanism as the short-term solution.
II. Presentations on Experiments and Experiences
Yongguang Zhang from HRL (Hughes Research Labs) presented the MBone-over-DirecPC experiment that was on-going during the 40th IETF at Washington D.C. During the week, one of the two IETF multicast channel was being carried by DirecPC (a service by Hughes Network System to connect users to the Internet by satellites). Using normal Mbone applications, all DirecPC users could receive the live multicast on their PCs. Beside, HRL also feed the multicast session received at Malibu back to the Mbone, so that Internet users at California can receive better quality video than over terrestrial Mbone. The experiment demonstrated the advantage of UDL.
Emmanuel Duros from INRIA presented another Mbone experiment that retransmit the SIGCOMM'97 keynote speech over satellite. SIGCOMM'97 was held at Cannes, France September 1997. The keynote speech was multicasted over the Mbone. To overcome the congestion, INRIA retransmitted the multicast session to U.K. and Germany over an EutelSat satellite. UDLR technology was used in the experiment.
Cheryl DeMatteis from Aerospace also gave a short presentation on Aerospace's experience of using GBS (Global Broadcast Satellite) links in the DARPA/AHPCA project. In this project, three sites at different locations were connected by GBS links (unidirectional). Various applications had run successfully over the UDLs.
III. Presentations on Implementations
Manish Karir from University Maryland presented HRL's implementation on UDLR tunneling mechanism. Manish was a summer intern at HRL where the implementation was done. HRL's implementation assumes a single feed multiple receiver case. It uses existing tunnel encapsulation mechanism (as Linux IP-in-IP tunnel device). A complex network of many Linux PCs and several Ethernet segments was used to test the implementation under various UDL topologies. Each UDL receiver has a tunnel device and both UDL receive interface and the tunnel interface are assigned IP addresses of the same UDL subnet. The tunnels are used to connect to the UDL feed, forming a virtual symmetric network. HRL's implementation requires no change to gated to support RIP. It however requires some minor changes to mrouted (because it locates the incoming VIF by source address, which is improper in UDL), but no change to DVMRP protocol. HRL's implementation does not use dynamic tunnel configuration.
Emmanuel Duros from INRIA presented his work on implementing a tunneling solution. INRIA's implementation uses GRE as the encapsulation mechanism because it also delivers ARP reply from UDL receivers to the feed. It uses a dynamic tunnel configuration protocol to automatically discover feeds and set up tunnels at the receiver side.
Hidetaka Izumiyama from WIDE/JCSAT presented their progress on UDLR implementation. Since he last IETF, WIDE has implemented a broadcast emulation (BCE) layer in their tunneling mechanism, so that both feeds and receivers can treat the UDL as a broadcast type bi-directional link. BCE guarantees that broadcast-type packets from a receiver can reach all feeds and all receivers just once. It also calls for all feeds to set up tunnels among themselves because not all feeds can have the receive capability at the UDL interfaces.
IV. Presentations on Dynamic Tunnel Configurations
First, Charlie Perkins from SUN presented the TEP (Tunnel Establishment Protocol) that he and Pat Calhoun (3COM) co-authored for the MobileIP WG. TEP may be applicable to UDLR WG because both MobileIP and ULDR have to deal with the same problem of setting up tunnels between two sites across various intermediate networks, some of which may be uncooperative such as firewalls. TEP has a complex procedure on how to set up a tunnel to pass through all those.
Noritonshi Demizu from Sony CSL presented the DTCP (Dynamic Tunnel Configuration Protocol). On the feed-to-receiver direction, DTCP notifies the availability of feed and the tunnel endpoint, on the receiver-to-feed direction, DTCP passes the receiver's MAC address (in lieu of ARP). DTCP also provides some type of dynamic IP assignment for receivers (similar to DHCP).
V. Discussion
Discussions in the WG meeting focused on the dynamic tunnel configuration issue.
There seems to be an agreement in the WG that TEP might be applicable when the receiver needs to set up a tunnel to the feed, but it does not address the problem of DTCP, whereas how the receiver finds out the tunnel end-point address of the feed.
The difference between Sony's DTCP and INRIA's mechanism have been narrowed into two parts: 1) the HELLO message format, and 2) whether the MAC address should be passed back from receivers to feeds. There were a continuous disagreement on whether to depend on DTCP's constant MAC feedback or an on-demand ARP mechanism. Emmanuel Duros pointed out that scalability requires an on-demand ARP to be supported. Yongguang Zhang drew a parallel between ARP (passing MAC address from receiver to feed) and DTCP (passing tunnel end-point address, which could be considered MAC address for UDL from feed to receiver) and suggested that both periodic "push" and on-demand "pull" mechanism could be supported. There is also a suggest that the neighbor discovery mechanism in IPv6 may be useful in dynamic tunnel configuration.
There is a question about security, on how to prevent just everyone from connecting to the feed. Christian Huitema pointed out that IPSEC could be used as a mechanism in setting up the tunnels.
VI. Conclusion and Actions
The action was to finish the draft common I-D.
Yongguang Zhang will document on multicast/broadcast emulation ("all-feed" multicast).
Emmanuel Duros and Hidetaka Izumiyama will resolve the difference in DTCP announce message format, and the ARP issue.
Finish the draft I-D and put on the list by the end of January.
We will meet again at the 41st IETF (LA, March 98).
Unidirectional Link Routing WG
Dynamic Tunnel Configuration Protocol (DTCP)