[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minutes of the last udlr meeting
Here follows (two months later!) the minutes of our last meeting.
Emmanuel will send the last version of the Informational RFC draft
on the mailing list for comments. If we reach a consensus on the document
we will submit it to IESG. This version was written after a interim
WIDE-INRIA meeting that was hel at INRIA about the end of May.
On the other hand, we talked last time about having a BoF meeting
to discuss IP over satellite issues. I would like to ask for a slot
during next meeting for this BoF. Any comments/input is welcome.
Please respond to the mailing list.
Walid Dabbous
http://www.inria.fr/rodeo/dabbous
INRIA U.R. de Sophia Antipolis | Email : dabbous@sophia.inria.fr
2004, Route des Lucioles BP 93 | Phone : +33 4 92 38 77 18
06902 Sophia Antipolis CEDEX France | Fax : +33 4 92 38 79 78
IETF-41st Meeting
Walid Dabbous presented the Agenda :
I)-presentation of the current version of the Internet-Draft
II)-discussion, future of the WG
I)
Section 1) Introduction & terminology
Presentation of the terminolgy which will be included in the draft.
Unidirectional link: A one way transmission link.
Receiver: A router that has receive-only connectivity to an UDL.
Send-only feed: A router that has a send-only connectivity to an UDL.
Receive capable feed: A router that has a send-and-receive connectivity
to an UDL.
Feed: A send-only or a receive capable feed.
Section 2) Topology & problems
Presentation of a possible topology with a Send-only feed, a Receive
capable feed and 2 Receivers. They are all connected to the Internet.
Introduction of the Tunnel use which allow communication between
Receivers and Feeds.
3) Broadcast link emulation
Presentation of possible scenario to emulate a broadcast
communication.
sc 1: receiver to feed
sc 2: receiver to all
sc 3: receiver to receiver
sc 4: feed to SO feed
sc 5: feed to all
sc 6: feed to receiver
Sc 1 : A receiver sends a packet to a Feed.
A receiver encapsulates the packet and sends it to the bidirectional
address of the feed. The feed decapsulates it and delivers it the Link
Layer of the unidirectional interface.
Sc 2 : A receiver sends a Broadcast packet over the UDL
The Receiver encapsulates the packet and sends it to the default feed.
The feed decapsulates the packet which is delivered to the Link Layer of its UD interface.
The feed sends the packet over the UDL
The feed sends the encapsulated packet to Send-Only feeds multicast group
A SOF has to join the SOF Multicast group in order to receive
packet which are supposed to be received from the UDL.
The presentation of this scenario was follwed by a discussion on the
choice of the Multicast group allocated for Feed
multicast communication.
There was a proposal to Unicast instead of Multicast ?
In fact, using multicast allows maintaining tunnel dynamically,
but this supposes that the SOF MUST support multicast.
A feed may ask a receiver to tell him the presence of all feeds, and
therefore avoid the need to use a SOF multicast group.
There were a rough consensus in using meshed tunnels between SO Feeds
instead of a multicast group in this version of the draft.
Sc 3 : receiver sends a packet to another receiver
The receiver encapsulates the packet and sends it to the default Feed.
A Receiver maintains the list of Feeds. The feed decapsulates the Packet
and forwards it directly over the UDL.
Sc 4 : A feed sends a packet to a Unidirectional feed
The feed sends the encapsulated packet to Unidirectional feed tunnel end-point
The Unidirectional feed decapsulates it and delivers it locally.
Sc 5 : A feed sends a broadcast/multicast packet to all nodes
The feed sends the packet over the UDL
Sc 6 :
Defautl communication behavior of the UDL
Section 6.3: DTCP
packet format
Description of the field :
-Command (Join and Leave)
-Sequence Number
-Tunnel Proto : GRE
-ARP Type
-Feed UDL IP addr
-Feed BDL IP addr
Refering to a question on the mailing list :
"Why do not we announce all bidir interface + Metric?"
The metric is not relevant information for the receiver.
Proposition of announcing all the IP addr without metric. A set of
receiver can send to a particular interface of the Feed. This based on
"HOST UNREACHABLE" messages which are sent back by the feed when a Receiver.
There was an aggreement to list all the IP addresses in the HELLO.
Christian Huitema said : The protocol must be IPv6 compliant or at make the
distinction between IPv4 or IPv6.
There were a consensus on this point.
There were proposals to add to the HELLO message:
the list of bidirectional interfaces
and whether the feed is receive capable.
There were a description of the Link Layer representation for both the
receiver and the Feed (Send-Only, Receive Capable)
A preference in a diagram with the whole path followed by a packet from
a receiver to a Feed (this will be added to the draft).
Sacalability :
DTCP does not limit scalability in itself.
(Lack of) Scalibility problems are general and not specific to UDL.
They are not addressed in the udlr working group.
Future activities :
First : Finishing the document. Final comments on the ML before the next
IETF. Hopefully this document will a informtional RFC by next Meeting.
Two independant implementations (WIDE & INRIA).
We expect this informational RFC to become a standard RFC later.
What After UDLR ?
Focus on IP over Satellite. UDLR is for any UDL and could not focus on
the specific pb of satellites. We want to addr is the framing mechanism
(IP>DVB, link sharing).
ARP : MAC addressing issues, adapting ARP to satellite environment
Multicast : IGMP : because of delays their is a risk of implosions
Scalability (Feedback)
Support of IPv6
A new working group : IPSAT ?
A Bof will be requested for Chicago meeting.