draft-ietf-udlr-lltunnel-00.txt   draft-ietf-udlr-lltunnel-01.txt 
Network Working Group E. Duros Network Working Group E. Duros
Internet-Draft W. Dabbous Internet-Draft W. Dabbous
February 1999 INRIA Sophia-Antipolis April 1999 INRIA Sophia-Antipolis
H. Izumiyama H. Izumiyama
N. Fujii N. Fujii
WIDE WIDE
Y. Zhang Y. Zhang
HRL HRL
A Link Layer Tunneling Mechanism for Unidirectional Links A Link Layer Tunneling Mechanism for Unidirectional Links
<draft-ietf-udlr-lltunnel-00.txt> <draft-ietf-udlr-lltunnel-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A version of this draft document is intended for submission to the
RFC editor as a Proposed Standard for the Internet Community.
Abstract Abstract
This document describes a mechanism to emulate bidirectional This document describes a mechanism to emulate bidirectional
connectivity between nodes that are directly connected by a connectivity between nodes that are directly connected by a
unidirectional link. The "receiver" uses a link layer tunneling unidirectional link. The "receiver" uses a link layer tunneling
mechanism to forward datagrams to "feeds" over a bidirectional mechanism to forward datagrams to "feeds" over a bidirectional
network. network.
1. Introduction 1. Introduction
Internet routing and upper layer protocols assume that links are Internet routing and upper layer protocols assume that links are
bidirectional, i.e., directly connected hosts can communicate with bidirectional, i.e., directly connected hosts can communicate with
each other over the same link. each other over the same link.
This document describes a link layer tunneling mechanism that allows This document describes a link layer tunneling mechanism that allows
nodes which are directly connected by a unidirectional link (feeds nodes which are directly connected by a unidirectional link (feeds
and receivers, see section 2 for terminology) to send datagrams as if and receivers, see section 2 for terminology) to send datagrams as if
they were connected to a bidirectional link. We present a generic they were connected to a bidirectional link. We present a generic
topology with a tunneling mechanism that supports multiple feeds and topology with a tunneling mechanism that supports multiple feeds and
receivers. receivers.
skipping to change at page 9, line 50 skipping to change at page 10, line 5
enable a bidirectional communication with it. Static tunneling enable a bidirectional communication with it. Static tunneling
configuration is not appropriate, as new feeds can be connected configuration is not appropriate, as new feeds can be connected
to the unidirectional link at any time. to the unidirectional link at any time.
2) when the unidirectional link is down, receivers must disable 2) when the unidirectional link is down, receivers must disable
their tunnels. The tunneling mechanism emulates bidirectional their tunnels. The tunneling mechanism emulates bidirectional
connectivity between nodes. Therefore, if the unidirectional connectivity between nodes. Therefore, if the unidirectional
link is down, a feed should not receive datagrams from the link is down, a feed should not receive datagrams from the
receivers. Indeed there are protocols that consider a link as receivers. Indeed there are protocols that consider a link as
operational if they receive datagrams from it (e.g., the RIP operational if they receive datagrams from it (e.g., the RIP
protocol [rfc1388]). protocol [rfc2453]).
3) when a feed is down, receivers must disable their corresponding 3) when a feed is down, receivers must disable their corresponding
tunnel. This prevents unnecessary datagrams from being tunneled tunnel. This prevents unnecessary datagrams from being tunneled
which would overload Internet. For instance, there is no need which would overload Internet. For instance, there is no need
for receivers to forward a broadcast message through a tunnel for receivers to forward a broadcast message through a tunnel
whose end-point is down. whose end-point is down.
The DTCP protocol provides a means for receivers to discover The DTCP protocol provides a means for receivers to discover
dynamically the presence of feeds and to maintain a list of dynamically the presence of feeds and to maintain a list of
operational tunnel end-points. It is based on feed periodical operational tunnel end-points. It is based on feed periodical
skipping to change at page 17, line 40 skipping to change at page 17, line 43
and receivers have to run routing protocols. They will work fine and receivers have to run routing protocols. They will work fine
because feeds and receivers consider themselves as directly because feeds and receivers consider themselves as directly
connected, and can exchange routing messages over the unidirectional connected, and can exchange routing messages over the unidirectional
link. link.
The tunneling mechanism allows one to forward all the IP traffic, and The tunneling mechanism allows one to forward all the IP traffic, and
not only routing protocol messages from receivers to feeds. Receivers not only routing protocol messages from receivers to feeds. Receivers
can route datagrams on the Internet using the most suitable feed or can route datagrams on the Internet using the most suitable feed or
receiver as a next hop. receiver as a next hop.
Feeds and receivers can run multicast routing daemon and therefore
dynamic multicast routing can be performed over the unidirectional
link. However issues related to multicast routing (e.g. protocol
configuration) are not addressed in this document.
8.3. Scalability 8.3. Scalability
The DTCP protocol does not generate a lot of traffic whatever the The DTCP protocol does not generate a lot of traffic whatever the
number of nodes. The problem with a large number of nodes is not number of nodes. The problem with a large number of nodes is not
related to this protocol but to a more general issue such as the related to this protocol but to a more general issue such as the
maximum number of nodes which can be connected to a link. This is out maximum number of nodes which can be connected to a link. This is out
of scope of this document. of scope of this document.
9. Acknowledgments 9. Security Considerations
Receivers send packets through tunnels to feeds. Because of
scalability reasons, there is no specific mechanism in this document
to ensure that a receiver is allowed to set a tunnel to a feed. Any
malicious individual that gains access to the unidirectional link can
get full connectivity to feeds. Therefore it is higly recommended on
the feed site to have some firewall capabilities.
10. Acknowledgments
We would like to thank Patrick Cipiere (INRIA) for his valuable input We would like to thank Patrick Cipiere (INRIA) for his valuable input
concerning the design of the encapsulation mechanism. concerning the design of the encapsulation mechanism.
We would like also to thank for their participation: Akihiro Tosaka We would like also to thank for their participation: Akihiro Tosaka
(IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi
Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony),
Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu
(Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri (Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri
Hakulinen (Nokia). Hakulinen (Nokia).
skipping to change at page 18, line 25 skipping to change at page 18, line 42
November 1982. November 1982.
[rfc1702] 'Generic Routing Encapsulation over IPv4 networks', S. [rfc1702] 'Generic Routing Encapsulation over IPv4 networks', S.
Hanks, NetSmiths, Ltd., T. Li, D. Farinacci, P. Traina, Hanks, NetSmiths, Ltd., T. Li, D. Farinacci, P. Traina,
Cisco System, October 1994. Cisco System, October 1994.
[rfc1701] 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths, [rfc1701] 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths,
Ltd., T. Li, D. Farinacci, P. Traina, Cisco System, October Ltd., T. Li, D. Farinacci, P. Traina, Cisco System, October
1994. 1994.
[rfc1388] 'RIP Version 2 - Carrying Additional Information', G. [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998
Malkin, Xylogics, Inc., January 1993.
Author's address Author's address
Emmanuel Duros Emmanuel Duros
INRIA Sophia Antipolis INRIA Sophia Antipolis
2004, Route des Lucioles BP 93 2004, Route des Lucioles BP 93
06902 Sophia Antipolis 06902 Sophia Antipolis
France France
Phone : +33 4 92 38 79 42 Phone : +33 4 92 38 79 42
Fax : +33 4 92 38 79 78 Fax : +33 4 92 38 79 78
 End of changes. 8 change blocks. 
6 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/