不久前，國際電聯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>。
提案中同樣將衛星網絡與IP地面網絡集成中的傳輸需求看成一項新的挑戰。而在1999年公佈的RFC2488中就描述了衛星信道上的TCP協議。IETF在這方面的工作也從未停止，[email protected]郵件列表中有一個活躍的社區，致力於將QUIC協議應用於衛星通信；QUIC for SATCOM(<https>)則討論瞭如何在衛星通信中集成非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）”中獲益。
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>.
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 [email protected] mailing list has an active community working on QUIC's application to satellite communications; QUIC for SATCOM <https> 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.
編譯：中國教育和科研計算機網
閱讀更多 高校科技進展 的文章
