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:[email protected]] 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, <[email protected]> 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:[email protected]] > 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, <[email protected]> > <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
