Hi Rémi,
I didn't get my answer yet. I'm looking for the explanation about the behaviour
of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned
with port sets of different sizes. What is the configuration of that node?
Cheers,
Med
-Message d'origine-
De : Rémi Després [mailto:despres.r...@laposte.net]
Envoyé : mardi 13 septembre 2011 19:42
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms
(draft-bsd-softwire-stateless-port-index-analysis)
Le 13 sept. 2011 à 18:08, mohamed.boucad...@orange-ftgroup.com a écrit :
Hi Rémi,
Thank you or your answer but my question was not on the CPE side but the
operations at the border router side.
The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE
doesn't need to know the length of the CPE IPv6 prefix of that BR.
This is a major difference with the old 4rd where this length was a rule
parameter. (It is now a parameter only with the CPE-cascade option, to be
ignored for this discussion.)
As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6
address L bits from the A+P port.
This length L is 14 bits unless it has to be limited for this prefix to fit
into 64 bits.
The result can be a subnet prefix that typically differs from the CPE IPv6
prefix, with some extra port bits after the CPE IPv6 prefix.
However, because the subnet prefix does start with the CPE IPv6 prefix, the
packet reaches the CPE.
There, the 4rd IID is enough for the packet to be recognized as a 4rd packet.
Is this, now, the explanation you were looking for?
Cheers,
RD
Cheers,
Med
-Message d'origine-
De : Rémi Després [mailto:despres.r...@laposte.net]
Envoyé : lundi 12 septembre 2011 17:05
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms
(draft-bsd-softwire-stateless-port-index-analysis)
Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com
mohamed.boucad...@orange-ftgroup.com a écrit :
...
To double check the ability of 4rd-addmapping algo to support differentiated
port sets without any state on the BR, could you please provide some
examples to show this behaviour? FWIW, below are listed some configuration
proposals:
With 4rd-addmapping, of port-set sizes are directly derived from lengths of
delegated IPv6 prefixes.
Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the
port set of B is 2^k times smaller than that of A.
Besides that, IPv6 prefixes are assigned without any constraint coming from
IPv4.
(1) Differentiated port sets bound to distinct IPv4 address
* Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1
* Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2
(2) Differentiated port sets bound to the same IPv4 address (Because 0-4095
range is excluded, (n+1)*4096 + m*1024 = 2^16))
* Port sets of 4096 ports assigned to n CPEs
* Port sets of 1024 ports assigned to m CPEs
First, note that, because of privileged-port exclusion for fairness, port-set
sizes of 4rd are 15/16 * 2^k.
For (1):
- POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have
15/16*4096=3840 ports per CPE).
- POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have
15/16*1024=960 ports per CPE).
For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of
length L+2 to m CPEs.
OK?
Cheers,
RD
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
