2.5.10 UniDirectional Link Routing (udlr)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99


Walid Dabbous <dabbous@sophia.inria.fr>
Yongguang Zhang <ygz@hrl.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:udlr@sophia.inria.fr
To Subscribe: udlr-request@sophia.inria.fr
Archive: ftp://zenon.inria.fr/rodeo/udlr/archive.txt

Description of Working Group:

Note: An alternate site for UDLR's files is: ftp://irl.cs.ucla.edu/pub/udlr

High bandwidth, unidirectional transmission to low cost, receiver-only hardware is becoming an emerging network fabric, e.g. broadcast satellite links or some cable links.

Two cases for unidirectional links support may be envisaged:

1. unidirectional links on top of bidirectional underlying network (wired Internet) 2. bidirectional islands connected via unidirectional links.

In both cases, the integration of unidirectional links may require changes to the routing protocols in order to preserve dynamic routing across these links. A short term solution (i.e. to solve the first case) is to adopt current protocols with possible modifications. A long term solution (i.e. for the second case) is to propose, design and implement protocols that remove assumed link symmetry (e.g. by supporting 2-way metrics).

There have been several proposed approaches for the short term case. The first is based on the modification of the common routing protocols (RIP, OSPF, DVMRP) in order to support unidirectional links. The second is to add a layer between the network interface and the routing software to emulate bi-directional links through tunnels.

The purpose of the UDLR Working Group, therefore, is to study these approaches and suggest a short term solution to provide dynamic routing (including multicast) in the presence of unidirectional links.

Goals and Milestones:

Apr 97


Meet at IETF. Finish discussion of the general solution.

Apr 97


Post the description of the proposed solutions and the issues for the short term solution as I-D(s).

Aug 97


Preliminary experiments results of the short term solution.

Aug 97


Post the description of the short term solution as an I-D.

Dec 97


Produce Informational RFC on the proposed approach.

Dec 97


End WG.


No Request For Comments

Current Meeting Report

Reported by Patrick Cipiere.


Chairs: Walid Dabbous, Yongguang Zhang

- Status of the Draft (Walid) 5mn
- Interoperability tests INRIA-WIDE (Emmanuel Duros) 20mn
- Presentation of BGP Direction Attributes (Dave Thaler) 15mn
- Discussion (All)

Status of the draft

IESG comments
- be more precise about the security considerations firewall is not an enough defined term
- identify the possible threats in the tunnel
- clarify problem description

AD's comments
- precise implications of the MAC level (ie MPE vs Ethernet)

These comments will be taken in account and a new version of the draft will be issued as soon as possible. We ask for a volonteer who has English as first language, to help in mofifying the draft. Thanks to Tim Gleeson who is volonteer.

AD's raise an issue about GRE (RFC1701) which is informational. draft relies on GRE, so we have to wait for RFC1701 to become a proposed standard. How long will it take?
Dave Oran and Rob Coltun answer is: should not be a long time. They just have to find the person to do the job. They will manage that very soon.

Interoperability tests between Sony (WIDE) and INRIA (Emmanuel Duros)
- Sony people at INRIA: because of satellite coverage
- UDL MAC layer: MultiProtocol Encapsulation (MPE)
- INRIA satellite network
- Interoperabily tests

The slides describing the interoperability tests can be found under:

During the presentation, there was (again) a discussion about the solution based on broadcast link emulation.

Harri Hakulinen says he preferes a solution which is not based on broadcast emulation at the link level.

Patrick Cipiere answers that this is the goal of the draft: a solution for the UniDirectional Link Routing problem based emulation of a bidirectional broadcast link. It does not rpeclude other solutions but the Working group converged to this solution.

Harri Hakulinen complains about scalibilty of the solution: if we have 10k or 1M of receivers it will not work.
Yongguang Zhang replied it is the same pb on any broadcast capable links (e.g. Ethernet) and this is not specific to the LLTM mechanism

Gorry Fairhurst complains about the fact that the draft mention MAC layer encapsulation in the GRE tunnel.
Patrick Cipiere answers that the back channel encapsulate the same MAC layer that the one used on the UDL link.

Dave Oran explains that is simple enough to handle all the scenarios. He also mentions that it is broadcast emulation therefore if we want to be coherent we must sent back through the back-channel MAC layer packets. Sending layer 3 paquets would lead to unexpected behaviour.

Jun Takei says that a feed should at least understand a common MAC layer (Ethernet) on the back channel.
Hitoshi Asaeda agrees.
Harri Hakulinen disagrees.

There is a rough consensus on using MAC layer on the back channel. The implications will be detailed in the new version of the draft.

BGP direction attributes for multicast (Dave Thaler)
- bidirectional routes
- go-to routes
- come-from routes
- should a router having one go-to route and one come-from route advertize a bidirectional route. NO, because of DUP's.
- http://www.ietf.org/internet-drafts/draft-ietf-idmr-bgp-mcast-attr-00.txt

People who participated in the discussions:


None received.