Med, On 2011/09/14, at 14:40, <[email protected]> wrote:
> 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? > If I correctly understand his algorithm, the size of port sets depend on delegated IPv6 prefix length to each CE. As the example in his mail, a CE gets /48, then it uses whole IPv4 address, another CE gets /52, then it uses an IPv4 address with restricted to 3840 ports. cheers, --satoru > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
