MPLS-TP: 一场ITU和IETF的战争

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




ITU的SDH/Sonet技术发展遇到了瓶颈,不能满足日益增长的数据业务需求了,于是自然而然的想到找一个取代技术。而ethernet, IP/MPLS发展得如火如荼,各种新技术层出不穷,可惜,很多地方不适合做电信级传输网,于是ITU就想到对MPLS进行改良,用改良后的MPLS来做packet transport network,这就是T-MPLS。

可是ITU没料到的是,由于T-MPLS对MPLS的改动有点伤筋动骨,导致了跟MPLS的不兼容,触及到了IETF MPLS阵营的核心利益,就好像我辛辛苦苦搞了一个发明专利出来,你一声不响的拿过去,改头换面,准备推广赚钱,我自然是不答应。结果就是T-MPLS还没大面积推广,就受到了IETF的强烈抵制。于是在争吵与妥协中,ITU和IETF联合工作组MEAD成立了,MPLS-TP诞生。

联合工作组MEAD中,IETF占据了强势主导地位。制定标准的过程中也不忘了利用自己的特权攻击一下ITU,RFC5704把这种行径暴露无疑,我电脑上的RFC 5704我给它还取了一个后缀,整个文件全名是RFC 5704—扯皮.txt,其实不是扯皮,是IETF攻击ITU.现摘抄几段:

2.4章我把它称为“争权”

A code-point such as an IEEE Ethertype is allocated to a design authority such as the IETF. It is this design authority that establishes how information identified by the code-point is to be
interpreted to associate appropriate invariants. Modification and extension of a protocol requires great care. In particular, it is necessary to understand the exact nature of the invariants and the consequences of modification. Such understanding may not always be possible when protocols are modified by organizations that don’t have
the experience of the original designers or the design authority expert pool. Furthermore, since there can only safely be a single interpretation of the information identified by a code-point, there must be a unique authority responsible for authorizing and documenting the semantics of the information and consequential
protocol actions.

In the case of IP and MPLS technologies, the design authority is the IETF. The IETF has an internal process for evolving and maintaining the protocols for which it is the design authority. The IETF also
has change processes in place [RFC4929] to work with other SDOs that require enhancements to its protocols and architectures. Similarly, the ITU-T has design authority for Recommendation E.164 [E.164] and
allocates the relevant code-points, even though the IETF has design authority for the protocols (“ENUM”) used to access E.164 numbers through the Internet DNS [RFC3245].

It is a recommendation of this document that the IETF introduces additional change mechanisms to encompass all of the technical areas for which it has design authority.

2.5章我把它称为“隐式攻击“

It may be tempting for a designer to assert that the protocol extensions it proposes are safe even though it breaks the invariants of the original protocol because these protocol variants will operate
as ships in the night. That is, these protocol variants will never simultaneously exist in the same network domain and will never need to inter-work. This is a fundamentally unsound assumption for a
number of reasons. First, it is infeasible to ensure that the two instances will never be interconnected under any circumstances. Second, even if the operators that deploy the protocols apply
appropriate due diligence to ensure that the two instances do not conflict, it is infeasible to ensure that such conflicting protocols will not be interconnected under fault conditions.

3.1章我把它称为”显式攻击”

A recent example where another SDO created a protocol based on misunderstandings of IETF protocols is T-MPLS. T-MPLS was created in ITU-T in an attempt to design a packet-transport method for
transport-oriented networks. This is an example of the success that IETF protocols have enjoyed, and ITU-T’s interest and selection of MPLS is a compliment to the IETF work. Quite late in the ITU-T
design and specification cycle, there were a number of liaison exchanges between the ITU-T and the IETF, where the IETF became increasingly concerned about incompatibility of IETF MPLS procedures
and technologies with ITU-T T-MPLS [RFC5317]. Extensive discussions took place regarding interpretation, definition, and misunderstandings regarding aspects such as MPLS Label 14, MPLS swap
operation, TTL semantics, reservation of additional labels, and EXP bits. If ITU-T had worked with IETF from the start in developing T-MPLS, these problems could have been avoided. A detailed analysis
of the T-MPLS case is provided in Appendix A.

顺便提一下,这个RFC的三个作者都是IETF的,其中两个是Cisco的,一个是IAB(Internet Architecture Board)的:)

(2个打分, 平均:3.00 / 5)

雁过留声

“MPLS-TP: 一场ITU和IETF的战争”有17个回复

  1. 打酱油的干活 于 2010-10-30 1:58 下午

    说的问题不错, 但言语有明显的电信倾向性。说IETF攻击ITU是对协议控制权的竞争, 只是这个问题显露的一方面。

    超越厂家和组织的不同, 总的来说IP网和电信网有许多基本理念上的不同。这些理念就像宗教和哲学一样,经过多年严密的发展, 都有强大的粉丝团支撑。两个组织中有许多人对这些基本理念有着虔诚的信仰。这些理念不是做个简单比较说谁比谁强就可以令人信服的。信仰的争吵有可能永远没对错。

    MPLS-TP端到端强控制的思想与IP网智能在节点的思想有根本的冲突。ITU与IETF, 华为/阿朗与思科/瞻博可能要碰撞好久。

    就我个人看来传统电信网被全面IP化。 恰恰说明了IP和IETF的许多理念是有强大生命力的。

  2. CC 于 2010-10-31 5:44 上午

    cisco,juniper是不遗余力的贬低ITU的,坚决不会支持T-MPLS那套东东的,而HW不会坚决支持ITU,基本上HW只是想赚钱,什么标准出来,它就支持什么好了,而自己在电信和IP的积累,致使它在TP这个领域必然会具有一定优势。而AL和HW差不多,不会像C,J力挺IETF那样支持ITU的。而从TP的进程来看,ITU真是没地位,IETF真是一点面子也不给它留啊。

  3. CC1 于 2010-10-31 5:53 上午

    HW这次不错啊,TP的RFC,HW占了不少份额。就从运营商这个角度,HW机会很多啊。

  4. 理客 于 2010-10-31 12:09 下午

    ZZ对技术确实影响很大,但同时也不能忽略技术本身是否符合市场需求的技术优劣,最终结果一定是一个多方的妥协,比如IP本来是非常自由的,但运营商网络基本不允许自由的路由,因为这样对运维会带来灾难性后果,所以给予路由的复杂拓扑,metric处理,是第一要处理好的,也因此给负复杂网络拓扑带来许多难题,进而流量管理引入到TE…和现实世界一样,网络也是在一个合理约束下的自由才有稳定的生命力

  5. droplet 于 2010-10-31 8:22 下午

    电信公司干不过网络公司,这是一个大趋势。

  6. 通信人生 于 2010-11-01 7:29 上午

    现在中国三个运营商联合一个Italia运营商,说一定要用基于Y.1731的OAM,摒弃IETF所力推的BFD,并且可能把它上升到类似TD那种国家战略的高度,按照中国运营商的性格特点,可能最后就变成:不管你们IETF推什么,不管你Cisco, Juniper怎么叫唤,想进中国市场,就要按照我的规则出牌,你要仅仅支持BFD是吧?那对不起,别进来。不过这次中国的运营商说不定做了一件正确的事情,Y.1731已经相对成熟了,干嘛一定要在BFD上另起炉灶?

  7. ab 于 2010-11-01 7:41 上午

    这是因为国内的运营商在PTN领域做的很早,像电信的PTN,就是基于T-MPLS的,那他当然希望这个是行业标准了。

  8. 闲言 于 2010-11-01 9:35 上午

    有趣的RFC,分析的很好:)不过它的作者只有两位,都是思科的,IAB不是作者,而是IETF的指导机构。这叫做代IAB捉刀,不需要投票的。

  9. 闲言 于 2010-11-01 9:42 上午

    MPLS-TP面向的是一个传送网和IP网趋向融合的一个市场,两边当然都很重视了。实际上,除了竞争之外,两边也有互相学习的地方。传送一方借用了MPLS的标签交换机制,而边缘路由器也多半实现了Y.1731。

  10. ccc 于 2010-11-04 7:47 上午

    mpls tp oam 在中国由中国研究院牵头主导mpls tp based Y1731为mpls tp的标准;从当前实现角度和可行度来讲,比较容易实现,兼容性也比较好,至少现在商用的Y1731(802.1ag)都是比较成熟的技术,对于报文丢失率,时延都有对应的解决方案;相对于mpls tp based BFD目前仅仅是定义一个CV的标准出来,其他的消息类型千呼万唤还没出来。

  11. ccc 于 2010-11-04 8:01 上午

    我感觉BFD就是一个畸类的协议,bfd interval的间隔都不知道是怎么想出来的,值的范围是U32的范围,粒度是1ms,理论依据是什么?

  12. ccc 于 2010-11-04 9:01 上午

    对于前者由于Y1731(802.1ag)协议上是比较成熟,但是报文的封装和网络的部署目前还没有成熟的方案,所以在实现时不知道如果去做?主要变现为:

    1) 是否支持点对多点?如何支持?
    2) 在MIP 上处理LBM并回复LBR如何实现?难道还要为之建一张MIP的表,里面包含MEP 的信息,包括LBR回去携带的Label?
    3)目前在最新的draft文档中提到MIP可以per interface 活per node实现?具体实现如何做?

  13. jjww 于 2011-03-28 11:46 下午

    电信公司干不过网络公司,这又从何说起?哪些是电信公司,哪些是网络公司?列举一下

  14. ccc 于 2011-03-31 8:20 上午

    按目前的发展趋势,Y1731 已被ITU定为 MPLS TP OAM的标准,不知道何时能公布

  15. 通信人生 于 2011-04-01 7:10 上午

    其实Y.1731 based OAM挺好的,很成熟了。 Cisco/Juniper这帮恶心的人非要为自己利益考虑搞BFD进来。

  16. ccc 于 2011-04-01 8:49 上午

    特别是BFD的interval,微秒级,如果让芯片实现微妙级的时间间隔,简直就是一种白痴的做法。

  17. IE 于 2011-04-05 2:36 上午

    恩?J也支持Y.1731啊,怎么就恶心了…