[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes of UDLR meeting
Draft of 14/8/97
Minutes of UniDirectional Link Routing Working Group Meeting
of 11/8/97, Munich, 39th IETF
Reported by WG Co-Chair, Walid Dabbous
[Apologies from other Co-Chair, Yongguang Zhang]
0 Agenda
5 min I. Agenda Bashing
20 min II. Terminology Discussion
30 min III. Presentation on ongoing work concerning tunneling
a) INRIA
b) WIDE
60 min IV. Discuss tunneling issues
IV-1) Receiver is a host case:
*) ARP
IV-2) Receiver is a router with static IP address
*) Support of MAC addresses
IV-3) Receiver is a router with dynamic IP address
*) Dynamic Configuration Protocol
*) Encapsulation (GRE or IP-in-IP)
10 min V. Documents
5 min VI. AOB
------------------
1 Introduction
Walid Dabbous gave a brief history and remind the WG focus.
UDLR WG chartered to discuss a solution for the support
of dynamic routing over unidirectional links with the
assumption that there exists a bidirectional path between
"receivers" and the corresponding "feeds" (a backchannel).
Multiple Unidirectional Links (UDLs) could exist, but a
bidirectional "back channel" is assumed to exist for all UDLs.
The solution of this problem is called "short term" solution.
Two approaches had been discussed to solve this problem,
namely routing protocol modification and tunneling.
Routing protocol modification (presented in the
three INRIA I-D referenced hereafter) was considered
as non necessary to solve the short term problem.
It was decided in Memphis meeting to focus on tunneling.
Both INRIA and WIDE are implementing a tunneling mechanism.
W. Dabbous slides are in
ftp://zenon.inria.fr/rodeo/udlr/slides/general.ps.gz
2 Terminology Discussion
It was decided to use the following terminology
Non Commutative Link: denotes a Link between two nodes A and B, where
A can reach B does not mean that B can reach A.
A UniDirectional Link is a special case of NCL.
Focus should be made on the Unidirectionality of the receive-only
interface. It will be called Unidirectional Receive-only Interface,
or Receive-only Interface.
The term Feed (resp. Receiver) designates a node
connected to a NCL with a send-capable interface (resp.
receive-only interface).
It was decided not to use a specific term to designate
the networks considered by the udlr working groups, but
to deiscribe the topology at the beginnign of the draft.
(i.e. not to use terms such as alternative unidirectional
network).
Scott Michel will post soon a draft section on terminology
to be added to the common I-D.
3 Presentations
Emmanuel Duros from INRIA presented his current work
on implementing a tunneling solution.
As the receiver needs to send a routing message to the feed (the destination
address is either the feed's send-capable interface or the broadcast address
of the corresponding subnet) it is tunneled via the receiver's
bidirectional interface. The packet is encapsulated (using GRE)in an IP packet
whose IP destination address is the feed bidirectional interface.
The datagram is then sent to the end point of the tunnel via the back channel.
As it is received by the feed, the payload of the datagram is decapsulated.
The new IP packet that is obtained is routed according it its destination
address which is the IP address of the feed's send-capable interface or
the broadcast address of corresponding subnetwork. The packet is then
delivered ``locally'' and not forwarded since the destination address
is the feed itself. The IP stack passes the packet to higher level,
in our case the routing protocol.
A mechanism to dynamically discover feeds and set up tunnels is also
being implemented. When a receiver boots up it must discover the
presence of feeds dynamically and creates a tunnel with each of them.
The tunnel end points are the bidirectional interfaces of the receiver
.and the feed. In order to allow the receiver to learn the tunnel
end point (i.e. a feed interface belonging to the bidirectional network)
a new simple protocol is needed. Feeds periodically advertise their
tunnel end point over the NCL. As a receiver gets this message, it checks
if the tunnel exists, if not it creates a tunnel and uses it.
A time-out mechanism is used to clear the tunnel entry if no advertisement
messages are received. This protocol is very close to DTPC (proposed
by WIDE) and a common protocol will be described in the I-D.
The work is ongoing and it is expetec to experiment RIP
and DVMRP operation soon over the Eutelsat satellite link using
INRIA uplink station.
The slides of Emmanuel's presentation are in:
ftp://zenon.inria.fr/rodeo/udlr/slides/inria39.ps.gz
Hidetaka Izumiyama from JCSAT/WIDE project presented their
implmentation work on tunneling.
The WIDE project has been working on tunneling since San Jose
meeting. The proposed solution is based either on static
or dynamic configuration of tunnels. Regular keep-alive
messages are used to "refresh" the MAC/IP address mapping.
No ARP mechanism is needed. Therefore IP in IP
encapsulation is used (no need for GRE). RIP, OSPF and DVMRP
had already been tested on the JCSAT satellite.
Ongoing work concerns the design and implementation of the Dynamic
Tunneling Path Configuration protocol. This work will be
carried on in close collaboration with INRIA, while still keeping
two distinct implementations (hopefully interoperable!).
The slides if Izu's presentation are in:
ftp://zenon.inria.fr/rodeo/udlr/slides/wide39.ps.gz
4 Discussion
Several points were discussed during and after the presentations.
The first question concerns the "receiver is a host" case, i.e.
when no routing protocol is running on the receiver.
The question is whether we should have an "on-demand" ARP mechanism
or should we have regular keep-alive messages. In fact, in this
case, the "tunnel" will not be used to send any traffic from
the receiver to the feed, and no "implicit refresh" messages
are received. (If there were a routing protocol "using" the tunnel
the routing messages would behave as implicit refresh for
the MAC/IP address mapping). Christian Huitema pointed out
that an on-demand ARP mechanism is needed. Regular keep-alive
messages from receivers to feeds may be used, but one cannot
expect the feed to keep all the information. A combination
of both techniques should be used. Steeve Deering also expressed
his preference to support an ARP mechanism.
The second question concerns the "receiver is a router" case.
In this case, there is no need for keep-alive messages.
However, for scalability resons, one cannot expect that all the
MAC/IP mappings will be kept by the feeds. Therefore a combination
of implicit refresh and on-demand ARP resquest should be supported.
The third question is related to the two above:
which encapsulation mechaism to use. If ARP is to be supported
GRE is needed. Otherwise, IP in IP is sufficient.
Chrisitan Huitema proposed to use IP in DTCP encapsulation
i.e. a new mechanism specific to UDLR.
There were a rough consensus about GRE, but this should be
confirmed on the mailing list. Please give any feedback on this
subject as soon as possible as the common I-D should be edited
soon and it SHOULD propose the use of ONE encapsualtion mechanism.
5 Documents
Seven documents were already submitted to the udlr working group.
d1) VIPRE -- Virtual Internet Packet Relay
An Encapsulation Architecture for Unidirectional Links
by James Stepanek (The Aerospace Corporation)
and Stephen Schwab (Twin Sun Inc). February 1997.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-vipre-00.txt
d2) An IP tunneling approach for Uni-directional Link routing
by Hidetaka Izumiyama, Akihiro Tosaka and Akira Kato
(WIDE project). July 1997.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-wide-tunnel-00.txt
d3) Dynamic Tunneling Path Configuration for Uni-directional
Link Routing
by Hidetaka Izumiyama and Akihiro Tosaka (WIDE project).
July 1997.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-dtpc-00.txt
d4) Supporting Unidirectional Paths in the Internet
by Emmanuel Duros and Walid Dabbous, INRIA. June 1996.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-general-00.txt
d5) Handling of unidirectional links with RIP
by E. Duros and C. Huitema, INRIA, March 1996.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-rip-00.txt
d6) Handling of unidirectional links with OSPF
by E. Duros, INRIA, March 1996.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-ospf-00.txt
d7) Handling of unidirectional links with DVMRP
by E. Duros and W. Dabbous, INRIA, March 1996.
http://www.inria.fr/rodeo/udlr/documents/draft-udlr-dvmrp-00.txt
These documents will be sent to the IETF as UDLR I-Ds, to be
put on the I-D directory.
6 Action points
Scott Michel to prepare a draft section on terminology.
Emmanuel Duros and Walid Dabbous to prepare a draft on the
common solution (that will integrate the terminology).
Put the draft I-D on the list for discussion.
Walid Dabbous to forward the above documents to IETF.