Subject: Re: [SAM] draft-kellil-sam-mtocp

From: "KELLIL Mounir" <[email-masked]>
Date: Thu, 1 Apr 2010 15:04:03 +0200

Dear Matthias,

Thanks a lot for your valuable comments. Please see below my answers.

> > >   * How does the MTO-Ctrl knows other MTO entities? Must all MTOCP
> > > entities have to register at the MTO-Ctrl?
> > >
> > [MK] Currently (or in the current implementation if you want),
> > MTO-Ctrl gets the list of overlay nodes and connection descriptions
> > from an external module defined in a deliverable of the FP7 CCAST
> > project work, which MTOCP is part of.  Actually, the current MTOCP
> > draft focuses on the "enforcement/configuration" of the overlay tree
> > in the network. The "generation" of the topology/form of the overlay
> > tree is out of the scope of the draft. In our project
implementation,
> > the generation of the overlay topology is handled by a specific
> > network context-aware component interacting with (but could be
> > integrated in) the MTO-Ctrl; but this is external to the MTOCP
> > protocol.
> >
> [MW] OK ... The MTO-Ctrl is an entity to establish centrally multicast
> states. The topolog creation should probably be integrated within the
> MTO-Ctrl as topologies will be constructed depending on the receivers.
> On ther other hand, one can collect, maybe aggregate, and delegate
> receiver subscriptions to the specific topology component.
> 
[MK] The MTO_Ctrl establishes both multicast and unicast states when it
is provisioned with such states. In the demo/current implementation the
states are provided by an external component ("the topology component").
For receiver subscription, please see my comments below.

>   Nevertheless, the receivers have to register at the MTO-Ctrl - or at
> the topology component.
> 
[MK] If it is a multicast receiver, it registers via standard IGMP/MLD
(besides, in the current implementation, it uses SIP to get information
on the session, e.g., multicast addresses and ports). If the receiver is
unicast, it uses an out of band mechanism to register. On key
requirement for such a case is that the out of band mechanism should not
modify receiver's TCP/IP stack (this is also true for multicast
receivers, actually). In the current implementation, the out of band
mechanism is SIP. So, the SIP server contacts the receiver to provide
him with the session description (in particular, the IP address of the
L-ON the receiver will be attached to). In addition, the SIP server
informs the topology component about receiver's unicast address and
listening port. The topology component then forwards the information to
MTO-Ctrl, which then pushes it to the L-ON through MTOCP. Of course such
an out-of-band mechanism ("SIP + topology component") is not the only
possible one. And, providing other alternatives is not a critical issue
per se.  

> > * The forwarding process is a bit unclear to me: By which means does
> > > an overlay node to unicast or to multicast?
> > >
> > [MK] An ON receives forwarding information from the MTO-CTRL (via
the
> > MTCOP protocol) in the form of one input transport connection and
one
> > or multiple output transport connections (for a given MTO Tree ID).
> > These input/output connections are bound together in the ON "MTO
> > forwarding table". When the overlay node receives data on the input
> > transport connection, it then just forwards the data onto the output
> > connections indicated in its "MTO forwarding table". Of course, the
> > destination address of transport connections could be multicast or
> > unicast, IPv4 or IPv6.
> >
> [MW] OK, an ON decides on multicast or unicast based on the
destination
> address in its local MTOCP state table.
>
[MK] Yes.

>   How do you map the destination address to an actual IP forwarding
> interface at an ON? Is this based on the local unicast routing table?
>
[MK] Yes, this is true for unicast connections.

> And what does this mean for a multicast destination address: multicast
> addresses are not included in unicast routing tables. Thus, you cannot
> easily replicate packets and require an addition multicast
> routing/signaling, right?
> 
[MK] This is a good point. To receive or send multicast traffic, the ON
uses the source address of the multicast input (respectively, output)
connection to select the downstream (respectively upstream) interface.
Of course, the source address of the multicast input/output connection
is mentioned by MTO-Ctrl. Also, in our specification (not indicated in
the draft, but we will mention this in a future version), ON is also an
IGMP/MLD listener. So, as such, it sends an IGMP/MLD report whenever it
should receive multicast packets from other ONs or from the source.

  Btw: Do you assume a global topology view - at least with respect to
> the overlay nodes? Otherwise it seems hard to determine appropriately
> the destination address for ON state tables.
>
[MK] Yes, there is a global topology view at MTO-Ctrl (this is quite
realistic in an operator network scenario), not at ON. ON needs only to
know its input and output connections.

Your comments are welcome

Best regards

Mounir