[發明專利]一種SCTP建鏈方法

無效

• 申請號: 200610061107.2
• 申請日: 2006-06-07
• 公開（公告）號: CN101060525A
• 公開（公告）日: 2007-10-24
• 發明（設計）人: 汪大海
• 申請（專利權）人: 華為技術有限公司
• 主分類號: H04L29/06
• 分類號: H04L29/06;H04L29/12
• 代理公司: 深圳中一專利商標事務所
• 代理人: 張全文

技術領域

本發明涉及SCTP(stream?control?transmission?protocol流控傳輸協議)技術領域，具體來說，涉及到SCTP建鏈的技術。

背景技術

SCTP和TCP/UDP(transport?control?protocol/user?datagram?protocol傳輸控制協議/用戶數據報協議)一樣，同屬于傳輸層協議，SCTP綜合了UDP報文傳輸(相對于TCP的字節流傳輸)和TCP的可靠保序的特點，特別適合于電信領域應用，因為這些應用通常要求可靠的投遞服務，又不希望上層自己為報文進行定界處理。

TCP/UDP通常使用一個四元組<Local?Address，Local?Port，RemoteAddress，Remote?Port><本地地址、本地端口、遠端地址、遠端端口>來標識一個通信關聯。

SCTP中采用被稱作SCTP多歸屬的方案，將上述四元組中的LocalAddress和Remote?Address延伸成了Local?Address?List(本地地址列表)和Remote?Address?List(遠端地址列表)，List中的地址通常對應不同的網絡接口，也就可能對應不同的網絡路由，使用四元組<Local?Address?List，Local?Port，Remote?Address?List，Remote?Port>來標識一個通信關聯。

建鏈完成后，缺省情況下，List中的某個地址被選為Primary?Address(主地址)，協議棧通常使用Primary?Address作為發送報文的目的地址，當Primary?Address對應的路徑不可用，如對應的接口故障或者網絡路由癱瘓)時，List中的另一個Address將被選作新的Primary?Address，這個新的Primary?Address將作為后續報文發送的目的地址。

上述的SCTP多歸屬建鏈方案可以提高報文發送的可靠性，但無法解決建鏈可靠性的問題，具體說明如下：

現有技術中SCTP建鏈過程如圖1所示：

1、在Client(客戶)側和Server(服務器)側由operator(操作者)在ULP(Upper?Layer?Protocol上層應用)中針對所建關聯配置各自可用的一個Address?List以及對應的端口號；

2、上述的配置數據通過ULP?Client和SCTP?PS(協議棧)之間的Initialize(初始化)原語由ULP傳達給SCTP協議棧；

3、從步驟1中配置給Server側可用于本Association(關聯)的Address?List中選擇的一個地址配置給Client側的ULP作為建鏈時的目的地址，ULP?Client通過建鏈原語Associate(關聯)將該地址傳遞給SCTP協議棧；

4、Client側的SCTP?PS發送Init(初始化)報文(對攜帶Init?Chunk(初始化參數模塊)的報文的簡稱)給Server側的SCTP?PS，啟動建鏈過程，該Init報文的目的地址使用上述步驟3中所述的地址，而目的端口號則使用步驟1中的配置數據；同時，在Init報文中可以攜帶很多建鏈相關的參數，其中一個就是地址列表(Local?Address?List)，指明建鏈完成后Client側可用于當前所建關聯的所有地址；

5、Server側的SCTP?PS在接收到來自Client側的SCTP?PS的Init報文之后，如果接受建鏈請求，則回送Init?Ack(初始化確認)報文，同理該報文也可以攜帶很多建鏈相關的參數，其中一個也是地址列表(RemoteAddress?List)，用以指明建鏈完成后Server側可用于當前所建關聯的所有地址；

6、Client側SCTP?PS在接收到來自Server側SCTP?PS的Init?Ack報文之后，發送Cookie?Echo報文給Server側SCTP?PS；

7、Server側SCTP?PS回應Cookie?Ack的報文，關聯建立；

8、客戶側和服務器側的SCTP?PS通過Communication?Up(通信建立)原語上報各自的ULP建鏈成功。