draft-ietf-udlr-lltunnel-01.txt   draft-ietf-udlr-lltunnel-02.txt 
Network Working Group E. Duros Network Working Group E. Duros
Internet-Draft W. Dabbous Internet-Draft W. Dabbous
April 1999 INRIA Sophia-Antipolis June 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-01.txt> <draft-ietf-udlr-lltunnel-02.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 45 skipping to change at page 1, line 44
A version of this draft document is intended for submission to the A version of this draft document is intended for submission to the
RFC editor as a Proposed Standard for the Internet Community. 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. As it is implemented at link layer, other protocols than IP
may also use this tunneling mechanism.
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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
receivers. receivers.
The tunneling mechanism is implemented at the link layer of the The tunneling mechanism is implemented at the link layer of the
interface connected to the unidirectional link on every feed and interface connected to the unidirectional link on every feed and
every receiver. The aim is to hide from higher layers, i.e. network every receiver. The aim is to hide from higher layers, i.e. network
layer and above, the unidirectional feature of the link. The layer and above, the unidirectional feature of the link. The
tunneling mechanism also includes an automatic tunnel configuration tunneling mechanism also includes an automatic tunnel configuration
protocol that allows feeds and receivers to come up/down at any time. protocol that allows feeds and receivers to come up/down at any time.
The tunneling mechanism proposes to use Generic Routing Encapsulation The tunneling mechanism proposes to use Generic Routing Encapsulation
[rfc1701] and provides a means for carrying IP and ARP datagrams from [rfc1701] and provides a means for carrying IP, ARP datagrams and any
receivers to feeds. layer-3 protocol from receivers to feeds.
The tunneling mechnism described in this document was discussed and The tunneling mechanism described in this document was discussed and
agreed upon by the UDLR working group. agreed upon by the UDLR working group.
2. Terminology 2. Terminology
Unidirectional link (UDL): A one way transmission link, e.g. a Unidirectional link (UDL): A one way transmission link, e.g. a
broadcast satellite link. broadcast satellite link.
Receiver: A router that has receive-only connectivity to an UDL. Receiver: A router that has receive-only connectivity to an UDL.
Send-only feed: A router that has send-only connectivity to an UDL. Send-only feed: A router that has send-only connectivity to an UDL.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
x : IP layer at the receiver generates a datagram to be forwarded x : IP layer at the receiver generates a datagram to be forwarded
on the receive-only interface. on the receive-only interface.
O : Entry point where the link layer tunneling mechanism is O : Entry point where the link layer tunneling mechanism is
triggered. triggered.
Figure 2: Scenario 1 using the LL Tunneling Mechanism Figure 2: Scenario 1 using the LL Tunneling Mechanism
6.1. Tunneling mechanism on the receiver 6.1. Tunneling mechanism on the receiver
The tunneling mechanism is inserted at the link layer of the A datagram is delivered from the network layer to the link layer of
receive-only interface. As a datagram is delivered to the link layer the unidirectional interface (see Figure 2). It is then encapsulated
from the network layer, it is encapsulated (See Figure 2). behind a MAC header corresponding to the unidirectional link. This
packet cannot be sent over the link and is then processed by the
tunneling mechanism.
The datagram is encapsulated behind an IP header whose destination is The packet is encapsulated behind an IP header whose destination is
the IP address of a feed bidirectional interface (f1b or f2b), also the IP address of a feed bidirectional interface (f1b or f2b), also
called the tunnel end-point. The mechanism for a receiver to learn called the tunnel end-point. The mechanism for a receiver to learn
these addresses and to choose the feed is explained in Section 6.3. these addresses and to choose the feed is explained in Section 6.3.
The type of encapsulation is described in Section 7. The type of encapsulation is described in Section 7.
The new datagram is passed to the network layer that forwards it The new datagram is passed to the network layer that forwards it
according to its destination address. The destination address of the according to its destination address. The destination address of the
encapsulated datagram is a feed bidirectional interface which is encapsulated datagram is a feed bidirectional interface which is
reachable via the Internet. The datagram is then forwarded via the reachable via the Internet. The datagram is then forwarded via the
receiver bidirectional interface (r1b). receiver bidirectional interface (r1b).
We have to distinguish several cases as the datagram is to be We have to distinguish several cases as the datagram is to be
tunneled according to the next hop address. If the next hop address tunneled according to the destination MAC address. If the destination
is: MAC address is:
1) the IP address of a feed interface connected to the 1) the MAC address of a feed interface connected to the
unidirectional link (scenario 1): the datagram is encapsulated, unidirectional link (scenario 1): the datagram is encapsulated,
the destination address of the new datagram is the feed tunnel the destination address of the new datagram is the feed tunnel
end-point (f1b referring to Figure 2). end-point (f1b referring to Figure 2).
2) a broadcast/multicast address (Scenario 2): the datagram is 2) a MAC broadcast/multicast address (Scenario 2): the datagram is
encapsulated, the destination address of the new datagram is the encapsulated, the destination address of the new datagram is the
default feed tunnel end-point. See Section 6.3.4 for further default feed tunnel end-point. See Section 6.3.4 for further
details on the default feed. details on the default feed.
3) an IP address that belongs to the unidirectional network but is 3) a MAC address that belongs to the unidirectional network but is
not a feed address (Scenario 3): the datagram is encapsulated not a feed address (Scenario 3): the datagram is encapsulated
and sent to the tunnel end-point of the default feed. and sent to the tunnel end-point of the default feed.
At this point, the network layer passes a datagram to the link layer At this point, the network layer passes a datagram to the link layer
of the receive-only interface, it is encapsulated and sent to a feed of the receive-only interface, it is encapsulated and sent to a feed
via its bidirectional interface. via its bidirectional interface.
6.2. Tunneling mechanism on the feed 6.2. Tunneling mechanism on the feed
A feed processes packets in two different ways: packets must be A feed processes packets in two different ways: packets must be
skipping to change at page 8, line 4 skipping to change at page 8, line 6
A feed cannot send directly over the unidirectional link a packet to A feed cannot send directly over the unidirectional link a packet to
a send-only feed. In order to emulate this type of communication, a a send-only feed. In order to emulate this type of communication, a
feed MUST maintain a list of send-only feed tunnel end-points. This feed MUST maintain a list of send-only feed tunnel end-points. This
is configured manually at the feed by the local administrator. In is configured manually at the feed by the local administrator. In
fact, as stated in Section 3, the number of feeds is expected to be fact, as stated in Section 3, the number of feeds is expected to be
relatively small, therefore a manual configuration can be envisaged. relatively small, therefore a manual configuration can be envisaged.
How to use this list is detailed in the next section. How to use this list is detailed in the next section.
6.2.1. Forwarding packets over the unidirectional link 6.2.1. Forwarding packets over the unidirectional link
The way a packet is forwarded depends on its next hop IP address, if
it is:
1) the IP address of a receiver or a receive capable feed (Scenario The way a packet is forwarded depends on its destination MAC address,
6). The packet is encapsulated behind a link layer header with if it is:
the corresponding MAC address of the destination. It is then
sent over the unidirectional link.
2) the IP address of a send-only feed (Scenario 4). The packet is 1) the MAC address of a receiver or a receive capable feed
(Scenario 6). The packet is sent over the unidirectional link.
This is the classical "forwarding".
2) the MAC address of a send-only feed (Scenario 4). The packet is
encapsulated and sent to the send-only feed tunnel end-point. encapsulated and sent to the send-only feed tunnel end-point.
The type of encapsulation is described in Section 7.
3) a broadcast/multicast destination (Scenario 5). The packet is 3) a broadcast/multicast destination (Scenario 5). The packet is
sent over the unidirectional link with a link layer header sent over the unidirectional link with a link layer header
corresponding to the broadcast/multicast addressing scheme. corresponding to the broadcast/multicast addressing scheme.
Currently, a copy of this packet is encapsulated and sent to Currently, a copy of this packet is encapsulated and sent to
every feed of the list of send-only feed tunnel end-points. every feed of the list of send-only feed tunnel end-points.
6.2.2. Receiving encapsulated packets 6.2.2. Receiving encapsulated packets
Feeds listen to incoming encapsulated datagrams on their tunnel end- Feeds listen to incoming encapsulated datagrams on their tunnel end-
point. An encapsulated packet which is received from the point. An encapsulated packet which is received from the
bidirectional interface, traverses the IP stack and enters a bidirectional interface, traverses the IP stack and enters a
decapsulation process (See Figure 2). Note that the original datagram decapsulation process (See Figure 2). Note that the original datagram
was encapsulated and therefore its IP header has not been modified by was encapsulated and therefore its payload (especially MAC and IP
intermediate routers. It is decapsulated and further actions depend header) has not been modified by intermediate routers. It is
on the next hop IP address which can be: decapsulated and further actions depend on the destination MAC
address which can be:
1) the address of the feed interface connected to the 1) the MAC address of the feed interface connected to the
unidirectional link, this corresponds to Scenarios 1 and 4. The unidirectional link, this corresponds to Scenarios 1 and 4. The
packet is passed to the link layer of the interface connected to packet is passed to the link layer of the interface connected to
the unidirectional link which then delivers it to the network the unidirectional link which then delivers it to the network
layer. As a result, the datagram is processed as if it was layer. As a result, the datagram is processed as if it was
coming from the unidirectional link. At this point, Scenarios 1 coming from the unidirectional link. At this point, Scenarios 1
and 4 are now feasible, a receiver or a feed can send a packet and 4 are now feasible, a receiver or a feed can send a packet
to a feed. to a feed.
2) a receiver address, this corresponds to Scenario 3. The packet 2) a receiver address, this corresponds to Scenario 3. The packet
is passed to the link layer of the interface connected to the is passed to the link layer of the interface connected to the
skipping to change at page 9, line 18 skipping to change at page 9, line 22
charge of sending the multicast packet to all nodes. An charge of sending the multicast packet to all nodes. An
encapsulation process at the feed encapsulates the packet and encapsulation process at the feed encapsulates the packet and
sends a copy to the list of send-only feed tunnel end-points. sends a copy to the list of send-only feed tunnel end-points.
The packet is also passed to the link layer of the interface The packet is also passed to the link layer of the interface
which forwards it directly over the unidirectional link (all which forwards it directly over the unidirectional link (all
receivers and receive capable feeds receive it). The link receivers and receive capable feeds receive it). The link
layer also delivers it locally to the network layer. Caution: layer also delivers it locally to the network layer. Caution:
a receiver which sends an encapsulated broadcast/multicast a receiver which sends an encapsulated broadcast/multicast
packet to a default feed will receive its own packet via the packet to a default feed will receive its own packet via the
unidirectional link. Correct filtering as described in unidirectional link. Correct filtering as described in
RFC1112 must be applied. [rfc1112] must be applied.
ii) the feed receives the packet and keeps it for local ii) the feed receives the packet and keeps it for local
delivery. The packet is passed to the link layer of the delivery. The packet is passed to the link layer of the
interface connected to the unidirectional link which delivers interface connected to the unidirectional link which delivers
it to the network layer. it to the network layer.
Scenario 2 is now feasible, a receiver can send a Scenario 2 is now feasible, a receiver can send a
broadcast/multicast packet over the unidirectional link and it broadcast/multicast packet over the unidirectional link and it
will be heard by all nodes. will be heard by all nodes.
6.3. Dynamic Tunnel Configuration Protocol (DTCP) 6.3. Dynamic Tunnel Configuration Protocol (DTCP)
Receivers and feeds have to know the feed tunnel end-points in order Receivers and feeds have to know the feed tunnel end-points in order
to forward encapsulated datagrams (e.g, Scenarios 1 and 4). to forward encapsulated datagrams (e.g, Scenarios 1 and 4).
The configuration of the send-only feeds list is performed manually The configuration of the send-only feeds list is performed manually
at the feed. The administator sets up tunnels to all send-only feeds. at the feed. The administrator sets up tunnels to all send-only
A tunnel end-point is an IP address (FBIP) of a send-only feed. feeds. A tunnel end-point is an IP address of a send-only feed.
For scalability reasons this cannot be done at the receivers. Tunnels For scalability reasons this cannot be done at the receivers. Tunnels
must be configured and maintained dynamically in order to cope with must be configured and maintained dynamically in order to cope with
the following events: the following events:
1) when a new feed comes up, every receiver must create a tunnel to 1) when a new feed comes up, every receiver must create a tunnel to
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.
skipping to change at page 10, line 13 skipping to change at page 10, line 16
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 [rfc2453]). 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 Note that these tunnels have no existence at the IP layer and are not
dynamically the presence of feeds and to maintain a list of considered as tunnel interfaces. The DTCP protocol provides a means
operational tunnel end-points. It is based on feed periodical for receivers to discover dynamically the presence of feeds and to
announcements over the unidirectional link that contain tunnel end- maintain a list of operational tunnel end-points. It is based on feed
point addresses. Receivers listen to these announcements and maintain periodical announcements over the unidirectional link that contain
a list of tunnel end-points. tunnel end-point addresses. Receivers listen to these announcements
and maintain a list of tunnel end-points.
6.3.1. The HELLO message 6.3.1. The HELLO message
The DTCP protocol is a 'unidirectional protocol', messages are only The DTCP protocol is a 'unidirectional protocol', messages are only
sent from feeds to receivers. sent from feeds to receivers.
The packet format is shown in Figure 2. Fields contain binary The packet format is shown in Figure 2. Fields contain binary
integers, in normal Internet order with the most significant byte integers, in normal Internet order with the most significant byte
first. Each tick mark represents one bit. first. Each tick mark represents one bit.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Com | Interval | Sequence | | Vers | Com | Interval | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed UDL IP addr (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed BDL IP addr (FBIP1) (32/128 bits) | | Feed BDL IP addr (FBIP1) (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed BDL IP addr (FBIPn) (32/128 bits) | | Feed BDL IP addr (FBIPn) (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet Format Figure 3: Packet Format
Every datagram contains the following fields, note that constants are Every datagram contains the following fields, note that constants are
skipping to change at page 11, line 12 skipping to change at page 11, line 14
Vers (4 bits): DTCP version number. MUST be DTCP_VERSION. Vers (4 bits): DTCP version number. MUST be DTCP_VERSION.
Com (4 bits): Command field, possible values are Com (4 bits): Command field, possible values are
1 - JOIN A message announcing that the feed sending this message 1 - JOIN A message announcing that the feed sending this message
is up and running. is up and running.
2 - LEAVE A message announcing that the feed sending this message 2 - LEAVE A message announcing that the feed sending this message
is being shut down. is being shut down.
Interval (8 bit unsigned integer): Interval in seconds between HELLO Interval (8 bit unsigned integer): Interval in seconds between HELLO
messages. The recommended value is HELLO_INTERVAL. This field MUST messages for the same layer-3 protocol. The recommended value is
not be changed while sending. HELLO_INTERVAL. This field MUST not be changed while sending.
Sequence (16 bit unsigned integer): Random value initialized at boot Sequence (16 bit unsigned integer): Random value initialized at boot
time and incremented by 1 every time a value of the HELLO message time and incremented by 1 every time a value of the HELLO message
is modified. is modified.
res (3 bits): Reserved/unused field, MUST be zero. res (3 bits): Reserved/unused field, MUST be zero.
F (1 bit): bit indicating the type of feed: F (1 bit): bit indicating the type of feed:
0 = Send-only feed 0 = Send-only feed
1 = Receive-capable feed 1 = Receive-capable feed
IP Vers (4 bits): IP protocol version of the feed bidirectional IP IP Vers (4 bits): IP protocol version of the feed bidirectional IP
addresses (FBIP): addresses (FBIP):
4 = IP version 4 4 = IP version 4
6 = IP version 6 6 = IP version 6
Tunnel Type (8 bits): tunneling protocol supported by feed, Tunnel Type (8 bits): tunneling protocol supported by feed,
correponds to the type of encapsulation used by receivers to corresponds to the type of encapsulation used by receivers to
encapsulate packets which are tunneled: encapsulate packets which are tunneled:
47 = GRE [rfc1701] (recommended) 47 = GRE [rfc1701] (recommended)
x = any other tunneling supporting the UDL MAC packets. x = any other tunneling supporting the UDL MAC packets.
Nb of FBIP (8 bits): Number of bidirectional IP feed addresses which Nb of FBIP (8 bits): Number of bidirectional IP feed addresses which
are enumerated in the HELLO message are enumerated in the HELLO message
reserved (8 bits): Reserved/unused field, MUST be zero. reserved (8 bits): Reserved/unused field, MUST be zero.
Feed UDL IP addr: 32 or 128 bit field. The value is the IP address of Feed BDL IP addr: 32 or 128 bit field. The feed bidirectional IP
the feed interface connected to the unidirectional link which sends address is the IP address of a feed bidirectional interface (tunnel
the HELLO packet.
Feed BDL IP addr: 32 or 128 bit field. The bidirectional IP address
feed is the IP address of a feed bidirectional interface (tunnel
end-point) reachable via the Internet. A feed has 'Nb of FBIP' IP end-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 prefered order. FBIP1 being the most suitable tunnel enumerated in preferred order. FBIP1 being the most suitable tunnel
end-point. end-point.
6.3.2. DTCP on the feed: sending HELLO packets 6.3.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.
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. the feed interface connected to the unidirectional link. In the rest
of the document, this value is called FUIP (Feed Unidirectional IP
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 6.3.1. the datagram according to the description given in Section 6.3.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
presence to receivers. It MUST send HELLO packets containing a JOIN presence to receivers. It MUST send HELLO packets containing a JOIN
command every HELLO_INTERVAL over the unidirectional link. command every HELLO_INTERVAL over the unidirectional link.
Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO
messages with the FUIP field set to f1u (resp. f2u) and the FBIP1 messages with the FBIP1 field set to f1b (resp. f2b).
field set to f1b (resp. f2b).
When a feed is about to be shut down, or when routing over the When a feed is about to be shut down, or when routing over the
unidirectional link is about to be intentionally interrupted, it is unidirectional link is about to be intentionally interrupted, it is
recommended to: recommended to:
1) stop sending HELLO messages containing a JOIN command. 1) stop sending HELLO messages containing a JOIN command.
2) send a HELLO message containing a LEAVE command to inform 2) send a HELLO message containing a LEAVE command to inform
receivers that the feed is no longer performing routing over the receivers that the feed is no longer performing routing over the
unidirectional link. unidirectional link.
skipping to change at page 12, line 51 skipping to change at page 12, line 48
When a receiver is started, it MUST run a process which joins the When a receiver is started, it MUST run a process which joins the
"DTCP announcement" multicast group and listens to incoming packets "DTCP announcement" multicast group and listens to incoming packets
on the HELLO_PORT port from the unidirectional link. on the HELLO_PORT port from the unidirectional link.
Upon the reception of a HELLO message, the process checks the version Upon the reception of a HELLO message, the process checks the version
number of the protocol. If it is different from HELLO_VERSION, the number of the protocol. If it is different from HELLO_VERSION, the
packet is discarded and the process waits for the next incoming packet is discarded and the process waits for the next incoming
packet. packet.
After successfully checking the version number it is recommended to After successfully checking the version number, further action
check that the FUIP contained in the packet is the same as the source depends on the type of command:
address of the HELLO packet. Further action depends on the type of
command:
- JOIN: - JOIN:
The process verifies if the address FUIP contained in the HELLO The process verifies if the address FUIP already belongs to the
packet already belongs to the list of active feeds. list of active feeds.
If it does not, the entry (FUIP,FBIP1,...,FBIPn) is added to the If it does not, the entry (FUIP,FBIP1,...,FBIPn) is added to the
list of active feeds. The number of feed bidirectional IP list of active feeds. The number of feed bidirectional IP
addresses to read is deduced from the 'Nb of FBID' field. The addresses to read is deduced from the 'Nb of FBID' field. The
tunnel type is also read and recorded for this FUIP. A timer set tunnel type is also read and recorded for this FUIP. A timer set
to HELLO_LEAVE is associated with this entry. to HELLO_LEAVE is associated with this entry.
If it does, the sequence number is compared to the sequence number If it does, the sequence number is compared to the sequence number
contained in the previous HELLO packet sent by this feed. If it is contained in the previous HELLO packet sent by this feed. If it is
equal the timer associated with this entry is reset to equal the timer associated with this entry is reset to
HELLO_LEAVE. Otherwise all the information corresponding to FUIP HELLO_LEAVE. Otherwise all the information corresponding to FUIP
is reset. is reset.
Referring to Figure 1 in Section 3, both receivers (recv 1 and Referring to Figure 1 in Section 3, both receivers (recv 1 and
recv 2) have a list of active feeds containing two entries which recv 2) have a list of active feeds containing two entries which
are (f1u,(f1b)) and (f2u,(f2b)). are (f1u,(f1b)) and (f2u,(f2b)).
- LEAVE: - LEAVE:
The process checks if there is an entry with the value FUIP The process checks if there is an entry with the value FUIP that
contained in the HELLO packet that belongs to the list of active belongs to the list of active feeds. If it does, the entry
feeds. If it does, the entry (FUIP,FBIP1,...,FBIPn) is deleted (FUIP,FBIP1,...,FBIPn) is deleted from the list and the
from the list and the corresponding timer is disabled. The LEAVE corresponding timer is disabled. The LEAVE message provides a
message provides a means of quickly updating the list of active means of quickly updating the list of active feeds.
feeds.
A timeout occure for two reasons: A timeout occurs for two reasons:
1) a feed went down without sending a LEAVE message. As JOIN 1) a feed went down without sending a LEAVE message. As JOIN
messages are no longer sent from this feed, a timeout occures at messages are no longer sent from this feed, a timeout occurs at
HELLO_LEAVE after the last JOIN message. HELLO_LEAVE after the last JOIN message.
2) the unidirectional link is down. Thus, no more JOIN messages are 2) the unidirectional link is down. Thus, no more JOIN messages are
received from the feeds. All the timeouts associated with received from the feeds. All the timeouts associated with
entries (FUIP,FBIP1,...,FBIPn) expire at HELLO_LEAVE after the entries (FUIP,FBIP1,...,FBIPn) expire at HELLO_LEAVE after the
last JOIN message from the unidirectional link. last JOIN message from the unidirectional link.
In both cases, the associated (FUIP,FBIP1,...,FBIPn) entries are In both cases, the associated (FUIP,FBIP1,...,FBIPn) entries are
removed from the list of active feeds. As either the feed does not removed from the list of active feeds. As either the feed does not
route datagrams over the unidirectional link or the link is down, route datagrams over the unidirectional link or the link is down,
skipping to change at page 14, line 19 skipping to change at page 14, line 13
section, we describe how to integrate the HELLO protocol into the section, we describe how to integrate the HELLO protocol into the
tunneling mechanism described in Sections 6.1 and 6.2. tunneling mechanism described in Sections 6.1 and 6.2.
6.3.4. Tunneling mechanism using the list of active feeds 6.3.4. Tunneling mechanism using the list of active feeds
This section explains how the tunneling mechanism uses the list of This section explains how the tunneling mechanism uses the list of
active feeds to handle datagrams which are to be tunneled. Referring active feeds to handle datagrams which are to be tunneled. Referring
to Section 6.1, it shows how feed tunnel end-points are selected. to Section 6.1, it shows how feed tunnel end-points are selected.
The choice of the default feed is done by the receiver administrator The choice of the default feed is done by the receiver administrator
according to a local policy. This policy is out of scope of this according to a local policy. This policy is out of scope of in this
document. document. However, as an example, the default feed may be the feed
that has the lowest round trip time to the receiver.
When a receiver sends a packet to a feed it chooses the tunnel end-
point within the FBIP list. The 'preferred FBIP' is generally FBIP1
(see 6.3.1). However, for some reasons, a receiver may have a better
connectivity to another FBIPi of this feed. In that case, it is
possible to use FBIPi instead of FBIP1 as tunnel end-point. This
decision is taken by the receiver administrator.
Several cases are enumerated in Section 6.1 to determine where to Several cases are enumerated in Section 6.1 to determine where to
forward an IP datagram according to the next hop address. If the next forward a MAC packet according to its destination address. If the
hop address is: destination address is:
1) the IP address of a feed interface connected to the 1) the MAC address of a feed interface connected to the
unidirectional link: this is TRUE if the address matches with an unidirectional link: this is TRUE if the address matches with
FUIP in the list of active feeds. The datagram is encapsulated the MAC address of an FUIP in the list of active feeds. The
and sent to the corresponding FBIP1. The encapsulation type datagram is encapsulated and sent the preferred FBIP of the
depends on the tunnel type required by the feed FUIP. feed. The encapsulation type depends on the tunnel type required
by the feed FUIP.
2) the broadcast address of the unidirectional link or a multicast 2) the broadcast address of the unidirectional link or a multicast
address: a copy of the datagram is encapsulated and sent to the address: a copy of the datagram is encapsulated and sent to the
default feed if it belongs to the list of active feeds. preferred FBIP of the default feed. The encapsulation type
Otherwise the packet is discarded. The encapsulation type
depends on the tunnel type required by the default feed. depends on the tunnel type required by the default feed.
3) an address that belongs to the unidirectional network but is not 3) an address that belongs to the unidirectional network but is not
a feed address (i.e., it does not match any FUIP in the list of a feed address (i.e., it does not match a MAC address of any
active feeds): the datagram is encapsulated and sent to the FUIP in the list of active feeds): the datagram is encapsulated
default feed if it belongs to the list of active feeds. and sent to the preferred FBIP of the default feed. The
Otherwise the packet is discarded. The encapsulation type encapsulation type depends on the tunnel type required by the
depends on the tunnel type required by the default feed. default feed.
6.3.5. Constant definitions 6.3.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.1.124.
HELLO_PORT is 652. It is a reserved system port, no other traffic HELLO_PORT is 652. It is a reserved system port, no other traffic
skipping to change at page 15, line 33 skipping to change at page 15, line 35
broadcast MAC packets over the unidirectional link via its tunnels. broadcast MAC packets over the unidirectional link via its tunnels.
The encapsulation process should encapsulate link layer level The encapsulation process should encapsulate link layer level
packets. As a result, after decapsulating an incoming packet, the packets. As a result, after decapsulating an incoming packet, the
feed can perform link layer filtering as if data was directly coming feed can perform link layer filtering as if data was directly coming
from the unidirectional link (See Figure 2). from the unidirectional link (See Figure 2).
The Generic Routing Encapsulation (GRE) [rfc1701] suits our The Generic Routing Encapsulation (GRE) [rfc1701] suits our
requirements because it specifies a protocol for encapsulating requirements because it specifies a protocol for encapsulating
arbitrary packets within IP as the delivery protocol. Alternatively, arbitrary packets within IP as the delivery protocol. Alternatively,
we can also encapsulate directly a MAC level packet within an IP we can also encapsulate directly a MAC level packet within an IP
datagram. Other encapsultion mechanisms can be chosen. datagram.
It is the feed's local administrator who decides what encapsulation It is the feed's local administrator who decides what encapsulation
is used by a receiver to send a packet via a tunnel to this feed. The is used by a receiver to send a packet via a tunnel to this feed. The
tunnel type field in the HELLO message is either set to GRE or to any tunnel type field in the HELLO message is either set to GRE or to any
other encapsulaton supporting UDL MAC level packets. other encapsulation supporting UDL MAC level packets.
7.1. Generic Routing Encapsultation on the receiver 7.1. Generic Routing Encapsulation on the receiver
A GRE packet is composed of a header in which a type field specifies A GRE packet is composed of a header in which a type field specifies
the encapsulated protocol (ARP, IP, IPX, etc.). See the encapsulated protocol (ARP, IP, IPX, etc.). See
[rfc1701][rfc1702] for details about the encapsulation. In our case, [rfc1701][rfc1702] for details about the encapsulation. In our case,
only the support of the MAC addressing scheme of the unidirectional only the support of the MAC addressing scheme of the unidirectional
link MUST be implemented. link MUST be implemented.
A packet tunneled with a GRE encapsulation has the following format: A packet tunneled with a GRE encapsulation has the following format:
the delivery header is an IP header whose destination is the tunnel the delivery header is an IP header whose destination is the tunnel
end-point (FBIP), followed by a GRE header specifying the link layer end-point (FBIP), followed by a GRE header specifying the link layer
type of the unidirectional link. Figure 4 presents the entire type of the unidirectional link. Figure 4 presents the entire
encapsulated packet. encapsulated packet.
---------------------------------------- ----------------------------------------
| IP delivery header | | IP delivery header |
| destination addr = FBIP | | destination addr = FBIP |
| IP proto = GRE (47) | | IP proto = GRE (47) |
---------------------------------------- ----------------------------------------
skipping to change at page 16, line 23 skipping to change at page 16, line 26
| type = MAC level of the UDL | | type = MAC level of the UDL |
---------------------------------------- ----------------------------------------
| Payload packet | | Payload packet |
| MAC packet | | MAC packet |
---------------------------------------- ----------------------------------------
Figure 4: Encapsulated packet Figure 4: Encapsulated packet
7.2. Encapsulation of UDL MAC level packets 7.2. Encapsulation of UDL MAC level packets
An alternative is to encapsultate the MAC level packet within IP. The An alternative is to encapsulate the MAC level packet within IP. The
protocol field in the IP datagram is then set to the MAC level type protocol field in the IP datagram is then set to the MAC level type
of the unidirectional link. Figure 5 presents the entire encapsulated of the unidirectional link. Figure 5 presents the entire encapsulated
packet. packet.
---------------------------------------- ----------------------------------------
| IP delivery header | | IP delivery header |
| destination addr = FBIP | | destination addr = FBIP |
| IP proto = MAC level of the UDL | | IP proto = MAC level of the UDL |
---------------------------------------- ----------------------------------------
| Payload packet | | Payload packet |
skipping to change at page 18, line 14 skipping to change at page 18, line 16
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. Security Considerations 9. Security Considerations
Receivers send packets through tunnels to feeds. Because of Receivers send packets through tunnels to feeds. Because of
scalability reasons, there is no specific mechanism in this document 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 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 malicious individual that gains access to the unidirectional link can
get full connectivity to feeds. Therefore it is higly recommended on get full connectivity to feeds. Therefore it is highly recommended on
the feed site to have some firewall capabilities. the feed site to have some firewall capabilities.
10. Acknowledgments 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).
11. References 11. 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
University, August 1989
[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.
[rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998
 End of changes. 46 change blocks. 
87 lines changed or deleted 95 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/