[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tunneling vs routing protocol modification
Tunneling vs routing protocol modification
Elements for discussion
I would like to avoid that the next wg meeting concentrates
on the "presentation" of the two approaches to address udlr,
namely tunneling and routing protocol modifcation (i will RPM in
the remainder). In fact, i think that these two approaches
are similar in many aspects, and in particular in the open
issues.
The main problems to solve for udlr are:
pb1 how feeds and receivers detect each other dynamically,
pb2 how receivers send routing information to feeds.
Both tunneling and RPM approaches allow to solve the above problems.
However, we discuss the support of the following features in both approaches.
a) support for dynamic routing (i.e. exchange of routing
information over the unidirectional link).
The lack of a back channel on the unidirectional link
is masked with the tunneling approach and taken into
account explicitly in the RPM approach. In other words,
in the tunneling approach, a tunnel to send routing
information back to the feed is set without modifying
the routing protocol. However, there is a need to choose
"asymetric" metrics for the tunnel to avoid that the
back channel is used for sending user data.
The RPM approach allows the feeds to send routing traffic
on a unidirectional link, and to receive routing traffic
in opposite direction on another interface. The lack of the
back channel is known by the routing protocol. Note that
the routing information sent by the feeds will be discarded
by the receivers in both approaches. In RPM because
the routing protocols implementation was changed to do so,
and in tunneling solution because the high cost of the back channel
makes the announcement of a route to a network behind the feeds
irrelevant. In fact, the three proposed tunneling solutions (Hughes,
Aerospace and WIDE) propose to configure the routing protocols so
that a high metric is used for the back channel in order to avoid
using this tunnel for sending data trafic. Only routing protocol
trafic will be sent on this vitrual interface. In the RPM
approach we know that there is no back channel.
Therefore, if there is a simple way to configure the routing
protocols dynamically the tunneling solution seems more attractive.
Still the problem of what value to choose for the metric. In RIP,
it is simple. In OSPF we need to know the distance between
the receiver and the feed and choose a higher value.
Hughes solution is to set RIP metric to 15, Aerospace
said in their draft that the routing protocols will have
to be configured to reflect the high cost. Same for WIDE.
DirecPC and Berkely extension support split routing. There
is no exchange of dynamic routing information.
b) Routing efficiency
Both approaches will allow to avoid encapsulation for user data traffic.
This is not the same for DirecPC solution and for the home-agent
based routing proposed by Berekeley to extend DirecPC to support
several stations in a LAN interconnection.
Therefore no preference for tunneling or RPM
c) easy configuration (without scalability issues)
the RPM solution is auto-configurable. WIDE and Aerospace
tunneling solutions propose a dynamic configuration to
address pb1 above. Aerospace solution is based on a solution
inspired from ICMP router discovery. When a receiver detectes
a feed it sets a tunnel (entry in table that will trigger
encapsulation). However, we need a mechanism to "inform"
the routing protocol about the asymetric metric to use
for this tunnel (as cited before).
d) Multicast routing support
Reverse Path Forwarding (RPF) assumes that links are symmetric
(and not only bidirectional). Therefore, the tunneling solution
should assumes that both metrics are equal for multicast routing.
Multicast traffic should not be forwarded on the virtual
interface at the receiver, in order to avoid duplication.
The RPM approach addresses this explictly:
routing protocols implementation is modified to allow the forwarding
of IP mulitcast datagrams by receivers even if they are received
on an interface different that the receiver uses to reach the
feeds. The two approaches therefore support RPF.
e) Scalability
The problem is the same for both approaches.
Tunneling solution may benefit from Mutlicast tunneling
(e.g. a receiver establishing a multicast tunnel with all
feeds, encapsulating routing information in multicast datagrams).
Can someone provide more information on that?
f) Inter Domain routing consideration
We need to specify which routing information is to be exchanged
over the bidirectionnal virtual interface. Satellite udlinks
allow to reach destinations in other AS. Which subnets should
be announced?
----
could you please comment the above discussion elements?
My feeling is that the two approaches are really similar, and
that they face the same problems: e) and f) above.
I propose that we discuss this in the meeting, with the
goal of reaching a "single" solution if possible (I hope so).
After that, we may concentrate on writing an I-D describing
all the (agreed) details of this solution, and specifying
the open issues in order to address them before Munich.
I will send another draft agenda taking this into account.
see you next week,
Walid Dabbous
http://www.inria.fr/rodeo/personnel/Walid.Dabbous/me.html
INRIA U.R. de Sophia Antipolis | Email : dabbous@sophia.inria.fr
2004, Route des Lucioles BP 93 | Phone : +33 4 93 65 77 18
06902 Sophia Antipolis CEDEX France | Fax : +33 4 93 65 77 65