Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

[Leaf yeh <[e-mail]>]

I'd like to add one more row in the below table, then let it look like as follows.

+----------+-----------------+--------------------+
|          |source address   | destination address|
+----------+-----------------+--------------------+
|  CE-CE   |                 |                    |
+----------+-----------------+--------------------+
|  CE-BR   |                 |        Yes         |
+----------+-----------------+--------------------+
|  BR-CE   |                 |                    |
+----------+-----------------+--------------------+

And one more question for you: Do you think it is really necessary to include the case while CE 4rd prefix (defined in draft-murakami-softwire-4rd-01) or CE generalized IPv4 prefix (defined in draft-despres-softwire-4rd-addmapping-01) is less than 32 bits, which sounds CE has been assigned a IPv4 subnet?


Best Regards,
Leaf



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tetsuya Murakami
Sent: Wednesday, October 12, 2011 1:55 PM
To: GangChen
Cc: Softwires-wg
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation


On 2011/10/08, at 20:14, GangChen wrote:

> As Ole said, "for the outside domain traffic" (Actually, I never argue
> that point for that case)
> Thereby, it's worth to be clarified whether need encoding whole IPv4
> address, as the below table
> 
> +----------+-----------------+--------------------+
> |          |source address   | destination address|
> +----------+-----------------+--------------------+
> |  CE-CE   |      N/A        |        N/A         |
> +----------+-----------------+--------------------+
> |  CE-BR   |      N/A        |        Yes         |
> +----------+-----------------+--------------------+


+1.

The above matrix is very clear to me.

In case of CE-BR, this case represents the traffic to the outside of the domain. In this case, I agree the full IPv4 destination address must be embedded in IPv6 destination address.

In case of CE-CE, this case represents the mesh communication between CEs. In this case, I don't think we need to embed full IPv4 destination address to IPv6 destination address. Because IPv6 destination address already includes enough information of IPv4 destination address (part of IPv4 address and port-set id).

>From the implementation point of view, 4rd function checks if the destination is existed inside of the domain or outside of the domain at the first step. If the destination is inside of the domain, then 4rd function generates the IPv6 destination address from the IPv4 destination address or both IPv4 destination address and port. If the destination is outside of the domain, then 4rd function can generate the IPv6 destination address having the full IPv4 destination address. The process of the IPv6 address generation is different on each traffic case. Hence, I think 4rd function might be having the separated code for the destination address generation and either of code can be invoked according to the result of the first step check. In fact, our implementation is having the separated code for this IPv6 address generation.

In addition, if using the unified address format in CE-CE communication as well, some additional CPU cycles per packet are required at CE in order to embed the full IPv4 address (and port-set id) in the last 64bit of the IPv6 address.

Thanks,
Tetsuya Murakami
_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires