城域网系列 – 5 ALU新ME的前世今生（IPTV 4）

作者 | 2010-04-26 01:18 | 类型 通讯产品 | 11条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 城域网系列

  1. 城域网系列1 – 前传（上）
  2. 城域网系列1 – 前传（下）
  3. 城域网系列2 – ATM插曲
  4. 城域网系列 – 3：大片之前的加片（上）
  5. 城域网系列 – 3：大片之前的加片（下）
  6. 城域网系列 – 4 AL ME大片前以太网的总结
  7. 城域网系列 – 5 ALU新ME的前世今生（上）
  8. 城域网系列 – 5 ALU新ME的前世今生（中1）
  9. 城域网系列 – 5 ALU新ME的前世今生（中2）
  10. 城域网系列 – 5 ALU新ME的前世今生（中3）
  11. 城域网系列 – 5 ALU新ME的前世今生（中4）
  12. 城域网系列 – 5 ALU新ME的前世今生（中5）
  13. 城域网系列 – 5 ALU新ME的前世今生：L2VPN
  14. 城域网系列 – 5 ALU新ME的前世今生（VOIP和IPTV）
  15. 城域网系列 – 5 ALU新ME的前世今生（IPTV 2）
  16. 城域网系列 – 5 ALU新ME的前世今生（IPTV 3）
  17. 城域网系列 – 5 ALU新ME的前世今生（IPTV 4）
  18. 城域网系列 – 5 ALU新ME的前世今生（MPLS/TE）
  19. 城域网系列 – 5 ALU新ME的前世今生（下）
  20. 城域网系列 – 6 另类玩法PBT
  21. 城域网系列 – 7：FMC 决战城域网（1）
  22. 城域网系列 – 7：FMC 决战城域网（2）
  23. 城域网系列 – 7：FMC 决战城域网（3）- 又见ATM
  24. 城域网系列 – 7：FMC 决战城域网（4）- 3G、IP和数据
  25. 城域网系列 – 7：FMC 决战城域网（4）- 3G、IP和数据（continue）

3、 频道监控
OAM在什么情况下最需要？一个是因为质量差而构筑复杂的协议和保证系统，比如X25，ATM，一个是一堆各种豆子给灰姑娘出难题，像triple play，FMC。TV在过去单一的传输体制下，承载网络并没有很高的OAM需求，但是在triple play甚至更美的FMC下，问题就来了，这里一个IPTV的小问题，就可能和其他各种业务混在一起，而人类对视频的敏感比语音还高，闪电快于惊雷，所以大家最相信的是自己的眼睛，有时听了不信，要偷拍才成。从这个角度看，SDH也是一个简单优美，scalability好的技术和网络，以致WDM也做SDH化成为现在的OTN标准
对于基于channel和flow的视频，用通用的IP/MPLS OAM可以解决网络问题，但是更精确到channel和flow，是没有办法的，但是现实生活中，别人家电视好好的，就我家不能看的情况也不是非常罕见，并且对于电信/广电运营商，大家从即使感觉上也喜欢看到对每个频道质量的监控，具体原理不是十分复杂，无非是每条流做时延抖动丢包的监控统计和定位。但商用实现起来却不容易
（1） 识别视频流：比如识别RTP流等，这个不是很难
（2） 时延和抖动：这里双向不是问题，如果秒级也不是但，但视频流是单向的，并且是毫秒级的，所以就需要在时间戳处理上，增加时钟同步功能，而高精始终是需要硬件做一些配合的
（3） 需要同头端到尾端的所有包转发设备都支持，才好
4、 增值广告
这个就是看以Google为主的基内容分析的精准广告推放眼红，运营商也希望为自己的IPTV用户欣赏的到自己喜欢的广告努力一下，但这个东西，放在承载网络未必合适，把广告插入到正常的频道中，不是是抢ICP的饭碗吗？所以可能还是在IPTV系统上实现比较好，比如送给客户一个超宽屏的彩电，两边的区域用于显示广告，再搞个传感器，看用户的眼球是关注美女的眼睛，还是breast，来决定是做眼睛美容广告还是丰胸广告，当然，再精确一点还有看用户的胸围，如果已经是几个F了，那就别再推丰胸广告了

在IPTV的系统优化方案上，CISCO其实是走的最先的，但目前AL走在前头，可见思科在城域这块目前的投入情况，因此导致思科城域产品青黄不接（C76和ASR9K）的困境也不太难理解了。

IPTV的种种问题，来源于紧密融合型triple play对传统电视的传输改变太大，那么能否还是用独立通道的模式做IPTV，当然有人这么想并且这么做，就是美国的Verizon，通过FTTH，整个IPTV系统，单独用一个波长做IPTV，一根λ的管子到底，中间也不要什么啥子组播了，啥都生了。据说很成功，但是为不使用全球这么多运营商，毕竟FTTX的投入不是很多运营商能很快做到的。

具体在到AL的VPLS组播方案，本身也是非常复杂，比L3还复杂，所以还不如直接就L3组播到边缘，只是过去大家的惯性观点，再加上现在的供应商为了自己的方案和产品优势及多收钱考虑，把L3组播忽悠成比VPLS贵的方案，至于L3组播故障收敛慢的问题，目前已经有相对成熟的方案解决了，不是大问题。L3组播的主要问题是VPN的问题，组播VPN很复杂，而MPLS的P2MP组播技术最近才看是成熟，导致L3组播不能和MPLS很好的结合，有些不爽。在MPLS的组播方面，J做得最好

系列前一篇 系列下一篇
(3个打分， 平均：3.67 / 5)

工具箱
本文链接 | | 打印此页 | 11条用户评论 »

雁过留声

“城域网系列 – 5 ALU新ME的前世今生（IPTV 4）”有11个回复

  1. fpeking 于 2010-04-28 6:24 上午

    to be honest, you spend lots of words to mention those thing that is not relevated to 7×50 at all.
    If I can input Chinese I would like to say:
    You Chou You Chang

  2. 理客 于 2010-04-28 12:46 下午

    to fpeking:
    Thank you for your criticism due to partly fact, it is from 7750, but beyond it, each one has his opinion freely, it does not matter of the same or not.
    My English is not so good, and I also hope you can input Chinese criticism to avoid some misunderstanding although any curious persion is possible

  3. 陈怀临 于 2010-04-28 3:25 下午

    客客的英文确实好像比我都差一些。fpeking, we’d really appreciate what keke’s been doing for the metro part. Should you have some ideas, why not write it down as an article and we can discuss then…?

  4. 理客 于 2010-04-28 8:14 下午

    是的，我英语还要很大的增长空间

  5. fpeking 于 2010-04-29 2:06 上午

    昨天我的中文输入法有点问题，所以选择写英文，没有批评的意思。是觉得这个系列的东西，猛看上去是要写城域网，再一看又是在写7×50。在仔细一看吧，又觉得综述里面很多不清不楚的东西。像是市场文章，不像是技术文章。例如后面一个系列讲到PW Redundancy, mc-lag, mc-ring，实际可以去展开分析的东西多得很。但是蜻蜓点水的一过，要么就是不懂，要么结果就是：懂的人知道是什么，不懂的人看上去就是一个符号。
    所以我觉得，需要的是精，不是多。

  6. fpeking 于 2010-04-29 6:04 上午

    收回我前面说的话，LZ要盖大楼，和修别墅还是有差别的。
    另外其他几个系列似乎比 IPTV写的还是精。

  7. 理客 于 2010-04-29 6:16 上午

    如fpeking所说，是以市场为中心，具体技术细节除非有特别之处，否则不会过多涉及和分析，只是蜻蜓点水说明用处。主要目的是要说市场和技术是如何互相选择和结合的，对没有ME基础的，读起来会有些痛苦，对希望技术细节分析的，也会比较失望，个人精力和能力有限，勉为其难，希望多批评

  8. 理客 于 2010-04-29 6:30 上午

    本想盖三间草房做别墅，不小心还是盖成了象大楼的草房

  9. 过客 于 2010-04-30 12:11 上午

    市场领引技术。支持笔者

  10. malabas 于 2010-05-14 10:35 下午

    三层组播到边缘是一个趋势，组播一定要走P2MP路才能有保护和快速收敛能力吗，非也。随着路由IP FRR盛行，在菊花链和典型双归的网络上，使得双JOIN单发组播流的IP保护成为可能。这是个技术创新为王的年代。

  11. smoke 于 2010-06-26 11:04 上午

    没搞明白楼上的说FRR、Multihoming与IPTV组播间是何关系～～～
    要说保护那也应该是另外一个topic吧？