Hi Rémi, I checked draft-despres-softwire-4rd-addmapping again and you reverse only the L bits identifying the PSID. This is why I'm puzzled how it is possible to support differentiated port sets (which means distinct PSID of distinct length e.g., 4 and 6).
Cheers, Med -----Message d'origine----- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mercredi 14 septembre 2011 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, Le 14 sept. 2011 à 07:40, <mohamed.boucad...@orange-ftgroup.com> a écrit : ... > 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? Please see my answer to Satoru-san. Copy enclosed below. Cheers, RD ------------------ The AFTR doesn't need to imply any CPE prefix length to build the right DST subnet prefix (64 bits). Let's take the example of sec. 6 (A), namely: +--------------------+--------------------+-------------------------+ | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | +--------------------+--------------------+-------------------------+ | 192.32../12 | 2001:db0::/28 | 2001:db0:aaaa:aaaa::/64 | +--------------------+--------------------+-------------------------+ +-------------------------+--------------+------------------+-------+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-------------------------+--------------+------------------+-------+ | 2001:db1:1111:/48 | 192.33.17.17 | NA | 64K | | 2001:db2:2222:2000::/52 | 192.34.34.34 | yyyyxxxxxxx0100x | 3840 | +-------------------------+--------------+------------------+-------+ Let's assume that the AFTR has A+P packets to send to CPE IPv4 addresses 192.33.17.17 and 192.34.34.34 respectively, and both with dst port 0x4445. The L port bits to be included in subnet prefixes are then 2888::/15 (reversed order port bits 0-14). Destination subnet prefixes then comprise: - The Domain IPv6 prefix 2001:db0::/28 - 32 - 12 = 20 rightmost bits of IPv4 addresses, 1111:1000::/20 and 2222:2000::/20 respectively - 2888::/15 - One padding bit set to 0 They are: - 2001:db1:1111:2888::/64 - 2001:db2:2222:2888::/64 Each one starts with the CPE IPv6 prefix of the right dst CPE, which is enough to reach it. Hope it clarifies. ----------------- > > 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