Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-00

From: Tom Taylor <[email-masked]>
Date: Mon, 17 Jan 2011 09:00:40 -0500

A Softwires version of this document using encapsulation will be 
submitted shortly.

A new version of I-D, draft-tsou-behave-translated-multicast-00.txt has 
been successfully submitted by Tom Taylor and posted to the IETF repository.

Filename:	 draft-tsou-behave-translated-multicast
Revision:	 00
Title:		 A Generic Approach to Multicast Translation In Support of IPv6 
Transition
Creation_date:	 2011-01-17
WG ID:		 Independent Submission
Number_of_pages: 9

Abstract:
Consider a situation which will arise in many IPv6 transition
scenarios, where Network A, to which a host is attached, supports one
IP version, but the host and Network B support a different IP
version.  Suppose that the host wishes to access a multicast group
which is rooted or sourced in Network B. This document specifies a
stateful translation mechanism whereby the host can obtain its
desired access using the native multicast capabilities of Network A.

The IETF Secretariat.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Jan 2011 11:06:40 -0800

Today, multicast IP addresses are learned by hosts using proprietary 
electronic program guides (EPG) or, sometimes, via SDP conveyed in SIP, 
SAP, or RTSP.

The introduction says:

   Instead it makes use of the fact that for a given network, it is
   unnecessary to map the complete universe of IPv6 addresses into IPv4,
   but only those addresses actually being carried through the network.

Because the mapping is not algorithmic it needs to be synchronized with the 
EPG, SIP, SAP, or RTSP.  This synchronization is unique to this proposal, 
and is an additional operational burden for the network operator.  Which
makes me wonder:  what is the advantage of the dynamic mapping?

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Taylor
> Sent: Monday, January 17, 2011 6:01 AM
> To: [email-masked]
> Cc: Cathy Zhou; [email-masked]; Tina TSOU
> Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-
> translated-multicast-00
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jan 2011 19:20:20 +0000

Good question. If I read the draft correctly, I think this draft tries to
do a stateful map in the HMAF and BMAF. The pool is required to
pre-configure and the mapping is required to be synchronized between HMAF
and BMAF using a TBD OOB protocol. Before we jump to the solution. What
exact scenario we want to solve? Do we have a use case where a v4 listener
wants to receive v6 content?

Regards,
Yiu

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 14:32:31 -0500

The synchronization happens automatically. There is no burden on the 
operator. The host gets the multicast address from the electronic 
program guide, signals to the HMAF, and the HMAF asks the mapper 
(mapping function) for allocation of IPvy addresses to map to the 
signalled IPvx addresses.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 14:34:38 -0500

That is not covered by this draft. It allows an IPv4 listener to get 
IPv4 content across an IPv6 network, or an IPv6 listener to get IPv6 
content across an IPv4 network.

> wants to receive v6 content?
...

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jan 2011 21:26:06 +0000

But I thought people agree that doubt translation is bad. Why not use
softwire for this the 4-6-4 case?

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 17:26:04 -0500

A softwire draft has been prepared, but I'd like to take up this point. 
It depends on why double mapping is bad. In this case, the second 
translation is simply the inverse of the first one.

On 19/01/2011 4:26 PM, Lee, Yiu wrote:
> On 1/19/11 2:34 PM, "Tom Taylor"<[email-masked]>  wrote:
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Jan 2011 15:55:59 -0800

> Sent: Wednesday, January 19, 2011 2:26 PM
> To: Lee, Yiu
> Cc: 'Tom Taylor'; [email-masked]; [email-masked]; 'Cathy
> Zhou'; Dan Wing; 'Tina TSOU'
> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
> behave-translated-multicast-00
> 

If it is a "lossless translation", that is, the same IP address 
exists on both sides -- then the two translation functions are
equivalent to a tunnel and indistinguishable from a tunnel.  The
term "inverse" is an accurate term for such a lossless 
translation.

However, the function described in draft-tsou-behave-translated-multicast 
is not lossless -- the mapped address is chosen from a pool of 
addresses.  From Section 3.1 of draft-tsou-behave-translated-multicast:

...
   2. <Source, Group> Address Mapping At the HMAF

   The HMAF checks its cache of mappings to see if it already has a
   mapping between the IPvx <Source, Group> address pair received in the
   host request and a corresponding pair of IPvy addresses.  Failing to
   find a mapping, it sends a request for the required mapping to the
   mapping function.  The mapping function in turn checks whether it has
   already created the mapping.  If not, it assigns unicast and
   multicast IPvy addresses from its pool and records the mapping for
   further use.
...

-d

> >>> Good question. If I read the draft correctly, I think this draft
> tries
> >>> to
> >>> pre-configure and the mapping is required to be synchronized
> between
> >>> HMAF

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Jan 2011 16:01:41 -0800

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2011 11:33 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 'Cathy Zhou'

Thanks.  I see now where the draft says:

   As a result, the host-side multicast adaptation function (HMAF) needs
   to obtain a mapping between this IPvx address pair and the
   corresponding IPvy address pair used in the IPvy network to denote
   the same multicast stream.  

So -- what is the advantage of this dynamic mapping, and what is the
advantage of this round trip before joining a multicast group?  

Is there an assumption that there are more IPv6 multicast groups
than can be mapped to the IPv4 multicast space, _and_ that some
(many) of them won't have active listeners?

-d

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 20:52:07 -0500

The mapping is lossless. I think what we failed to make clear in the 
draft is that the "Mapping Function" is a centralized entity. It could 
be collocated with the border gateway, as one possibility (which I 
suspect has problems), or it could be a standalone device. Thus the 
mapping the HMAF receives from the Mapper (let's call it that) is the 
same mapping the BMAF will receive when it in turn consults the Mapper. 
  As a result, the second translation will truly be an inversion, both 
for outgoing signalling and incoming content.

On 19/01/2011 6:55 PM, Dan Wing wrote:
>     2.<Source, Group>  Address Mapping At the HMAF
>
>     mapping between the IPvx<Source, Group>  address pair received in the

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 20:54:42 -0500

Yes, that is precisely the assumption. I have in mind that Network B 
does not necessarily have any relationship to the intermediate Network 
A, so we're really contemplating a selection from the whole wide world, 
not just the provider's own content sources.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Jan 2011 18:34:27 -0800

> Sent: Wednesday, January 19, 2011 5:55 PM
> To: Dan Wing

But that can only work with IPv6 receivers, otherwise there will be 
IPv4 conflicts with the IPv4 multicast space (exactly the same as IPv4 
conflicts with RFC1918 space).  And there also isn't IPv4 on the 
Internet (the whole world) which does not appear to be changing with 
IPv6.

-d

> >>>      unnecessary to map the complete universe of IPv6 addresses
> into
> >> IPv4,
> >>>> A new version of I-D, draft-tsou-behave-translated-multicast-
> 00.txt
> >> has

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 20 Jan 2011 02:43:01 +0000

Is this similar to what draft-xu-softwire-mesh-multicast-00 tries to
solve?

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 22:22:02 -0500

I'm not sure I follow. I'm an IPv4 user attached to an IPv6 network. I 
want to listen to a multicast of an IETF meeting. Are you saying there 
will be an address conflict?

...

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Jan 2011 22:41:06 -0500

I think the Xu paper goes more deeply into the problem, by considering 
the topology required to serve many multicast groups. We aren't trying 
to do better than what PIM can accomplish.

On 19/01/2011 9:43 PM, Lee, Yiu wrote:
> On 1/19/11 8:54 PM, "Tom Taylor"<[email-masked]>  wrote:
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Jan 2011 08:10:10 -0800

> Sent: Wednesday, January 19, 2011 7:22 PM
> To: Dan Wing

* Multicast does not generally exist on the IPv4 Internet.  Yes, I know
  that a few times a year an organization called the IETF has a week-long
  multicast feed.
* Multicast generally exists within private networks, which assign their
  own multicast IPv4 addresses to whatever streams they like.
* A network, such as an ISP's network, cannot successfully interconnect
  their multicast network with "the whole wide world" because of that
  IPv4 multicast address overlap.

-d

---

From: Jacni Qin <[email-masked]>
Date: Fri, 21 Jan 2011 01:23:19 +0800

Re-,

The scenarios proposed in Abstract are confusing, IPvx -> IPvy? It seems to
conflict with later sections in the draft.

On Mon, Jan 17, 2011 at 10:00 PM, Tom Taylor <[email-masked]> wrote:

> A Softwires version of this document using encapsulation will be submitted
> shortly.
>
> Title:           A Generic Approach to Multicast Translation In Support of
> IPv6 Transition

---

From: Jacni Qin <[email-masked]>
Date: Fri, 21 Jan 2011 01:27:41 +0800

Re-,

> term "inverse" is an accurate term for such a lossless

Jacni>: May be equivalent if it is the "lossless translation". :-)
But not sure if the reconstructing of packets during the translations brings
impacts. I'm trying to check this out while it is difficult in most cases,
since many algorithms used for pretecting DRM, integrity are of property.
Maybe someone can help.

> addresses.  From Section 3.1 of draft-tsou-behave-translated-multicast:

Jacni>: Agree, the stateful translation specified in the document is not
lossless.

---

From: Jacni Qin <[email-masked]>
Date: Fri, 21 Jan 2011 01:31:51 +0800

Dear Tom,

Sorry I don't follow the point, does the centrally controlled mapping make a
difference?

Cheers,
Jacni

On Thu, Jan 20, 2011 at 9:52 AM, Tom Taylor <[email-masked]> wrote:

> The mapping is lossless. I think what we failed to make clear in the draft
> is that the "Mapping Function" is a centralized entity. It could be
> collocated with the border gateway, as one possibility (which I suspect has
> problems), or it could be a standalone device. Thus the mapping the HMAF
> receives from the Mapper (let's call it that) is the same mapping the BMAF
> will receive when it in turn consults the Mapper.  As a result, the second
> translation will truly be an inversion, both for outgoing signalling and
> incoming content.
>
>
>
>>

---

From: Jacni Qin <[email-masked]>
Date: Fri, 21 Jan 2011 01:34:01 +0800

Dear Tom,

On Thu, Jan 20, 2011 at 11:41 AM, Tom Taylor <[email-masked]> wrote:

> I think the Xu paper goes more deeply into the problem, by considering the
> topology required to serve many multicast groups. We aren't trying to do
> better than what PIM can accomplish.

Jacni>: Can you please elaborate it, not sure I understand the sentence?
Thanks. :-)

Cheers,
Jacni

---

From: Tom Taylor <[email-masked]>
Date: Fri, 21 Jan 2011 00:11:14 -0500

Not sure what this means. Are you saying a 4-6-4 scenario won't happen, 
or simply that an IPv4 user requesting connection to a multicast channel 
may get a surprise if an IPv4 network nearer the user than the intended 
one uses the same multicast address?

---

From: Tom Taylor <[email-masked]>
Date: Fri, 21 Jan 2011 00:14:10 -0500

I assure you, the mapping is lossless. One thing the whole discussion 
makes clear: we'd better add some numerical examples to the document to 
make it easier for people to see what is going on.

On 20/01/2011 12:27 PM, Jacni Qin wrote:
> Re-,
>
> On Thu, Jan 20, 2011 at 7:55 AM, Dan Wing<[email-masked]>  wrote:
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 21 Jan 2011 00:15:13 -0500

It ensures that the HMAF and BMAF receive the same mapping, thus 
ensuring that one performs the inverse translation relative to the other.

On 20/01/2011 12:31 PM, Jacni Qin wrote:
> On Thu, Jan 20, 2011 at 9:52 AM, Tom Taylor<[email-masked]>  wrote:
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 21 Jan 2011 00:17:14 -0500

PIM deals with one multicast group at a time. The Xu paper tries to 
define a structure to deal with all the multicast groups that a network 
might carry.

On 20/01/2011 12:34 PM, Jacni Qin wrote:
> Dear Tom,
>
> On Thu, Jan 20, 2011 at 11:41 AM, Tom Taylor<[email-masked]>  wrote:
>

---

From: Jacni Qin <[email-masked]>
Date: Tue, 25 Jan 2011 15:47:19 +0800

Re-,

ok, we can wait for your updates to see the details, thanks.

Cheers,
Jacni

On Fri, Jan 21, 2011 at 1:14 PM, Tom Taylor <[email-masked]> wrote:

> I assure you, the mapping is lossless. One thing the whole discussion makes
> clear: we'd better add some numerical examples to the document to make it
> easier for people to see what is going on.
>
>