專利名稱：基于多家鄉(xiāng)主機擴展hip協(xié)議實現(xiàn)流分配和流重定向的方法
技術領域：
本發(fā)明涉及一種基于多家鄉(xiāng)主機擴展主機標識協(xié)議HIP實現(xiàn)流分配和流重定向 的方法，屬于互聯(lián)網通信技術領域。
背景技術：
現(xiàn)在，越來越多的主機配置有多個網絡接口，這些網絡接口既可以在主機上配置 多個物理接口來實現(xiàn)，也可以通過物理接口和邏輯接口的結合來實現(xiàn)。比如，當前的移動設 備(手機或筆記本電腦)通常通過多個接口(有線，無線等)連接網絡。這些接口可以連 接到相同的網絡，也可以連接到不同的網絡。隨著網絡的普及和發(fā)展，用戶對網絡的傳輸性能提出了更高要求，在帶寬有限的 情況下，如何為用戶提供高性能的服務已經成為一個重要問題。多接口主機的存在使得在 有限帶寬下提供更好的服務成為可能。因為各接口連接的網絡當前的可用帶寬、擁塞情況 等的不同，導致各個接口能夠提供不同的服務質量，如果能將數據分配到網絡狀況較好的 接口，或者同時分配到多個接口上進行傳輸，能提高服務質量，使用戶得到更好的服務體 驗。但是，由于多個接口的IP地址不同，在當前的網絡架構中，IP地址不僅是位置標 識，同時也是主機標識，傳輸層是與IP地址綁定在一起的，發(fā)送方無法將同一個應用流關 聯(lián)到多個IP地址上，而且，接收方的上層應用也無法區(qū)分從多個接口收到的目的IP地址的 不同數據包是否屬于同一個流。主機標識協(xié)議HIP (Host Identity Protocol)通過在傳輸層和網絡層之間增加主 機標識層，該層采用主機標識HI (Host Identity)來標識主機，使得IP地址僅為主機的位 置標識，從而將IP地址的主機標識功能分離開來，切斷了網絡層和傳輸層的緊密耦合，使 應用層和傳輸層的連接不受IP地址變化的影響。在HIP協(xié)議中，只要確定主機標識HI，就 能根據主機標識和端口號來區(qū)分上層應用，而目的IP地址只起到路由功能，當IP地址在一 個連接中發(fā)生改變時，HIP協(xié)議為終端分配的主機標識HI保持不變，從而為多接口的同時 使用提供了便利?，F(xiàn)有的HIP協(xié)議支持多家鄉(xiāng)主機的場景，即支持一個主機存在多個IP地址的情況 的方式為多家鄉(xiāng)主機通過更新(Update)消息將自己的多個可用IP地址通知給通信對端， 同時指定其中的一個IP地址作為通信的首選IP地址(PreferredIP)。在與對端的通信過 程中，對端主機在多家鄉(xiāng)主機的多個可用地址中選擇一個IP地址作為首選地址進行通信， 當該IP地址不可達或多家鄉(xiāng)主機指定另一個首選地址時，對端主機就將當前使用的目的 地址變?yōu)樾碌氖走x地址(參見RFC5206)。因此，盡管多家鄉(xiāng)主機可能存在多個可用接口，但 是，現(xiàn)有的HIP協(xié)議將每個流同時只發(fā)送到一個IP地址上，即通信對端只選擇多家鄉(xiāng)主機 指定的首選IP地址作為目的地址，并沒有同時充分利用多家鄉(xiāng)主機的多個可用接口對數 據流進行調度，多家鄉(xiāng)主機也不能根據應用的特征為應用數據選擇合適的網絡接口，以提高傳輸效率和網絡利用率；同時，現(xiàn)有的HIP協(xié)議對于接口的改變是基于主機進行的，并不 是針對某個流進行，不夠靈活。這些缺陷就成為HIP協(xié)議拓展應用的技術瓶頸，如何針對網 絡當前的可用帶寬與擁塞等情況盡快解決數據流的重新分配和再定向的技術課題，就成為 業(yè)內科技人員關注的焦點
發(fā)明內容

有鑒于此，本發(fā)明的目的是提供一種基于多家鄉(xiāng)主機擴展HIP協(xié)議實現(xiàn)流分配和 流重定向的方法，該方法是對HIP協(xié)議進行擴展，在主機標識不改變的前提下，將數據流從 主機的一個接口切換到另一個接口或者分配到多個接口上，以便充分利用主機的多個接 口，提高數據的傳輸效率和網絡的利用率。為了達到上述目的，本發(fā)明提供了一種基于多家鄉(xiāng)主機擴展主機標識協(xié)議HIP實 現(xiàn)流分配和流重定向的方法，其特征在于對現(xiàn)有的HIP協(xié)議進行擴展，增添多個重定向消 息，使得數據的接收端能夠為不同類型的數據設定多個不同的接收接口 ；所述方法包括下 列操作步驟(1)在通信之前，發(fā)送端和接收端通過HIP協(xié)議的基本交換過程建立雙方的主機 標識關聯(lián)；(2)接收端使用更新消息中的定位符LOCATOR參數向發(fā)送端追加接收端的多個新 的IP地址；(3)發(fā)送端接收到接收端發(fā)送的更新消息后，先更新主機標識關聯(lián)及其與接收端 間的綁定信息，再向接收端的新的IP地址發(fā)送該更新消息的應答消息；(4)接收端接收到發(fā)送端發(fā)送的該更新消息的應答消息后，向發(fā)送端反饋該更新 消息的確認消息；當發(fā)送端接收到該更新消息的確認消息后，就認為接收端的新的IP地址 有效；(5)為提高傳輸效率，接收端以攜帶有重定向請求選項的重定向請求消息向發(fā)送 端提出請求，要求發(fā)送端將某個應用的數據包發(fā)送到另一個或多個接口 ；(6)發(fā)送端通過攜帶有重定向回復選項或重定向失敗選項的重定向應答消息通知 接收端其重定向請求中攜帶的多個IP地址全部被接受、或拒絕其中的部分IP地址、或拒 絕全部IP地址；(7)接收端收到發(fā)送端發(fā)送的重定向應答消息后，向發(fā)送端發(fā)送重定向確認消息； 如果重定向應答消息中攜帶的是重定向回復選項，則重定向確認消息表示接收端已經準備 好從相應的接口接收數據；如果重定向應答消息中攜帶的是重定向失敗選項，則重定向確 認消息表示接收端已經準備好從正確的接口接收數據；(8)發(fā)送端和接收端之間的通信轉換到接收端相應的一個或多個接口進行，或者 維持原有發(fā)送鏈路不變。所述更新消息用于接收端向發(fā)送端追加多個新的IP地址，以便接收端通過該更 新消息中的LOCATOR參數將該多個新的IP地址通知發(fā)送端，并指定其中一個為首選地址； 該更新消息包括下述三個參數封裝安全有效負載信息，包括用于建立安全關聯(lián)的舊的和 新的安全參數索引SPI(Security Parameter Index) ；LOCATOR，包括接收端希望向發(fā)送端 追加的新的IP地址；用數字表示的序列號，攜帶序列號參數的更新消息表明更新消息的接收端必須對接收到的該更新消息進行確認。所述更新消息的應答消息是發(fā)送端對接收端的更新消息的響應；該更新消息的應答消息包括下述三個參數封裝安全有效負載信息，包括用于建立安全關聯(lián)的舊的和新的 安全參數索引SPI ；用數字表示的序列號，其數值與發(fā)送端接收到的更新消息中的序列號 的數值相同；用一個隨機數表示的回響請求，當更新消息的應答消息中包含回響請求參數 時，更新消息的接收端必須回復該應答消息，用于證明追加的新的IP地址的有效性。所述更新消息的確認消息是接收端對發(fā)送端的更新消息的應答消息的確認；該更 新消息的確認消息包括下述兩個參數確認，用于對發(fā)送端發(fā)出的該更新消息的應答消息 進行確認；用一個隨機數表示的回響回復，其數值和更新消息的應答消息中回響請求的隨 機數的數值相同。所述重定向消息是接收端和發(fā)送端之間用于實現(xiàn)接收端的重定向請求與協(xié)商的 相關信息，根據其中攜帶的重定向請求選項、重定向回復選項與重定向失敗選項、確認的四 種不同選項而細分為重定向請求消息、重定向應答消息和重定向確認消息。所述重定向請求消息是接收端使用該消息中的重定向請求選項向發(fā)送端發(fā)出重 定向請求，請求發(fā)送端將當前某個應用的數據流發(fā)送到該重定向請求選項中指定的另一個 或多個目的IP地址，以便實現(xiàn)負載分擔，提高傳輸效率；該重定向請求消息格式依次設有下述六個字節(jié)類型，標識該消息為重定向請求 消息；長度，標明該消息長度；生存期，標明該消息的有效時間；端口號，接收數據的端口 號，與主機標識標簽HIT (Host Identity Tag)共同標識一個流；主機標識標簽，接收端的主 機標識；切換的一個或多個IP地址，順次在該選項中設定。所述重定向應答消息是由發(fā)送端根據接收端提出的IP地址是否可達或其他情況 對重定向請求消息作出的響應，包括下述兩種應答消息攜帶重定向回復選項的重定向應答消息表示發(fā)送端接受接收端的流重定向請 求，并根據重定向請求消息的要求將流分配到另一個或多個接口，或者維持原來的流分配 不變；該應答消息格式依次設有下述五個字節(jié)類型，標識該應答消息中的選項類型；長 度，標明該消息長度；生存期，標明該消息的有效時間；端口號，接收相應數據流的端口號， 與主機標識標簽共同標識一個流；主機標識標簽，接收端的主機標識；攜帶重定向失敗選項的重定向應答消息表示發(fā)送端拒絕接收端的流重定向請 求，其中的重定向失敗選項設有拒絕的IP地址列表和拒絕理由，而在重定向請求消息中包 含的、未在拒絕的IP地址列表中出現(xiàn)的IP地址則默認為發(fā)送端接受的重定向的IP地址； 該應答消息的格式依次設有下述六個字節(jié)類型，標識該應答消息中的選項類型；長度，標 明該消息長度；生存期，標明該消息的有效時間；端口號，標明接收相應數據流的端口號， 與主機標識標簽共同標識一個流；主機標識標簽，接收端的主機標識；錯誤類型，告知接收 端拒絕該IP地址的原因；錯誤的IP地址，順次在該選項中設定。所述重定向請求消息中可能涉及多個IP地址，當發(fā)送端拒絕其中部分IP地址時， 發(fā)送端要將拒絕的IP地址的相關信息通知接收端；如果拒絕多個IP地址時，則錯誤類型和 錯誤IP地址的組合字節(jié)會有順序的多組，逐個說明每個拒絕的IP地址的拒絕原因。所述重定向確認消息是帶有確認的重定向消息，用于接收端和發(fā)送端之間的重定 向請求消息的互相確認。
本發(fā)明方法是基于主機標識協(xié)議HIP，利用HIP協(xié)議中增加的主機標識HI (Host Identity)和端口號來區(qū)分每個流，不需要在原有IP包的基礎上再做額外的封裝。HIP協(xié) 議將主機標識和位置標識分離，使通信不會因為位置(IP地址)的改變發(fā)生中斷，這就為將 一個數據流從多家鄉(xiāng)主機的一個接口重定向到另一個或多個接口提供了很好的前提條件。
本發(fā)明方法的優(yōu)點是由用戶提出同時使用多個接口的請求，可以根據接收端的 主動要求，將某個數據流從一個地址/接口切換到另外一個地址/接口，或將某一個流分 配到多個地址/接口上，這樣就能更好地利用主機的多個接口來提高傳輸效率和網絡利用 率，實現(xiàn)流量均衡，為用戶提供更好的服務。此外，本發(fā)明對于接口的改變是基于業(yè)務流進 行的，具有更好的靈活性。當多個網絡接口負載很不均衡時，如果將負載流量大的接口上的 業(yè)務流轉移到主機上的其他負載較小的接口，或者在主機的多個接口上平均分配所有的流 量，能夠實現(xiàn)負載均衡，提高網絡利用率。本發(fā)明技術創(chuàng)新點是在HIP協(xié)議里拓展了重定向請求、重定向應答與重定向確認 等消息，從而既增強了 HIP協(xié)議對多接口的支持，又與現(xiàn)有的HIP協(xié)議保持很好的兼容。本 發(fā)明方法在實施時，可以逐步部署和推廣，不會對現(xiàn)行的通信網絡或秩序造成混亂。并且在 實施過程中，對于支持本發(fā)明擴展方法的終端與不支持擴展方法的主機或終端的通信都沒 有影響。對于不能識別本發(fā)明擴展消息的主機或終端，只需維持其原來目的地址即可實現(xiàn) 其通信。因此，本發(fā)明的部署和推廣可以逐步地開展，不需在短時間內大規(guī)模地改變現(xiàn)有網 絡系統(tǒng)的部署。再者，本發(fā)明的操作步驟簡單、便利、易行，只需對主機的相關通信協(xié)議進行 擴展，對網絡上其他網元不需進行任何修改，因此，對于現(xiàn)有通信協(xié)議的修改量非常小。所 以，本發(fā)明具有很好的推廣應用前景。


圖1是本發(fā)明基于多家鄉(xiāng)HIP協(xié)議實現(xiàn)流分配和流重定向的方法中發(fā)送端與接收 端的操作時序示意圖；圖2是本發(fā)明擴展HIP協(xié)議的重定向請求消息格式示意圖。圖3(A)、(B)是本發(fā)明擴展HIP協(xié)議的分別攜帶有重定向回復選項和重定向失敗 選項的兩種重定向應答消息的格式示意圖。
具體實施例方式為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖對本發(fā)明作進一步 的詳細描述。眾所周知，主機標識協(xié)議HIP定義了一個新的名字空間主機標識 HI (HostIdentity)，用于將主機標識和主機的位置標識分離開。在傳統(tǒng)網絡中，主機的IP 地址既是主機標識，同時也是主機的位置標識，當重新編址時，IP地址的改變意味著主機標 識也發(fā)生了改變，應用層會話必須終止連接，并與新的IP地址重新建立連接?；谛碌拿?名空間，HIP協(xié)議在傳輸層和IP層之間增加了一個主機標識層，去除了 IP地址的主機標識 功能，傳輸層不再綁定到IP地址，而是綁定到主機標識；重新編址時，主機標識不會發(fā)生變 化，這樣在發(fā)生地址改變時，上層應用的會話不需要重新建立連接。由于HIP議在IP層和TCP層之間封裝了一個主機標識層，在數據傳輸過程中，可以通過主機標識和端口號唯一標識一個流，不論IP層的地址是否改變，對流的識別沒有影 響，因此在HIP協(xié)議中很容易將一個流發(fā)送到目的端的任意一個或者多個接口，而不影響 上層應用。雖然HIP協(xié)議本身支持主機多家鄉(xiāng)的情況，主機可以緩存對端的多個IP地址，能 從多個IP地址中選擇一個作為目的地址。但是，在存在多接口主機時，現(xiàn)有的HIP協(xié)議對 一個流同時只發(fā)送到一個地址，在首選地址失效或首選地址改變時，就發(fā)送到另一個接口， 但是，這種切換是基于主機、不是基于流進行的，沒有很好地利用多接口進行流的調度。為了更好地利用多接口，本發(fā)明是對現(xiàn)有的HIP協(xié)議進行擴展，利用主機標識不 變的特點，根據網絡的實時狀況和應用的需求，增加重定向請求、應答和確認的相關消息， 使得數據的接收端能夠為不同類型的數據指定不同的接收接口，將某個流發(fā)送到另一個接 口，或者將屬于同一個流的數據包同時發(fā)送到多個接口上，提高傳輸效率。假設數據的發(fā)送端和接收端都使用HIP協(xié)議，且接收端是多家鄉(xiāng)主機，它有兩個 網絡接口 接口 1和接口 2，它們的IP地址分別為IPl和IP2。在發(fā)送端向接收端發(fā)送數據 之前，二者需要通過主機標識協(xié)議的基本交換(Base Exchange)過程建立主機標識關聯(lián)，只 有主機標識關聯(lián)成功建立后，二者才可相互通信，假設建立主機標識關聯(lián)時，接收端使用的 是接口 1的IP地址(IPl)。發(fā)送端和接收端建立主機標識關聯(lián)后，接收端通過向發(fā)送端發(fā)送更新消息 (Update)將接口 2的IP地址(IP2)通知給發(fā)送端，更新消息中攜帶IP2的參數是LOCATOR。 為了提高效率，接收端希望通過接口 1和接口 2同時接收發(fā)送端發(fā)送的數據。接收端通過 重定向請求消息，請求發(fā)送端將報文同時發(fā)送到接口 1和接口 2。發(fā)送端接收到接收端的重 定向請求消息后，先判斷該請求是否可以滿足，如果能夠滿足，則重新對數據包進行封裝， 發(fā)送到接收端的不同接口。在該過程中，因接收端的主機標識不變，所以發(fā)送給接收端的數 據包的HIP層包頭不變，發(fā)送端根據接收端的重定向請求，將IP層包頭分別封裝為接口 1 和接口 2的IP地址。也就是上述過程發(fā)生改變的事用于路由的接收端的位置標識(IP地 址)。參見圖1，具體介紹本發(fā)明方法的操作過程(1)在通信之前，發(fā)送端和接收端通過HIP協(xié)議的基本交換過程建立雙方的主機 標識關聯(lián)?；窘粨Q過程的具體消息交互過程參照RFC5201。(2)接收端使用更新消息中的LOCATOR參數向發(fā)送端追加接收端的多個新的IP地 址。更新消息用于接收端向發(fā)送端追加多個IP地址，接收端通過更新消息中的LOCATOR參 數將其多個IP地址通知發(fā)送端，并指定其中一個為首選地址。更新消息的參數有三個用 于建立安全關聯(lián)的舊的和新的安全參數索引的封裝安全有效負載信息參數，包括接收端希 望向發(fā)送端追加新的IP地址的LOCATOR參數，以及用一個數字表示的序列號參數，攜帶序 列號參數的更新消息表明該更新消息的接收端必須對接收到的該更新消息進行確認。更新 消息的具體交互過程參照RFC5206。(3)發(fā)送端接收到接收端發(fā)送的更新消息后，先更新主機標識關聯(lián)及其與接收端間的綁定信息，再向接收端的新的IP地址發(fā)送該更新消息的應答消息。該應答消息的參數 也有三個用于建立安全關聯(lián)的舊的和新的安全參數索引的封裝安全有效負載信息參數， 其數值和上述更新消息中的序列號參數數值相同的序列號參數，以及由一個隨機數表示的 回響請求參數，該參數在更新消息中的作用是證明地址的有效性。
(4)接收端接收到發(fā)送端發(fā)送的該更新消息的應答消息后，向發(fā)送端反饋該更新消息的確認消息；該確認消息包括下述兩個參數確認，用于對步驟(3)發(fā)送端發(fā)出的該更 新消息的應答消息進行確認；用一個隨機數表示的回響回復，其數值和更新消息的應答消 息中回響請求的隨機數的數值相同。當發(fā)送端接收到該更新消息的確認消息后，就認為接 收端的新的IP地址有效。(5)為提高傳輸效率，接收端以攜帶有重定向請求選項的重定向請求消息向發(fā)送 端提出請求，要求發(fā)送端將某個應用的數據包發(fā)送到另一個或多個接口。重定向請求消息是接收端使用該消息中的重定向請求選項向發(fā)送端發(fā)出重定向 請求，請求發(fā)送端將當前某個應用的數據流發(fā)送到該重定向請求選項中指定的另一個或多 個目的IP地址，以便實現(xiàn)負載分擔，提高傳輸效率。參見圖2，舉例說明本發(fā)明中的重定向請求消息的格式-依次設有下述六個字節(jié)類型(16bits)，標識該消息為重定向請求消息；長度(16bits)，標明該消息長度；生存期debits)，標明該消息的有效時間；端口號(16bits)，接收數據的端口號，與主機標識標簽共同標識一個流；主機標識標簽HIT (Host Identity Tag, 128bits)，接收端的主機標識；切換的一個或多個IP地址，順次在該選項中設定。(6)發(fā)送端通過攜帶有重定向回復選項或重定向失敗選項的重定向應答消息通知 接收端其重定向請求中攜帶的多個IP地址全部被接受、或拒絕其中的部分IP地址、或拒 絕全部IP地址。重定向應答消息是由發(fā)送端根據接收端提出的IP地址是否可達或者其他情況對 重定向請求消息作出的響應，包括下述兩種應答消息攜帶重定向回復選項的重定向應答消息是表示發(fā)送端接受接收端的流重定向請 求，并根據重定向請求消息的要求將流分配到另一個或多個接口，或維持原來的流分配不變。參見圖3(A)，舉例說明本發(fā)明中的重定向應答消息的格式-依次設有下述五個字 節(jié)類型(16bits)，標識該應答消息中的選項類型；長度(16bits)，標明該消息長度；生存期debits)，標明該消息的有效時間；端口號(16bits)，接收相應數據流的端口號，與主機標識標簽共同標識一個流；主機標識標簽(128bits)，接收端的主機標識；攜帶重定向失敗選項的重定向應答消息是表示發(fā)送端拒絕接收端的流重定向請 求，其中的重定向失敗選項設有拒絕的IP地址列表和拒絕理由，而在重定向請求消息中包 含的、未在拒絕的IP地址列表中出現(xiàn)的IP地址則默認為發(fā)送端接受的重定向的IP地址。參見圖3(B)，舉例說明本發(fā)明中的重定向應答消息的格式-依次設有下述七個字 節(jié)類型(16bits)，標識該應答消息中的選項類型；長度(16bits)，標明該消息長度；
生存期(16bits)，標明該消息的有效時間；端口號(16bits)，標明接收相應數據流的端口號，與主機標識標簽共同標識一個 流；主機標識標簽(128bits)，接收端的主機標識；錯誤類型(32bits)，告知接收端拒絕該IP地址的原因；
錯誤的IP地址，拒絕的IP地址，并順次在該選項中設定。因重定向請求消息中可能涉及多個IP地址，當發(fā)送端拒絕其中部分IP地址時，發(fā) 送端要將拒絕的每個IP地址的相關信息都通知接收端；如果拒絕多個IP地址時，則錯誤類 型和錯誤IP地址的組合字節(jié)會有順序的多組，逐個說明每個拒絕的IP地址的拒絕原因。(7)接收端收到發(fā)送端發(fā)送的重定向應答消息后，向發(fā)送端發(fā)送重定向確認消息， 告知其已準備好從相應的接口接收數據；如果重定向應答消息中攜帶的是重定向回復選 項，則重定向確認消息表示接收端已經準備好從相應的接口接收數據；如果重定向應答消 息中攜帶的是重定向失敗選項，則重定向確認消息表示接收端已經準備好從正確的接口接 收數據。重定向確認消息是帶有確認的重定向消息，用于接收端和發(fā)送端之間的重定向請 求消息的互相確認。(8)發(fā)送端和接收端之間的通信轉換到接收端相應的一個或多個接口進行，或者 維持原有發(fā)送鏈路不變。
權利要求
一種基于多家鄉(xiāng)主機擴展主機標識協(xié)議HIP實現(xiàn)流分配和流重定向的方法，其特征在于對現(xiàn)有的HIP協(xié)議進行擴展，增添多個重定向消息，使得數據的接收端能夠為不同類型的數據設定多個不同的接收接口；所述方法包括下列操作步驟(1)在通信之前，發(fā)送端和接收端通過HIP協(xié)議的基本交換過程建立雙方的主機標識關聯(lián)；(2)接收端使用更新消息中的定位符LOCATOR參數向發(fā)送端追加接收端的多個新的IP地址；(3)發(fā)送端接收到接收端發(fā)送的更新消息后，先更新主機標識關聯(lián)及其與接收端間的綁定信息，再向接收端的新的IP地址發(fā)送該更新消息的應答消息；(4)接收端接收到發(fā)送端發(fā)送的該更新消息的應答消息后，向發(fā)送端反饋該更新消息的確認消息；當發(fā)送端接收到該更新消息的確認消息后，就認為接收端的新的IP地址有效；(5)為提高傳輸效率，接收端以攜帶有重定向請求選項的重定向請求消息向發(fā)送端提出請求，要求發(fā)送端將某個應用的數據包發(fā)送到另一個或多個接口；(6)發(fā)送端通過攜帶有重定向回復選項或重定向失敗選項的重定向應答消息通知接收端其重定向請求中攜帶的多個IP地址全部被接受、或拒絕其中的部分IP地址、或拒絕全部IP地址；(7)接收端收到發(fā)送端發(fā)送的重定向應答消息后，向發(fā)送端發(fā)送重定向確認消息；如果重定向應答消息中攜帶的是重定向回復選項，則重定向確認消息表示接收端已經準備好從相應的接口接收數據；如果重定向應答消息中攜帶的是重定向失敗選項，則重定向確認消息表示接收端已經準備好從正確的接口接收數據；(8)發(fā)送端和接收端之間的通信轉換到接收端相應的一個或多個接口進行，或者維持原有發(fā)送鏈路不變。
2.根據權利要求1所述的方法，其特征在于所述更新消息用于接收端向發(fā)送端追加 多個新的IP地址，以便接收端通過該更新消息中的LOCATOR參數將該多個新的IP地址通 知發(fā)送端，并指定其中一個為首選地址；該更新消息包括下述三個參數封裝安全有效負 載信息，包括用于建立安全關聯(lián)的舊的和新的安全參數索引；LOCATOR，包括接收端希望向 發(fā)送端追加的新的IP地址；用數字表示的序列號，攜帶序列號參數的更新消息表明更新消 息的接收端必須對接收到的該更新消息進行確認。
3.根據權利要求1所述的方法，其特征在于所述更新消息的應答消息是發(fā)送端對接 收端的更新消息的響應；該更新消息的應答消息包括下述三個參數封裝安全有效負載信 息，包括用于建立安全關聯(lián)的舊的和新的安全參數索引SPI ；用數字表示的序列號，其數值 與發(fā)送端接收到的更新消息中的序列號的數值相同；用一個隨機數表示的回響請求，當更 新消息的應答消息中包含回響請求參數時，更新消息的接收端必須回復該應答消息，用于 證明追加的新的IP地址的有效性。
4.根據權利要求1所述的方法，其特征在于所述更新消息的確認消息是接收端對發(fā) 送端的更新消息的應答消息的確認；該更新消息的確認消息包括下述兩個參數確認，用 于對發(fā)送端發(fā)出的該更新消息的應答消息進行確認；用一個隨機數表示的回響回復，其數 值和更新消息的應答消息中回響請求的隨機數的數值相同。
5.根據權利要求1所述的方法，其特征在于所述重定向消息是接收端和發(fā)送端之間 用于實現(xiàn)接收端的重定向請求與協(xié)商的相關信息，根據其中攜帶的重定向請求選項、重定 向回復選項與重定向失敗選項、確認的四種不同選項而細分為重定向請求消息、重定向應 答消息和重定向確認消息。
6.根據權利要求5所述的方法，其特征在于所述重定向請求消息是接收端使用該消 息中的重定向請求選項向發(fā)送端發(fā)出重定向請求，請求發(fā)送端將當前某個應用的數據流發(fā) 送到該重定向請求選項中指定的另一個或多個目的IP地址，以便實現(xiàn)負載分擔，提高傳輸 效率；該重定向請求消息格式依次設有下述六個字節(jié)類型，標識該消息為重定向請求消息； 長度，標明該消息長 度；生存期，標明該消息的有效時間；端口號，接收數據的端口號，與主 機標識標簽HIT共同標識一個流；主機標識標簽，接收端的主機標識；切換的一個或多個IP 地址，順次在該選項中設定。
7.根據權利要求5所述的方法，其特征在于所述重定向應答消息是由發(fā)送端根據接 收端提出的IP地址是否可達或其他情況對重定向請求消息作出的響應，包括下述兩種應 答消息攜帶重定向回復選項的重定向應答消息表示發(fā)送端接受接收端的流重定向請求，并 根據重定向請求消息的要求將流分配到另一個或多個接口，或者維持原來的流分配不變； 該應答消息格式依次設有下述五個字節(jié)類型，標識該應答消息中的選項類型；長度，標明 該消息長度；生存期，標明該消息的有效時間；端口號，接收相應數據流的端口號，與主機 標識標簽共同標識一個流；主機標識標簽，接收端的主機標識；攜帶重定向失敗選項的重定向應答消息表示發(fā)送端拒絕接收端的流重定向請求，其 中的重定向失敗選項設有拒絕的IP地址列表和拒絕理由，而在重定向請求消息中包含的、 未在拒絕的IP地址列表中出現(xiàn)的IP地址則默認為發(fā)送端接受的重定向的IP地址；該應答 消息的格式依次設有下述六個字節(jié)類型，標識該應答消息中的選項類型；長度，標明該消 息長度；生存期，標明該消息的有效時間；端口號，標明接收相應數據流的端口號，與主機 標識標簽共同標識一個流；主機標識標簽，接收端的主機標識；錯誤類型，告知接收端拒絕 該IP地址的原因；錯誤的IP地址，順次在該選項中設定。
8.根據權利要求7所述的方法，其特征在于所述重定向請求消息中可能涉及多個IP 地址，當發(fā)送端拒絕其中部分IP地址時，發(fā)送端要將拒絕的IP地址的相關信息通知接收 端；如果拒絕多個IP地址時，則錯誤類型和錯誤IP地址的組合字節(jié)會有順序的多組，逐個 說明每個拒絕的IP地址的拒絕原因。
9.根據權利要求5所述的方法，其特征在于所述重定向確認消息是帶有確認的重定 向消息，用于接收端和發(fā)送端之間的重定向請求消息的互相確認。
全文摘要
一種基于多家鄉(xiāng)主機擴展HIP協(xié)議實現(xiàn)流分配和流重定向的方法，是對現(xiàn)有的HIP協(xié)議進行擴展，增添重定向請求、重定向應答與重定向確認等消息，從而既增強了HIP協(xié)議對多接口的支持，又與現(xiàn)有的HIP協(xié)議保持很好的兼容，使得數據接收端能為不同類型的數據設定多個不同的接收接口，提高數據傳輸效率和網絡利用率。本發(fā)明方法實施時，對于不能識別本發(fā)明擴展消息的主機或終端，只需維持其原來目的地址即可實現(xiàn)其通信。故可以逐步開展本發(fā)明的部署和推廣。再者，本發(fā)明操作步驟簡單、便利、易行，只需對主機的相關協(xié)議進行擴展，對網絡上其他網元不需進行任何修改，因此，對現(xiàn)有通信網絡的修改工作量很小。所以，本發(fā)明具有很好的推廣應用前景。
文檔編號H04L1/16GK101848164SQ20101019314
公開日2010年9月29日 申請日期2010年5月27日 優(yōu)先權日2010年5月27日
發(fā)明者侯云靜, 時巖, 李玉宏, 炳佳楠, 胡渭琦 申請人:北京郵電大學