[multrans] FW: RE:Updated version of the multicast PS draft
Tina Tsou <tena@huawei.com> Thu, 09 June 2011 19:56 UTC
Return-Path: <tena@huawei.com>
X-Original-To: multrans@ietfa.amsl.com
Delivered-To: multrans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id DC3FB11E81B3 for <multrans@ietfa.amsl.com>;
Thu, 9 Jun 2011 12:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No,
score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBxvlLawxEKR for
<multrans@ietfa.amsl.com>; Thu, 9 Jun 2011 12:56:35 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180])
by ietfa.amsl.com (Postfix) with ESMTP id 20D4A11E80E2 for
<multrans@ietf.org>; Thu, 9 Jun 2011 12:56:35 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com
(iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id
<0LMJ00GUDGQA4W@usaga04-in.huawei.com> for multrans@ietf.org;
Thu, 09 Jun 2011 14:56:34 -0500 (CDT)
Received: from TingZousc1 ([10.193.34.221]) by usaga04-in.huawei.com (iPlanet
Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id
<0LMJ00FBTGQ8U0@usaga04-in.huawei.com> for multrans@ietf.org;
Thu, 09 Jun 2011 14:56:33 -0500 (CDT)
Date: Thu, 09 Jun 2011 12:56:31 -0700
From: Tina Tsou <tena@huawei.com>
To: multrans@ietf.org
Message-id: <013d01cc26df$54b592d0$fe20b870$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative;
boundary="Boundary_(ID_TmR8GB0FUshd8tHRwyoVgg)"
Content-language: en-us
Thread-index: AcwmhMUGhFPt5RjYTWanea0gzLDdVgASiNEA
Subject: [multrans] FW: RE:Updated version of the multicast PS draft
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multrans>,
<mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>,
<mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2011 19:56:37 -0000
Hi Jacni, I bring it to the list, hope you don’t mind. We keep our promises with one another – no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:jacniq@gmail.com] Sent: Thursday, June 09, 2011 2:07 AM To: christian.jacquenet@orange-ftgroup.com Cc: DENG Xiaohong ESP/PEK; Tina Tsou; Lee, Yiu; BOUCADAIR Mohamed OLNC/NAD/TIP Subject: Re: RE:Updated version of the multicast PS draft hi all, I wrote some text for the IGMP-MLD mode, to clarify the IGMPv2-MLDv2 issue. ------------------------------------------------------- 4.4.1.1. IGMP-MLD In this mode, the IWF element performs the router portion on its interface facing hosts, and the host portion on its interface facing the Querier, as below: +------+ +-----+ +---------+ | Host | -- | IWF | -- | Querier | +------+ +-----+ +---------+ IPv4 receivers When receivers are IPv4, they can be connected to MLD Querier by IWF as below: +----------+ +-----+ +---------+ | IPv4 | -- | IWF | -- | MLD | | Reciever | +-----+ | Querier | +----------+ +---------+ If IGMPv2 operates in the IPv4 domain while MLDv2 operates on the MLD Querier, or if IGMPv3 operates in the IPv4 domain while MLDv1 operates on the MLD Querier, the issue mentioned above will be encountered. To solve this problem, the IWF should perform the router portion of IGMP which is of the same version operating in the IPv4 domain, and convert the IGMP message to MLD format accordingly (i.e. IGMPv2 to MLDv1, or IGMPv3 to MLDv2). Then the IWF can use the protocol interaction approach specified in Section 8 of [RFC3810] to exchange signaling messages with the MLD Querier on which the different version of MLD is operating. IPv6 receivers When receivers are IPv6, they can be connected to IGMP Querier by IWF as below: +----------+ +-----+ +---------+ | IPv6 | -- | IWF | -- | IGMP | | Reciever | +-----+ | Querier | +----------+ +---------+ If MLDv1 operates in the IPv6 domain while IGMPv3 operates on the IGMP Querier, or if MLDv2 operates in the IPv6 domain while IGMPv2 operates on the IGMP Querier, the issue mentioned above will be encountered. To solve this problem, the IWF should perform the router portion of MLD which is of the same version operating in the IPv6 domain, and convert the MLD message to IGMP format accordingly (i.e. MLDv1 to IGMPv2, or MLDv2 to IGMPv3). Then the IWF can use the protocol interaction approach specified in Section 7 of [RFC3376] to exchange signaling messages with the IGMP Querier on which the different version of IGMP is operating. ------------------------------------------------------ Comments? Cheers, Jacni