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 [behcetsarik...@yahoo.com]
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: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
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
