［沈杭東］

1 引言

我們所使用的計(jì)算機(jī)網(wǎng)絡(luò)中通常包括具備特定的網(wǎng)絡(luò)功能的專用硬件設(shè)備，這些專用硬件設(shè)備由網(wǎng)絡(luò)運(yùn)營商提供，這些設(shè)備上運(yùn)行的控制軟件通常與底層轉(zhuǎn)發(fā)芯片是強(qiáng)耦合的。隨著網(wǎng)絡(luò)功能數(shù)量的成倍增加，需要部署的硬件設(shè)備數(shù)量也在增加，每個(gè)新功能都需要額外的設(shè)備，或者對現(xiàn)有設(shè)備的芯片和軟件進(jìn)行修改。盡管這使得Internet應(yīng)用程序激增，但在這種框架下網(wǎng)絡(luò)管理任務(wù)：配置、管理、性能和安全變得越來越復(fù)雜；同時(shí)分布式控制軟件、供應(yīng)商互操作性和供應(yīng)商鎖定等方面問題也會阻礙研究人員和網(wǎng)絡(luò)管理員為網(wǎng)絡(luò)進(jìn)行創(chuàng)新和擴(kuò)展。

軟件定義網(wǎng)絡(luò)（SDN）是一種新的網(wǎng)絡(luò)范式，它基于功能分離，通過標(biāo)準(zhǔn)化接口實(shí)現(xiàn)控制平面和數(shù)據(jù)平面的解耦[1]。開放網(wǎng)絡(luò)基金會描述了基于三個(gè)平面：數(shù)據(jù)平面、控制平面和應(yīng)用平面，以及兩個(gè)平面間接口：數(shù)據(jù)和控制器平面的接口（D-CPI）、應(yīng)用和控制器平面的接口（A-CPI）的SDN 架構(gòu)[2]。數(shù)據(jù)平面由轉(zhuǎn)發(fā)要素組成，這些要素通過D-CPI 將數(shù)據(jù)處理功能暴露給控制平面。OpenFlow 是一種標(biāo)準(zhǔn)化的D-CPI，它支持使用流表[3]的轉(zhuǎn)發(fā)平面的通用模型?？刂破矫嬗蛇壿嫾锌刂破鹘M成，負(fù)責(zé)通過A-CPI向應(yīng)用程序平面提供數(shù)據(jù)平面的抽象視圖，并將應(yīng)用程序意圖表達(dá)為特定的流表?xiàng)l目。盡管沒有標(biāo)準(zhǔn)化的 A-CPI 存在，但應(yīng)用程序編程接口（API）（例如REST 接口）一般都是設(shè)計(jì)成這種方式。應(yīng)用程序平面包含的業(yè)務(wù)應(yīng)用程序描述了底層數(shù)據(jù)平面中進(jìn)行網(wǎng)絡(luò)配置的需求。SDN 控制器的網(wǎng)絡(luò)全局視圖的能力使得網(wǎng)絡(luò)管理員能輕松管理網(wǎng)絡(luò)，同時(shí)開放的接口通過為研究人員提供直接編程轉(zhuǎn)發(fā)行為的能力來實(shí)現(xiàn)創(chuàng)新[4]。

VoIP[5]是一組能夠通過IP 網(wǎng)絡(luò)傳輸語音包的技術(shù)，在過去十年中已經(jīng)成熟的技術(shù)。標(biāo)準(zhǔn)的VoIP 架構(gòu)包括建立呼叫的信令協(xié)議，例如會話發(fā)起協(xié)議（SIP）[6]、實(shí)時(shí)傳輸協(xié)議例如實(shí)時(shí)傳輸協(xié)議（RTP）以及實(shí)現(xiàn)服務(wù)質(zhì)量（QoS）的機(jī)制，QoS 機(jī)制源于底層用于VoIP 的傳輸層協(xié)議是UDP，而UDP 本質(zhì)上盡力而為的協(xié)議。典型的VoIP 部署包含多個(gè)專用硬件設(shè)備，例如SIP 代理服務(wù)器、具有QoS功能的交換機(jī)和路由器以及VoIP 電話。QoS 傳統(tǒng)上基于在網(wǎng)絡(luò)范圍內(nèi)配置的靜態(tài)服務(wù)級別的協(xié)議策略來實(shí)現(xiàn)，任何這些策略的更改都需要重新配置所有連接的設(shè)備。

在本文的研究中，我們利用了SDN 的原理，并嘗試在SDN 架構(gòu)中將SIP 代理功能從數(shù)據(jù)平面下放到應(yīng)用程序平面，目的是為了增強(qiáng)傳統(tǒng)的QoS，從而達(dá)到降低在大型網(wǎng)絡(luò)中管理多個(gè)基于硬件的SIP 代理所面臨的復(fù)雜性，并提供基于語音應(yīng)用程序特定信息做出動(dòng)態(tài)QoS 決策的能力。

在本文中，我們將SDN 的原理應(yīng)用于VoIP，并設(shè)計(jì)了一個(gè)用于SIP 信令控制和增強(qiáng)QoS 技術(shù)的應(yīng)用程序。這項(xiàng)研究的新穎之處在于其開發(fā)應(yīng)用程序的方法以及將應(yīng)用程序的感知納入網(wǎng)絡(luò)管理策略的方法。

我們通過獲取實(shí)時(shí)網(wǎng)絡(luò)參數(shù)和通過主動(dòng)和被動(dòng)方法使QoS 配置動(dòng)態(tài)化，能夠做到網(wǎng)絡(luò)感知的QoS，從而使得應(yīng)用平臺的程序在做出轉(zhuǎn)發(fā)決策時(shí)通過使用多個(gè)實(shí)時(shí)參數(shù)（例如帶寬、延遲和丟包率）來動(dòng)態(tài)增強(qiáng)QoS。

我們通過包含額外的SIP 消息和為語音流量增強(qiáng)的QoS 技術(shù)來增強(qiáng)SIP 代理軟件的能力，從而消除對專用SIP 硬件的需求。

2 研究概述

2.1 研究環(huán)境

如圖1 所示，研究環(huán)境遵循由三個(gè)獨(dú)立層組成的 SDN架構(gòu)定義：基礎(chǔ)設(shè)施層、控制層和應(yīng)用層。

圖1 研究環(huán)境

S1、S2、S3、S4 和S5 是支持OpenFlow[7]的虛擬交換機(jī)，SIP 端點(diǎn)是使用基于Linux 的Twinkle[8]來模擬的softphone，SDN Controller 為基于Ryu[9]的SDN 控制器，經(jīng)過良好測試并具有明確定義的API 集合。

Softphone 支持各種編解碼器，例如G.711、GSM、Speex、iLBC 和G.726。在softphone 上將虛擬IP 地址配置為SIP 代理服務(wù)器IP 地址，用來將所有SIP 流量從OpenFlow 交換機(jī)重定向到SDN 控制器。

支持OpenFlow 的虛擬交換機(jī)通過TCP 端口6653 與SDN 控制器建立帶外OpenFlow 連接。因?yàn)榫W(wǎng)絡(luò)中不存在SIP 服務(wù)器，并且控制器上沒有相應(yīng)的SIP 注冊器和代理服務(wù)器來運(yùn)行SIP 的服務(wù)，所以softphone 無法注冊或撥打電話。

2.2 SIP 控制器程序

為了和SDN 控制器通信，我們設(shè)計(jì)了一個(gè)能夠利用OpenFlow 完成SIP 功能的SIP Controller 控制器程序。

這個(gè)應(yīng)用程序的基本架構(gòu)如圖2 所示：該框架的三個(gè)組件是SIP Probe 模塊、SIP Registrar（注冊）模塊和 SIP Proxy（代理）模塊。

圖2 SIP Controller 程序

Probe模塊分析傳入的OpenFlow Packet-In消息以確定SIP 請求或者響應(yīng)的數(shù)據(jù)包類型，并將應(yīng)用層的信息轉(zhuǎn)發(fā)到SIP 注冊模塊、代理模塊或動(dòng)態(tài)QoS 程序。SIP 注冊模塊負(fù)責(zé)接收REGISTER 消息并將User Agent（用戶代理，通常是用戶設(shè)備即終端上的一個(gè)應(yīng)用或一個(gè)專用的硬件設(shè)備）的地址記錄（AOR）與其IP 地址的映射存儲為適合快速查找的數(shù)據(jù)結(jié)構(gòu)。該模塊通過檢查SIP REGISTER數(shù)據(jù)包并解析Contact 以獲取AOR 和IP 地址。該模塊還支持通過客戶端的Expires 或Contact 中的expires 參數(shù)設(shè)置到期間隔。在存儲完所需的信息后，SIP 注冊模塊構(gòu)造一個(gè)200 OK 響應(yīng)發(fā)給User Agent，表示注冊成功。響應(yīng)通過使用OpenFlow交換機(jī)的Packet-Out消息發(fā)送到User Agent，響應(yīng)包包含與REGISTER 消息中相同的Contact URI 以及expires 參數(shù)。如果REGISTER 不包含expires 參數(shù)或Expires 頭部，則模塊選擇默認(rèn)時(shí)間3 600秒并將其附加到響應(yīng)中的Contact頭部。來自同一User Agent 的后續(xù)REGISTER 消息通過檢查 Contact、To、From、Call ID 和From 頭部是否與原始REGISTER 消息中的字段相同，因?yàn)镃Seq 已增加，可以確認(rèn)請求是更新相同的AOR，不是新的注冊。此外，SIP Registrar 模塊如果在過期定時(shí)器到期之前沒有收到User Agent的注冊刷新，則會刪除注冊條目。如果收到一個(gè)User Agent 的不帶Contact 頭部的REGISTER 消息，則支持返回存儲在數(shù)據(jù)結(jié)構(gòu)中的此用戶當(dāng)前的注冊信息。

SIP 代理模塊管理從一個(gè)User Agent 到另一個(gè)User Agent 的SIP 路由以及其他呼叫建立的功能。SIP 代理模塊通過維護(hù)事務(wù)的狀態(tài)來模擬SIP 事務(wù)狀態(tài)的代理。在收到主叫方的INVITE 請求作為OpenFlow Packet-In 消息后，該模塊解析該請求，從To 頭部中提取被叫方的URI，并從SIP Registrar 模塊的數(shù)據(jù)結(jié)構(gòu)中查找被叫方的IP 地址，然后在連接到主叫方的交換機(jī)上添加一個(gè)流表項(xiàng)，在附加其IP 地址作為另一個(gè)Via 頭字段之后，使用OpenFlow 的Flow-Mod 消息將INVITE 轉(zhuǎn)發(fā)給被叫方。此外，為了最大限度地減少網(wǎng)絡(luò)中 INVITE 重傳的次數(shù)，該模塊創(chuàng)建了一個(gè)100 Trying 消息，通過OpenFlow Packet-Out 消息，只發(fā)送給收到 INVITE 的交換機(jī)。如果被叫方的AOR 在注冊模塊的數(shù)據(jù)中不存在并且匹配本地域前綴，則SIP Proxy模塊創(chuàng)建一個(gè)404 Not Found消息并使用OpenFlow Packet-Out 消息將其發(fā)送給主叫方，此消息僅從和主叫方連接的交換機(jī)發(fā)送，以減少網(wǎng)絡(luò)流量。

此外，發(fā)往本地域前綴之外的User Agent 的INVITE請求將使用默認(rèn)路由轉(zhuǎn)發(fā)到SIP 網(wǎng)關(guān)。同理，SIP Proxy 模塊在接收到來自被叫方的180 Ringing 或200 OK消息后，在第一個(gè)Via 字段中驗(yàn)證自己的 IP 地址，驗(yàn)證后刪除第一個(gè) Via 字段，然后根據(jù)下一個(gè)Via 字段中的IP 地址將消息轉(zhuǎn)發(fā)到主叫方。此消息僅由邊緣交換機(jī)進(jìn)行傳輸。此外，SIP 代理模塊通過使用OpenFlow Flow-Mod 消息在User Agent 之間轉(zhuǎn)發(fā)請求消息和相應(yīng)的200 OK 來支持對話外即時(shí)消息傳遞（如圖3 所示）。

圖3 SIP 即時(shí)消息流程

2.3 動(dòng)態(tài)QoS 程序

為了給研究網(wǎng)絡(luò)中的SIP 流量提供增強(qiáng)的QoS 功能，我們設(shè)計(jì)了一個(gè)動(dòng)態(tài)QoS 應(yīng)用程序，應(yīng)用架構(gòu)如圖4 所示。該應(yīng)用程序的三個(gè)組件是網(wǎng)絡(luò)狀態(tài)發(fā)現(xiàn)（NSD）模塊、路徑?jīng)Q策模塊和QoS 執(zhí)行器模塊。

圖4 動(dòng)態(tài)QoS 程序

NSD 模塊通過A-CPI 接口聯(lián)系SDN 控制器，并指示控制器向所有交換機(jī)發(fā)送OpenFlow Packet-Out 消息，告訴它們從每個(gè)交換機(jī)的所有端口傳輸自定義的UDP 發(fā)現(xiàn)幀。自定義幀由如下三個(gè)字段的有效負(fù)載組成：發(fā)送方的交換機(jī)ID、發(fā)送方的時(shí)間戳和發(fā)送方端口，該幀的目的是映射網(wǎng)絡(luò)并獲取QoS的延遲信息。這些幀是單跳廣播幀，當(dāng)另一個(gè)支持OpenFlow 的交換機(jī)收到自定義幀時(shí)，交換機(jī)有一個(gè)流表項(xiàng)指示交換機(jī)將該幀發(fā)送給SDN 控制器。當(dāng)SDN控制器通過OpenFlow從交換機(jī)接收到這些自定義幀時(shí)，SDN 控制器將消息傳遞給NSD 模塊。

然后，NSD 模塊將信息編寫到當(dāng)前鏈路狀態(tài)數(shù)據(jù)庫中，從而完成網(wǎng)絡(luò)的映射。除了通過獲取任意兩臺連接的交換機(jī)的鏈路信息來映射網(wǎng)絡(luò)外，NSD 模塊還使用自定義UDP 幀來預(yù)測網(wǎng)絡(luò)的延遲。由于VoIP 中的音頻流通常通過UDP 傳輸，因此可以通過自定義UDP 發(fā)現(xiàn)幀去收集和分析相關(guān)的延遲測量數(shù)據(jù)。NSD 模塊從自定義幀內(nèi)的發(fā)送方的時(shí)間戳中減去當(dāng)前時(shí)間，就可以計(jì)算連接兩個(gè)交換機(jī)的鏈路的延遲。這種計(jì)算每3 秒發(fā)生一次，如果數(shù)據(jù)庫中的時(shí)間戳變得陳舊比如超過45 秒未更新，則從數(shù)據(jù)庫中刪除這條鏈接信息。此外，NSD 模塊使用OpenFlow Port-Stats multipart 消息跟蹤每個(gè)交換機(jī)端口的帶寬利用率。

路徑?jīng)Q策模塊根據(jù)建立SIP 會話時(shí)可用的最佳路徑主動(dòng)決定語音呼叫的路徑，并且在當(dāng)前網(wǎng)絡(luò)條件發(fā)生變化時(shí)做出反應(yīng)。該模塊執(zhí)行的步驟是：

（1）當(dāng)被叫方接收呼叫并以200 OK 響應(yīng)時(shí)，路徑確定模塊被觸發(fā)，并根據(jù)NSD 創(chuàng)建的當(dāng)前鏈路狀態(tài)數(shù)據(jù)庫中的可用信息確定主叫方和被叫方之間的可用路徑數(shù)。然后，該模塊選擇具有最少交換機(jī)間 UDP 延遲的作為主路徑（由 NSD 模塊使用自定義 UDP 發(fā)現(xiàn)幀計(jì)算）和其他則作為備用路徑。

（2）對于在步驟1 中選擇的路徑，接下來確定要為呼叫保留的帶寬量。路徑?jīng)Q策模塊從SIP 控制器程序的SIP Probe 模塊獲取SDP 中的媒體會話的信息。該模塊從INVITE 請求和200 OK 響應(yīng)消息中SDP 的m 字段中提取RTP 媒體信息，從a 字段中提取媒體屬性，以及從SDP中存在的b 字段中提取可選帶寬信息。如果該字段不存在于數(shù)據(jù)包中，則將提取的信息與現(xiàn)有的媒體編解碼列表進(jìn)行匹配，以確定要為每條路徑保留的帶寬量。表1 列出了一個(gè)路徑所需的編解碼器和帶寬量。G.711 所示的帶寬計(jì)算執(zhí)行如下：

表1 不同編碼要求的帶寬

①總數(shù)據(jù)包大?。ㄒ宰止?jié)為單位）=14（Ethernet）+20（IP）+8（UDP）+12（RTP）+160（G.711）+4（CRC）=218 字節(jié)

②每秒數(shù)據(jù)包=編解碼器比特率/語音有效載荷大小=64 kbit/s/160 byte=50/s

③所需帶寬=總數(shù)據(jù)包大小x 每秒數(shù)據(jù)包=87.2 kbit/s

（3）路徑?jīng)Q策模塊此后從當(dāng)前鏈路狀態(tài)數(shù)據(jù)庫檢查所需的帶寬量是否在雙向選擇的路徑中的每個(gè)交換機(jī)的每個(gè)出口端口上可用。如果所需的帶寬不存在，模塊會從步驟1 中選擇一條備用路徑并再次執(zhí)行相同的檢查。

（4）為了在正在進(jìn)行的會話期間及時(shí)地檢查呼叫質(zhì)量，該模塊會跟蹤RTP 會話上發(fā)生的數(shù)據(jù)包丟失。OpenFlow Flow-Stats multipart消息用于每5秒獲取一次呼叫路徑中第一個(gè)和最后一個(gè)交換機(jī)上與特定RTP 流匹配的數(shù)據(jù)包數(shù)量。該模塊能夠根據(jù)路徑上的數(shù)據(jù)丟包率進(jìn)行決策，如果丟包率增加到設(shè)置的閾值（20%）以上，它會將RTP 流切換到一條備用路徑。這里閾值選擇為20%，是因?yàn)閷τ诖笥?0%的數(shù)據(jù)包丟包率，MOS 值通常趨于小于2.5[10]。

最后，QoS 執(zhí)行器模塊從路徑?jīng)Q策模塊收集所有相關(guān)信息，用來在基礎(chǔ)設(shè)施層提供所需的QoS 策略。該模塊使用OVSDB[11]在為呼叫選擇的路徑中的所有交換機(jī)上創(chuàng)建Linux 分層令牌桶（HTB）[12]隊(duì)列。根據(jù)步驟2 中通過SDP 協(xié)商的編解碼器的帶寬要求，該模塊首先創(chuàng)建保留最小帶寬的隊(duì)列，然后在鏈接路徑的交換機(jī)上添加流表項(xiàng)以引導(dǎo)特定流量，這些流表項(xiàng)中匹配從SDP 中獲取到的IP 地址和UDP 端口號，以用于后續(xù)的RTP 會話。此外,當(dāng)SIP控制器程序檢測到BYE 消息時(shí)，QoS 執(zhí)行器模塊會刪除HTB 隊(duì)列配置，以允許保留的帶寬再次用于所有其他流量。

2.4 結(jié)果與分析

在上訴的研究環(huán)境中對SIP 控制器和動(dòng)態(tài)QoS 程序進(jìn)行了如下的功能驗(yàn)證。

2.4.1 與SDN 控制器通信的程序能否重寫SIP 功能，從而消除對專用SIP 硬件的需求？

User Agent 的SIP 注冊，分四步完成（如圖5 所示）。在User Agent 上配置了一個(gè)虛擬IP 作為SIP 代理服務(wù)器地址，并且該IP 的所有ARP 請求都被邊緣交換機(jī)攔截并發(fā)送到 SDN 控制器，沒有轉(zhuǎn)發(fā)給網(wǎng)絡(luò)上的其他交換機(jī)。ARP 請求由SIP 控制器程序應(yīng)答，包含虛擬媒體訪問控制（MAC）地址的ARP 應(yīng)答，僅從網(wǎng)絡(luò)中的邊緣交換機(jī)傳輸。

圖5 SIP 注冊流程

最開始時(shí)，所有啟用OpenFlow 的交換機(jī)都有默認(rèn)流表項(xiàng)，將所有不匹配任何規(guī)則的數(shù)據(jù)包轉(zhuǎn)發(fā)到SDN 控制器。

（1）User Agent 1 發(fā)送了一個(gè)以虛擬IP 地址為目標(biāo)的 REGISTER 請求，該請求到達(dá)交換機(jī)S1。

（2）S1 捕獲REGISTER 請求并將其作為OpenFlow Packet-In 消息發(fā)送到SDN 控制器。

（3）SDN 控制器中的SIP 控制器的注冊模塊解析REGISTER 請求，提取并存儲User Agent 的聯(lián)系信息，創(chuàng)建200 OK 響應(yīng)并將其作為Packet-Out 消息發(fā)送回S1。

（4）S1通過其OpenFlow通道收到Packet-Out消息，并將200 OK 響應(yīng)發(fā)送回User Agent 1。

User Agent 2 按照與上述類似的步驟同樣注冊成功。此外，還成功測試了其他注冊機(jī)制，例如注冊用戶更新和請求聯(lián)系人列表以及取消注冊。

接下來，通過SIP 控制器程序測試了User Agent 1 和2 之間的呼叫建立和釋放。

SIP代理模塊成功地使用OpenFlow Flow-Mod消息在注冊User Agent 之間路由INVITE、180 Ringing 和200 OK數(shù)據(jù)包。它還使用發(fā)送到交換機(jī)的OpenFlow Packet-Out消息創(chuàng)建并向User Agent 發(fā)送100 Trying 數(shù)據(jù)包。還測試了SIP 即時(shí)消息功能，該程序成功地路由了User Agent 之間的請求和200 OK 等響應(yīng)數(shù)據(jù)包，進(jìn)行了呼叫未注冊用戶、被叫用戶未接聽、主叫未接聽電話、被叫拒絕接聽等異常測試場景，以驗(yàn)證應(yīng)用的完整性，能夠覆蓋到每個(gè)場景的相關(guān)SIP 消息，如404 Not Found、480 Temporarily Unavailable、487 Request Terminated 和603 Decline。

該實(shí)驗(yàn)的結(jié)果證明，開發(fā)用于重寫SIP 功能的程序作為與SDN 控制器通信的軟件是可以實(shí)現(xiàn)的。這種方法的主要優(yōu)勢在于，服務(wù)器上運(yùn)行的軟件無需使用專用硬件設(shè)備在網(wǎng)絡(luò)中提供SIP 代理功能。此外，該應(yīng)用程序完全使用開源技術(shù)開發(fā)，因此價(jià)格低廉。對此類應(yīng)用程序進(jìn)行編程的能力允許在不依賴于網(wǎng)絡(luò)供應(yīng)商的情況下測試和實(shí)施自定義功能。其他網(wǎng)絡(luò)優(yōu)勢包括通過將ARP 請求轉(zhuǎn)發(fā)到特定端口而不是將它們泛洪到整個(gè)網(wǎng)絡(luò)以節(jié)省帶寬來減少廣播ARP 流量；對SIP 代理服務(wù)器的虛擬IP 的ARP 請求在第一跳交換機(jī)上由應(yīng)用程序生成回復(fù)數(shù)據(jù)包進(jìn)行響應(yīng)。此外，NSD 模塊通過映射交換機(jī)-電話和交換機(jī)-交換機(jī)鏈路，使整個(gè)交換機(jī)環(huán)境能夠充當(dāng)單個(gè)交換機(jī)。

2.4.2 應(yīng)用程序能否在做出轉(zhuǎn)發(fā)決策時(shí)通過使用多個(gè)實(shí)時(shí)參數(shù)（如延遲、帶寬和丟包率）來動(dòng)態(tài)增強(qiáng)QoS？

我們執(zhí)行了三組實(shí)驗(yàn)，每組實(shí)驗(yàn)有兩個(gè)測試，以驗(yàn)證動(dòng)態(tài)QoS 程序在確定語音流量路徑時(shí)是否考慮了當(dāng)前的延遲、帶寬和數(shù)據(jù)包丟包率的測量數(shù)據(jù)。Linux 模塊netem[13]用于模擬網(wǎng)絡(luò)中交換機(jī)間鏈路上的高延遲和數(shù)據(jù)包丟包。默認(rèn)的交換機(jī)間鏈路延遲約為5 ms，這意味著路徑S1-S2-S3-S4（路徑1）上的端到端延遲約為15 ms，而在路徑S1-S5-S4（路徑2）上大約10 ms，在第一次測試中，User Agent 1呼叫User Agent 2，在User Agent 2接收呼叫并回復(fù)200 OK 后，應(yīng)用程序選擇路徑2 作為主路徑，路徑1 作為RTP 的備份路徑。在第二個(gè)測試中，對于所有傳向S4 的數(shù)據(jù)包，在交換機(jī)S5 上模擬了所有數(shù)據(jù)包的30 ms 額外延遲，在本例中，由于從當(dāng)前鏈接狀態(tài)數(shù)據(jù)庫中路徑1 獲取的端到端延遲較小，因此選擇路徑1 作為主要路徑。這些測試展示了應(yīng)用程序根據(jù)延遲動(dòng)態(tài)做出QoS決策的能力。

第二組實(shí)驗(yàn)涉及驗(yàn)證應(yīng)用程序是否可以確定和檢查呼叫的帶寬要求。交換機(jī)間鏈路的默認(rèn)帶寬為100 Mbit/s。在第一個(gè)測試中，User Agent 1 呼叫User Agent 2 并使用G.711 協(xié)商音頻會話。應(yīng)用程序從200 OK 響應(yīng)中的SDP中提取編解碼器和帶寬信息（如果存在）進(jìn)行協(xié)商，并確定此會話所需的帶寬。然后，應(yīng)用程序檢查當(dāng)前鏈路狀態(tài)數(shù)據(jù)庫，以確定先前選擇的主路徑（路徑1）上是否有所需的帶寬量。由于主路徑上沒有模擬其他流量，應(yīng)用程序選擇了路徑1 并通知QoS 執(zhí)行器模塊，用于在交換機(jī)S1、S5 和S4 上創(chuàng)建必要的隊(duì)列和流表項(xiàng)。在第二個(gè)測試中，使用iperf[14]模擬擁塞場景，在路徑1 上的交換機(jī)S1 和S5之間生成了100 Mbit/s 的人工流量。在這種情況下，應(yīng)用程序沒有在出口端口上找到所需的可用帶寬量，因此從潛在的路徑列表中刪除了路徑1。然后它檢查沒有流量的路徑2，并為 RTP 會話選擇它。這些測試驗(yàn)證了應(yīng)用程序可以推斷即將到來的呼叫的帶寬要求并相應(yīng)地做出QoS 決策。

為了檢查應(yīng)用程序根據(jù)不斷變化的網(wǎng)絡(luò)條件做出動(dòng)態(tài)決策的反應(yīng)能力，進(jìn)行了第三組實(shí)驗(yàn)。在User Agent 1 和2 之間通過路徑1 進(jìn)行的持續(xù)呼叫期間，在交換機(jī)S5 和S4 之間模擬了數(shù)據(jù)包丟失。

在第一個(gè)測試中，在交換機(jī)S5 上為所有傳出到S4 的數(shù)據(jù)包模擬了5%的數(shù)據(jù)包丟失。路徑?jīng)Q策模塊通過檢查交換機(jī)S1 和S4 上的流計(jì)數(shù)器來檢測UA 之間語音RTP 流，但由于它在定義的閾值（20%）內(nèi)，因此未采取任何措施。

在第二個(gè)測試中，在S5 上模擬了20%的數(shù)據(jù)包丟失，在這種情況下，應(yīng)用程序檢測到丟包率達(dá)到閾值，將RTP 流量從路徑1 重定向到備份路徑2，通過更改交換機(jī)S1 和S4 上的流表項(xiàng)，并在S2 和S3 上添加新的流表項(xiàng)。本次實(shí)驗(yàn)驗(yàn)證了應(yīng)用程序根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境實(shí)時(shí)修改QoS決策的功能。

3 結(jié)束語

在這項(xiàng)研究中，我們設(shè)計(jì)了一套軟件定義的SIP 框架，以將傳統(tǒng)SIP 功能重新調(diào)整為能和SDN 控制器通信的軟件，并且與動(dòng)態(tài)QoS 程序一起運(yùn)行，以將應(yīng)用程序?qū)W(wǎng)絡(luò)自感知整合到網(wǎng)絡(luò)中。這項(xiàng)工作的目的是展示所設(shè)計(jì)的框架能夠利用SDN 的原則對SIP 應(yīng)用程序的管理提供更多控制。SIP 注冊和路由功能在具有網(wǎng)絡(luò)全局視角的控制器程序中實(shí)現(xiàn)，無需專用的SIP 代理硬件設(shè)備。動(dòng)態(tài)QoS程序完成了根據(jù)實(shí)時(shí)網(wǎng)絡(luò)參數(shù)來進(jìn)行實(shí)時(shí)調(diào)整工作，例如根據(jù)延遲、呼叫會話所需的帶寬和當(dāng)前數(shù)據(jù)包丟包率這些因素來進(jìn)行路徑確定的工作。

該SIP 框架系統(tǒng)驗(yàn)證了SDN 與SIP 會話系統(tǒng)結(jié)合的可行性，后續(xù)可對SIP 系統(tǒng)的協(xié)議功能進(jìn)一步開發(fā)完善，以便在實(shí)際部署應(yīng)用時(shí)可以適配現(xiàn)網(wǎng)的SIP 終端的注冊和會話控制等功能。