SIPv6 Translator系統之效能量測實驗

第四章 SIPv6 Translator之互通性測試與效能評估

4.2 SIPv6 Translator系統之效能量測實驗

為了分析本系統 SIPv6 Translator 的效能，我們觀察 SIP 撥話者通話建立時所增加的延遲時間，來作為 SIPv6 Translator 系統之效能量測實驗的評估依據。

為了快速地開發出 SIP 通話建立訊息測試程式，本論文採用開放原始碼的 osip 以及 eXosip 函式庫套件作為底層開發模組[23,24]。撥話者發出 SIP INVITE 要求到發出 SIP ACK 要求這段時間為通話建立時間，我們定義為通話建立時間（Call Setup Time；

簡稱 CST）。如圖 4-6 所示，本實驗中以測量 CST 所增加的延遲時間來評估 SIPv6 Translator 的效能。

Ti m e

UAC UAS

CST

INVITE

180 Ringing 200 OK

ACK 100 Trying

UAC: User Agent Client UAS: User Agent Server CST: Call Setup Time UAC: User Agent Client UAS: User Agent Server CST: Call Setup Time

圖 4-6 SIP 通話建立之訊息流程圖

IPv4 Network IPv4 Network

(NTU) (NTU)

SIPv6 Translator

IPv4 SIP UA (UA1)

IPv6 SIP UA (UA2)

NTU SIP Server

NCTU SIP Server IPv4 SIP UA

(UA3)

圖 4-7 SIPv6 Translator 系統之效能量測實驗環境架構圖

效能測試實驗環境架構圖如圖 4-7 所示。UA1 與 UA3 為 IPv4 SIP UAs，UA2 為 IPv6 SIP UA。UA1 與 UA2 擔任為撥話者，UA3 則擔任受話者。接下來我們以三個實驗來測試 SIPv6 Translator 所增加的額外負擔，每個實驗分成實驗組 a 與對照組 b。實驗組表示此實驗環境不包含 SIPv6 Translator，對照組表示此實驗環境包含 SIPv6 Translator。

藉由實驗組與對照組的比較，就可以得到 SIPv6 Translator 所增加的延遲時間。底下描述各分項實驗之環境架構。

如圖 4-8 所示，在最簡單的環境（實驗 1）下，兩個 UAs 不需要透過 SIP 伺服器直接互相連線。實驗 1 的目的是在最簡單的環境下測量 SIPv6 Translator 所增加的 CST。

在實驗 1a，UA1 與 UA3 之間直接透過網路線連接。在實驗 1b，UA2 與 UA3 透過 SIPv6 Translator 連接。

SIPv6 Translator 透過 NCTU SIP 伺服器與 UA3 建立通話。在實驗 2b，UA2 會先經過 SIPv6 Translator 的轉換，再透過 NCTU SIP 伺服器與 UA3 建立通話。比較實驗 1 與 2，我們可以得到 SIPv6 Translator 與 SIP 伺服器之 CST。

SIPv6 Translator

給 NCTU SIP 伺服器，然後再透過 NTU SIP 伺服器傳給 UA3 來建立通話。實驗 3 增加了從 NCTU 到 NTU 網路之間經過了兩次 TANet（Taiwan Academic Network）骨幹網路傳輸，因此比較實驗 2 與 3 可得網路傳輸之 CST。

CST 大約增加 11.3 ms；而經過 SIPv6 Translator，CST 大約增加不到 1 ms。由此可知，

SIP 伺服器、網路以及 SIPv6 Translator 都會增加 CST 的負擔，在這些因素之中，SIPv6 Translator 的影響最小。

表 4-2 SIPv6 Translator 在各分項實驗中所增加負擔之比較

實驗2b (Method 1)

932 (4.93%) 967 (24.15%) 0

Extra Overhead

19823.7192 實驗3b (Method 1)

4970.3859 實驗1b (Method 1)

4003.3634

實驗2b (Method 1)

932 (4.93%) 967 (24.15%) 0

Extra Overhead

19823.7192 實驗3b (Method 1)

4970.3859 實驗1b (Method 1)

4003.3634 實驗1a

Mean CST (us)

表 4-3 比較 SIP-ALG 實作方式一與二的效能。SIPv6 Translator 採用方法二來實作 SIP-ALG，對 CST 所增加的負擔大約 0.2 ms，效能大約比方法一提升近 5 倍。從實驗 1 來看，SIPv6 Translator 所增加的負擔降到了 5.07%，在實驗 2 更是降到了 2.76%。

表 4-3 SIP-ALG 實作方法一與二之效能比較

989 (13.02%)

8584.6394

實驗2b (Method 1)

210 (2.76%)

7805.0647

實驗2b (Method 2)

203 (5.07%)

4206.1100

實驗1b (Method 2)

967 (24.15%)

Extra Overhead

4970.3859

實驗1b (Method 1)

Mean CST (us)

989 (13.02%)

8584.6394

實驗2b (Method 1)

210 (2.76%)

7805.0647

實驗2b (Method 2)

203 (5.07%)

4206.1100

實驗1b (Method 2)

967 (24.15%)

Extra Overhead

4970.3859

實驗1b (Method 1)

Mean CST (us)

實驗結果顯示，SIP-ALG 實作方法二的效能比方法一提升接近 5 倍。一個 SIP Proxy 所增加的時間延遲大約為 3.6 ms，經過了網路之後，所增加的時間延遲大約為 11.3 ms，

而本論文的 SIPv6 Translator 系統僅僅增加了大約 0.2 ms 的負擔，幾乎可以被忽略不計。

第五章結論

由於越來越多人使用 SIP 網路電話，每個網路電話裝置都至少需要一個 IP 位址。

隨著網路電話的普及，IPv4 將不足以分配給每一台網路電話。IPv6 提供大量的 IP 位址來解決 IPv4 位址不足的問題，但在 IPv6 佈建初期，大多數的 SIP 網路電話仍只支援 IPv4。本論文提出 SIPv6 Translator 系統之設計與實作，提供一個 SIP 協定的轉換機制，

讓 IPv6 網路電話使用者與 IPv4 網路電話使用者可以互相通訊。SIPv6 Translator 系統以 NAT-PT 機制為基礎，加入了 SIP-ALG 轉換機制，針對 SIP 訊息內的 IP 資訊作轉換，

讓 SIP 訊息可以在 IPv6 與 IPv4 網路 SIP 設備之間正確的傳遞。SIP 伺服器、網路路由以及 SIPv6 Translator 都會對 SIP 通話建立的時間造成影響，然而在這些影響 SIP 通話建立時間的因素之中，以 SIPv6 Translator 系統所增加的負擔最小，其中 SIP-ALG 實作方法二之延遲幾乎可以被忽略。

未來期望以 SIPv6 Translator 的開發成果，協助 NICI IPv6 基礎建設分組之 IPv6 SIP 網路之建置，藉 SIP 網路電話之應用來推動國內 IPv6 之使用，並促進 SIP 設備廠商進一步研發 IPv6 SIP 網路電話設備。此成果對於 IPv6 與 VoIP 的推廣均有相當大的助益。

參考文獻

[1] Tsirtsis, G., and Srisuresh, P., “DNetwork Address Translation - Protocol Translation (NAT-PT)”, RFC 2766, February 2000.

[2] Nordmark., E., “Stateless IP/ICMP Translation Algorithm (SIIT)”, RFC 2765, February 2000.

[3] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification”, STD 5, RFC 791,USC/Information Sciences Institute, September 1981.

[4] J. Postel, "Transmission Control Protocol", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.

[5] J. Postel, "User Datagram Protocol", STD7 , RFC 768, USC/Information Sciences Institute, August 1980.

[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC

2460, December 1998.

[7] Hinden, R. and S. Deering, "Internet Protocol Version 6 ( IPv6 ) Addressing Architecture", RFC 3513, April 2003.

[8] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[9] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.

[10] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

[11] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[12] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC

1035, November 1987.

[13] Thomson, S. , Huitema, C., Ksinant, V. and M. Souissi, "DNS Extensions to support IP version 6", RFC 3596, October 2003.

[14] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.

[15] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and Heffernan, A., “DNS extensions to Network Address Translators (DNS_ALG)”, RFC 2694, September 1999.

[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks , R. , Handley, M. , and E. Schooler , “SIP: Session Initiation Protocol”, RFC 3261, June 2002.

[17] Johnston, A., Donovan, S., Cunningham, C., and Summers., K., “Session Initiation Protocol (SIP) Basic Call Flow Examples”, RFC 3665, December 2003.

[18] Handley, M. and V. Jacobson, “SDP: Session Description Protocol”, RFC 2327, April 1998.

[19] Olson, S., Camarillo G., A. B. Roach, “Support for IPv6 in Session Description Protocol (SDP)”, RFC 3266, June 2002.

[20] Rosenberg, J., and Schulzrinne, H., “An Offer/Answer Model with the Session Description Protocol (SDP)”, RFC 3264, June 2002.

[21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, “A Transport Protocol for Real-Time Application”, RFC 3550, July 2003.

[22] Silvia Hagen. IPv6 Essentials. Oreilly. 2002.

[23] http://savannah.nongnu.org/projects/exosip/

[24] http://www.gnu.org/software/osip/osip.html

附錄 A

DNS-ALG 模組實作原理

當網路上的使用者想要建立連線，必須先知道雙方的 IP 位址，然而 IP 位址繁瑣冗長，使用者並不容易牢記，因此就有 DNS（Domain Name System）協定被提了出來。

DNS 伺服器提供 IP 與網域名稱（Domain Name）對應的服務，網域名稱為一連串有意義的字串，字串之間以句號分隔（例如 www.nctu.edu.tw 對應到 140.113.1.1 ）。網域名稱對使用者來說較為記憶方便。

A.1 DNS 訊息格式

DNS 訊息如圖 A-1 所示。DNS 訊息最前面的部份為 DNS 標頭，接著四個部份依序為 Query Entries、Answer RRs（Resource Records）、Authority RRs 以及 Additional RRs。DNS header 指明此訊息是查詢（Query）訊息或回應（Response）訊息，並記錄 Query Entries、Answer RRs（Resource Records）、Authority RRs 以及 Additional RRs 的個數。Query Entries 指明訊息中查詢的資訊。Answer RRs 指明該查詢的答覆。Authority RRs 指明授權的名稱伺服器資訊。Additional RRs 指明其他相關資訊。DNS header 在 DNS 訊息中一定會出現，而 Query Entries、Answer RRs（Resource Records）、Authority RRs 以及 Additional RRs 則不一定會出現。

DNS Header

Query Entries

Answer RRs

Authority RRs

Additional RRs

圖 A-1 DNS 訊息格式

如圖 A-2 所示，DNS 標頭格式中的 QDCount 欄位記載著 Query Entries 的個數，

ANCount、NSCount 以及 ARCount 欄位分別記載 Answer RRs、Authority RRs 以及 Additional RRs 的個數。當上述四個欄位中任一欄位為 0，則對應的資訊不會出現在 DNS 訊息之中。例如 ARCount 欄位為 0，則 Additional RRs 不會出現在 DNS 訊息中。其餘欄位定義請參閱 RFC1035。

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ID

Z RCode

OpCode AA TC RD RA QR

QDCount ANCount NSCount ARCount

圖 A-2 DNS 標頭格式

查詢類別定義請參閱 RFC1035。

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

QName

QType QClass

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

QName

QType QClass

圖 A-3 DNS Query Entry 格式

如圖 A-4 所示，Query Entries、Answer RRs（Resource Records）、Authority RRs 以及 Additional RRs 的格式皆相同，包括名稱（Name）、型態（Type）、類別（Class）、

有效時間（TTL）、RR 資料長度（Data Length）與 RR 資料內容（Data）。

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Name Type Class

RDLength RData

Class

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Name Type Class

RDLength RData

Class

圖 A0-4 DNS Answer RR, Authority RR, Additional RR 格式

在 Query Entries 中的查詢名稱欄位以及 RRs 中的名稱欄位中，大多數的情況下帶有非常長的字串名稱（例如 www.csie.nctu.edu.tw 共有 21 個字元），而且在 DNS 訊息中，名稱欄位內的網域名稱有可能重複。由於在現實網路環境中 DNS 訊息的使用非常頻繁，為了減少 DNS 訊息在網路中的流量，DNS 標準文件提出了訊息壓縮（Message

Compression）的模式。當名稱欄位最前面兩個位元同時為 1 的情況下，表示此名稱欄位為訊息壓縮的模式，接著並以 14 個位元的位移（Offset）欄位指明名稱字串指標在 DNS 訊息中的位置。雖然 DSN 標準文件稱為訊息壓縮模式，實際上是以 16 個位元來指明 DNS 訊息中已經出現過的名稱。訊息壓縮的範例請參閱 RFC1035 第 31 頁。

Offset 1 1

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Offset 1 1

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

圖 A-5 在 DNS Entry 與 RR 中，名稱欄位之訊息壓縮格式

A.2 DNS-ALG 之實作原理

在 NAT-PT 的網路架構中，IPv6 網路上的主機藉由 IPv6 DNS 伺服器與 IPv6 網路上其他的主機建立連線，IPv4 網路上的主機使用 IPv4 DNS 伺服器與 IPv4 網路上其他的主機建立連線。但是當 IPv6 主機要與 IPv4 主機建立連線之前，會先向 IPv6 DNS 伺服器查詢 IPv4 主機的位址，由於在 IPv6 DNS 伺服器與 IPv4 DNS 伺服器之間並沒有傳遞（Forwarder）關係，因此就無法遞迴式（Recursive）查詢到 IPv4 使用者的位址。除此之外，即使 IPv6 與 IPv4 DNS 伺服器互相設定傳遞關係，由於 IPv4 DNS 伺服器回傳給 IPv6 DNS 伺服器是 IPv4 位址，IPv6 主機仍然無法以 IPv4 位址在 IPv6 網路中建立連線。

為了讓 IPv6 與 IPv4 網路的主機可以雙向查詢並且正確建立連線，首先在 NAT-PT 上設定 IPv6 DNS 伺服器的 Public IPv4 位址靜態對應（Static Mapping），讓 IPv4 伺服器可以將 DNS 封包送到此 Public IPv4 位址，然後透過 NAT-PT 的轉換之後傳遞給 IPv6

址作轉換。

DNS-ALG 模組針對 DNS 通訊協定的封包進行分析。DNS-ALG 模組內部包括 DNS 解析（DNS Parser）單元（圖 A-6○^a ）、IP 位址字串處理單元（圖 A-6○^b ）以及封包長

/ Definition of DNS Message /

struct DNSMessage {

DNSHeader header; /* Header Section /

DNSEntry qdENT; /* point of question Entry /

DNSRR anRR; /* point of answer RR /

DNSRR nsRR; /* point of authority RR /

DNSRR arRR; /* point of additional RR /

}

圖 A-7 DNS 通訊協定資料結構的型態定義圖

Question Entries

ARCount

^arRR1 ^arRR2 ^arRR3

nsRR1 nsRR2 nsRR3

anRR1 anRR2 anRR3

qdENT1 qdENT2 qdENT3

Question Entries

Answer RRs

ARCount

^arRR1 ^arRR2 ^arRR3

nsRR1 nsRR2 nsRR3

anRR1 anRR2 anRR3

qdENT1 qdENT2 qdENT3

圖 A-8 DNS 通訊協定資料結構的型態關係圖

IP 位址字串處理單元針對 DNS 訊息內的 IP 位址，進行轉換的工作。底下對 Question Entries 以及其他 RRs（包括 Answer RRs、Authority RRs 以及 Additional RRs）分別說明轉換演算法。

IP 位址字串處理單元針對於 DNS 訊息內的 Question Entries 進行分析工作。若類別

（Class）欄位為 Internet（值等於 1），且型態（Type）欄位的值為 A（值等於 1），

表示這是一個 DNS IPv4 正查訊息，IP 位址字串處理單元要將型態欄位的值由 A 轉換

IP 位址字串處理單元針對於 DNS 訊息內的 Answer RRs, Authority RRs, Additional

IPv6 位址；若型態欄位的值為 AAAA，表示這是一個 DNS IPv6 訊息，IP 位址字串處理單元要者將型態欄位的值由 AAAA 轉換為 A，並且將 RR 資料內的 IPv6 址轉換為 IPv4 位址（如表 A-2 所示）。

表 A-1 Question Entries 轉換演算法

Field

If QClass==IN（1） If QClass==IN（1） and QType==PTR（12）

QType

A（1）轉換 AAAA（28）

No Modification

QName No

Modification IPv4 octets with preceding string “IN-ADDR.ARPA”

（e.g., 100.100.113.140.IN-ADDR.ARPA.）

轉換

IPv6 octets with preceding string “IP6.NET”

（e.g., 4.6.4.6.1.7.c.8.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.6.3.e.f.f.3.IP6.NET.）

表 A-2 Answer RRs, Authority RRs, Additional RRs 轉換演算法

Field

Type A（1）轉換 AAAA（28）

RData 4-bytes IPv4 address（e.g., 140.113.100.100）

轉換

16-bytes IPv6 address（e.g., 3ffe:3600:1::8c74:6060）

封包長度修正單元負責兩個工作。第一，針對 IP 位址資訊已轉換完成的 RRs 進行 RR 資料長度欄位的修正；第二，當 DNS 訊息中名稱欄位內的 IP 位址經過轉換之後，

IP 位址的字串長度會改變，若其他的 Query Entries 或 RRs 中有名稱欄位採用訊息壓縮模式，則會影響到位移指標所指的位置，因此必須根據 IP 位址的改變長度，再去重新計算位移指標的值。最後，封包長度修正單元會將 DNS 訊息轉換完成後的資料長度資訊，透過 ALG Dispatcher 傳遞給 SIIT 模組，來對 IP 標頭中的資料長度欄位進行修正。

在文檔中以SIP為基礎之IPv4/IPv6網路電話轉換器之研發 (頁 49-0)

第四章 SIPv6 Translator之互通性測試與效能評估

4.2 SIPv6 Translator系統之效能量測實驗

Ti m e

UAC UAS

CST

INVITE

180 Ringing 200 OK

ACK 100 Trying

IPv4 Network IPv4 Network

(NTU) (NTU)

實驗2b (Method 1)

932 (4.93%) 967 (24.15%) 0

19823.7192 實驗3b (Method 1)

4970.3859 實驗1b (Method 1)

4003.3634

實驗2b (Method 1)

932 (4.93%) 967 (24.15%) 0

19823.7192 實驗3b (Method 1)

4970.3859 實驗1b (Method 1)

4003.3634 實驗1a

989 (13.02%)

實驗2b (Method 1)

210 (2.76%)

實驗2b (Method 2)

203 (5.07%)

實驗1b (Method 2)

967 (24.15%)

實驗1b (Method 1)

989 (13.02%)

實驗2b (Method 1)

210 (2.76%)

實驗2b (Method 2)

203 (5.07%)

實驗1b (Method 2)

967 (24.15%)

實驗1b (Method 1)

第五章 結論

參考文獻

2460, December 1998.

1035, November 1987.

附錄 A

DNS-ALG 模組實作原理

A.1 DNS 訊息格式

DNS Header

Query Entries

Answer RRs

Authority RRs

Additional RRs

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ID

Z RCode

OpCode AA TC RD RA QR

QDCount ANCount NSCount ARCount

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

QName

QType QClass

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

QName

QType QClass

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Offset 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Offset 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

A.2 DNS-ALG 之實作原理

/* Definition of DNS Message */

struct DNSMessage {

DNSHeader * header; /* Header Section */

DNSEntry * qdENT; /* point of question Entry */

DNSRR * anRR; /* point of answer RR */

DNSRR * nsRR; /* point of authority RR */

DNSRR * arRR; /* point of additional RR */

}

Question Entries

ARCount

Question Entries

Answer RRs

ARCount

第五章結論

/ Definition of DNS Message /

DNSHeader header; /* Header Section /

DNSEntry qdENT; /* point of question Entry /

DNSRR anRR; /* point of answer RR /

DNSRR nsRR; /* point of authority RR /

DNSRR arRR; /* point of additional RR /