MLPPP

隨着PPP的廣泛應用，ML-PPP（Multilink-PPP）作為PPP功能的擴展協議應運而生。RFC1990為多鏈路點對點協議（ML-PPP）因特網協議標準，用於解決PPP一次只能處理一個實際鏈接的侷限。

多鏈路捆綁是ML-PPP協議的核心技術，它是一個較為簡單的協議。MP協議相當於為PPP幀增加了一個二層幀頭，MP捆綁需要解決的關鍵問題是，如何知道後發起的PPP是前面PPP的捆綁鏈路，以及採用什麼樣的幀格式表示MP頭。一般情況下，在設備中都會有一個MP Server來負責登記PPP是否為捆綁用户，以及IP地址等屬性，當後來的捆綁鏈路連接時，通過查表即可知道與哪條PPP捆綁，然後將該兩個鏈路捆綁起來，以MP頭作為鏈路層的頭，實現捆綁。

可將多個物理鏈路捆綁成一個邏輯鏈路，擴展傳輸帶寬；

可對鏈路資源進行動態分配，有效地利用寶貴的帶寬資源；

解決了多徑傳輸的時延問題，組網更加靈活。

通過ML-PPP協議，路由器和其它訪問設備可以合併多條PPP鏈路到一個邏輯數據管道。例如，在ISDN業務中，連接兩台計算機最常用的協議是PPP，訪問Internet通常也採用該協議。PPP的功能雖然很強，但在網絡部署方面卻存在着侷限性，即一次只處理一個鏈接，而ML-PPP則不受該限制，它是用於B信道聚集的新的Internet工程任務組（IETF）標準。使用ML-PPP協議，可以將多個PPP鏈路進行捆綁，增加設備間傳輸的可用帶寬。

首先，MLPPP協商有四種命令：

·Configure-Request請求

·Configure-Reject拒絕

·Configure-Nak 建議修改

·Configure-Ack收到/同意

假設A和B是兩個要協商的設備，那麼它們之間會發送一些包含LCP選項的Configure-Request（配置請求命令）。如果A打算告知B將使用某鏈路做MP鏈路，那麼會發送含有MRRU選項的請求，那麼B會確認A所請求的選項信息是否可用，如果可用，B發回一個Configure-Ack命令確認收到。如果B希望修改某些選項參數，那麼它會發送Configure-Nak命令和一些新的選項值。如果A接受修改，那麼A會重新發送一個Configure-Request命令。如果雙方任何一方不接受請求，可以發送Configure-Reject表示拒絕

A、B兩端都必須保證它們已經使能MLPPP，一條MLPPP鏈路才會激活。如果A發送了一個含有MRRU的LCP選項的Configure-Request請求並且B也同意，A也不能馬上發送MP數據。這是一個雙方協商的過程，B同意後會發送一個Configure-Ack命令回來，表示同意MRRU配置，但是A還是要等待B發送一個Configure-Request請求才能確定B已經做好了準備。同樣，雖然B做好了準備，但是它也不能發送數據，必須要等A回覆一個Configure-Ack命令以確定A已經收到同意信息並做好了準備。當雙方都準備好了，才開始建立MLPPP鏈路