[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
                                                          C. Benassy-Foch
                                                               P. Charron
    Internet Draft                                           Y. Guinamand
    Document: draft-ietf-udlr-dvmrp-conf-03.txt             Alcatel Space
    Expires: December 2002                                      June 2002
 
 
             Configuration of DVMRP over a UniDirectional Link
 
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance
    with 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 groups may 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/ietf/1id-abstracts.txt
    The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.
 
 Abstract
 
    Routers connected to a UniDirectional Link (UDL) such as a
    satellite network, implement a link layer tunneling mechanism, as
    defined in the RFC 3077 [UDLR]. These routers could exchange
    multicast routing information. This document describes how DVMRPv3
    works on this network architecture and suggests a different
    configuration of DVMRPv3 on routers connected to the UDL more
    adapted and optimized to this network architecture.
 
 Table of Contents
 
    Status of this Memo..............................................1
    Abstract.........................................................1
    1. Introduction..................................................2
    2. DVMRPv3 over a UDL............................................2
    2.1 Network architecture.........................................2
    2.2 DVMRPv3 implementation.......................................3
    2.3 Active mode configuration on receivers.......................3
    2.3.1 Feed configuration and behavior............................4
    2.3.2 Receiver configuration and behavior........................4
    2.3.3 Scalability issue of DVMRP.................................5
 
                    Configuration of DVMRP over a UDL     June 2002
 
 
    2.4 Passive mode configuration on receivers......................6
    2.4.1 Feed configuration and behavior............................6
    2.4.2 Receiver configuration and behavior........................7
    2.5 When and How to switch between active and passive mode.......7
    3. Domains of application........................................8
    3.1 Application using a Reliable Multicast Transport Protocol....8
    3.2 Multicast application with interactivity.....................8
    4. Others network architectures..................................9
    4.1 Connectivity on the same LAN as the Feed....................10
    4.2 Mbone connectivity via two access points: the UDL and the LAN11
    5. Acknowledgements.............................................12
    6. References...................................................12
    7. Author's Addresses...........................................13
    8. Full copyright statement.....................................13
 
 1. Introduction
 
    Multicast routing on a UDL such as a satellite network seems very
    complex because the receiver can not send its routing information
    to the feed.
 
    The RFC 3077, which describes a link-layer mechanism to emulate the
    full bi-directionality of all nodes connected by a unidirectional
    link, allows to connect natively receivers and feeds, emulating the
    behavior of a LAN. Feeds and receivers can therefore easily
    exchange their routing information. DVMRPv3 could be used as
    multicast routing protocol on this network.
 
 2. DVMRPv3 over a UDL
 
 2.1 Network architecture
 
    Feed and receivers are connected via a UDL, which is a satellite
    link. A geostationnary link features a UDL between the feed and
    receivers, a minimum throughput of 2048Kbps up to 48000Kbps and a
    250ms delay from the feed to receivers.
 
    A satellite link is extremely well suited for multicast IP. The
    large coverage associated to multicast allows to connect the feed
    to a huge number of receivers using a modest amount of bandwidth.
 
    The Feed is directly connected to DVB/MPEG-2 [ETSI EN 300 421]
    transmission equipment. Receivers integrate a DVB-S/MPEG Satellite
    reception card (receive-only interface) with a MAC address of 48
    bits, similar to an Ethernet card. This reception card supports
    unicast, broadcast and multicast mode.
 
    The feed and receiver implement the RFC 3077, hence making the UDL
    totally transparent for the IP layer.
 
                   Informational - Expires December 2002                 2
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
 
                        UniDirectional Link (UDL)
                +-------->--------->------------>-----+
                |                        |            |
            --------                  --------     --------
            | Feed |                  |Recv 1|     |Recv 2|
            --------                  --------     --------
                |                        |            |  |
                |      Workstation [WS]--|            |  |--[WS]
                |                        |--[WS]      |  | LAN
                |                    LAN |            |  |--[WS]
                |                        |            |
                |                        v            v
                |                        |         -------
                |         Access router [X]        |modem| PPP
                |                        |         -------
                |                        |            |
    +-------+   |                        |         -------
    | MBONE |--[X] Router                |         | ISP |
    +-------+   |                        |         -------
                |                        |            |
                |        +--------+      v            v
                +---<----|INTERNET|--<---+----<-------+
                         +--------+
 
    Figure 1: Connectivity feed/receiver via an access router or a PPP
    connection.
 
    The Feed is connected to the MBONE and to the INTERNET. So it can
    forward multicast traffic over the UDL.
 
    Receivers have an Ethernet interface to connect to a LAN on which
    workstations are connected. The LAN is connected to the INTERNET
    via an access router (which does not have multicast routing
    ability) or via a PPP connection. Receivers route IP traffic
    encapsulated into GRE packets to the bi-directional interface of
    the Feed.
 
 2.2 DVMRPv3 implementation
 
    DVMRPv3 is running on the feed and receivers. The feed and
    receivers are DVMRP routers. In the experiment the DVMRPv3
    implementation is mrouted 3.9b3. Feed and receivers run FreeBSD
    3.4-RELEASE.
 
 2.3 Active mode configuration on receivers
 
    The feed and receivers are DVMRP routers. In active mode feed and
    receivers have a standard DVMRPv3 implementation(mrouted 3.9b3).
 
    A return link channel is necessary for receivers to exchange DVMRP
    messages. Thanks to the Link Layer Tunneling Mechanism, feed and
    receivers are considered to be on the same LAN. Thus they are DVMRP
    neighbor routers.
 
                   Informational - Expires December 2002                 3
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
 2.3.1 Feed configuration and behavior
 
    Feed configuration:
 
    The feed is the only DVMRP router of the LAN having access to the
    MBONE. The feed must be elected as the Designated Forwarder
    [Pusa00] on the UDL to forward multicast data over the UDL.
 
    The feed is the closest element from all receivers in term of
    transmission duration. To ensure that all queries are well
    centralized on the feed, it has to be elected as the Designated
    Querier as defined in IGMPv2 [IGMPv2]. It needs to have the
    smallest IP address on the UDL.
 
    Feed behavior:
 
    The feed periodically sends Probe messages over the UDL to discover
    DVMRP neighbor routers. These messages contain the list of neighbor
    router addresses.
 
    Upon reception of a Probe message from a receiver via the GRE
    tunnel, the feed updates its list of neighbors. If its address is
    included into this report message, the feed establishes a two-way
    neighbor adjacency with this receiver.
 
    As the feed has DVMRP neighbor routers on the UDL, it sends route
    information into Report messages over the UDL. A Report message
    contains the list of source networks and the associated metrics.
    It enables routers to determine the Reverse Path neighbor back to
    the source of the multicast traffic.
 
    These two DVMRP messages use a reserved multicast IP address (ALL-
    DVMRP-ROUTERS) and have a TTL set to 1.
 
    Upon reception of multicast traffic from the MBONE the feed will
    broadcast traffic over the UDL and will stop flooding it when it
    receives Prune messages from all downstream routers(all receivers).
 
 2.3.2 Receiver configuration and behavior
 
    Receiver configuration:
 
    Receivers are standard DVMRP routers. The return link channel is
    used to exchange DVMRP messages.
    In this network architecture it is primordial to ensure that the
    upstream router receives all Prune messages from its downstream
    routers. If a prune message is lost, useless traffic continues to
    be forwarded and hence wastes bandwidth. The GRE tunnel between
    receivers and the feed crosses many routers in the INTERNET.
    Therefore it dramatically increases the probability to lose a Prune
    message.
 
                   Informational - Expires December 2002                 4
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    For this reason Prune message must be transmitted using a binary
    exponential back-off during the lifetime of the Prune message if
    the traffic is still arriving on the upstream interface. This
    algorithm is described in [Pusa00] section 3.5.5.
 
    Example of configuration using mrouted (implementation of DVMRP):
    Add "rexmit_prunes on"
 
    Receiver behavior:
 
    Receivers send Probe messages to discover others DVMRP routers.
    Probe messages are encapsulated into the GRE tunnel and forwarded
    to the feed. Receivers consider the feed as a DVMRP neighbor
    router.
    Then receivers send Report messages to the Feed via the GRE tunnel.
 
    When the feed broadcast multicast data over the UDL, Receivers uses
    the DVMRP routing table to determine if the traffic should be or
    not forwarded to their Ethernet interfaces. First receivers check
    if the incoming interface is the upstream interface of the data.
    Secondly the multicast traffic is forwarded to downstream
    interfaces as indicated into the DVMRP routing table. If there is
    no downstream interface, the receiver sends a Prune message to the
    upstream routeur via the GRE tunnel. After the receiver will send a
    Graft message to the upstream router if the list of downstream
    interfaces associated to this traffic is not any more empty.
 
 2.3.3 Scalability issue of DVMRP
 
    There are two main factors that limit the scalability of DVMRP over
    a UDL.
 
    First, the number of Probe messages periodically exchanged between
    receivers and the feed is proportional to the number of receivers
    connected to the UDL. The period is 10s. The size of Probe message
    depends on the number of DVMRP routers.
    In case of many receivers connected to the LAN, the DVMRP traffic
    will dramatically increase on the UDL.
 
    For example: A UDL with a feed and 70 receivers
    The feed would receive 70 Probe messages every 10s. The Feed would
    send a probe message over the UDL containing 70 IP addresses every
    10s too. The size of this Probe message would be 292 Bytes (the IP
    header would be 24 Bytes because of the IP router Alert option then
    the IP packet would be 316 Bytes)(the maximum size is 576 Bytes
    including IP header).
 
    DVMRP implementations can support a limited number of DVMRP
    neighbors. For instance in mrouted implementation (mrouted 3.9b3)
    the maximum number of DVMRP neighbors is 64. A satellite UDL allows
    more than 64 receivers.
 
    In addition, Report messages are sent over the UDL. A router sends
    a Report message every 60s in multicast and sends a Report message
 
                   Informational - Expires December 2002                 5
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    in unicast when a new neighbor router is discovered (reception of a
    Probe message with its own address into the list of neighbor
    addresses). To prevent an implosion of Report messages, the sending
    of Report messages is spread out across the report interval. So
    each receiver would send a Report message every 60s to the Feed via
    the GRE tunnel.
 
    The return link channel will be loaded by DVMRP Messages. To enable
    receivers connected to the UDL to forward multicast traffic without
    a return link channel, Receivers could be configured in passive
    mode.
 
 2.4 Passive mode configuration on receivers
 
    When the UDL is for example a satellite link, the number of
    receivers easily overloads the capabilities of DVMRP. To avoid
    this, the chosen solution is to implement a passive mode in the
    standard implementation of DVMRP. This mode allows the mrouted
    implementation to forward a valid multicast source from the UDL to
    the lan of receivers without sending any information to the
    upstream router (the feed)(the return link channel is not used).
 
    A change is required on the DVMRP implementation used on receivers:
    a new parameter has to be added into the implementation. It is
    detailled in the section 2.3.2 (Receiver configuration and
    behavior).
 
    In this mode, receivers get from the feed the Multicast streams and
    the RPF tables (contained into Report messages). The standard
    implementation of multicast routing table is not modified, so
    receivers need the RPF information to choose the feed as a valid
    upstream router for the Multicast sessions they receives. This is
    mandatory to avoid the creation of routing loop.
 
    Without this RPF information receivers are not able to forward a
    source from the feed to the lan. As described in the DVMRPv3
    [Pusa00] a DVMRP router will send RPF information on an interface
    only if there is at least one neighbor on this interface.
 
    According to this, the feed must have at least one DVMRP neighbor
    router on the UDL. So at least one receiver must be in active mode.
    This active receiver will send Probe message to the feed via the
    GRE tunnel and the feed will send over the UDL route information.
 
 2.4.1 Feed configuration and behavior
 
    The implementation of the multicast routing daemon is unmodified
    into the feed. The feed configuration is the same as the one when
    receivers are in active mode. The feed does not require any
    modification to allow receivers to run in passive mode.
 
    As the multicast routing algorithm is not modify, the feed must
    receive a join IGMP message in order to forward a multicast session
    on the UDL. An internal application could be developed to send a
 
                   Informational - Expires December 2002                 6
 
 
                    Configuration of DVMRP over a UDL    June 2002
 
    join message on the UDL interface of the Feed. This internal
    application might be based on a mtest program.
 
    For instance, it is interesting to configure the Feed to forward
    advertisement of multicast sessions via the Session Announcement
    Protocol [SAP] and multicast sessions about hot topics.
 
 2.4.2 Receiver configuration and behavior
 
    To support the passive mode receivers has to accept a new parameter
    in their DVMRP configuration file (mrouted 3.9b3). The LAN
    interface must contain the new parameter "switch_uni_bi
    <group_ip_address>". This <group ip address > is not a multicast
    group address related to a multicast group session. This address is
    dedicated to the configuration of the Receiver on the LAN
    interface.
    In addition the UDL interface of the passive receiver must be
    declared as "one_way".
 
    This is an example of a default receiver configuration file:
 
         Phyint dvb0 # UDL Interface
          Threshold 8
          Boundary LOCAL
          One_way
         Phyint eth0 # Lan Interface
          Switch_uni_bi 224.5.6.7
 
    In this configuration the receiver is launched in passive mode and
    only forwards the valid sources it has received to its lan
    interface.
    "Valid sources" means multicast data from a source having not an
    empty list of downstream interfaces into the routing table.
 
    As described in the DVMRP protocol [Pusa00] the feed will send
    Report messages needed to calculate the Reverse Path neighbor back
    to the source of a multicast traffic, only if there is at least one
    valid neighbors on the UDL.
 
    This means you need to have all the time an active receiver on your
    UDL. Section 4.1 of this document present a solution to this
    problem.
 
 2.5 When and How to switch between active and passive mode
 
    In the experiment the passive mode is the default configuration of
    receiver.
 
    A receiver needs to switch to active mode when it has subscribers
    on its LAN to a multicast session that is not forwarded by the Feed
    over the UDL at this moment(all other active receivers have sent a
    prune message).
 
                   Informational - Expires June 2002                 7
 
 
                    Configuration of DVMRP over a UDL     December 2002
 
    When a end-user on the LAN wishes to participate to a multicast
    session (to send multicast data), a receiver has to switch to
    active mode too.
 
    To switch to active mode, someone on the LAN must send a join
    message to the session defined by the <group_ip_address>, the
    groupe IP address of the æswitch_uni_biÆ parameter (here 224.5.6.7
    in the example). Upon reception of an IGMP join on the lan
    interface to this specific group address the receiver switches to
    active mode.
 
    The receiver will work in active mode until there is no more
    members for the æswitch_uni_biÆ session, and will automaticaly
    return to passive mode as it does not receive any more IGMP join
    for this session.
 
 3. Domains of application
 
    The purpose of this section is to describe two kinds of
    applications wherein dynamic multicast routing over a UDL presents
    a lot of benefits.
 
 3.1 Application using a Reliable Multicast Transport Protocol
 
    [UDLR] is very well suited for applications using Reliable
    Multicast Transport protocol based on Negative-ACKnowledgment.
 
    A multicast push server is connected to the feed, which forwards
    multicast data over the UDL to receivers. A receiver who is missing
    data packets could send a NACK in multicast to the push server.
    This retransmission request is relayed by the GRE tunnel to the
    feed. It forwards the request to the push server and on the UDL
    too. Upon reception of the NACK, the push sender retransmits the
    requested packet. Then this requested packet is sent by the Feed
    over the UDL. Other receivers connected to the UDL will receive the
    missing packet. As the feed has forwarded the NACK request on the
    UDL receivers have suppressed the sending of the same NACK.
    This NACK suppression mechanism is easy to implement over a UDL. It
    can be scaled to a large number of receivers and it reduces the use
    of the return channel link.
 
    With such a reliable multicast transport protocol based on NACK
    some receivers on the UDL could be in active mode to send
    retransmission request to the push server. Other receivers
    connected to the UDL on passive mode will receive missing packet
    without sending any request. These two modes on receivers will
    improve the NACK suppression mechanism.
    The application will offer a better service (a reliable transport
    service) without overloading return channel links of receivers.
 
 3.2 Multicast application with interactivity
 
    Applications such as tele-teaching and collaborative work require a
    main multicast flow from a main source to end-users (to deliver a
 
                   Informational - Expires December 2002                 8
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    course or a lecture) and several minor flows from end-users to the
    main source and other end-users (questions and remarks from end-
    users).
 
    For these applications, end-users are on the LAN interface of
    passive receivers and they have joined the multicast session (they
    have sent an IGMP report message for the session group address).
    Passive receivers forward multicast session data to their LAN
    interfaces.
    If an end-user wishes to participate to the multicast session (for
    instance, asking a question), the receiver must switch to active
    mode. The return link channel will be set up. DVMRP messages will
    be sent via the GRE tunnel to the feed and multicast data will be
    forwarded via the GRE tunnel over the UDL.
    After if no more end-user wishes to participate, the receiver will
    switch back to passive mode.
 
    Receivers in passive mode could listen multicast session without
    sending DVMRP messages, hence without using their return link
    channels. However they can participate multicast session by
    switching to active mode. The use of the return link is optimized.
 
 4. Others network architectures
 
    This section proposes other network architectures well-adapted to
    these two modes of configuration. These networks are based on a UDL
    and a return channel link implementing the Link Layer Tunneling
    Mechanism [UDLR]. The first architecture suggests a solution for an
    operator of such a network to always have an active receiver
    connected to the UDL under its control. In the second architecture,
    a receiver has an access to the Mbone as the Feed has. In this case
    the GRE tunnel is not worth forwarding multicast message to the
    Feed or to a multicast source, it is better to forward these
    multicast messages through the Mbone. To solve that, a
    configuration of the DVMRP router included into the receiver is
    proposed.
 
                   Informational - Expires December 2002                 9
 
 
                    Configuration of DVMRP over a UDL    June 2002
 
 4.1 Connectivity on the same LAN as the Feed
 
                        UniDirectional Link (UDL)
                +-------->------------>-----+
                |              |            |
            --------        --------     --------
            | Feed |        |Recv 1|     |Recv 2|
            --------        --------     --------
                |              |            |  | Workstations
                |        [WS]--|            |  | LAN
                |              |--[WS]      |  |--[WS]
            LAN +--------------+            |
                |                           v
                |                       -------
        Router [X]                      |modem| PPP
                |                       -------
                |                          |
    +-------+   |                       -------
    | MBONE |--[X] Router               | ISP |
    +-------+   |                       -------
                |                          |
                |        +--------+        v
                +----<---|INTERNET|---<----+
                         +--------+
 
    Figure 2: Connectivity feed/receiver on the same LAN
 
    In this architecture, the feed has its Ethernet interface connected
    on the same LAN as the receiver Recv 1. Recv 1 has a receive-only
    interface and an Ethernet interface.
 
    The Recv1 must not forward traffic to the UDL, the feed must be the
    Designated Forwarder. So the feed must have the cheapest route
    between the LAN of the Feed and the UDL.
 
    Example of configuration with mrouted:
    # fl0: The LAN interface of the feed
    phyint fl0 metric 1 threshold 1
    # r1l0: The LAN interface of the recv 1
    phyint r1l0 metric 10 threshold 20
 
    Recv 1 should be in active mode. In this case the feed has a
    permanent DVMRP neighbor router. Thus the feed will continue to
    send Report messages over the UDL, and all other receivers
    connected to the UDL will be able to determine the Reverse Path
    neighbor back to the source of a multicast traffic.
 
    Recv 2 could be in passive mode if it wants to receive multicast
    traffic. If it wishes to become a multicast source, it has to
    switch to active mode.
 
                   Informational - Expires December 2002                10
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    With this network architecture, there is at least one receiver in
    active mode on the UDL allowing a huge number of passive receivers
    to listen multicast sessions.
 
 4.2 Mbone connectivity via two access points: the UDL and the LAN
 
    A feed is connected to the MBone/Internet and can forward multicast
    traffic over the UDL. IGMP and DVMRP messages come from receivers
    through the GRE tunnels.
 
    Receivers are connected to the UDL and also to a LAN which already
    has MBone connectivity. Receivers send routing information through
    the GRE tunnels to the feed.
 
    A client located on a remote LAN can receive multicast traffic
    either from the UDL (e.g. a satellite link) or from the
    "terrestrial" network.
 
                   UniDirectional Link (UDL)
               ---->------------------------>----
              |                                |
              |                                |
          ----------                      -----------
          |  Feed  |                      |  Recv1  |
      A   ----------                      -----------       C
      |       |                                |            |
     ---------------- LAN 1          LAN 2 -----------------------
        |                                                 |
      ----                                               ----
      |R1|                                               |R2|
      ----                                               ----   B
        |                                                 |     |
       ----------------------------------------------------------
      |                   Internet / MBone                     |
      ----------------------------------------------------------
 
    Figure 3 : MBone connectivity via 2 access points
 
    In the architecture described in the figure 3 : The Feed and Recv1
    are neighbor DVMRP routers. R1 (respectively R2) is a multicast
    router connected to the MBone that communicates with the Feed.
 
    A and B are 2 multicast sources which transmit on the same
    multicast group. C located on LAN2 joins this group.
 
    From A, the multicast traffic is routed over the MBone cloud and
    through R2 to reach the client.
 
    In both cases, the shortest path is chosen to route the traffic
    between the source and the destination. Routing operates here in an
    optimal way.
 
    When C starts generating multicast traffic :
 
                   Informational - Expires December 2002                11
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    1) to B : this traffic is routed through R2 and through the MBone.
    2) to A : this traffic would normally be routed through Recv1 and
    the feed because DVMRP thinks that C is only 2 hopes away from A.
    In fact, the multicast traffic would go from C to Recv1, then
    encapsulated within GRE packets, would go through the Internet up
    to the Feed and then forwarded over LAN1.
 
    This is not the optimal way to route traffic from LAN2 to LAN1
    because the multicast traffic would be forwarded in a GRE tunnel
    between Recv1 and the Feed over the Internet, whereas it could be
    natively and optimally routed in multicast between R2 and R1 over
    the MBone.
 
    Furthermore, the GRE encapsulation adds extra overhead useless
    here.
 
    To route the multicast traffic from LAN2 to LAN1 over the MBone and
    not within the GRE tunnel, DVMRP has to be configured on the
    receiver. The solution is to set an infinite metric to the bi-
    directional interface of the receiver.
 
    As a result, the receiver cannot compute the shortest path to a
    source via its bi-directional interface and then, cannot forward
    the traffic over the UDL.
 
    Furthermore, a receiver cannot announce valid routes to the feed
    since they would all have infinite metrics. The feed cannot compute
    any reverse path back through these receivers.
 
    Hence, it is not possible for the multicast traffic to come from
    the UDL but it flows from the terrestrial network to LAN1.
 
 5. Acknowledgements
 
    We would like to thank Emmanuel Duros for his technical inputs,
    especially for the section 4.2, and all UDLR WG members for their
    comments.
 
 6. References
 
    [UDLR] E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang, "A
    Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077,
    March 2001
 
    [Pusa00] T. Pusateri, "Distance Vector Multicast Routing Protocol"
    ,2000
 
    [IGMPv2] W. Fenner, " Internet Group Management Protocol, Version
    2", RFC 2236, November 1997
 
    [ETSI EN 300 421] "Digital Video Broadcasting (DVB), Framing
    structure, channel coding and modulation for 11/12 GHz satellite
 
                   Informational - Expires December 2002                12
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    services"
 
    [SAP] M. Handley, C. Perkins, E. Whelan, "Session Annoucement
    Protocol", October 2000
 
 7. Author's Addresses
 
       Celine Benassy-Foch
       Alcatel Space Industries
       26 av. J.F. Champollion
       31037 Toulouse Cedex
       France
       Phone: (+33) 5 34 35 39 34
       Email: celine.benassy@space.alcatel.fr
 
       Philippe Charron
       Alcatel Space Industries
       100, Bd du Midi
       06156 Cannes la Bocca Cedex
       France
       Phone: (+33) 4 92 92 79 89
       Email: philippe.charron@space.alcatel.fr
 
       Yann Guinamand
       166 rue du President Wilson
       92 300 Levallois Perret
       France
       Phone: (+33) 6 73 48 23 26
       Email : yann@guinamand.com
 
 8. Full copyright statement
 
    Copyright (C) The Internet Society (1999).  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 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
 
                   Informational - Expires December 2002                13
 
 
                    Configuration of DVMRP over a UDL     June 2002
 
    revoked by the Internet Society or its successors or assigns.
 
    This document and the information contained herein is provided on
    an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
           Informational - Expires December 2002                14