draft-ietf-udlr-llencap-01.txt

[tim@rsd.dl.nec.com (Tim Woodall)]

Hello all,


> A new ID concerning the Link layer tunneling mechanism for supporting
> unidirectional links is available.
>
> You can find it at the following url:
>
> http://www.inria.fr/rodeo/udlr/documents/draft-ietf-udlr-lltunnel-00.txt
> 
> All comments are welcome. Discussions during next IETF in Los Angeles
> will be focussed on this ID.
> 
> Emmanuel


Based on very similar work that NEC is doing in this area, 
it would be desirable for the DTCP to support advertisement 
of multiple end-point addresses. This list should include 
all bi-directional or receive-only interfaces that had been
administratively enabled to act as a tunnel-endpoint.

This allows (but does not require) the receiver to choose 
a tunnel end-point based on some metric (e.g. lowest
RIP hop count). This can be extremely useful if another
UDL is available for the return path.

Consider the case where a small set of receive sites may 
also be acting as feeds, yet the underlying transport does 
not support multiple feeds per UDL, so N feeds results in N
distinct unidirectional links.

Assume a site is acting as both a feed for UDL1 and a 
receiver for UDL2. If this feed advertises all receive
capable interfaces in its DTCP advertisements, a receiver
on UDL1 that is also acting as a feed for UDL2 can choose 
the advertised tunnel end-point on UDL2 as it is directly 
connected to this network. 

This capability would also support feeds with multiple 
connections to the internet. Receivers could choose the 
tunnel end-point based on the best routing metric back 
to the feed.
 

Regards,
Tim S. Woodall
NEC America
tim@rsd.dl.nec.com