Hi Med, But RTCP streaming is not used much because HTTP streaming is used. Maybe that's why RFC 6346 does not mention this constraint.
Regards, Behcet > Hi Behcet, > > This property aims to assess if the proposed algorithms: > > 1. Preserve the port parity as discussed in Section 4.2.2 of > [RFC4787]. > > and > > 2. Preserve port contiguity as discussed in Section 4.2.3 of > [RFC4787] (i.e., RTCP=RTP+1). > > An elaboration is also provided in: > http://tools.ietf.org/html/draft-boucadair-softwire-stateless-requirements-00#section-2: > > REQ#8: Applications requiring even/odd and port contiguity (e.g., > RTP/RTCP) SHOULD NOT be broken due to the port set assignment > scheme. > > Traditionally the voice/video applications that use > RTP and RTCP would specify only the RTP port that the > application would use for streaming the RTP data. > The inherent assumption is that the RTCP traffic will > be sent on the next higher port. Even though RFC3605 > defines a new attribute for explicitly specifying the > RTCP attribute for the SDP-based applications, but > since it is not a MUST to use this attribute, there > are still applications that are not compliant with > this RFC. There are also non-SDP based applications > that use RTP/RTCP like H323, that make the assumption > that RTCP streaming will happen on RTP+1 port. > > Cheers, > Med > > > ________________________________________ > De : Behcet Sarikaya [[email protected]] > Date d'envoi : mercredi 14 septembre 2011 17:32 > À : 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, > > Thanks for the analysis. > I have a small question: > Compliance with RTP/RTCP applications > what does this mean? > > (BTW this is what my spell checker gave :-) ) > > Regards, > > Behcet > >> 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. >> >> 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
