AG真人

  • <tr id='0P6Ip2'><strong id='0P6Ip2'></strong><small id='0P6Ip2'></small><button id='0P6Ip2'></button><li id='0P6Ip2'><noscript id='0P6Ip2'><big id='0P6Ip2'></big><dt id='0P6Ip2'></dt></noscript></li></tr><ol id='0P6Ip2'><option id='0P6Ip2'><table id='0P6Ip2'><blockquote id='0P6Ip2'><tbody id='0P6Ip2'></tbody></blockquote></table></option></ol><u id='0P6Ip2'></u><kbd id='0P6Ip2'><kbd id='0P6Ip2'></kbd></kbd>

    <code id='0P6Ip2'><strong id='0P6Ip2'></strong></code>

    <fieldset id='0P6Ip2'></fieldset>
          <span id='0P6Ip2'></span>

              <ins id='0P6Ip2'></ins>
              <acronym id='0P6Ip2'><em id='0P6Ip2'></em><td id='0P6Ip2'><div id='0P6Ip2'></div></td></acronym><address id='0P6Ip2'><big id='0P6Ip2'><big id='0P6Ip2'></big><legend id='0P6Ip2'></legend></big></address>

              <i id='0P6Ip2'><div id='0P6Ip2'><ins id='0P6Ip2'></ins></div></i>
              <i id='0P6Ip2'></i>
            1. <dl id='0P6Ip2'></dl>
              1. <blockquote id='0P6Ip2'><q id='0P6Ip2'><noscript id='0P6Ip2'></noscript><dt id='0P6Ip2'></dt></q></blockquote><noframes id='0P6Ip2'><i id='0P6Ip2'></i>
                IETF主席回应New IP
                发布时间:2020-04-07    来源:未知
                【字体: 】   【打印本页】   【关闭窗口

                不久前,国际电联ITU-T审议了有关“新IP,塑造未来口中却感动网络”的文案。该文案□ 提出,应以一种新IP的方式重新设计互联网。

                  国际互联网技术和标ζ准组织IETF主席于3月30日◣发表声明,就新IP提出的技术问题冷暖逐一进行了回应。这份声●明表示,没有任何证据表明,互联网需要一个换做你自上而下设计的独立的“新IP”体系结构。

                声明全文

                亲爱反面正义的同事们,

                  互¤联网工程任务组(IETF)感谢有机会☆回应您的联络声明。虽然我们了解这些意见可能已经在电在我看来信标准化咨询小组(TSAG)会议上考『虑过,我们仍然要求这些意见在召开世界电信标准化全会♀(WTSA)之前的会↙议流程中予以考虑。

                  互联网的成功源∑于TCP/IP灵活的模块化体系结构

                  IETF开发了TCP / IP协议栈,也将继续维护和▓扩展它。我们相信,互联网的成功源于TCP/IP协议栈灵活和模块化的体系结构」。其中IP协议提供的基础结构用丰富的异构应用程序连▼接了丰富的异构网络。我们希望现有的协议栈能像过去50年一样继续发≡展以满足新网络和新应用的需求,我们还没有看到任何证张云峰是张耀德据表明我们需要一个自上届时而下设计的独立而庞大的“New IP”体系结构。

                  在审阅您㊣的联络声明所含提案时,我们发现有一些缺乏证据支持或不正确的△内容。其中第一条是:“首先,由于历史原】因,当前网络的设计仅适用于两种设备:电话〓和计算机←。”

                  IP协议栈的基本设计不限于电话和计算机,而是涵盖恩情了非常广泛的设备,甚至包括了提案中认为是未来工作天地同化部分的许多设╳备。例如提案在与“物联网(IoT)”设备相关的工作中提到“物联网和工业互联网的发展将在未来网络中引入更∩多类型的设备”。而物联网设备在互联网上的集成已经进行了♂十多年。IETF的一个与物联网相关的工作组--Constrained RESTful Environments工作组(CORE)刚刚迎来了它已经是曲平的十周年;在此期间,物联网设备数量已你走吧达到数十亿。IETF已经完成★了在网络中集成和管理物联网设备的大量工作,正如RFC8520所体现的。有关IETF在物联网工作方面的概述,请访问<https://www.ietf.org/blog/ietf105-iot-wrapup/>。

                  提案中来世若你还在同样将卫星网络与IP地面网◣络集成中的传输需求看成一项新的挑战。而在1999年公布的RFC2488中就描述了卫※星信道上的TCP协议。IETF在这方面的工作也从未停止,etosat@ietf.org邮件列表中有一个活跃的社区,致力于将QUIC协议应用于卫星通↘信;QUIC for SATCOM(<https://datatracker.ietf.org/doc/draft-kuhn-quic-4-sat/>)则讨论☆了如何在卫星通信中集成非TCP协议的问题。

                  提案提出的另一组问题是关于超低延迟的用例需求。消除不必要的延△迟是IETF和ITU(国际电信联盟)长期〖共同关注的工程目标。IETF在这个领域的研究历史可以追溯到上世纪90年代,先后提出了多种技他未必就不敢动术,例如集●成服务(IntServ),资源保留协ω 议(RSVP),多协议标签交换(MPLS),差异化服务(DiffServ)和ξ主动队列管理(AQM)。在过去的五年往右走中,我们还看到了对这一领域的高度关注,并涌现出众多新的进展:定向HTTP、传也伸出了右手与握在了一起输层安全(TLS)、QUIC、确定性来排除异己网络(DetNet),以ξ 及其他低延迟、低损耗、可扩展吞吐量(L4S)技术。

                  那些对网络抖动、延迟和吞吐量等属性有严格要求的应用程序如今已部署在互联网上,同时并没有使用提案中设想的紧密的跨层链接,而都是部署◤在现有协议和设计约束之下。这紫迷蝶翼冷流年些应用程序,包括会议、增强现实和游虽然是个活脱脱戏,为改进Internet协议的特性提供了▓市场动力。IETF正在多个领域中开展网络组件或协议层次之间的协调工作。我们相信,这■些努力能够提高这些性能指标,同时也认识》到设计上的其他限制,包括业务需求、安全性和隐私权。我们希望这些努力能满足新型实时应用但这样的需要,包括全息通信,而无需新▅的网络体系结构。我们还注№意到,由于光速的限制,任何需要亚毫秒级延迟的实时系统都不可避免地具有局限╱性。

                  互联网让所有用户从“无需许可将自己的创新”中获益

                  提案还提出了一套关于新的身份这是一个不能让他安逸自如识别系统的你看不出来么几个期望属性。其虽然英气逼人中一种说法是“异构地址空间应该能够彼此交→流。” 但是,这似乎与提案中其他的描述冲突,因为提案中另一段说法是:“如果所有技术都使用自时候自己错过了己的协议作为内部通』信语言,那么在技术岛屿之间的通信就必须部署复杂的'翻译器'。”

                  不相交的寻楚大老板摇摇晃晃址系统必须要求独立的路由以确保每个系统就在此刻的可达性。尽管这可能通过蛋蛋分层路由(如RFC 8660中定义的SR-MPLS技术,是在IP路由︽之上层次)来解决,使用没有公共基础的◥异构地址空间意味着在不同的域间必需使用复杂的翻译程序才能实现互联互通。而这种∏翻译需要维护额外的网络状态以实现互操作性,这可能会增加网络的脆弱性和通信延迟。

                  我们理解这与异构□网络互连互通的设计目标背道而▲驰。IETF相信这体力也会有耗尽个设计目标(我们通常表达为互操作性的◣需求)对于IP和Internet的发展至关重要(参见1996年发布的RFC 1958)。保持互操作性让新∮的应用系统可以加入当前网上面冲下三个西装打扮络,可以利用现有的网络成果和╲已经建立的基础设施。这就是互联网实现的所有网络用户可以从“无需许可的创新(permissionless innovation)”中获益。

                1.png

                  IETF一直致力〓于实时系统、不同地面和卫星网络之间的集成,以及诸如QUIC等新传********************************************************************输协议方面的工作,IETF相信,当前IP协议栈的发展将使我们能够达到您建议书中所提出的目标。我们很高兴看到业界对这些研究的热情卐日益高涨,我们也热情地邀请大家共同参与并作出贡献。

                  迄今为止,对于您联络声明中提及的扩展或替换现有IP协议栈的工作,我们在IETF中◇尚未收到任何相关的正式提案。但我们将第三十二 洗经始终对讨论此类提案保持开↑放的态度。

                  以自上而下的设计代替现有的IP协议栈将是有害的

                  近年来,IETF的工作意思是说越来越重视并行协议的实现和协议标准的开发⌒过程,以便从初步实施和互操作性测试中获得经验并反馈到标准的设计中。例如,HTTP/2,TLS 1.3和QUIC等协议就从数十个不同的实权势现中获益匪浅,这些实现是在Ψ 标准制定过程中开发的,并在整个互联网的规模上进行这柱灭门惨案了测试。未来标准◆化工作的成功很大程度上取决于现实中不同供应商的实现经验能〓反馈到标准制定过程中,而不是试图预测无疯翎法在互联网规模上进行测试⊙的需求和要求。

                  提案中没有清楚表达其意图,是要扩展或发展◥现有的IETF协议(例如IP协议),还是完全我们师兄弟三人也甚是内疚取代它们。IETF为了保障全球互操作性暗灭之魂的权益∞,对IP协议栈的规范保无疑也很重视自己有版权和更改控制权。如果提案①的目的是扩展IETF的协议,我们希望提醒您注意IETF先前发布↑的IETF最新话对他们来说有如圣旨最佳实践文件“Procedures for Protocol Extensions and Variations(协议扩展和变更过程,RFC 4775,BCP 125),其中描述了扩展或修改IETF规范的∩通用流程。在与包括ITU-T在内的其他标准开发组织讨论前虽然最后安月茹,对IETF技术的扩展或修改的要○求是必须先与IETF进纵然他已经经历了一次历史行交流和讨论∴。我们要求ITU-T鼓励那些ITU-T社区中想要更改或扩展IETF技术的人们,将他们的需求和提案带到IETF来,并且在IETF有机会讨论这些就是因为她提案前,ITU-T拒说着不等他答话绝接受它们。IETF也会对扩展ITU-T技术的提案和建议进行同样的处理。

                  总之,我们相信以这种自上而下的设计代替现有的IP协议栈的工作将是就算是皇帝又怎样有害的。这样做将很⌒ 可能会创建出网络孤岛,破坏网络︻互连,并危害网络的互操作性。自上而下的方法将无法满足不断发展的☆应用生态系统。我们更信任现有网络持续的模块化和弹性的进化方案,我们欢迎与所有有兴√趣的各方进行合作以提供服ω务。我们看不师父出有任何证据表明,提案中所描述的挑战不能通过现〗有IP协议套件●的不断发展而获得解决。

                  回应声明英文原文如下:

                Dear Colleagues,

                The Internet Engineering Task Force (IETF) appreciates the opportunity to respond to your liaison statement. While we understand the Telecommunication Standardization Advisory Group (TSAG) meeting at which these comments might have been considered is past, we request that they be considered in the process leading up to the World Telecommunication Standardization Assembly (WTSA).

                The IETF developed the TCP/IP protocol stack and we continue to maintain and extend it. We believe the Internet's success has resulted from its flexible,modular architecture, with IP providing the fabric that connects an incredible wealth of heterogeneous networks with an incredible wealth of heterogeneous applications. We expect the existing protocol stack to continue to evolve to meet the needs of new networks and applications, just as it has for more than 50 years. We have not seen any evidence of the need for a monolithic "New IP"designed from the top down.

                In reviewing the proposals included with your liaison statement, we find that there are several statements that are unsupported or incorrect. The first of these is: "Firstly, due to historical reasons, the current network is designed for only two kinds of devices: telephones and computers."

                The fundamental design of the IP protocol stack is not limited to telephones and computers, but encompasses a very broad range of devices, including many that the proposals consider as future work. Work related to "Internet of Things" (IoT) devices is, for example, noted as "the development of IoT and the industrial internet will introduce more types of devices into the future network." Yet the integration of IoT devices on the Internet has been taking place for over a decade. One of the relevant working groups in the IETF,Constrained RESTful Environments (CORE), just passed its tenth anniversary;during this period IoT devices have come to number in the billions. Much work has already been done to integrate and manage these devices on the current network, e.g., in RFC 8520. A useful overview of IETF work on IoT is available at <https://www.ietf.org/blog/ietf105-iot-wrapup/>.

                The proposals similarly treat the transport requirements associated with the integration of satellite networks with IP terrestrial networks as a new challenge. Yet RFC 2488, which describes TCP over satellite channels, was published in 1999. Nor did the IETF's work on this stop at that point; the etosat@ietf.org mailing list has an active community working on QUIC's application to satellite communications; QUIC for SATCOM <https://datatracker.ietf.org/doc/draft-kuhn-quic-4-sat/> is one contribution to that discussion which touches particularly on the question of a non-TCP protocol's integration with satellite communications.

                Another set of issues raised by the proposals were for use cases which are asserted to require extremely low latency. Eliminating needless latency is, of course, a useful engineering objective that both the IETF and the International Telecommunication Union (ITU) have worked on extensively. The IETF's work in this area dates back to the 1990s and spans the development of such technologies as Integrated Services (IntServ), Resource ReSerVation Protocol (RSVP), Multiprotocol Label Switching (MPLS), Differentiated Services (DiffServ), and Active Queue Management (AQM). Over the last five years we have seen an intense focus in this area targeting HTTP; Transport Layer Security (TLS); QUIC; Deterministic Networking (DetNet); and Low Latency, Low Loss, Scalable Throughput (L4S), among others.

                Applications that are regarded as having tight requirements from the network with respect to properties like jitter, latency, and throughput are being deployed on the Internet today without requiring the type of tight cross-layer linkage that the proposals envision. This occurs within the constraints of existing protocols and designs. These applications -- which include conferencing, augmented reality, and gaming -- produce market pressure to improve these characteristics for Internet protocols. Efforts to improve coordination between network components or layers are ongoing in several areas in the IETF. We believe that the efforts most likely to improve performance on these metrics also recognize other constraints on design including business imperatives, security, and privacy.  We expect those efforts to continue to meet the needs of newer real-time applications, including holographic communications, without the need for a new network architecture. We also note that any real-time systems requiring sub-millisecond latency inevitably have limited scope because of the constraints of the speed of light.

                The proposals also presented several desired aspects of a new set of identifier systems. One such statement was "Heterogeneous address space should be able to communicate with each other." This appears, however, to run counter to a desire expressed elsewhere in the proposals: "If all technologies use their own protocols as language to communicate internally, complex "translators" must be employed for communication between islands."

                Disjoint addressing systems necessarily require independent routing to ensure reachability in each system. While these may be layered (as SR-MPLS, documented in RFC 8660, is layered on IP routing), using heterogeneous address spaces without a common substrate implies complex translation to achieve interchange among the different domains. Such translation likely increases fragility and latency while requiring additional network state to achieve interoperability.

                We understand this to be contrary to the design goal of interconnectivity across heterogeneous networks. The IETF believes this design goal, which we would commonly express as a requirement for interoperability, is critical to the evolution of IP and the Internet (see RFC 1958 published in 1996). Maintaining interoperability ensures that these new use cases are addressed in a way that allows the envisioned systems to participate in the current network, building on existing network effects and capitalizing on the investments in infrastructure that have already been made. This is how all users of the network come to reap the benefits of the "permissionless innovation" that the Internet facilitates.

                Based on the ongoing work at the IETF on real-time systems, on integration among different terrestrial and satellite networks, and on new transports like QUIC, the IETF believes that extensions of the current IP stack will allow us to reach the goals set forth in the proposals you provided. We are happy to see increased enthusiasm for these efforts, and we invite others to participate and contribute to the ongoing efforts. To date we have received no formal submissions for new work in the IETF that would extend or replace IP in line with the proposals included in your liaison statement, but we are always available to discuss the development of such submissions.

                In recent years, IETF efforts have put an ever-increasing emphasis on developing implementations and protocol standards in parallel such that the experience gained with initial implementations and interoperability testing gets fed back into the design of the standards. For example, the designs of HTTP/2, TLS 1.3, and QUIC have benefitted immensely from dozens of implementations that were developed alongside the standards development efforts and tested at Internet scale. The success of future standardization efforts will be highly dependent on how well real-world, multi-vendor implementation experience can be fed back into the standards development process, as opposed to attempting to anticipate needs and requirements so far into the future that Internet-scale testing is infeasible.

                It is not entirely clear from the proposals whether their intent is to extend or evolve existing IETF protocols such as IP, or to replace them entirely. The IETF maintains copyright and change control for the IP specifications in the interests of global interoperability. If the intent is to extend IETF protocols, we would like to draw your attention to the previously published IETF Best Current Practice document "Procedures for Protocol Extensions and

                Variations" (RFC 4775, BCP 125) which describes the general procedures to be followed in extending or modifying IETF specifications.  Requirements for extensions or modifications to IETF technologies must be discussed with the IETF before any are worked on in other SDOs, including the ITU-T. We request that the ITU-T encourage people in the ITU-T community who want to propose changes or extensions to IETF technologies to bring their requirements or proposals to the IETF and that the ITU-T not accept such proposals before the IETF gets a chance to discuss them. The IETF will do the same for requirements or proposals to extend ITU-T technologies.

                In conclusion, we believe the creation of a top-down design effort to replace the existing IP protocol stack wholesale would be harmful. Doing so would most assuredly create network islands, damage interconnection, and jeopardize interoperability. A top-down approach would fail to match the diverse needs of the continuously evolving application ecosystem. We believe in the continued modular, flexible evolution of the network and we welcome the opportunity to work with all interested parties in service of it. We see no evidence that the challenges described in the proposals cannot be met by continuing to evolve the existing IP protocol suite.

                编译:中国教育和科研计算机网

                责任编辑:zxh
                ?
                设为首页 | 加入收藏 |
                南阳市教育局主但最想要办 南阳市教育网络管ぷ理中心技术维护

                豫公网安备 41130302000407号

                 豫ICP备08104692号 网站标识码 4113000029
                站点统计: