青牛鄭州電銷卡辦理

IETF（互聯(lián)網(wǎng)工程任務(wù)組）DETNET（確定性網(wǎng)絡(luò)工作組）被明確排除在修改網(wǎng)絡(luò)層之外，盡管它具有提高多協(xié)議標(biāo)簽交換網(wǎng)絡(luò)中數(shù)據(jù)包幸免于擁塞的概率的技術(shù)，但是尚無相應(yīng)的IP解決方案獲得工作組采用或普遍接受。請(qǐng)注意，“降低丟包率”不等于“消除丟包”。即使使用MPLS基于流量工程的資源預(yù)留協(xié)議RSVP-TE構(gòu)建隧道來傳輸時(shí)間敏感的數(shù)據(jù)包，但是能保證的只是隧道上的最小帶寬。沒有任何機(jī)制可以保證端到端吞吐量、高精度時(shí)延以及零丟包。因此，確定性網(wǎng)絡(luò)工作組DETNET從根本上受到IP層（用于全球連接）可以提供受限擴(kuò)展性的限制。

我很高興【SHARP】的作者提及了IEEE 802.1時(shí)間敏感網(wǎng)絡(luò)和ITU-T（國(guó)際電信聯(lián)盟電信標(biāo)準(zhǔn)化部門）SG15（第15研究組）。但是請(qǐng)注意其解決方案分別為第2層和第1層解決方案。我在這里看到一個(gè)問題：我們可以提供第3層確定性或高精度通信嗎？如果New IP社區(qū)選擇研究這一問題，那么我看到了潛在價(jià)值。

7) IETF（互聯(lián)網(wǎng)工程任務(wù)組）解決了特定協(xié)議（例如邊界協(xié)議安全（BGPSEC）、域名系統(tǒng)安全（DNSSEC）、資源公鑰基礎(chǔ)設(shè)施（RPKI）等）中的安全問題，以及在各征求意見稿RFC中要求有一個(gè)章節(jié)考慮安全問題，將研究和新開發(fā)考慮在內(nèi)。IEEE（電氣電子工程師學(xué)會(huì)）在相關(guān)協(xié)議（例如IEEE 802.1AE、IEEE 802.11i）中解決了媒體訪問控制（MAC）層的安全問題。

在安全性方面，還有很多事情要做，尚不清楚關(guān)于IP設(shè)計(jì)的基本限制是否是障礙。研究根本的改變是否會(huì)帶來改善絕對(duì)不會(huì)產(chǎn)生任何害處。另外，我們非常了解所謂的“靜態(tài)”安全性及其在盡力而為網(wǎng)絡(luò)中的適用性。我們只是在學(xué)習(xí)如何確保動(dòng)態(tài)行為的安全。

在互聯(lián)網(wǎng)設(shè)計(jì)之初，很多地方都沒有考慮安全。當(dāng)出現(xiàn)安全問題時(shí)，安全功能被開發(fā)為附加特性。事后嘗試增加安全特性僅能起到繃帶或止痛藥的作用，雖然可以幫上一陣子，但不能根本解決問題。請(qǐng)查看IP地址偽造導(dǎo)致的分布式拒絕服務(wù)放大攻擊或網(wǎng)絡(luò)釣魚和虛假冒名。底層設(shè)計(jì)的不足是目前引起重大損害的主要問題。

就像我之前說的那樣，我認(rèn)為國(guó)際互聯(lián)網(wǎng)協(xié)會(huì)ISOC將支持并歡迎大家努力提高互聯(lián)網(wǎng)的安全性，尤其是新型物聯(lián)網(wǎng)設(shè)備和工業(yè)機(jī)器在尋求接入互聯(lián)網(wǎng)之際。

8) IETF（互聯(lián)網(wǎng)工程任務(wù)組）傳輸域開發(fā)傳輸協(xié)議（例如，流控制傳輸協(xié)議（SCTP）、實(shí)時(shí)協(xié)議（RTP）和Web實(shí)時(shí)通信（WebRTC）和QUIC）和主動(dòng)隊(duì)列管理協(xié)議（例如，低延遲、低損耗、可擴(kuò)展吞吐量服務(wù)架構(gòu)（L4S）和某些擁塞預(yù)警（SCE）顯示擁塞通知ECN校驗(yàn)點(diǎn)）。在考慮到與互聯(lián)網(wǎng)上TCP流量的交互以及對(duì)互聯(lián)網(wǎng)上TCP的影響的同時(shí)，這些工作增加了吞吐量，降低了延遲，并進(jìn)一步支持了實(shí)時(shí)流量的需求。