Mohamed, all,
First, thanks for the analysis draft. It sounds good. Let me try to bring my
thought.
An interesting point is here. In the algorithms which define offset to exclude
ports such as 1024, 4096 whatever, the efficiency of port utilization is
decreased, which algorithm is 4rd, and complexity of calculation are increased,
which algorithm is dIVI's modulo, when the number of CEs which share an address
exceed the number of excluded ports.
For example, in the case of that someone uses modulo with excluding under 1024
port, port-set ID is always placed at last 9 bits in a port if the number of
CEs which share one address isn't exceed 1024. But when the number of CEs
exceed 1024, complexity of modulo operation will be increased to calculate port
set ID from port number at BR and CE. In the case of 4rd, which exclude under
4096 port, if CEs over 4096, which CEs share one address, 8K, 16K, 32K of ports
are unusable respectively.
To keep simple implementation and operation, I think that offset port and the
maximum address sharing ratio should be same. So the question is what is the
number. 1024 is small a little. 2048 or 4096? I think that first nibble of port
to utilize offsetting is helpful for implementation and is easy to read in hex.
So In my opinion, 4096 is adequate for both offset port and maximum sharing
ratio. If it would be applied to 4rd, a following figure could be depict.
Port-set ID is always placed on right after the first nibble. CE's NAT needs to
maintain just only fifteen port ranges, and BR and CE just remove first nibble
to pick a port set ID from port number in a packet.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-set |h h h h|x x x x x x x x| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<head> |<-Port-set ID->|<-tail->
4bits max 12bits
(0x1-0xF)
Second, I think that the character differences of these analyzed algorithms
come from where is port-set ID in a port number. Each algorithms is a result of
labor to define where are port-set ID bits. I agree with last paragraph in
section 2 that says 'the whole Port-Set may be deduced by extrapolation', so it
would be predictable port set regardless of which analyzed algorithm generates.
If I add one point to the analysis, that is 'Complexity of CE side NAT ports
pool configuration and management', which NAT is already distributed to the
fields. Several contiguous port ranges are helpful to configure and manage NAT
ports pool. On the other hand, scattered scheme increases complexity of
configuration and management as the number of ports in port set increased.
So I think that having unique port set derivation for each stateless address
sharing domain is important.To make variation of port-set indexing, port-set ID
mask option could be helpful. As I'm inspired by a discussion with Xiaohong,
the port-set ID mask is used for which bits indicate port-set ID. That bits are
fully configurable by each operator's domain. In terms of port-set ID mask
configuration, the default port indexing is just one of configuration
variation. Please see a following figure.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-set |h h h h| x x x x x x x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<head> | ^ ^ ^ ^ ^ ^ ^
4bits | | | | | | |
(0x1-0xF) | | | | | | |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-set |0 0 0 0|0 1 0 1 1 0 1 1 0 1 1 0|
ID mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option <------> <---------------------->
must Port-set ID mask
be (‘1’ indicates port-set ID bits)
zero
I have no draft for that yet, but I'd like to discuss at the interim meeting.
Have a good weekend, hope to see you in Beijing, next week.
cheers,
--satoru
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
