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

[Maoke <[e-mail]>]

hi Tetsuya,

questions of trying to understand points, inline.

2011/10/12 Tetsuya Murakami <[e-mail]>

>
> 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.


how does 4rd do the check? through routing table(s) or through all the
mapping rules which is either configured or distributed or learned?


> 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.
>
>
how many additional CPU cycles (or instructions) per packet will cost in
order to put things in the last 64bits?
does it not cost CPU cycles to check whether the destination exists inside
or outside of the domain? or it is not per-packet pace?

Thanks,
> Tetsuya Murakami


thanks and regards,
maoke