Network Working Group For list of authors
Internet-Draft See Authors' section
July 2003 Expires december 2003
Experiments with RFC 3077
<draft-ietf-udlr-experiments-01.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groupsmay also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
In March 2001, [RFC 3077] was published and describes a protocol
which allows to integrate unidirectional links in the Internet. Since
then, a number of experimentations and deployements using this
protocol have been led. This document presents various protocols,
e.g. layer 2 and layer 3 protocols, which have been commonly used
over [RFC 3077] in a satellite environment. This document raises
issues for each of these protocols.
Table of Contents
1. Characteristics of Uni-Directional Links .................... X
1.1. Characteristics of UDLR networks ............................ X
1.1.1. Asymmetric routing paths .................................. X
1.1.3. Forward link capacity ..................................... X
Authors [Page 1]
Internet Draft Experiments with RFC 3077 July 2003
1.1.3. Asymmetric link capacity .................................. X
1.1.4. Asymmetric loss environment ............................... X
1.1.5. Flat networks ............................................. X
1.1.6. Subnetwork round trip delay ............................... X
2. Description of Network Architecture ......................... X
2.1. Topology .................................................... X
2.2. Multicast Forwarding over UDLR .............................. X
3.0. Layer 2 Protocols ........................................... X
3.1. Hardware Address Resolution ................................. X
3.1.1 Hardware Address Resolution protocol over UDLR ............. X
3.1.2 Issues using a hardware resolution protocol over UDLR ...... X
3.1.2.1 Long round trip delays ................................... X
3.1.2.2 Large number of receivers ................................ X
3.2. PPPoE ....................................................... X
3.2.1 Introduction ............................................... X
3.2.2 Architecture ............................................... X
3.2.2.1 Specificities ............................................ X
3.2.2.2 Description of a connection .............................. X
3.2.3 Advantages ................................................. X
3.2.4 Limitations ................................................ X
3.2.5 Security Issues ............................................ X
4.0. Layer 3 Protocols ........................................... X
4.1. Dynamic Host Configuration Protocol ......................... X
4.1.1. DHCP Overview ............................................. X
4.1.2. DHCP over UDLR ............................................ X
4.1.2.1. Configuration and tuning guidelines ..................... X
4.1.2.2. Security issues ......................................... X
4.2. Issues using IGMP over UDLR ................................. X
4.2.1. Basic IGMP Operation ...................................... X
4.2.2. IGMPv2 Leave Processing ................................... X
4.2.3. IGMPv3 Operation .......................................... X
4.2.4. Forwarding Groups at the Receiver based on IGMP ........... X
4.3. IGMP-Proxy .................................................. X
4.4. Dense Mode Multicast Routing ................................ X
4.4.1. DVMRP ..................................................... X
4.4.2. Dense Mode PIM (PIM-DM) ................................... X
4.5. Sparse Mode Multicast Routing ............................... X
4.5.1. Sparse Mode PIM (PIM-SM) .................................. X
4.5.2. PIM-SM RPs and MSDP ....................................... X
5. Security Considerations ..................................... X
6. Conclusions ................................................. X
7. Acknowledgements ............................................ X
8. References .................................................. X
8.1. Normative References ........................................ X
8.2. Informative References ...................................... X
9. Authors' Addresses .......................................... X
10. Full Copyright Statement .................................... X
11. IANA Considerations ......................................... X
Authors [Page 2]
Internet Draft Experiments with RFC 3077 July 2003
1. Characteristics of Uni-Directional Links
This document describes issues that concern use of UDLR networks
[RFC3077] to support the IP multicast service. In this document it is
assumed that the feed router is a multicast router [RFC1122].
The format of an IPv4 multicast packet [RFC 1112] is identical to
that of an IPv4 unicast packet and is distinguished only by a special
class of destination address (class D, i.e., addresses in the range
from 224.0.0.0 to 239.255.255.255).
There are five distinct multicast scenarios. The issues that arise
and the approaches to be recommended will be a function of these
scenarios. The list of scenarios to be addresses is:
Scenario A. An edge-network, where end hosts receive a multicast
service from an upstream router via the Feed Router. Multicast
forwarding is controlled via a group memberhip protocol (e.g. IGMP
[RFC2236]). Each end host is directly via a UDLR feed link.
Scenario B. A bridged edge-network, where one or more end hosts
receive a multicast service via a common LAN connection to a UDLR
Receiver. Multicast forwarding is controlled via a group memberhip
protocol (e.g. IGMP [RFC2236]). The UDLR Receiver is connected to the
upstream Feed Router via a UDLR tunnel.
Scenario C. A bridged-network supporting multicast routers, where
one or more multicast routers receive a multicast service provided
via a common LAN connection to a UDLR Receiver. Multicast forewarding
is controlled by a Layer 3 Multicast Routing Protocol (e.g. PIM-SM
[DRAFT-PIM-SM-NEW]). The UDLR Receiver is connected to an upstream
router via a UDLR tunnel.
Scenario D. A multicast routed-network, where the UDLR Receiver acts
as a multicast router. This receives a multicast service provided
from the upstream Feed Router. Multicast forewarding is controlled by
a Layer 3 Multicast Routing Protocol, (e.g. PIM-SM [DRAFT-PIM-SM-
NEW]).
Scenario E. An inter-domain multicast network, in which two or more
separate multicast domains are connected using the UDLR network. The
complexity of this scenario increases with the need to support other
protocols (e.g. MBGP, MSDP).
A simple network may have only one of these scenarios, but more
complex networks may have a combination.
1.1 Characteristics of UDLR networks
Authors [Page 3]
Internet Draft Experiments with RFC 3077 July 2003
UDLR subnetworks present characteristics which differ significantly
from those experienced in the general Internet. These characteristics
lead to specific problems and raise specific issues that need to be
addressed to deploy an IP multicast service. This section identifies
specific characteristics that impact multicast performance resulting
from the asymmetry and the types of network over which the UDLR is
commonly implemented. These are:
1.1.1 Asymmetric routing paths
Unidirectional links give rise to differing forward (feed) and return
(tunnel) paths. Multicast routing protocols that use the "reverse
shortest path tree" towards the source as a part of their forwarding
decision (e.g. DVMRP, PIM-SM [DRAFT-PIM-SM-NEW], PIM-DM) will not
work correctly over asymmetric routing paths. Solutions include the
use of UDLR [RFC 3077] and the use incongruent MBGP routing.
1.1.2 Asymmetric multicast capability
Asymmetric multicast capability is not a fundamental feature of UDLR.
In some UDLR networks both forward (feed) and return paths may
support native IP multicast. In other UDLR networks, a case may
arise where the forward link supports native multicast, whereas
return link may supports only unicast. UDLR routing allows a non-
broadcast/multicast link to be used for the return path by employing
a tunnel in the return direction [RFC2784].
1.1.3 Forward link capacity
Since many UDLR networks employ wireless technology for the forward
(feed) link (e.g., [EN00]), there may be an appreciable cost for
forwarding traffic on the feed link. This leads to a desire to
prevent forwarding unnecessary multicast traffic, this implies the
need to control which groups are forwarded. However, other factors,
(e.g., asymmetric links, and asymmetric loss environment), may
suggest a desire to minimise the volume and frequency of control
messages in the return direction.
1.1.3 Asymmetric link capacity
The capacity of the forward (feed) and return (tunnel) paths may
differ significantly (e.g., forward link using DVB-S [EN00], return
using a GRE tunnel over a dial-up modem or ISDN interface for the
return path). The high normalised bandwidth ratio can lead to a
performance bottleneck, in addition the "cost" of setting up and
maintaining capacity in the reverse direction may be significantly
greater than in the forward direction [DRAFT-PILC-ASYM]. Although a
Authors [Page 4]
Internet Draft Experiments with RFC 3077 July 2003
class of multicast applications do not require a return path for
their transport protocol (e.g. unidirectional transmission of
multimedia using RTP [DRAFT-AVT-RTP-NEW]), a path may still be
required for other supporting protocols (e.g. DNS, IGMP , Multicast
Routing). The cost of establishing and maintaining a return path for
these applications may be appreciable, especially considering its
minimal use.
1.1.4 Asymmetric loss environment
UDLR does not by itself introduce an imbalance in the packet loss
rate between the transmit and receive paths, however different link
technologies are often used to implement the forward (feed) and
return (tunnel) links of UDLR networks. In some important cases this
can lead to a significantly higher probability of packet loss in the
return direction [DRAFT-PILC-ASYM].
1.1.5 Flat networks
The link technologies that are often used to implement the UDLR
feed link may support a multicast/broadcast capability that permits a
very large number of directly connected downstream receivers. For
example, a single satellite down-link may support 1tens of thousands
of UDLR Receivers. The numbers of Receivers connected via the same
physical link may be much larger than found in other common LAN
technologies, (e.g. Ethernet). Current routing protocols, and some
multicast application protocols do not scale to arbitrary large
numbers of participants.
1.1.6 Subnetwork round trip delay
UDLR does not by itself introduce an appreciable subnetwork round
trip delay, however many practical UDLR networks are built using
links that may introduce significant path delay (e.g. satellite
links). Since the subnetwork round trip delay impacts the performance
of the protocols that support the multicast service, the impact of
this delay needs to be considered.
2. Description of the Network Architecture
2.1 Topology
The UDLR protocol can be used over various types of unidirectional
links. Among these links we can list the DVB-S [EN00], DVB-T [], DAB
[] links and some cable modems technologies which are
unidirectionals. So far, the UDLR protocol has been mainly used in a
satellite environment (DVB-S) whose technology seems speader than the
Authors [Page 5]
Internet Draft Experiments with RFC 3077 July 2003
others.
In this document we focus on the use of UDLR in a satellite
environment since most experiments have been performed with this
technology. A send-only feed is connected to the global Internet with
a bidirectional interface (e.g. Ethernet). It is also connected to
the unidirectional link with a send-only interface. There is no
receive-capable feed in the architecture.
A set of receivers is connected to the unidirectional link with a
receive-only interface. They all have a bidirectional interface (e.g.
Ethernet or ppp) connected to the Internet. The receivers can reach
the feed bidirectional interface through the Internet.
All the nodes connected to the unidirectional link, i.e. the feed and
the receivers, implement UDLR. As a result, every node can send a
unicast, a multicast or a broadcast layer-two frame over the
unidirectional link. A node can reach any other node as if they were
connected to a bidirectional broadcast network. In other words, nodes
are connected in a similar way to an Ethernet local area network.
Figure 1 depicts this architecture with a single feed and several
receivers:
Satellite
~~~~ ---- ~~~~
/ /-| OO |-/ /
~~~ ---- ~~~
_/ \ \
_/ \ \
_/ \ \ Unidirectional
_/ \ \ Link
_/ \ \
_/ \ \
/ \ \
| | |
-------- -------- -------- ----------
| Feed | |Recv 1| |Recv 2|---|subnet A|
-------- -------- -------- ----------
| | | |
| | | |
----------------------------------------------------
| Internet |
----------------------------------------------------
Figure 1: Typical UDLR topology
Authors [Page 6]
Internet Draft Experiments with RFC 3077 July 2003
Recv 1 is host, e.g., the end-user work station integrating a
satellite reception card. The host may have an ISDN or RTC connection
for a terrestrial Internet provided by a local ISP.
Recv 2 is a routeur connected to a local area network (Subnet A).
Other routeurs may be connected to the subnet and exchange routing
informations with Recv 2. Recv 2 may have an ISDN or RTC connection
for a terrestrial Internet provided by a local ISP.
The examples of terrestrial connecvities for a host or a router are
non-exhaustives, they may also use other technologies such as
Ethernet or GSM, etc.
The UDLR protocol supports the case where several feeds are connected
to a satellite. This case is not described in the document because
not as many experiments as with a single feed, have been performed.
2.2 Multicast Forwarding over UDLR
A UDLR Feed Router connected to an upstream multicast router MAY
choose to forward all received IP multicast packets on all forward
feeds, or MAY alternatively use a group management or routing
protocol to determine the set of multicast groups that must be
forwarded for each forward feed.
MUST forward all IPv4 packets with an address 224.0.0.0/24 [RFC
1122]. It MAY also forward all other packets with other multicast
addresses (224.0.0.0/4) [RFC 3171], but SHOULD use group membership
information to avoid forwarding packets belonging to groups for which
there are no downstream members connected via UDLR receiver(s) (see
section 4.2). In some cases, this forwarding will be controlled using
MAC address filters. Since a number of IPv4 multicast addresses are
often mapped to a common MAC address, address overlap may occur (e.g.
[RFC1122]). In this cases a Feed Router may determine the set of IP
multicast addresses in use, and hence the corresponding set of MAC
address and then choose to forward all IP groups that map to this set
of MAC addresses.
This is normal IP multicast routing behaviour.
The rules for forwarding those multicast packets received by the Feed
Router differ when the packets are received via the feed tunnel end-
point [RFC3077]. In this case, the Feed Router MUST forward all
multicast packets to the interfaces associated with:
(i) the list of send-only feed tunnel end-points
(ii) the forward feeds
(iii) the upper layer protocols of a multicast enabled Feed
Authors [Page 7]
Internet Draft Experiments with RFC 3077 July 2003
Router (i.e., for possible forwarding to upstream multicast
router(s)).
In cases (ii) and (iii) the multicast forwarding does not include the
normal Reverse Path Forwarding (RPF) check, the normal processing of
the Time To Live (TTL) field, or the normal processing of
administratively scoped multicast addresses.
In addition, a UDLR Receiver MUST must perform normal multicast
forwarding of IP multicast packets received on the forward feed
interface, but MUST NOT forward any packets that were originated by
the same Receiver (i.e., were previously sent via the return
direction tunnel). This later requirement is equivalent to an RPF
check. Multicast packets received by the node on other (i.e., non-
feed) interfaces MUST be forwarded to the Feed Router using the
return tunnel interface.
3.0 Layer 2 Protocols
3.1 Hardware Address Resolution
A hardware address resolution can be used over UDLR to allow a node,
e.g. a feed or a receiver, to discover the MAC address of another
node.
Regardless of whether the link is unidirectional or bidirectional, if
a nodes sends a packet over a non-point-to-point type network, it
requires the data link address of the destination. ARP [RFC826] is
used on Ethernet networks for this purpose.
This mechanism usually requires that the underlying transmission
media is bidirectional in order for a node to obtain the data link
address of a destination. The node sends an ARP REQUEST over the link
and waits for an ARP RESPONSE from the destination that contains its
data link address. Upon reception of the ARP response, the node can
then send traffic to the destination. Note that an ARP REQUEST is
broadcast-type frames, all nodes connected to the link receive it and
process it. An ARP RESPONSE is a unicast-type frame, only the
receiver whose hardware address is identical the MAC destination
address of the frame processes it.
3.1.1 Hardware Address Resolution protocol over UDLR
In a satellite environment, receivers connected to a DVB-S link use
reception cards which have their own unique hardware address. This
hardware address is 6-bytes long, like an Ethernet address. It may be
then sensible to use a mechanism similar to [RFC826] for a feed to
Authors [Page 8]
Internet Draft Experiments with RFC 3077 July 2003
discover the hardware address of a receiver. Thanks to the UDLR
protocol which emulates a bidirectional connectivity over the
satellite link. It allows a receiver to send back to the feed layer
two packets such as ARP responses.
Note that, for other satellite data link formats different from DVB-
S, receivers still have a unique hardware address and a similar
address resolution protocol based on exchanging REQUEST and RESPONSE
messages may be used.
In a topology where we have a feed and a number of receivers
connected to the satellite link, there are 3 typical hardware address
resolution scenarios:
i) Scenario 1: A feed needs a receiver's hardware address.
This usually occures when a feeds has to send a unicast IPv4
packet to a receiver whose MAC address is unknown.
The feed sends an ARP REQUEST over the satellite link whose
payload contains the IP address of the receiver. All the
receivers listen to the ARP REQUEST. The receiver which
recognizes its IP address in the payload sends an ARP RESPONSE
back to the MAC address of the feed. Note, the ARP REPONSE
reaches the feed through the UDLR GRE tunnel. Upon reception of
the ARP RESPONSE, the feed obtains the receiver MAC address from
the payload and can send IPv4 packets to it.
ii) Scenario 2: A receiver needs the feed's hardware address.
This usually occures when a receiver has to send a unicast IPv4
packet to the feed whose MAC address is unknown.
The data link layer of the receiver creates a ARP REQUEST which
is sent through the UDLR GRE tunnel. The ARP REQUEST payload
contains the IP address of the feed. Upon reception of the ARP
REQUEST, the feed which recognizes its IP address in the payload
sends over the satellite link an ARP RESPONSE to the MAC address
of the receiver. Upon reception of the ARP RESPONSE, the
receiver obtains the feed MAC address from the payload and can
send IPv4 packets to it.
iii) Scenario 3: A receiver needs a receiver's hardware address.
This usually occures when a receiver has to send a unicast IPv4
packet to another receiver whose MAC address is unknown.
The receiver sends an ARP REQUEST, which contains the IP address
Authors [Page 9]
Internet Draft Experiments with RFC 3077 July 2003
of a receiver, through the UDLR GRE tunnel. Upon reception of
the frame, the feed forwards it over the satellite as it is a
broadcast-type frame (see [RFC3077] for details).
All the receivers listen to the ARP REQUEST. Only the receiver
which recognizes its IP address in the payload sends back an ARP
RESPONSE to the requesting receiver. The ARP RESPONSE is sent
through the UDLR GRE tunnel to the feed. Upon reception of the
frame, the feeds figures out that the destination MAC address is
a receiver's one and then forwards it over the satellite link
(see [RFC3077] for details). The requesting receiver receives
the ARP RESPONSE, obtains the desired MAC address and can send
IPv4 packets to it.
These 3 scenarios allow any node connected to the satellite link to
obtain the MAC address of any other node.
3.1.2 Issues using a hardware resolution protocol over UDLR
The scenarios described in Section 3.1.1 raise a number of issues
when using a hardware resolution protocol over UDLR in a satellite
environment.
3.1.2.1 Long round trip delays
Regarding to scenarios 1 and 2, it requires over 250 milliseconds for
a node, a feed or a receiver, to obtain the MAC a destination of a
destination. 250 milliseconds is the fix and uncompressable satellite
link propagation delay. It should also be added to it the propagation
delay on the terrestrial link from the receiver to the feed. This
delay may vary from a few milliseconds up to a couple of hundred
milliseconds depending on the receiver's connectivity. E.g., a slow
GSM connectivity has a significative impact on the overal round trip
time whereas a fast T1 access has very little impact.
Because of long round trip delays, reactive address resolution
methods may not work well in some cases. For example, a feed may have
to forward UDP unicast packets at high data rates to a receiver whose
hardware address is unknown. The stream of packets is passed to the
link-layer driver of the feed send-only interface. When the first
packet arrives, the link-layer realizes it does not have the
corresponding hardware address of the next hop, and sends an ARP
request. While the link-layer is waiting for the response (at least
250 milliseconds), IP packets are buffered by the feed. If it runs
out of space before the ARP response arrives, IP packets will be
dropped. However, for TCP traffic, this should not happen since the
first TCP packet sent to a receiver whose MAC address is unknown, is
generally a TCP SYN indicating the start of a new session. This
Authors [Page 10]
Internet Draft Experiments with RFC 3077 July 2003
packet is not followed by a stream of packet until the receiver
replies to it. Therefor not many packets are buffered or lost for the
session. Note that subsequent IP packets sent to the same receiver
hop are not buffered anymore as long as the ARP entry is valid.
Regarding to scenario 3, the round trip delay between two receivers
is twice the round trip delay of scenarios 1 and 2. Both, the ARP
REQUEST and ARP RESPONSE are sent over the terrestrial network
through UDLR GRE tunnel and over the satellite link. An IP packet
delivered to the data link whose next hop MAC address is unknown,
must be buffered at least 500 milliseconds before being sent.
In order, to make a reactive harware address resolution protocol more
efficient in scenario 3, i.e. to reduce the round trip delay, it
might be sensible to configure an ARP server at the feed. The feed
would learn MAC addresse from ARP RESPONSES it receives from
receivers and would publish them as soon as a receiver requests one
of them. This mechanism would reduce the round trip down to 250
milliseconds, the feed would answer to an ARP REQUEST instead of a
receive reducing the latency.
3.1.2.2 Large number of receivers
Due to the large number of receivers which may be connected to the
satellite link, it is necessary to be able to allocate a sufficient
number of ARP entries in a ARP table. A feed may need to send unicast
packets to thousand of different receivers. For each of the
receivers, a correspondance between a MAC address and the IP address
of a receiver must be maintained.
Furthermore, when the size of the ARP table is significant, the
search for a MAC address corresponding to the next hop IP address
must be performed rapidely in order to prevent IP packets from being
buffered too long.
It is also common to associate an expiration date to an ARP entry in
order not to keep an entry for ever. After being deleted, an ARP
entry associated to a receiver is renewed when an IP packet is sent
again to this receiver. The main reasons for aging entries are:
- Automatic discovery of a receiver new MAC address. One may
replace the reception card of a receiver for maintainance puposes.
The IP address of the receiver does not change but its MAC address
does. When deleting the ARP entry of this receiver, a new IP
packet destined to it triggers the request of its new MAC address.
- ARP table size adjustable. Receivers may not be constantly
connected to the satellite link. During idle periods, it is then
Authors [Page 11]
Internet Draft Experiments with RFC 3077 July 2003
not necessary to keep an ARP entry for these receivers. The size
of the ARP table can then be adjusted to the number of active
receivers.
3.2 PPPoE
3.2.1 Introduction
The use of PPPoE with UDLR enables to offer a real satellite local
loop. It represents a good alternative for non covered by ADSL
areas. As PPPoE is a level 2 (OSI model) protocol, it matches well
with the LLTM mechanisms of the UDLR that make all the equipments
directly linked in Ethernet to the UDLR client and server see each
other on the same logical LAN (Local Area Network). The only needed
routing is the one between the UDLR client and the UDLR server for
establishing the GRE tunnel.
3.2.2 Architecture
Unidirectional Link
-------------<-----------
| |
| |
| |
| |
| |
\|/ .
. /|\
| |
--------- --------- --------
Ethernet | PPPoE/| IP Networks | LLTM | PPPoE | BAS |
-------| LLTM |-------->------|Server |---------| |
| Router| | | | |
| --------- --------- --------
| ____ |
|--|PC| |
| ---- --------
| ____ LAN | ISP |
|--|PC| --------
| ----
Figure 1 : Connectivity to a BAS via UDLR/PPPoE
In the Figure 1, the connections with arrow are unidirectionnal, others
are bidirectionnal.
3.2.2.1 Specificities
Authors [Page 12]
Internet Draft Experiments with RFC 3077 July 2003
The specificities of this architecture are :
- the use of a UDLR client (implementing the RFC 3077) on a
satellite terminal.
- the use of a UDLR server (implementing the RFC 3077) on a DVB
(Digital Video Broadcasting) Gateway acting as an Ethernet
Bridge (so you need a routeur co-located with the DVB gateway)
- a connection to a BAS (Broadband Access Server). The BAS is
directly connected to the DVB gateway in Ethernet. The BAS
manages the PPPoE connection. The PPPoE can end into the BAS
(open model) or continue and end into the RADIUS server of an
ISP (Internet Service Provider) (closed model). The PPPoE
authentication is done where the PPPoE tunnel ends (PPPoE
server).
- the use of a PPPoE client; there are two possible scenarii :
> the PPPoE client is implemented on the satellite
terminal that acts as a routeur for the PCs in LAN behind. The
PPPoE session is initiated between the satellite terminal and
the BAS or the Radius server.
> the PPPoE client is implemented on the PC, the
satellite terminal is now acting as an Ethernet Bridge : each
client is using its own PPPoE connection. All the PPPoE
tunnels are encapsulated in the same GRE tunnel.
3.2.2.2 Description of a connection
Here are the different steps of a connection to Internet :
- a user on a PC is trying to connect to a distant server of the
Internet
- the satellite terminal detects IP traffic
- after an authentication on the satellite platform, a GRE tunnel
is initiated between the DVB interface of the satellite terminal
and the DVB gateway. Now a LAN has been emulated and all the
Ethernet frames coming from the satellite terminal can be
directed to the gateway DVB and therefore to the BAS.
- after an authentication on the BAS (or the Radius server of an
ISP), a PPPoE tunnel is initiated between the satellite terminal
or the PC and the BAS (the specificities of a PPPoE connection
is described in the RFC 2516).
- the BAS redirect the PPP connection to the right ISP through a
L2TP tunnel.
3.2.3 Advantages
The bidirectionnal connectivity through PPPoE offers the
following advantages :
- a complete layer 2 (OSI model) satellite connectivity is offered
with a total transparency at an IP level between the terminal
satellite (UDLR client) and the IP network.
Authors [Page 13]
Internet Draft Experiments with RFC 3077 July 2003
- UDLR supports natively the PPPoE so no hardware development is
needed. The PPPoE client has to be integrated in the satellite
terminal or in the PC.
- PPPoE enables an interconnection with a Broadband Access Server
and besides the use of its functionalities (such as traffic
shaping).
- A satellite access based on UDLR/PPPoE can be complementary with
the ADSL network :
> same performances as the ADSL network
> reduction of the access costs due to the equipments'
convergence point in the return channel and a unique
management system for both satellite and terrestrial access
(accounting, billing, etc.)
- a multi-ISP configuration for the Internet access.
- a difference can be made between the IAP (Internet Access
Provider) and the ISP
3.2.4 Limitations
It is important to notice that PPPoE supports only PPP connection for
unicast flows. The multicast is provided directly by the IAP at the
DVB gateway level or coming from the Mbone through the BAS without
using PPPoE.
3.2.5 Security issues
The security issues are the same as the UDLR ones. So you need a
first authentication for the establishment of the GRE tunnel.
Afterwards, you need a second authentication of the client done by
the BAS or the Radius server of the ISP. This authentication is done
within the PPPoE mechanism (PAP or CHAP). It's also possible to use
cryptography¿with the IPSec protocol (e.g. RFC 3457)
4.0 Layer 3 Protocols
4.1 Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCPIP network,
and a mechanism for automatic temporary allocation of network
addresses.
4.1.1 DHCP Overview
DHCP is based on Bootstrap Protocol (BOOTP). It consists of two
components: a protocol for delivering host-specific configuration
parameters from a DHCP server to a host (default gateway, DNS server)
and a mechanism for allocation of network addresses to hosts. DHCP
Authors [Page 14]
Internet Draft Experiments with RFC 3077 July 2003
[RFC 2131] defines a set of transactions between a DHCP server and a
DHCP client to afford/request a valid network address, configuration
parameters or both. These transactions are constructed by DHCP
messages defined in RFC2131 (DHCPDISCOVER, DHCPREQUEST, DHCPOFFER)
that could include DHCP options defined in RFC2132.
DHCP runs over UDP. It uses port 67 on server's side, and port 68 on
client's side. A DHCP client is not supposed to know the DHCP
server's IP address initially.
When a host needs to acquire an IP address and eventually
configuration parameters, it broadcasts a DHCPDISCOVER message on its
physical subnet. Relay agents (if running on connected routers) may
pass the message on to DHCP servers not on the same physical subnet.
One or more DHCP server may respond to the client by proposing a
network address in a DHCPOFFER message. Server may probe the offered
address with an ICMP Echo Request.
The client may receive one or more offers. It broadcasts anyway a
DHCPREQUEST message that contains a server identifier option, and
eventually other options, to notice all DHCP servers of its
selection.
The selected server sends a DHCPACK message to confirm allocation.
The client may probe a last time the allocated address (e.g. ARP
request). This is a typical example of a successful DHCP transaction.
There are other DHCP transactions, messages and options. Please refer
to [RFC2131] for a complete description of DHCP protocol, and to
[RFC2132] for a complete description of DHCP options.
4.1.2 DHCP over UDLR
LLTM mechanism makes nodes connected to the UDL see themselves on the
same logical Local Area Network. Encapsulating layer-two frames allow
them to be sent in unicast and broadcast through Internet and UDL.
Thanks to this feature, DHCP can run on networks using UDLR
architecture, i.e. satellite networks. DHCP may be a solution to IP
addressing scalability and increasing number of nodes on such
networks. e.g. A node can be assigned a temporary network address
from a pool of public addresses . DHCP provides also a means of
requesting and getting local configuration parameters for clients
from their ISP.
4.1.2.1 Configuration and tuning guidelines
Before sending a DHCP request, a client node needs Layer-two
Authors [Page 15]
Internet Draft Experiments with RFC 3077 July 2003
connectivity to one DHCP server at least. Actually, a common use of
DHCP consists of making a DHCP client send DHCPDISCOVER message at
boot. While using DHCP over UDLR, DHCP client messages should be sent
only after establishing the GRE tunnel. Therefore, use of DHCP should
be taken into account while dimensioning the DTCP HELLO message
periodicity.
Lease duration and address pools' width, configured on DHCP server
side, depend on the number of nodes to serve and the nature of
offered services. Lease duration should not be too short to avoid an
increasing DHCP traffic and the risk of inability of renewing leases.
And should not be too long to avoid misusing addresses and increasing
the blocking probability.
A DHCP server can reassign addresses allocated before. It may check
an address before reallocation by an ICMP echo request; and the
client may do the same, after receiving an address, by an ARP
request. Such messages should be allowed to avoid address conflicts.
A DHCP server can be located on a receiver or a feed. For security
and delay considerations, implementing DHCP server on feed's side
reduces transaction duration to a half, and prevents from allocating
a lease by an unauthorised DHCP server.
Client sends DHCPRELEASE message to notice the server that client has
relinquished the lease. Some implementations of DHCP client keep
configuration information even after sending a DHCPRELEASE message.
This may lead to an address conflict and reduces the available
address pool.
DHCP servers and clients should take into account network transit
delay while assigning timers: DHCP messages retransmission timeout,
maximum delay that a DHCP server waits before deciding that the
absence of an ICMP echo response means that the relevant address is
free.
The global delay of a successful DHCP transaction is composed of:
1) One or two RTTs (Round Trip Time) for DHCP transaction. I.e.
requesting and acquiring a lease is done by exchanging four
messages, renewing a lease is done by exchanging two messages.
2) More than one RTT, which is the time needed to check the
availability of a network address. E.g. ICMP echo.
3) Time needed to read/write configuration and database files on
both server and client sides.
Authors [Page 16]
Internet Draft Experiments with RFC 3077 July 2003
DHCP clients may also retransmit DHCP messages if they do not receive
a response. Some client implementations timeout DHCPDISCOVER message
(for example) on an Ethernet delay basis. And a DHCP server may
respond to DHCPDISCOVER retransmission before that checking lease
availability (by an ICMP echo request) timeout expires, resulting on
an eventual address conflict.
4.1.2.2 Security issues
DHCP works over UDP/IP stack. These protocols are not inherently
secure. And UDLR technology is widely used over links that may be
easily accessed. Some DHCP messages (e.g. DHCPDISCOVER) are layer-two
broadcasted on the UDL, a malicious DHCP server may allocate network
addresses or false configuration information. An unauthorised host
may capture information sent to a DHCP client; Configuration
information can be then set manually. Link layer or IP security
mechanisms are of great interest.
Authorising DHCP server to serve unknown clients should be done with
special attention. DHCP permits authentication on a hardware address
basis through DHCP header and options, on the other hand LLTM
mechanism encapsulates layer-two frames. Authentication is another
important security feature.
DHCP transactions should be allowed after client authentication.
4.2 Issues using IGMP over UDLR
The Internet Group Management Protocol (IGMP) [RFC1112, RFC2236, RFC-
IGMPv3] is used in multicast edge networks (i.e., an Ethernet LAN or
the UDLR Scenarios A and B). Forwarded between multicast routers is
controlled by a different protocol (see section 5). The first version
of IGMP, IGMPv1 [RFC1112] is little used. At the time of writing,
most current end hosts use IGMPv2 [RFC2236]. IGMPv3 is increasingly
being deployed [RFC-IGMPv3]. A MIB has also been defined [RFC2933].
IGMP messages are sent with an IPv4 Time To Live (TTL) of 1,
indicating these are link local. On a UDLR return link, these
messages are sent using the return link tunnel, and retransmitted
over the feed (see 1.1.1).
4.2.1 Basic IGMP Operation
IGMP Membership Reports are sent by end hosts to communicate their
desire to receive specific IP multicast groups. Multicast routers in
the same subnetwork use IGMP Membership Reports to help determine
whether IP multicast packets should be forwarded to the subnetwork.
Multicast routers may already be forwarding this group, if not they
Authors [Page 17]
Internet Draft Experiments with RFC 3077 July 2003
start to forward IP multicast packets for the reported group after
the subnetwork RTT plus any additional delay required for the Feed
Router to join the requested multicast flow.
To validate the set of currently active groups, one multicast router
per subnetwork (the Querier) periodically sends a multicast packet
containing an IGMP Group Membership Query to all end hosts (i.e.,
using the IPv4 address 224.0.0.1). The Query Interval must be greater
than the sum of the Max Response Time and the Subnetwork Round Trip
Time, and is typically much larger. The Query message is received by
all systems in the subnetwork that have multicast enabled. This
mechanism also acts as an opportunity for end hosts to resend a
Membership Report which was not received by the UDLR Feed Router.
Each end host sets a random timer for each group it wishes to
receive. When the timer expires, it responds with one IGMP Group
Membership Report for each group which it wishes to receive. IGMP
includes a technique to reduce the number of Reports received by the
querier. This suppression mechanism relies upon visibility of the
responses sent by all members of the multicast group (i.e., the UDLR
Feed Router must re-send received Membership Reports on the all
feeds). If the other group members do not receive copies of the
Membership Reports, they will each send one Membership Report per
query, Groups which contain many members therefore generate a large
volume of return traffic.
Even when suppression is used, a large subnetwork RTT, may lead to
many receivers sending IGMP Membership Reports for the same group(s)
within the Max Response Time [RFC2236]. If it is known that there
may be many group members, one mitigation is to increase the Max
Response Time. which allows suppression to occur after one
Subnetwork RTT.
A Querier that identifies a previously forwarded group that currently
has no group members will send several (Robustness Variable) Queries
each separated by the Query Interval. The Query Interval must be
greater than the sum of the Max Response Time and the Subnetwork
Round Trip Time. If no Membership Reports are received for a specific
group (i.e., after a total period called the Group Membership
Interval) the multicast routers stop forwarding multicast packets
with this group address. Decreasing the Robustness Variable and/or
the Query Interval reduces the time to detect the last memebr
leaving a group(s). This can reduce the volume of unnecessary
multicast traffic sent over a UDLR feed link. Reducing the
Robustness Variable also reduces tolerance to loss of Membership
Reports sent over the return link (see 1.1.4).
The number of Membership Reports is an issue for flat networks (see
Authors [Page 18]
Internet Draft Experiments with RFC 3077 July 2003
1.1.5), particularly if they also exhibit a larger subnetwork RTT
(see 1.1.6). The number sent for each group is a function of the
number of systems that wish to receive the group, the Subnetwork RTT,
and the Max Response Time. Suppression requires the multicast packets
containing multicast Membership Reports received from UDLR Receivers
to be forwarded by the UDLR Feed Router.
A large Max Response Time, can reduce the number of redundant
Membership Reports, reducing return link traffic, but it also has the
drawback of increasing the leave latency. This may, in turn, increase
the volume of traffic unnecessarily forwarded on the forward link
when there are no remaining group members. This is an issue for UDLR
networks with limited forward link capacity (see 1.1.3).
4.2.2 IGMPv2 Leave Processing
In IGMPv1, it may take a considerable time for a multicast router to
discover there are no remaining end hosts interested in a group that
it is already forwarding. A refinement in IGMPv2 [RFC2236] allows end
hosts to send a Leave message explicitly indicating the group address
which the end host wishes to leave. This message is sent to an IPv4
address of 224.0.0.2. In some, but not all implementations, end hosts
will suppress sending an IGMP Leave message when they believe there
are other remaining group members.
Reception of an IGMP Leave message is not sufficient for a forwarding
multicast router to determine that there are no longer any end hosts
interested in a group. The Querier therefore responds by sending a
Group-Specific Query to request responses from other end hosts
interested in the group. If no Membership Report is received, the
Query is repeated each Last Member Query Interval up to Last Member
Query Count times, after which it will conclude there are no
remaining group members. This allows multicast routers to more
quickly stop transmission of multicast packets to groups for which
there are no longer any active receivers. The value for Last Member
Query Interval may be tuned, but MUST be greater than the Subnetwork
RTT. The time taken to terminate an IP multicast flow is therefore
the sum of the subnetwork RTT and the delay introduced by the IGMP
Querier.
4.2.3 IGMPv3 Operation
IGMPv3, allows an end host to report an interest in receiving not
only a specific group address, but also from a specific set of IP
source addresses (or all except a specific set of IP source
addresses). This allows finer control over the multicast packets
forwarded to the subnetwork. This may conserve link capacity,
especially when a system switches from receiving one multicast group
Authors [Page 19]
Internet Draft Experiments with RFC 3077 July 2003
to another.
End hosts that receive an IGMPv3 Query start a random timer. The
maximum value is specified as a parameter in the Query, allowing an
appropriate scaling factor to be selected based on the anticipated
size of the group and the Subnetwork RTT. IGMPv3 Membership Reports
are sent to a specific multicast address (i.e. the IPv4 address
224.0.0.22). A potential modification to UDLR would allow this group
to be filtered by the Feed Router.
One significant change in IGMPv3, is that end hosts MUST send
Membership Reports following a Query to indicate the groups they wish
to receive (i.e., there is no suppression), although a single message
may report several groups. This may increase the number of IGMP
messages sent over a subnetwork. This can consume both feed and
tunnel capacity (see 1.1.3, 1.1.4). To mitigate this in flat
networks (see 1.1.5) or networks with a large subnetwork RTT (see
1.1.6), IGMPv3 therefore also allows the use of much larger response
times.
An advantage of IGMPv3 is that it allows routers (and connected LAN
switches) to provide explicit tracking of which end hosts request
each group. Explicit tracking allows routers to discover immediately
when the last group member leaves, and suspend forwarding of the
group within a Subnetwork RTT.
4.2.4 Forwarding Groups at the Receiver based on IGMP
Note that in IGMPv1 and IGMPv2, Leave and Membership Report messages
are sent to the same group destination address as the group it is
notifying. A bridged (Scenario B) solution requires these messages
to be parsed at the UDLR receiver in order to establish an
appropriate filter set to forward multicast packets to the attached
end hosts. One scheme is called Snooping [DRAFT-MAGMA-SNOOP].
Separating these Membership Reports from multicast traffic can be
processor intensive and may impact performance, many Ethernet LAN
switches employ ASICS to optimise this processing.
4.3 IGMP-Proxy
The IGMP Querier function is normally implemented in a multicast
Router, and the IGMP client in a multicast end host. It is also
possible to implement the IGMP protocol within UDLR Receiver, this is
called an IGMP membership Proxy [DRAFT-MAGMA-PROXY, DRAFT-MAGMA-
SNOOPING].
Consider Scenario B. An IGMP membership proxy at the UDLR Receiver
behaves as if it were an end host (i.e., sends IGMP Membership
Authors [Page 20]
Internet Draft Experiments with RFC 3077 July 2003
Reports for groups it wishes to receive) in response to IGMP Queries
received over the UDLR forward feed.
The receiver also executes an IGMP Querier for the attached LAN and
therefore sends IGMP Queries. The Membership Reports received by the
Receiver allow it to collect group membership information, which can
be directly used to control forwarding of multicast packets received
over the UDLR feed.
An IGMP Proxy may use different group membership protocols on the
UDLR and LAN networks. This could be a mixture of IGMPv2 and IGMPv3,
or could possibly be a modified protocol on the UDLR network.
An IGMP Proxy may also implement Proxy Reporting [DRAFT-MAGMA-
SNOOPING; DRAFT-MAGMA-PROXY], where the proxy only reports which
sources and groups need to be forwarded. This can significantly
reduce the number / frequnecy of Reports. A UDLR Receiver employing
an IGMP Proxy can separate the distribution of group membership
information into the UDLR subnetwork and any attached networks
connected via a UDLR client. This allows the protocol parameters
used within the UDLR network to be tuned.
4.4 Dense Mode Multicast Routing
4.4.1 DVMRP
4.4.2 Dense Mode PIM (PIM-DM)
4.5 Sparse Mode Multicast Routing
4.5.1 Sparse Mode PIM (PIM-SM)
The issues of PIM-SM operation on unidirectional links are:
1. Reverse Path Forwarding
2. Rendezvous Point selection
3. Designated Router selection
This section describes these issues in details. In this section, all
nodes are assumed to be PIM-SM routers (Scenario D) and the UDL runs
PIM-SM as the only multicast routing protocol.
Reverse Path Forwarding
In the case of Receive networks do not use the Feed Router to forward
unicast traffic to multicast sources and the Rendezvous Point, the
receivers do not send PIM-SM Join/Prune messages to the Feed Router.
As the result, multicast traffic does not flow on the unidirectional
Authors [Page 21]
Internet Draft Experiments with RFC 3077 July 2003
link. This is the PIM-SM reverse path problem on unidirectional
links.
There are two solutions, at least, for this problem:
1. Configure UDLR Receive networks to route unicast traffics to all
possible multicast sources and Rendezvous Points via the Feed
router.
2. Prevent PIM-SM routers in UDLR receive networks from
switching to the shortest-path tree of multicast sources located
outside the receive network. In this scheme, the UDL receive
networks only need to route unicast traffic to all possible
Rendezvous Points via the Feed Router.
If the possible multicast sources includes all hosts in the Feed
network, then the first option is to route traffic to the Feed
network via the Feed Router. The second option simplifies the routing
requirement from routing to all hosts in the Feed network to routing
to the possible Rendezvous Points. The second option, however,
doesn't work on SSM destination addresses. [DRAFT-PIM-SM-NEW]
specifies some rules concerning the SSM destination addresses
overriding the normal PIM-SM behavior. This document states that a
router MUST NOT send a (*,G) Join/Prune message for any reason, thus
PIM-SM never uses the rendezvous-point tree for traffic to SSM
destination addreses.
Rendezvous Point selection
The Feed network can advertise routes to the possible Rendezvous
Points using unicast routing protocols natively such that the UDLR
receive networks route to them via the Feed Router. This scheme
causes UDLR receive networks to route all networks between the Feed
Router to the possible Rendezvous Points via the Feed Router. To
minimize the number of networks routed via the Feed Router, the
possible RPs should be as close as possible to the Feed Router. This
number reaches the minimum if the Feed Router's unidirectional link
interface address is the only possible Rendezvous Point.
In the case where no unicast routing protocol is running on the uni-
directional link and unicast routing advertisements are limited only
within each Feed network and Receive network, the UDLR receive
networks may use static routes. Static routes to the possible RPs via
the Feed router are set on the UDL receivers and they are injected to
the receive network's unicast routing protocol.
Designated Router selection
Authors [Page 22]
Internet Draft Experiments with RFC 3077 July 2003
A PIM-SM router performs Designated Router election on each
interface. A DR has the task to send PIM-SM Register packets and to
send Join/Prune messages toward the RP or the multicast source. The
DR election is important for unidirectional links if multicast
sources exist. If a multicast source exists on a unidirectional link,
the Feed Router should be elected as the DR for the unidirectional
link to avoid the overhead due to the LLTM mechanism. In the Scenario
D, DR election result is not important as all UDL nodes are multicast
routers.
A PIM-SM router sends Hello messages periodically every Hello_Period
to each active inteface. In addition, a PIM-SM router also sends a
Hello message when Hello message is received from a new neighbor, or
a Hello message with a new GenID is received from an existing
neighbor. a PIM-SM router will remove a neighbor if it does not
receive any neighbor's Hello message in the HoldTime advertised by
the neighbor.
The number of neighbors is an issue for flat networks (see 1.1.5).
The bandwidth consumption Periodic Hello messages can be reduced by a
large Hello_Period. A large HoldTime can reduce the probability of
removing a PIM-SM neighbor due to Hello message packet loss, thus
reducing the probability of a Hello message storm. However, the
probability of a router reboot on flat networks having many nodes may
be high, thus the probability of a Hello message storm due to
receiving a Hello message with a new GenID from a newly rebooted
neighbor.
Join/Prune messages are sent periodically toward the multicast source
or the RP. An overriding Join is also sent by a router having a
multi- cast state if it receives a Prune of that multicast state sent
by a neighbor to the upstream router. If a PIM-SM router receives a
Join with the same state, it can suppress sending a Join message of
the same state.
Join message suppression can reduce the bandwidth consumption of a
shared link. For flat networks with many nodes or large round trip
delay, a large Override interval will help. The large Override
interval value causes a large Prune Pending Timer, thus multicast
traffic will flow for a longer time on the unidirectional link even
though there is no more downstream routers.
4.5.2 PIM-SM RPs and MSDP
In the Scenario E, each Receive network has its own RP and MSDP is
used to connect each RP. Each Receive network's RP MSDP peers with
the RP of the Feed network.
Authors [Page 23]
Internet Draft Experiments with RFC 3077 July 2003
In the case of multicast routing using PIM-SM and MSDP, flowing
multicast traffic from a source S in the Feed network to multicast
listeners in Receive networks via a UDLR requires that: 1. Join(S,G)
message from Receive networks to the Feed network flows via
the UDLR. 2. The MSDP peer in the Feed network is the RPF peer of
the MSDP peer
in the Receive networks toward the originating RP of S. These
requirements suggest that a separate MRIB is needed to flow the
traffic via the UDLR and the MRIB has to create the RPF route to S
and its originating RP via the UDLR.
[DRAFT-MSDP-DEPLOY] discusses several scenarios to deploy MSDP and
PIM-SM. The best current practice for inter-domain multicast is to
use MBGP along with PIM-SM and MSDP. In the UDLR case, A Receive
network MBP peers with the Feed network for the multicast address
family only. This practice creates a different multicast topology to
the unicast topology.
If PIM-SM and MBGP are the only multicast routing protocols, the non-
MBGP speaker routers in Receive networks do not have a separate MRIB.
These routers perform RPF checks solely based on their unicast
routing table; therefore they do not send Join(S,G) messages toward
the Feed router. These routers should be set to not join the SPT.
The RP in Receive networks should be the Receive routers unless all
rou- ters from the Receive routers to the RP learn the multicast
topology from MBGP. If this is not the case, the MSDP peer in the
Feed network passes the peer-RPF check at the MSDP peer in the
Receive networks, but when the MSDP peer in the Receive networks send
Join(S,G), the Join(S,G) path fol- lows the unicast routing table.
Based on these facts, Receive networks should be configured as
follows: 1. PIM-SM routers should not join the SPT. 2. RP, which is
also the MSDP peer, should be the Receive router. 3. Receive routers
should MBGP peer with the Feed router for the multi-
cast address family.
The configuration no. 1 basically also states that Receive networks
can only be stub PIM-SM domain, because if they MBGP peer and MSDP
peer with a downstream PIM-SM domain, the Receive networks have to
create MRIBs on all routers along the intended Join(S,G) path from
the RP of their down- stream domain to the Receive routers.
4.6 NAT environment
Network Address Translation (NAT) technology is getting popular in
the Internet these days. Normally NAT box translate private IP
address to global IP address on regular TCP protocols and some of UDP
Authors [Page 24]
Internet Draft Experiments with RFC 3077 July 2003
services. UDLR defined by RFC3077 employs GRE encapsulation technique
to communicate receivers and a feed. But RFC3077 does not consider to
exist NAT box between the GRE tunnel between a receiver and a feed.
By this nature RFC3077 does not support NAT environment. It may work
with some NAT box but it depends on the implementation of NAT
function.
5. Security Considerations
The recommendations contained in this document do not impact the
integrity of IP multicast transport protocols, or applications using
IP multicast transport protocols.
There are known Denial of Service (DoS) attacks that can be staged
UDLR operation. UDLR employs GRE tunnel mechanism to carry a packet
from a receiver to a feed. If the intruder send a faked packet to the
tunnel end point at feed, it will be a cause of the link down of the
UDL. Intruders also can send flooding packet to the UDL receivers via
UDL. It will be a cause of UDL flood. Third case of the intrusion is
related to ARP mechanism. If the operator employs ARP mechanism to
resolve MAC address to IP address, these negotiation should be
authenticated and protected from faked ARP packet. Faked ARP packet
may be a cause of ARP table overflow on feed or other routers.
To avoid these attack, it is recommended to protect tunnel end point
at feed by packet filtering, hide tunnel interface IP address from
unknown users, etc.. And it is also recommended that a packet sent to
the UDL should be encrypted using any kind of encryption mechanism.
UDL has a nature of broadcast link. That means packets on the UDL may
be received by unexpected nodes.
6. Conclusions
7. Acknowledgements
8. References
8.1 Normative References
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD
37, RFC 826, November 1982
[RFC1112] Deering, S.E., "Host extensions for IP multicasting",
RFC1112, 1989, (STD0003).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors [Page 25]
Internet Draft Experiments with RFC 3077 July 2003
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
1997
[RFC2132] S. Alexander,R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, 1997
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", 1997, RFC 2236, (Proposed Std).
[RFC2516] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R.
Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)",RFC 2516, February 1999
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P.,
"Generic Routing Encapsulation (GRE)", RFC2784, (Proposed
Std).
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional
Links', RFC 3077, March 2001
[RFC-IGMPv3] "Internet Group Management Protocol, Version 3",
(Author's note, with IESG - this reference needs to be
solved when issued as an RFC).
8.2 Informative References
[DRAFT-AVT-RTP-NEW] Schulzrinne/Casner/Frederick/Jacobson, "RTP: A
Transport Protocol for Real-Time Applications, <draft-ietf-
avt-rtp-new-11.txt>, Work in Progress.
[DRAFT-MSDP-SPEC] D. Meyer, B. Fenner, "Multicast Source Discovery
Protocol (MSDP)", <draft-ietf-msdp-spec-20.txt>, Work in
Progress.
[DRAFT-MSDP-DEPLOY M. McBride, "Multicast Source Discovery Protocol
(MSDP) Deployment Scenarios", draft-ietf-mboned-msdp-
deploy-02.txt, Work in Progress.
[DRAFT-MAGMA-SNOOP] M. Christensen, F. Solensky "IGMP and MLD
snooping switches", <draft-ietf-magma-snoop-02.txt>, Work
in Progress.
[DRAFT-MAGMA-PROXY] Fenner, B. et al, "IGMP-based Multicast
Forwarding (IGMP Proxying)", <draft-ietf-magma-
proxy-02.txt>, (Author's note: not in ID archive), Work in
Progress.
Authors [Page 26]
Internet Draft Experiments with RFC 3077 July 2003
[DRAFT-PILC-ASYM] Balakrishnan, H., V. N. Padmanabhan, G. Fairhurst,
M. Sooriyabandara, "TCP Performance Implications of
Network Path Asymmetry", <draft-ietf-pilc-asym-08.txt>,
Work in Progress.
[DRAFT-PIM-SM-NEW] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", <draft-ietf-pim-sm-
v2-new-07.txt>, Work in Progress.
[EN00] "Digital Video Broadcasting (DVB); Interaction Channel for
Satellite Distribution Systems", Draft European Standard
(Telecommunications series) ETSI, Draft EN 301 790, v.1.1.1
[RFC1889] Schulzrinne H. , S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
1996, (Proposed Std).
[RFC2933] K. McCloghrie, D. Farinacci, D. Thaler, "Internet Group
Management Protocol MIB", RFC2933, 2000, (Proposed Std).
[RFC2402] Kent, S., Atkinson., R., "IP Authentication Header",
RFC2402, 1998, (Proposed Std).
[RFC2406] Kent, S., Atkinson., R., "IP Encapsulating Security Payload
(ESP)", RFC 2406, 1998, (Proposed Std).
[RFC3171] Albanna, Z., K. Almeroth, D. Meyer, M. Schipper. "IANA
Guidelines for IPv4 Multicast Address Assignments", 2001, (
BCP0051)
[RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", RFC3228, 2002, (BCP0057).
9. Authors' Addresses
In alphabetic order:
Gilles Chanteau
France Telecom R&D
38/40 rue du General Leclerc
92131 Issy-Les-Moulineaux Cedex
France
Phone: (+33) 1 45 29 58 67
EMail : gilles.chanteau@rd.francetelecom.com
Yann Codaccioni
France Telecom R&D
Authors [Page 27]
Internet Draft Experiments with RFC 3077 July 2003
38/40 rue du General Leclerc
92131 Issy-Les-Moulineaux Cedex
France
Phone: (+33) 1 45 29 64 67
EMail : yann.codaccioni@rd.francetelecom.com
Emmanuel Duros
UDcast
2455 Route des Dolines BP355
06906 Sophia Antipolis France
France
EMail : Emmanuel.Duros@UDcast.com
Virginie Faineant
France Telecom R&D
38/40 rue du General Leclerc
92131 Issy-Les-Moulineaux Cedex
France
Phone: (+33) 1 45 29 49 77
EMail : virginie.faineant@rd.francetelecom.com
Godred Fairhurst
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Achmad Husni Thamrin
Graduate School of Media and Governance
Keio University
5322 Endo, Fujisawa
Kanagawa 252-8520
Japan
Email: husni@ai3.net
Amine Lamani
France Telecom Research and Development
Satellite Networks Architecture
38-40, rue du General Leclerc, 92794
ISSY-LES-MOULINEAUX cedex 9
FRANCE
Jun Takei
JSAT Co.
1-11-1 Marunouchi, Chiyoda-ku
Authors [Page 28]
Internet Draft Experiments with RFC 3077 July 2003
Tokyo 100-6218
JAPAN
EMail : takei@csm.jcsat.co.jp
10. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
11. IANA Considerations
There are no IANA considerations associated with this draft.
Authors [Page 29]
