Subject: [multrans] about the charter of Multrans

From: huang cancan <[email-masked]>
Date: Fri, 16 Sep 2011 17:14:51 +0800

hi all:

We are ready to include solutions work in the charter.

cancanhuang

China Telecom

---

From: Tina TSOU <[email-masked]>
Date: Wed, 21 Sep 2011 23:14:16 +0000

Thank you, Cancan.
Here is updated version, scoped down to a single use-case for which there is commercial interest (i.e., IPTV).

Proposed MULTRANS Charter

The task of the MULTRANS Working Group is to devise the means whereby existing multicast mechanisms can operate successfully when signalling and content have to traverse one or more IPv4/IPv6 boundaries. The scope of the Working Group is initially limited to the IPTV case, since the requirements for this application are better understood than those for other potential multicast applications.

Goals

1. The Working Group's first task is to develop a problem statement that identifies the scope of the problem of multicast operation for the IPTV application during the transition from IPv4 to IPv6. The problem statement will identify:
      -- requirements that must be satisfied by the mechanisms
         for multicast transition;
      -- use cases that must be considered, ranked by priority;
      -- design considerations that should be taken into account in subsequent work.

2. The Multrans Working Group will develop Standards Track documents specifying protocol interworking for the new combinations of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for multicast transition from IPv4 to IPv6.

3. The Multrans Working Group will specify the means whereby multicast addresses may be translated between IPv4 and IPv6, in both stateful and stateless fashion, in direct analogy to RFC 6052 for unicast addresses.

4. The Multrans Working Group will specify extensions to DHCPv4, DHCPv6, and RADIUS attributes required to configure hosts during the transitional period.

5. The Multrans Working Group will specify the operational and management capabilities required to support multicast transition. In particular, this work may involve the specification of MIBs.

Relationship to other working groups:

- Work done in the Softwire working group on the use of encapsulation as a multicast transition mechanism will be coordinated with the more general work being done by the MULTRANS working group.

- The specification for translation between IPv4 and IPv6 multicast addresses will be reviewed jointly with the MBONED working group, as will recommendations relating to operation and management of multicast transition.

- DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS will be jointly reviewed with the appropriate other parties (DHC and RADEXT working groups, MIB Doctors directorate).

- The interworking recommendations for PIM, IGMP, and MLD developed in this group will be reviewed jointly with PIM, MBONED.

Milestones

May 2012  WG adopts
- problem statement draft
- interworking drafts
-  address translation draft
-  drafts related to operations and management of multicast transition

Sep 2012 Submit to IESG
- problem statement draft
- interworking drafts
-  address translation draft
-  drafts related to operations and management of multicast transition

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

From: huang cancan [mailto:[email-masked]]
Sent: Friday, September 16, 2011 2:15 AM
To: [email-masked]
Cc: Tina TSOU
Subject: about the charter of Multrans

hi all:

cancanhuang

China Telecom

---

From: <[email-masked]>
Date: Thu, 22 Sep 2011 07:58:44 +0200

Dear Tina,

Is there any interest on the stateful approaches? I have included it for discussion in the bar bof we had in Prague but, If I remember well, there was no interest.

IMHO, the charter should focus on the stateless.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Tina TSOU
Envoyé : jeudi 22 septembre 2011 01:14
À : huang cancan; [email-masked]
Objet : Re: [multrans] about the charter of Multrans

Thank you, Cancan.

Goals

Milestones

May 2012  WG adopts

Sep 2012 Submit to IESG

Best Regards,
Tina TSOU

hi all:

cancanhuang

China Telecom

---

From: Jacni Qin <[email-masked]>
Date: Thu, 22 Sep 2011 14:27:20 +0800

Re-,

On 9/22/2011 1:58 PM, [email-masked] wrote:
> Dear Tina,
> Is there any interest on the stateful approaches? I have included it 
> for discussion in the bar bof we had in Prague but, If I remember 
> well, there was no interest.
+1.

In addition, not sure whether the specifications of Interworking 
functions are necessary. Since fortunately the signalling protocols are 
sort of IP version independent, more important thing is the address 
mapping/conversion. And they are implementations to a great extent which 
should be handled by different transition approaches according to their 
target use cases/scenarios.

Cheers,
Jacni

> Cheers,
> Med
>
> ------------------------------------------------------------------------
> *De :* [email-masked] [mailto:[email-masked]] 
> *De la part de* Tina TSOU
> *Envoyé :* jeudi 22 septembre 2011 01:14
> *À :* huang cancan; [email-masked]
> *Objet :* Re: [multrans] about the charter of Multrans
>
> Thank you, Cancan.
>
> Here is updated version, scoped down to a single use-case for which 
> there is commercial interest (i.e., IPTV).
>
> The task of the MULTRANS Working Group is to devise the means whereby 
> existing multicast mechanisms can operate successfully when signalling 
> and content have to traverse one or more IPv4/IPv6 boundaries. The 
> scope of the Working Group is initially limited to the IPTV case, 
> since the requirements for this application are better understood than 
> those for other potential multicast applications.
>
> Goals
>
> 1. The Working Group's first task is to develop a problem statement 
> that identifies the scope of the problem of multicast operation for 
> the IPTV application during the transition from IPv4 to IPv6. The 
> problem statement will identify:
>
> 2. The Multrans Working Group will develop Standards Track documents 
> specifying protocol interworking for the new combinations of protocols 
> (for example, between PIM (IPv4) and PIM (IPv6)) required for 
> multicast transition from IPv4 to IPv6.
>
> 3. The Multrans Working Group will specify the means whereby multicast 
> addresses may be translated between IPv4 and IPv6, in both stateful 
> and stateless fashion, in direct analogy to RFC 6052 for unicast 
> addresses.
>
> 4. The Multrans Working Group will specify extensions to DHCPv4, 
> DHCPv6, and RADIUS attributes required to configure hosts during the 
> transitional period.
>
> 5. The Multrans Working Group will specify the operational and 
> management capabilities required to support multicast transition. In 
> particular, this work may involve the specification of MIBs.
>
> - Work done in the Softwire working group on the use of encapsulation 
> as a multicast transition mechanism will be coordinated with the more 
> general work being done by the MULTRANS working group.
>
> - The specification for translation between IPv4 and IPv6 multicast 
> addresses will be reviewed jointly with the MBONED working group, as 
> will recommendations relating to operation and management of multicast 
> transition.
>
> - DHCP options, RADIUS attributes, and MIB modules developed by 
> MULTRANS will be jointly reviewed with the appropriate other parties 
> (DHC and RADEXT working groups, MIB Doctors directorate).
>
> - The interworking recommendations for PIM, IGMP, and MLD developed in 
> this group will be reviewed jointly with PIM, MBONED.
>
> Milestones
>
> May 2012WG adopts
>
> --problem statement draft
>
> --interworking drafts
>
> --problem statement draft
>
> --interworking drafts
>
> *From:*huang cancan [mailto:[email-masked]]
> *Sent**:* Friday, September 16, 2011 2:15 AM
> *To:* [email-masked]
> *Cc:* Tina TSOU
> *Subject:* about the charter of Multrans
>
> hi all:
>
> _______________________________________________
> multrans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multrans

---

From: Tom Taylor <[email-masked]>
Date: Thu, 22 Sep 2011 15:32:04 -0400

As co-author of RFC 6052, perhaps you can explain why that document 
dealt with stateful translation.

---

From: <[email-masked]>
Date: Fri, 23 Sep 2011 08:26:38 +0200

Hi Tom,

Please refer to http://tools.ietf.org/html/rfc6144 for the discussion stateless vs. stateful for the unicast service. In particular, RFC6144 states:

   Stateless translation can be used for Scenarios 1, 2, 5, and 6, i.e.,
   it supports "an IPv6 network to the IPv4 Internet", "the IPv4
   Internet to an IPv6 network", "an IPv6 network to an IPv4 network",
   and "an IPv4 network to an IPv6 network".

And 

   Stateful translation can be used for Scenarios 1, 3, and 5, i.e., it
   supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet
   to an IPv4 network", and "an IPv6 network to an IPv4 network".

For the multicast and taking into account the use case prioritization:

(*) we need a representation IPv6 address of an IPv4 source in an IPv6 domain: this can be done in a stateless manner using IPv4-converted IPv6 addresses

(*) we need a representation IPv4 address of the multicast group IPv4 address in an IPv6 domain: this can be done in a stateless manner using the address format defined in draft-boucadair-*.

Using these address schemes we obtain:

   o  Stateless IPv4-IPv6 header translation of multicast flows
   o  Stateless IPv4-IPv6 PIM adaptation function
   o  Stateless IGMP-MLD interworking function (e.g., required for an
      IPv4 receiver to access to IPv4 multicast content via an IPv6
      network)
   o  Stateless (local) synthesis of IPv6 address when IPv4 multicast
      address are embedded in application payload (e.g., SDP [RFC4566])
   o  Except the provisioning of the same MPREFIX64, no coordination is
      required between IPv4-IPv6 PIM interworking function, IGMP-MLD
      interworking function, IPv4-IPv6 Interconnection Function and any
      ALG (Application Level Gateway) in the path
   o  Minimal operational constraints on the multicast address
      management: IPv6 multicast addresses can be constructed using what
      has been deployed for IPv4 delivery mode.

Cheers,
Med