Minutes of the UDLR Working Group

38th IETF - Memphis, TN, USA
Reported by: Walid Dabbous - Thanks to Scott Michel and Jean Bolot for taking notes.

Agenda

• Agenda bashing
• Presentation of approaches
• Discussion
• Documents
• Action items

I. AGENDA BASHING 5min

No special comment

II. PRESENTATION OF PROPOSED APPROACHES (30 min)

1. General presentation

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 recveivers (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.

1. 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)
2. Tunneling between receiver and feed
   Idea: mask the udl for routing protocols
   Routing information from feeds should 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)

2. 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.
Routing information from feeds is processed by receivers.
Metric of the backchannel is set dynamically as required.
Implementation available (at the UCLA mirror site)

- - WIDE (Hidetaka Izu)

Proposed I-D on "Unidirectional Link routing with IP tunneling"
Another proposed I-D on dynamic tunneling soon to come
Implementation: RIP2, OSPF, 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.

- - INRIA (Walid Dabbous)

Transmission of IP packets over DVP-MPEG
One feed and one receiver with Ethernet bidirectional link, currently static configuration
IP address used to filter packets
Second receiver in Paris, eventually to include the MERCI project.

III. DISCUSSION 60 min

If focus on tunneling for short term, then need to address the question: Is tunnelling sufficient to solve udlr?

Several issues to discriminate between the two approaches:

1. Dynamic Routing

(already discussed: which metric to use?)

2. Automatic Configuration, i.e. possibility for feeds and receivers to detect each other: trivial with RPM and  ICMP Relay Discovery with tunnelling.

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 WG 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 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 WG.

3. Routing Efficiency

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 tunnelling (use bidir interface to route traffic).

Discussion on sending things encapsulated or not encapsulated. It was pointed 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 which 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.

4. Support IP mcast forwarding:

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.

5. scalability

• pb with lots of feeds: 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 wg 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.)
  
• pb with lots of revs: 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 different for 5 people or for 5 M 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.

6. interdomain routing:

receivers likely in different AS; what nets should they announce? That's dealt with by BGP.

7. applicability to other udl areas:

maybe IP over cable.

8. Other issues:

ARP: did not condider 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 which handles the ARP case. IP-in-IP could also be extended to handle the ARP case.

Also what about IPv6? Agreed solution?

Consensus appears to be on tunneling, and it must handle the multicast routing case (IGMP), and ARP.

To extend the WG for a mesh of udl links then possibly start a new WG for addressing the general udl routing problem after udlr ends. To be discussed later.

IV. DOCUMENTS 20 min

Existing: VIPRE, WIDE, INRIA

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 tunnelling 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).

V. 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.

W. Dabbous slides are available at ftp://ftp-sop.inria.fr/rodeo/udlr/slides/general38.ps.gz

Izumiyama Hidetaka slides are available at ftp://ftp-sop.inria.fr/rodeo/udlr/slides/wide38.ps.gz

Walid Dabbous