RE: [ssm] Re: last call comments on ssm-arch doc

"Rolland Vida" <Rolland.Vida@lip6.fr> Wed, 15 January 2003 13:24 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26014 for <ssm-archive@lists.ietf.org>; Wed, 15 Jan 2003 08:24:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDcTJ10195; Wed, 15 Jan 2003 08:38:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDV7J09036 for <ssm@optimus.ietf.org>; Wed, 15 Jan 2003 08:31:07 -0500
Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25131 for <ssm@ietf.org>; Wed, 15 Jan 2003 08:15:58 -0500 (EST)
Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FDJ5mT029804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 14:19:05 +0100
X-pt: isis.lip6.fr
Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FDJ5312918; Wed, 15 Jan 2003 14:19:05 +0100 (MET)
From: Rolland Vida <Rolland.Vida@lip6.fr>
To: Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr>, holbrook@cisco.com
Cc: ssm@ietf.org
Subject: RE: [ssm] Re: last call comments on ssm-arch doc
Date: Wed, 15 Jan 2003 14:19:05 +0100
Message-ID: <NDBBLPHLPKFAHIKICCDPCEFICMAA.Rolland.Vida@lip6.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20030115.122655.70199744.Hitoshi.Asaeda@sophia.inria.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Scanned-By: isis.lip6.fr
Content-Transfer-Encoding: 7bit
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hitoshi,

> Let's imagine something like an application of a panel discussion.
> E.g., now, there are two senders (S1 and S2) as the speakers, and then
> we do ((S1,S2),G) join. In this case, does this panel discussion works
> as "a single channel" application or "two channels" application?

We obviously have two channels: (S1, G) and (S2,G). The fact that a receiver
sends an IGMPv3 join containing (INCLUDE(S1,S2),G) does not mean that there
is a unified channel, but that he wants to join two channels in the same
time.

You might have another receiver that sends INCLUDE(S1,G) only, so the
channels have to be separated.

> I've thought these answers would be "a single channel" since both S1
> and S2 work for a same application,

The fact that it is the same application or not has nothing to do with it.
Each source has its own channel.

> So, if each answer is "two channels", is it correct that a channel
> MUST consist of a single source except such failover mechanism?

As Hugh said, the channel ALWAYS corresponds to a single source. If we want
a secondary source to assure a failover mechanism for example, it should
have its own channel. But to assure the transparency of the mechanism for
the end-user, the binding between these two channels should be built in the
application itself, and not at the network layer. At least this is what I
understood from Hugh's message, and this is what seems to be correct for me
too.

Regards,
Rolland Vida

_______________________________________________
Ssm mailing list
Ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm