draft-ietf-udlr-lltunnel-05.txt   draft-ietf-udlr-lltunnel-06.txt 
Network Working Group E. Duros Network Working Group E. Duros
Internet-Draft UDcast Internet-Draft UDcast
November 2000 W. Dabbous January 2000 W. Dabbous
Exprires April 2001 INRIA Sophia-Antipolis Expires July 2001 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-05.txt> <draft-ietf-udlr-lltunnel-06.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 4, line 44 skipping to change at page 4, line 44
Note that nodes have IP addresses on their unidirectional and their Note that nodes have IP addresses on their unidirectional and their
bidirectional interfaces. The addresses on the unidirectional bidirectional interfaces. The addresses on the unidirectional
interfaces (f1u, f2u, r1u, r2u) will be drawn from the same IP interfaces (f1u, f2u, r1u, r2u) will be drawn from the same IP
network. In general the addresses on the bidirectional interfaces network. In general the addresses on the bidirectional interfaces
(f1b, f2b, r1b, r2b) will be drawn from different IP networks, and (f1b, f2b, r1b, r2b) will be drawn from different IP networks, and
the Internet will route between them. the Internet will route between them.
4. Problems related to unidirectional links 4. Problems related to unidirectional links
Receive-only interfaces are "dumb" and send-only interfaces are Receive-only interfaces are "dumb" and send-only interfaces are
"deaf". Thus a datagram passed to the link-layer driver of a "deaf". Thus a datagram passed to the link-layer driver of a receive-
receive-only interface is simply discarded. The link-layer of a only interface is simply discarded. The link-layer of a send-only
send-only interface never receives anything. interface never receives anything.
The network layer has no knowledge of the underlying transmission The network layer has no knowledge of the underlying transmission
technology except that it considers its access as bidirectional. technology except that it considers its access as bidirectional.
Basically, for outgoing datagrams, the network layer selects the Basically, for outgoing datagrams, the network layer selects the
correct first hop on the connected network according to a routing correct first hop on the connected network according to a routing
table and passes the packet(s) to the appropriate link-layer driver. table and passes the packet(s) to the appropriate link-layer driver.
Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. Referring to Figure 1, Recv 1 and Feed 1 belong to the same network.
However, if Recv 1 initiates a 'ping f1u', it cannot get a response However, if Recv 1 initiates a 'ping f1u', it cannot get a response
from Feed 1. The network layer of Recv 1 delivers the packet to the from Feed 1. The network layer of Recv 1 delivers the packet to the
skipping to change at page 5, line 23 skipping to change at page 5, line 23
Many protocols in the Internet assume that links are bidirectional. Many protocols in the Internet assume that links are bidirectional.
In particular, routing protocols used by directly connected routers In particular, routing protocols used by directly connected routers
no longer behave properly in the presence of a unidirectional link. no longer behave properly in the presence of a unidirectional link.
5. Emulating a broadcast bidirectional network 5. Emulating a broadcast bidirectional network
The simplest solution is to emulate a broadcast capable link-layer The simplest solution is to emulate a broadcast capable link-layer
network. This will allow the immediate deployment of existing higher network. This will allow the immediate deployment of existing higher
level protocols without change. Though other network structures, such level protocols without change. Though other network structures, such
as NBMA, could also be emulated, a broadcast network is more as NBMA, could also be emulated, a broadcast network is more
generally useful. Though a layer 3 network could be emulated, a generally useful. Though a layer 3 network could be emulated, a link-
link-layer network allows the immediate use of any other network layer network allows the immediate use of any other network layer
layer protocols, and most particularly allows the immediate use of protocols, and most particularly allows the immediate use of ARP.
ARP.
A link-layer tunneling mechanism which emulates bidirectional A link-layer tunneling mechanism which emulates bidirectional
connectivity in the presence of a unidirectional link will be connectivity in the presence of a unidirectional link will be
described in the next Section. We first consider the various described in the next Section. We first consider the various
communication scenarios which characterize a broadcast network in communication scenarios which characterize a broadcast network in
order to define what functionalities the link-layer tunneling order to define what functionalities the link-layer tunneling
mechanism has to perform in order to emulate a bidirectional mechanism has to perform in order to emulate a bidirectional
broadcast link. broadcast link.
Here we enumerate the scenarios which would be feasible on a Here we enumerate the scenarios which would be feasible on a
skipping to change at page 13, line 29 skipping to change at page 13, line 29
is the IP address of a feed bidirectional interface (tunnel end- is the IP address of a feed bidirectional interface (tunnel end-
point) reachable via the Internet. A feed has 'Nb of FBIP' IP point) reachable via the Internet. A feed has 'Nb of FBIP' IP
addresses which are operational tunnel end-points. They are addresses which are operational tunnel end-points. They are
enumerated in preferred order. FBIP1 being the most suitable tunnel enumerated in preferred order. FBIP1 being the most suitable tunnel
end-point. end-point.
7.2. DTCP on the feed: sending HELLO packets 7.2. DTCP on the feed: sending HELLO packets
The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP
announcement" multicast address over the unidirectional link on port announcement" multicast address over the unidirectional link on port
HELLO_PORT with a TTL of 1. HELLO_PORT with a TTL of 1. Due to existing deployements a feed
SHOULD also support the use of the old DTCP announcement address, see
Appendix B.
The source address of the HELLO packet is set to the IP address of The source address of the HELLO packet is set to the IP address of
the feed interface connected to the unidirectional link. In the rest the feed interface connected to the unidirectional link. In the rest
of the document, this value is called FUIP (Feed Unidirectional IP of the document, this value is called FUIP (Feed Unidirectional IP
address). address).
The process in charge of sending HELLO packets fills every field of The process in charge of sending HELLO packets fills every field of
the datagram according to the description given in Section 7.1. the datagram according to the description given in Section 7.1.
As long as a feed is up and running, it periodically announces its As long as a feed is up and running, it periodically announces its
skipping to change at page 17, line 5 skipping to change at page 17, line 7
In all cases, the encapsulation type depends on the tunnel type In all cases, the encapsulation type depends on the tunnel type
required by the feed which is selected. required by the feed which is selected.
7.5. Constant definitions 7.5. Constant definitions
DTCP_VERSION is 1. DTCP_VERSION is 1.
HELLO_INTERVAL is 5 seconds. HELLO_INTERVAL is 5 seconds.
"DTCP announcement" multicast group is 224.0.1.124. "DTCP announcement" multicast group is 224.0.0.36, assigned by IANA.
HELLO_PORT is 652. It is a reserved system port, no other traffic HELLO_PORT is 652. It is a reserved system port assigned by IANA, no
must be allowed. other traffic must be allowed.
HELLO_LEAVE is 3*Interval, as advertised in a HELLO packet, i.e. 15 HELLO_LEAVE is 3*Interval, as advertised in a HELLO packet, i.e. 15
seconds if the default HELLO_INTERVAL was advertised. seconds if the default HELLO_INTERVAL was advertised.
8. Tunnel encapsulation format 8. Tunnel encapsulation format
The tunneling mechanism operates at the link-layer and emulates The tunneling mechanism operates at the link-layer and emulates
bidirectional connectivity amongst receivers and feeds. We assume bidirectional connectivity amongst receivers and feeds. We assume
that hardware connected to the unidirectional link supports broadcast that hardware connected to the unidirectional link supports broadcast
and unicast MAC addressing. That is, a feed can send a packet to a and unicast MAC addressing. That is, a feed can send a packet to a
skipping to change at page 19, line 44 skipping to change at page 19, line 46
configuration) are not addressed in this document. configuration) are not addressed in this document.
9.3. Scalability 9.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 more general issues such as the related to this protocol but to more general issues such as the
maximum number of nodes which can be connected to any link. This is maximum number of nodes which can be connected to any link. This is
out of scope of this document. out of scope of this document.
10. Security Considerations 10. IANA Considerations
IANA has reserved the address 224.0.0.36 for the "DTCP announcement"
multicast address as defined in Section 7.
IANA has reserved the udp port 652 for the HELLO_PORT as defined in
Section 7.
11. Security Considerations
Many unidirectional link technologies are characterised by the ease Many unidirectional link technologies are characterised by the ease
with which the link contents can be received. If sensitive or with which the link contents can be received. If sensitive or
valuable information is being sent, then link-layer security valuable information is being sent, then link-layer security
mechanisms are an appropriate measure. For the UDLR protocol itself, mechanisms are an appropriate measure. For the UDLR protocol itself,
the feed tunnel end-point addresses, sent in HELLO messages, may be the feed tunnel end-point addresses, sent in HELLO messages, may be
considered sensitive. In such cases link-layer security mechanisms considered sensitive. In such cases link-layer security mechanisms
may be used. may be used.
Security in a network using the link-layer tunneling mechanism should Security in a network using the link-layer tunneling mechanism should
skipping to change at page 20, line 25 skipping to change at page 20, line 36
IP protocol (e.g. AH[rfc2402]) or in an authentication protocol IP protocol (e.g. AH[rfc2402]) or in an authentication protocol
integrated with the tunneling mechanism. integrated with the tunneling mechanism.
At a higher level, receivers may not be authorised to provide routing At a higher level, receivers may not be authorised to provide routing
information even though they are connected to the unidirectional information even though they are connected to the unidirectional
link. In order to prevent unauthorised receivers from providing fake link. In order to prevent unauthorised receivers from providing fake
routing information, routing protocols running on top of the link- routing information, routing protocols running on top of the link-
layer tunneling mechanism MUST use authentication mechanisms when layer tunneling mechanism MUST use authentication mechanisms when
available. available.
11. Acknowledgments 12. Acknowledgments
We would like to thank Tim Gleeson (Cisco Japan) for his valuable We would like to thank Tim Gleeson (Cisco Japan) for his valuable
editing and technical input during the finalization phase of the editing and technical input during the finalization phase of the
document. document.
We would like to thank Patrick Cipiere (UDcast) for his valuable We would like to thank Patrick Cipiere (UDcast) for his valuable
input concerning the design of the encapsulation mechanism. input 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).
A. Conformance and interoperability Appendix A: Conformance and interoperability
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. Applicability over a variety of equipment and unidirectional link. Applicability over a variety of equipment and
environments is ensured by allowing a choice of several key system environments is ensured by allowing a choice of several key system
parameters. parameters.
Thus in order to ensure interoperability of equipment it is not Thus in order to ensure interoperability of equipment it is not
enough to simply claim conformance with the mechanism defined here. A enough to simply claim conformance with the mechanism defined here. A
usage profile for a particular environment will require the usage profile for a particular environment will require the
definition of several parameters: definition of several parameters:
- the MAC format used - the MAC format used
- the tunneling mechanism to be used (GRE is recommended) - the tunneling mechanism to be used (GRE is recommended)
- the "tunnel type" indication if GRE is not used - the "tunnel type" indication if GRE is not used
For example, a system might claim to implement "the link-layer For example, a system might claim to implement "the link-layer
tunneling mechanism for unidirectional links, using IEEE 802 LLC, and tunneling mechanism for unidirectional links, using IEEE 802 LLC, and
GRE encapsulation for the tunnels." GRE encapsulation for the tunnels."
Appendix B: DTCP announcement address transition plan
Some older receivers listen for DTCP announcements on the 224.0.1.124
multicast address (the "old DTCP announcement" address). In order to
support such legacy receivers, feeds SHOULD be configurable to send
all announcements simultaneously to both the "DTCP announcement"
address, and the "old DTCP announcement" address. The default setting
is to send announcements to just the "DTCP announcement" address.
In order to encourage the transition plan, the "old" feeds MUST be
updated to send DTCP announcements as defined in this section. The
number of "old" feeds originally deployed is relatively small and
therefore the update should be fairly easy. "New" receivers only
support "new" feeds, i.e., they listen to DTCP announcements on the
"DTCP announcement" address.
References References
[rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer,
November 1982. November 1982.
[rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford
University, August 1989 University, August 1989
[rfc1700] 'ASSIGNED NUMBERS', J. Reynolds, J. Postel, ISI, October [rfc1700] 'ASSIGNED NUMBERS', J. Reynolds, J. Postel, ISI, October
1994 1994
skipping to change at page 22, line 9 skipping to change at page 23, line 9
[rfc2780] 'IANA Allocation Guidelines For Values In the Internet [rfc2780] 'IANA Allocation Guidelines For Values In the Internet
Protocol and Related Headers', S. Bradner, Harvard Protocol and Related Headers', S. Bradner, Harvard
[rfc2784] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li, [rfc2784] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li,
Procket Networks, S. Hanks, Enron Communications, D. Meyer, Procket Networks, S. Hanks, Enron Communications, D. Meyer,
Author's address Author's address
Emmanuel Duros Emmanuel Duros
UDcast UDcast
Les Taissounieres - HB3
1681, route des Dolines 1681, route des Dolines
06560 Sophia-Antipolis Les Taissounieres - BP 355
06906 Sophia-Antipolis Cedex
France France
Phone : +33 4 93 00 16 60 Phone : +33 4 93 00 16 60
Fax : +33 4 93 00 16 61 Fax : +33 4 93 00 16 61
Email : Emmanuel.Duros@UDcast.com Email : Emmanuel.Duros@UDcast.com
Walid Dabbous Walid Dabbous
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
 End of changes. 13 change blocks. 
19 lines changed or deleted 44 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/