【原创】无线回传网络L2VPN和L3VPN互转的需求以及实现方式

啸傲江湖

兄弟我不是搞无线的，只是因为芯片设计的需要，所以对传输网的设备需求做了不少研究。
在无线回传的传输网络中，通常在汇聚设备上，需要支撑L2VPN和L3VPN互转的gateway功能，
即该设备的下行方向的环网中是L2VPN网络，接入设备通过PW接入到该汇聚设备，汇聚设备
上行是L3VPN。



据我所了解，目前所有对L2VPN和L3VPN互转的支撑，基本上都是靠NP来做的。没有商业芯片可以支撑。
大家跟不少设备商以及运营商交流过，在盛科网络最新一代面向PTN/IPRAN的芯片CTC5160里面，支撑了
该功能。但是大家从不同地方了解到的设备需求有所差异，也可能本身就有多种模式，在这里跟
各位传输高人咨询一下，看大家的理解以及大家的做法是否有误。

大家的芯片有三种支撑模式，取决下下述需求的不同。

1. L2VPN是仅仅指VPWS接入，还是既有VPWS又有VPLS? 大家了解到的需求是主要是VPWS，但是也不排除有VPLS的应用
2.从L2VPN到L3VPN的方向，剥掉L2VPN的封装，用里面的IP header做路由查找的时候，是否需要先进行内层
   macDa的check? 如果需要，那么允许整个设备只使用一个Mac还是需要per L3VE port有一个Mac?

  大家了解到的需求是，有人说可以完全不需要check，直接查路由，有的人说需要check，但是全局用一个Mac就可以(即
  所有进来的报文的内层macDa，都跟这一个mac进行比较，相同就做路由查找，不同就丢掉），还有的人说需要per L3VE port进行check.

之所以目前的商业交换芯片都不支撑，大家不得已使用NP来做，主要的问题在于，从L3VPN到L2VPN这个方向，需要同时加两层L2 header，这个机制目前的商业芯片都没有。另外一个问题就是如果要支撑VPLS，需要查完mac再查路由，这更是一个对当前商业芯片pipleline的颠覆。最后是MacDa的check，如果要per l3ve port来做，那需要Mpls解封装之后出l3ve port信息。
所以现在的通常做法都是使用NP，进行环回处理。

盛科的CTC5160由于专门考虑了这个问题，所以芯片中做了相应的特殊处理，可以完全靠芯片内部来搞定。因为大家自己觉得算是个亮点特性，所以拿出来说一说。

具体有两种模式

1.模式一。 如果不需要支撑VPLS接入，并且上行做路由查找之前，不需要做内层macDa check或者即使check，该mac是per system mac，那无论上行还是下行都不需要环回。在下行方向(L3VPN->L2VPN)，可以一次加两层L2 header和PW/LSP label.
2.模式二。支撑VPLS接入或者需要per L3VE port进行内层Mac的check. CTC5160可以使用其专利的内部loopback技术，分两次完成MPLS解封装，mac 查找， check inner macDa, LPM查找，加MPLS label和内外层L2 header的动作。

当然，也许我的理解有不对的地方，毕竟大家不是专门做传输设备的。有误之处，敬请斧正，以便大家继续在下一代芯片改进