z**r 发帖数: 17771 | 1 一个multicast architecture已经很老了,基本上是全网打开,造成core router大量
mroutes,费力不讨好。
现在要转到mVPN上,可是一个VRF里的不同CE对于Multicast需求不太一样,有的要求
1mbps带宽的streaming就可以,有的需要2m或者3m甚至更高,这些高要求的在访问高带
宽的stream失败的时候,会自动去尝试低一些的stream,但是只有较低资源的CE不能访
问高带宽的stream,以前的方法是放不同级别的multicast source比如content engine
到不同的地方,然后做大量boundary,很不scalable。现在的情况下,有什么更好的办
法可以解决这个问题嘛?
不知道说清楚没有,需要其他细节的,请提问。 |
c*****i 发帖数: 631 | 2 一般这个不是都是application来定的?比如一个video同时有2个mcast tream,一个1m
,1个3m,application可以根据client在site location来选?cisco的cds好像有类似
的东西。 |
s*****g 发帖数: 1055 | 3 I can understand using mVPN to reduce multicast states on core routers, but
I don't know how vrf solution would be able to make any difference in terms
of application's bandwidth selection. |
t*******r 发帖数: 3271 | |
s*****g 发帖数: 1055 | 5 data MDT is only used to suppress traffic to PE that does not have a
receiver.
【在 t*******r 的大作中提到】 : data MDT不行么
|
k*****s 发帖数: 231 | 6 可以设定缺省的mdt, 然后设定DATA MDT 应对高带宽的需求把。基本思路可以这么走,
不过得看网络里有什么产品了。 |
z**r 发帖数: 17771 | 7 感谢各位回帖。
问题是mdt只是PE到PE的,主要限制是在CE上
【在 k*****s 的大作中提到】 : 可以设定缺省的mdt, 然后设定DATA MDT 应对高带宽的需求把。基本思路可以这么走, : 不过得看网络里有什么产品了。
|
z**r 发帖数: 17771 | 8 agree
【在 s*****g 的大作中提到】 : data MDT is only used to suppress traffic to PE that does not have a : receiver.
|
z**r 发帖数: 17771 | 9 this is my issue now. I need to figure out a way to satisfy the bandwidth
selection
but
terms
【在 s*****g 的大作中提到】 : I can understand using mVPN to reduce multicast states on core routers, but : I don't know how vrf solution would be able to make any difference in terms : of application's bandwidth selection.
|
m********d 发帖数: 188 | 10
engine
好问题,综合了应用/网络、design/operation等等问题。先说说我的理解。low-speed
ce/high
speed ce,但是应用程序不知道这些,应用程序应该只依靠能否检测到相应的
streaming来决定是否
灰化button。如果向low-speed ce过滤掉高带宽stream(一开始的boundary的作用?)
,应用程
序自然检测不到,用户也不会播放。如果保持应用程序不变,那就只能想办法让low-
speed ce只收到
低带宽的stream。为不同带宽的streaming设置不同的vpn,然后配置ce的时候,根据带
宽放到不同
vpn里(当然了,3mbps ce可以加入所有的vpn)。可行么?
【在 z**r 的大作中提到】 : 一个multicast architecture已经很老了,基本上是全网打开,造成core router大量 : mroutes,费力不讨好。 : 现在要转到mVPN上,可是一个VRF里的不同CE对于Multicast需求不太一样,有的要求 : 1mbps带宽的streaming就可以,有的需要2m或者3m甚至更高,这些高要求的在访问高带 : 宽的stream失败的时候,会自动去尝试低一些的stream,但是只有较低资源的CE不能访 : 问高带宽的stream,以前的方法是放不同级别的multicast source比如content engine : 到不同的地方,然后做大量boundary,很不scalable。现在的情况下,有什么更好的办 : 法可以解决这个问题嘛? : 不知道说清楚没有,需要其他细节的,请提问。
|
|
|
z**r 发帖数: 17771 | 11 把不同带宽需求的CE放在不同的VPN里,也是俺最开始想到的solution,但是这个VPN不
单单是针对multicast,还有很多别的应用,所以最后也否了这个了。最后的解决方案
还是采用了back door,绕过了VPN的限制
speed
【在 m********d 的大作中提到】 : : engine : 好问题,综合了应用/网络、design/operation等等问题。先说说我的理解。low-speed : ce/high : speed ce,但是应用程序不知道这些,应用程序应该只依靠能否检测到相应的 : streaming来决定是否 : 灰化button。如果向low-speed ce过滤掉高带宽stream(一开始的boundary的作用?) : ,应用程 : 序自然检测不到,用户也不会播放。如果保持应用程序不变,那就只能想办法让low- : speed ce只收到
|
m********d 发帖数: 188 | 12
engine
多说说你的backdoor办法,我们也好学习学习?
【在 z**r 的大作中提到】 : 一个multicast architecture已经很老了,基本上是全网打开,造成core router大量 : mroutes,费力不讨好。 : 现在要转到mVPN上,可是一个VRF里的不同CE对于Multicast需求不太一样,有的要求 : 1mbps带宽的streaming就可以,有的需要2m或者3m甚至更高,这些高要求的在访问高带 : 宽的stream失败的时候,会自动去尝试低一些的stream,但是只有较低资源的CE不能访 : 问高带宽的stream,以前的方法是放不同级别的multicast source比如content engine : 到不同的地方,然后做大量boundary,很不scalable。现在的情况下,有什么更好的办 : 法可以解决这个问题嘛? : 不知道说清楚没有,需要其他细节的,请提问。
|
m********d 发帖数: 188 | 13
engine
多说说你的backdoor办法,我们也好学习学习?
【在 z**r 的大作中提到】 : 一个multicast architecture已经很老了,基本上是全网打开,造成core router大量 : mroutes,费力不讨好。 : 现在要转到mVPN上,可是一个VRF里的不同CE对于Multicast需求不太一样,有的要求 : 1mbps带宽的streaming就可以,有的需要2m或者3m甚至更高,这些高要求的在访问高带 : 宽的stream失败的时候,会自动去尝试低一些的stream,但是只有较低资源的CE不能访 : 问高带宽的stream,以前的方法是放不同级别的multicast source比如content engine : 到不同的地方,然后做大量boundary,很不scalable。现在的情况下,有什么更好的办 : 法可以解决这个问题嘛? : 不知道说清楚没有,需要其他细节的,请提问。
|
z**r 发帖数: 17771 | 14 现在还是纸面上的,4月份会做一个CPOC,到时候验证一下。其实俺不喜欢这个
backdoor的方法,但是似乎目前看是唯一的解。
【在 m********d 的大作中提到】 : : engine : 多说说你的backdoor办法,我们也好学习学习?
|
z**r 发帖数: 17771 | 15 CPOC胜利结束,其中对于next gen multicast也有了新的方案。最后没有走backdoor的
方式,俺实在不喜欢。最后的方法是在靠近video source的地方做boundary,这样不需
要在receiver端做大量的boundary,只不过在source一端需要给每个mVPN一个入口,也
就是create多个VRF,确保每个mVPN都可以有机会接收所有stream,该block哪个stream
,只要在boudary上限制一下就可以。
开始试了在data mdt上加个access list,但是怎么也不成功,哪位说说为什么?
【在 z**r 的大作中提到】 : 现在还是纸面上的,4月份会做一个CPOC,到时候验证一下。其实俺不喜欢这个 : backdoor的方法,但是似乎目前看是唯一的解。
|