Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/udlr/udlr-minutes-97apr.txt

Text File | 1997-05-29 | 12KB | 286 lines

Editor's Note:  These minutes have not been edited.


38th IETF - Memphis, TN

Minutes of the UDLR WG meeting, Reported by Walid Dabbous
Thanks to notes taken by Scott Michel and Jean Bolot.

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.
a. 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)
b. 2nd approach: 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
    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
a. 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.)

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


The slides of the presentations are available at:

ftp://zenon.inria.fr/rodeo/udlr/ietf38/gen38.ps.gz
and
ftp://zenon.inria.fr/rodeo/udlr/ietf38/wide38.ps.gz


Walid Dabbous