rfc3077.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/4 页
TXT
1,404 行
the IP address of a feed bidirectional interface (f1b or f2b). This
destination address is also called the tunnel end-point. The
mechanism for a receiver to learn these addresses and to choose the
feed is explained in Section 7. The type of encapsulation is
described in Section 8.
In all cases the packet is encapsulated, but the tunnel end-point (an
IP address) depends on the encapsulated packet's destination MAC
address. If the destination MAC address is:
1) the MAC address of a feed interface connected to the
unidirectional link (Scenario 1). The datagram is
encapsulated, the destination address of the encapsulating
datagram is the feed tunnel end-point (f1b referring to Figure
2).
2) a MAC broadcast/multicast address (Scenario 2). The datagram
is encapsulated, the destination address of the encapsulating
datagram is the default feed tunnel end-point. See Section 7.4
for further details on the default feed.
3) a MAC address that belongs to the unidirectional network but is
not a feed address (Scenario 3). The datagram is encapsulated,
the destination address of the encapsulating datagram is the
default feed tunnel end-point.
The encapsulated datagram is passed to the network layer which
forwards it according to its destination address. The destination
address is a feed bidirectional interface which is reachable via the
Internet. In this case, the encapsulated datagram is forwarded via
the receiver bidirectional interface (r1b).
6.2. Tunneling mechanism on the feed
A feed processes unidirectional link related packets in two different
ways:
Duros, et al. Standards Track [Page 7]
RFC 3077 LL Tunneling Mechanism for UDLs March 2001
- packets generated by a local application or packets routed as
usual by the IP layer may have to be forwarded over the
unidirectional link (Section 6.2.1)
- encapsulated packets received from another receiver or feed need
tunnel processing (Section 6.2.2).
A feed cannot directly send a packet to a send-only feed over the
unidirectional link (Scenario 4). In order to emulate this type of
communication, feeds have to tunnel packets to send-only feeds. A
feed MUST maintain a list of all other feed tunnel end-points. This
list MUST indicate which are send-only feed tunnel end-points. This
is configured manually at the feed by the local administrator, as
described in Section 7.
6.2.1. Forwarding packets over the unidirectional link
When a datagram is delivered to the link-layer of the unidirectional
interface of a feed for transmission, its treatment depends on the
packet's destination MAC address. If the destination MAC address 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 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. The type of encapsulation is described in Section 8.
3) a broadcast/multicast destination (Scenario 5). The packet is
sent over the unidirectional link. Concurrently, a copy of
this packet is encapsulated and sent to every feed of the list
of send-only feed tunnel end-points. Thus the
broadcast/multicast will reach all receivers and all send-only
feeds.
6.2.2. Receiving encapsulated packets
Feeds listen for incoming encapsulated datagrams on their tunnel
end-points. Encapsulated packets will have been received on a
bidirectional interface, and traversed their way up the IP stack.
They will then enter a decapsulation process (See Figure 2).
Decapsulation reveals the original link-layer packet. Note that this
has not been modified in any way by intermediate routers; in
particular, the original MAC header will be intact.
Duros, et al. Standards Track [Page 8]
RFC 3077 LL Tunneling Mechanism for UDLs March 2001
Further actions depend on the destination MAC address of the link-
layer packet, which can be:
1) the MAC address of the feed interface connected to the
unidirectional link, i.e., own MAC address (Scenarios 1 and 4).
The packet is passed to the link-layer of the interface
connected to the unidirectional link which can then deliver it
up to higher layers. As a result, the datagram is processed as
if it was coming from the unidirectional link, and being
delivered locally. Scenarios 1 and 4 are now feasible, a
receiver or a feed can send a packet to a feed.
2) a receiver address (Scenario 3). The packet is passed to the
link-layer of the interface connected to the unidirectional
link. It is directly sent over the unidirectional link, to the
indicated receiver. Note, the packet must not be delivered
locally. Scenario 3 is now feasible, a receiver can send a
packet to another receiver.
3) a broadcast/multicast address, this corresponds to Scenarios 2
and 5. We have to distinguish two cases, either (i) the
encapsulated packet was sent from a receiver or (ii) from a
feed (encapsulated broadcast/multicast packet sent to a send-
only feed). These cases are distinguished by examining the
source address of the encapsulating packet and comparing it
with the configured list of feed IP addresses. The action then
taken is:
i) the feed was designated as a default feed by a receiver to
forward the broadcast/multicast packet. The feed is then in
charge of sending the multicast packet to all nodes.
Delivery to all nodes is accomplished by executing all 3 of
the following actions:
- The packet is encapsulated and sent to the list of send-
only feed tunnel end-points.
- Also, the packet is passed to the link-layer of the
interface which forwards it directly over the
unidirectional link (all receivers and receive capable
feeds receive it).
- Also, the link-layer delivers it locally to higher
layers.
Caution: a receiver which sends an encapsulated
broadcast/multicast packet to a default feed will receive
its own packet via the unidirectional link. Correct
filtering as described in [RFC1112] must be applied.
Duros, et al. Standards Track [Page 9]
RFC 3077 LL Tunneling Mechanism for UDLs March 2001
ii) the feed receives the packet and keeps it for local
delivery. The packet is passed to the link-layer of the
interface connected to the unidirectional link which
delivers it to higher layers.
Scenario 2 is now feasible, a receiver can send a
broadcast/multicast packet over the unidirectional link and it
will be heard by all nodes.
7. Dynamic Tunnel Configuration Protocol (DTCP)
Receivers and feeds have to know the feed tunnel end-points in order
to forward encapsulated datagrams (e.g., Scenarios 1 and 4).
The number of feeds is expected to be relatively small (Section 3),
so at every feed the list of all feeds is configured manually. This
list should note which are send-only feeds, and which are receive
capable feeds. The administrator sets up tunnels to all send-only
feeds. A tunnel end-point is an IP address of a bidirectional link
on a send-only feed.
For scalability reasons, manual configuration cannot be done at the
receivers. Tunnels must be configured and maintained dynamically by
receivers, both for scalability, and in order to cope with the
following events:
1) New feed detection.
When a new feed comes up, every receiver must create a tunnel
to enable bidirectional communication with it.
2) Loss of unidirectional link detection.
When the unidirectional link is down, receivers must disable
their tunnels. The tunneling mechanism emulates bidirectional
connectivity between nodes. Therefore, if the unidirectional
link is down, a feed should not receive datagrams from the
receivers. Protocols that consider a link as operational if
they receive datagrams from it (e.g., the RIP protocol
[RFC2453]) require this behavior for correct operation.
3) Loss of feed detection.
When a feed is down, receivers must disable their corresponding
tunnel. This prevents unnecessary datagrams from being
tunneled which might overload the Internet. For instance,
there is no need for receivers to forward a broadcast message
through a tunnel whose end-point is down.
Duros, et al. Standards Track [Page 10]
RFC 3077 LL Tunneling Mechanism for UDLs March 2001
The DTCP protocol provides a means for receivers to dynamically
discover the presence of feeds and to maintain a list of operational
tunnel end-points. Feeds periodically announce their tunnel end-
point addresses over the unidirectional link. Receivers listen to
these announcements and maintain a list of tunnel end-points.
7.1. The HELLO message
The DTCP protocol is a 'unidirectional protocol', messages are only
sent from feeds to receivers.
The packet format is shown in Figure 3. Fields contain binary
integers, in normal Internet order with the most significant bit
first. Each tick mark represents one bit.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Com | Interval | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed BDL IP addr (FBIP1) (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feed BDL IP addr (FBIPn) (32/128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet Format
Every datagram contains the following fields, note that constants are
written in uppercase and are defined in Section 7.5:
Vers (4 bit unsigned integer): DTCP version number. MUST be
DTCP_VERSION.
Com (4 bit unsigned integer): Command field, possible values are
1 - JOIN A message announcing that the feed sending this message
is up and running.
2 - LEAVE A message announcing that the feed sending this message
is being shut down.
Interval (8 bit unsigned integer): Interval in seconds between HELLO
messages for the IP protocol in "IP Vers". Must be > 0. The
recommended value is HELLO_INTERVAL. If this value is increased,
the feed MUST continue to send HELLO messages at the old rate for
at least the old HELLO_LEAVE period.
Duros, et al. Standards Track [Page 11]
RFC 3077 LL Tunneling Mechanism for UDLs March 2001
Sequence (16 bit unsigned integer): Random value initialized at boot
time and incremented by 1 every time a value of the HELLO message
is modified.
res (3 bits): Reserved/unused field, MUST be zero.
F (1 bit): bit indicating the type of feed:
0 = Send-only feed
1 = Receive-capable feed
IP Vers (4 bit unsigned integer): IP protocol version of the feed
bidirectional IP addresses (FBIP):
4 = IP version 4
6 = IP version 6
Tunnel Type (8 bit unsigned integer): tunneling protocol supported by
the feed. This value is the IP protocol number defined in
[RFC1700] [iana/protocol-numbers] and their legitimate
descendents. Receivers MUST use this form of tunnel encapsulation
when tunneling to the feed.
47 = GRE [RFC2784] (recommended)
Other protocol types allowing link-layer encapsulation are
permitted. Obtaining new values is documented in [RFC2780].
Nb of FBIP (8 bit unsigned integer): Number of bidirectional IP feed
addresses which are enumerated in the HELLO message
reserved (8 bits): Reserved/unused field, MUST be zero.
Feed BDL IP addr (32 or 128 bits). 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
addresses which are operational tunnel end-points. They are
enumerated in preferred order. FBIP1 being the most suitable
tunnel end-point.
7.2. DTCP on the feed: sending HELLO packets
The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP
announcement" multicast address over the unidirectional link on port
HELLO_PORT with a TTL of 1. Due to existing deployments a feed
SHOULD also support the use of the old DTCP announcement address, as
described in Appendix B.
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
of the document, this value is called FUIP (Feed Unidirectional IP
address).
Duros, et al. Standards Track [Page 12]
RFC 3077 LL Tunneling Mechanism for UDLs March 2001
The process in charge of sending HELLO packets fills every field of
the datagram according to the description given in Section 7.1.
As long as a feed is up and running, it periodically announces its
presence to receivers. It MUST send HELLO packets containing a JOIN
command every HELLO_INTERVAL over the unidirectional link.
Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO
messages with the FBIP1 field set to f1b (resp. f2b).
When a feed is about to be shut down, or when routing over the
unidirectional link is about to be intentionally interrupted, it is
recommended that feeds:
1) stop sending HELLO messages containing a JOIN command.
2) send a HELLO message containing a LEAVE command to inform
receivers that the feed is no longer performing routing over
the unidirectional link.
7.3. DTCP on the receiver: receiving HELLO packets
Based on the reception of HELLO messages, receivers discover the
presence of feeds, maintain a list of active feeds, and keep track of
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?