NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Walid Dabbous <Walid.Dabbous@sophia.inria.fr>
Yongguang Zhang <ygz@isl.hrl.hac.com>
Joel Halpern <jhalpern@newbridge.com>
General Discussion:udlr@sophia.inria.fr
To Subscribe: udlr-request@sophia.inria.fr
Archive: ftp://zenon.inria.fr/rodeo/udlr/archive.txt
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 bi-directional underlying network (wired Internet) 2. bi-directional 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:
Minutes of the UniDirectional Link Routing (UDLR) Working Group
Reported by: Walid Dabbous, Scott Michel, and Jean Bolot
II. Presentation of approaches
No special comment.
II. Presentation of Proposed Approaches (30 min.)
Walid presented the general problem and the two solutions for routing with UDL, namely: modify routing protocols (referred to later as RPM, or Routing Protocol Modification) or tunneling. Major UDLR problems: dynamic discovery of feeds and receivers, exchange of information between feeds and receivers (how, what to exchange?) Receivers are supposed to detect the feeds directly, and senders generate "appropriate" routing information so that receivers send along the backchannel and receive along the feed. Two approaches: routing protocol modifications or tunneling.
1st approach: RPM -> Change Protocols
Idea: Explicitly take into account UDL interface. Routing information from feeds on UDL is discarded by receivers (may result in less processing, e.g., in RIP and DVMRP).
+ No need for asymmetric metric + No need for encapsulation
Need change in feeds and receivers daemons in DV protocols (RIP/DVMRP) and in all routers in LS protocols (OSPF)
2nd approach: Tunneling Between Receiver and Feed
Idea: Mask the UDL for routing protocols. Routing information from feeds should be processed by receivers. Requires asymmetric metric for the back channel (to control its use to carry normal data). It is not clear whether it should be allowed or not. Noted that Aerospace people feel that using the backchannel is desirable in order to carry additional protocol information like RSVP that is carried back to the sender. How to choose the metric value? Note that this metric might have to be set dynamically (apparently easy to do in gated: send a signal to read config tables) Tunneling can handle dynamic discovery of feeds and receivers (extensions of ICMP)
What's New Since Last Meeting?
Aerospace Corporation (Scott Michel)
Presents VIPRe (proposed I-D describing it available).
Dynamic discovery of a feed via a new ICMP message.
Receivers process routing information from feeds.
Metric of the backchannel is set dynamically as required.
Implementation available (at the UCLA mirror site).
Proposed I-D on "Unidirectional Link routing with IP tunneling."
Another proposed I-D on dynamic tunneling soon to come.
Implementation: RIP2, OSPF, and DVMRP done in domestic testbed.
BPG-4 will be tested in international testbed.
In testbed, set metrics so that shortest path is as desired.Shows setups for DVMRP, seems to work fine (static metric setup though).Then shows geographical status.Hughes (Yongguang Zhang)
Multicast over NASA ACTS satellites; trying out ULDR multicast.
UDLR testbed in Hughes Research Labs using 11 PCs (FreeBSD) to create complex satellite network environments.
Transmission of IP packets over DVP-MPEG.
One feed and one receiver with Ethernet bi-directional link, currently static configuration.
IP address used to filter packets.
Second receiver in Paris, eventually to include the MERCI project.
If focus on tunneling for short term, then need to address the question: Is tunneling sufficient to solve UDLR? Several issues to discriminate between the two approaches:
Dynamic Routing (already discussed: which metric to use?)
Automatic Configuration, i.e., possibility for feeds and receivers to detect each other: trivial with RPM, ICMP Relay Discovery with tunneling.
Question: Why do we need another ICMP message? Walid points out that VIPRe uses a mechanism inspired from router discovery as documented by Deering - interrogator wants Working Group to use accepted methods and mechanisms instead of inventing yet another.
During the discussion of the second issue (automatic configuration), WIDE presented their Dynamic Tunneling Path Configuration approach: Automatic initiation of tunneling path: When a feed is up or a new receiver joins, a tunneling path is automatically established. Periodically detects the UDL for an unexpected death of feed or receiver:
When the feed (receiver) goes down unexpectedly, the receiver (feed) detects it and the tunneling path is canceled by using the Life Time of Tunneling Path (LTTP).
When the feed or the receiver goes away, the UDL is downed automatically: Before the feed (receiver) leaves the UDL, the feed (receiver) sends the "close message" to terminate the tunneling path.
This triggers discussion on amount of state per receiver. If the feed (receiver) sends "close" message to terminate the tunnel -> should have per receiver state/traffic at feeds.
Christian Huitema points out that there is no need for per receiver state at the feed, but only something that allows demuxing (to make feed believe that info came back over the satellite link). Confirmation from Aerospace.
It was pointed out that you might need state anyway for tunnel security; however, you can design for authentication.
Also question about relevance of explicit msgs to detect unexpected death of link (Aerospace says implicit discovery should be enough, e.g., by soft state update).
Bob Lindell pointed out that dynamic discovery is important in the multiple feed case. This isn't necessarily true in the single feed case. Walid points out that the support of multiple feeds should be an important feature of whatever drafts come out of the Working Group.
There should be no "imposed" encapsulation for traffic sent by receivers to hosts on the Internet (contrary to what's done by DirecPC and Berkeley). No pb for the RPM and tunneling (use bidir interface to route traffic).
Discussion on sending things encapsulated or not encapsulated. It was pointed out that encapsulation has no major performance problem, and encapsulating everything makes things consistent. In VIPRe, the issue of whether or not to route via the feeds is left as a local decision.
Tunnels are set up to hide the topology; this affects the original IP header (such as TTL). Impact analysis should take into account the transport and application layers, i.e., traffic that is tunneled through non-RSVP aware routers for RSVP traffic.
C. Huitema brought up the problem of layering. Also proposed that feeds have several IP addresses so that the receivers choose whether or not to encapsulate.
RPF ensures that shortest path routing happens if the reverse metric is used. But with "classical" tunneling we have asymmetric metrics. This should not be the case for DVMRP. Back channel metric should be chosen equal to the "forward" satellite link metric for DVMRP. On the other hand, no multicast traffic is forwarded on the virtual back channel to avoid duplication.
Hidetaka Izu said that it is not necessary to have this equality by showing the example in the WIDE slides. However, metric setting could be a problem. C. Huitema says DVMRP looks OK for now (still some work for setting metrics, but you could have something semi-automatic like feed = 32, router = 1).
C. Huitema pointed out another open point, when the receiver is a host, not a router. You need to support IGMP-like functionality between hosts and feeds.
C. Huitema pointed out that CBT might be a better solution for multicast, where the root of the CBT is the satellite feed.
Mcast back channel to all feeds? Is the large number of feeds case relevant? Use the multicast on the backchannel to all feeds? Mcast could not be the answer because a receiver does not hear all feeds. CH parallels with Ethernet - receiver need only send stuff when want to talk. On the issue of the multicast on the backchannel, the feed can detect which packets are addressed to it and not retransmit them over the broadcast link. Y. Zhang pointed out that we should encompass the problem in terms of ULD networks:
(Case 1) one feed, many receivers; (Case 2) multiple feeds, multiple receivers in the same footprint;
(Case 3) multiple feeds, multiple receivers with receivers in different footprints.
UDLR Working Group addresses the first two cases without excluding the applicability of the solution to the case 3. (Please correct if something missing here!)
Some of this work may be useful in the cellular radio case - which is an interesting subcase, which should not be excluded but we ought not expend energy to solving the problem. UDLR is very applicable to cable modem technology (which is essentially the same as the satellite model.)
How do you do IGMP? IGMP is simple: a router asks whether there are members of group X. Everyone receives that message and then replies - how do you avoid getting replies from everyone. The basic point that Huitema pointed out that IGMP is not scaleable. How do you do IGMP with 1 M receivers - here each will draw a timer and you could be flooded. Walid says broadcast group membership on the satellite link, but then 500 ms delay, so that means scaling the timer. Also how do you know how many receivers so as to set your timer differently for five people or for five million people). One idea: log polling (Capitanakis or Wakeman's algorithm which estimates the size of the group via logarithmic scaling, and it converges fairly rapidly to close to the group's size). Or just broadcast everything?
Huitema further pointed out that you have the exact same problem with pruning. Possible solution: have the feed send the prune when it gets it (but now back to the 1st pb).
This pb intrinsic to mcast, so not a way to decide between tunneling and RPM. General idea: Tunnel gives you the possibility to act as if you were a feed.
Interdomain Routing:
· Receivers likely in different AS; what nets should they announce? That's dealt with by BGP.
· Applicability to other UDL areas: maybe IP over cable.
Other issues:
· ARP: did not consider yet because IP over DVB standard not supported. Currently IP address used for both media and IP address in the INRIA implementation. The IP over DVB standard will be implemented. Huitema pointed out that ARP does not run over IP whereas tunnel provides IP level. Might have to resort to an IP v6 mechanism. GRE may be used as a solution. This brought the question of which tunneling protocol to use: currently IP-in-IP is widely used, but someone proposed using GRE that handles the ARP case. IP-in-IP could also be extended to handle the ARP case.
· Agreed solution? Consensus appears to be on tunneling, and it must handle the multicast routing case (IGMP), and ARP. To extend the Working Group for a mesh of UDL links then possibly start a new Working Group for addressing the general UDL routing problem after UDLR ends. To be discussed later.
Should they be adopted individually and label them as UDLR I-D's? Yes. Should make sure that they don't look like results; they should look like proposals. Suggest 1pp boilerplate that indicates proposalness.
· Edit a common ID on a single agreed tunneling solution:
· General presentation/terminology
· Short description of proposals
· Detailed description of solution (agreed details, open issues)
· ASCII version of Yongguang Zhang's UD network incorporated into the UDLR Unified I-D (to indicate that udlr addresses Cases 1 and 2 and does not exclude 3).
VI. Action Points (5 min.)
· Edit "issues" ID, post all IDs before end of May.
· Cross-post "issues" ID to other lists.
· INRIA may be able to demonstrate UDLR multicast over the Eutelsat satellite to show either the UDLR IETF session or the SIGCOMM '97 keynote or both.
The slides of the presentations are available at:
ftp://zenon.inria.fr/rodeo/udlr/ietf38/gen38.ps.gz
ftp://zenon.inria.fr/rodeo/udlr/ietf38/wide38.ps.gz