子计画四拟由张瑞雄教授与陈俊良教授共同主持建立IPv6环境.docx

子计画四拟由张瑞雄教授与陈俊良教授共同主持建立IPv6环境.docx

《子计画四拟由张瑞雄教授与陈俊良教授共同主持建立IPv6环境.docx》由会员分享，可在线阅读，更多相关《子计画四拟由张瑞雄教授与陈俊良教授共同主持建立IPv6环境.docx（12页珍藏版）》请在冰豆网上搜索。

子计画四拟由张瑞雄教授与陈俊良教授共同主持建立IPv6环境

子計畫四擬由張瑞雄教授與陳俊良教授共同主持。

建立IPv6環境下的，以802.11x無線網路為架構的行動通訊協定機制。

並在無線通訊端製作RSVP架構。

就目前IPv6的國際標準，雖然其尚未將Mobility支援的功能加以明確定義與規範，但是藉由IPv6所新增的功能與運作機制（如StatelessAddressAutoconfiguration和NeighborDiscovery等等），我們可以發現IPv6對於無線通訊行動能力的支援具有相當完整的考量。

其中最重要的一點就是利用IPv6標準所規範的stateless自動取得IPv6位址這項功能，能夠讓行動機於漫遊時，順利取得一組新的IPv6位址。

實作方法分為以下兩種：

Intra-domainHandoff及Inter-domainHandoff。

◆Intra-domainHandoff

如圖廿五所示，圖中之Router系以FreeBSD架設之Unix主機，並架設為IPv6Router，提供基本之IGPRouting及StaticRoute的功能，分別管轄不同的多個LAN；AccessPoint1（簡稱AP1）及AccessPoint2（簡稱AP2）為提供802.1x認證功能的AccessPoint，兩部AP隸屬於同一個子網路，或隸屬於同一個VLAN，由同一部Router所管轄；RadiusServer供AccessPoint進行使用者認證使用；MobileHost（簡稱MH）為一部以WindowsXP為作業平台的Notebook，並配備802.11b之無線網路卡。

圖廿五、Intra-domainMobileIPv6Architecture

當MH於AP1的訊號涵蓋範圍出現時，首先會透過802.1x通訊協定，向Radius進行使用者認證的工作，認證通過後，MH會由網路上取得一個IPv6Prefix，再加上網路卡上的MACAddress，經過EUI-64運算，便可得到一個Link-LocalIPv6Address；當MH由AP1的訊號涵蓋範圍移動至AP2的訊號涵蓋範圍時，MH必須先以802.1x透過AP2向RadiusServer進行認證，認證通過後MH不需要重新取得一個Link-LocalIPv6Address即可繼續通訊。

◆Inter-domainHandoff

如圖廿六所示，當MH於AP1的訊號涵蓋範圍出現時，首先會透過802.1x通訊協定，向Radius進行使用者認證的工作，認證通過後，MH會由網路上取得一個IPv6Prefix，再加上網路卡上的MACAddress，經過EUI-64運算，便可得到一個Link-LocalIPv6Address；當MH由AP1的訊號涵蓋範圍移動至AP2的訊號涵蓋範圍時，MH必須先以802.1x透過AP2向RadiusServer進行認證，然後再透過上述同樣之方法取得一組新的Link-LocalIPv6Address，並繼續進行通訊，此時，第一組Link-LocalIPv6Address的LifeTime（使用週期）將會遞減為0，隨即失效。

圖廿六、Intra-domainMobileIPv6Architecture

RSVP是一種能讓主機利用網路來互相溝通，而能取得網路資源並保留的協定，它藉由互傳訊息（Signaling）的機制來保留資源，其傳遞訊息的方式如圖廿七，步驟如下所述：

1.傳送端先送出一個Path的訊息給接收端，以告知接收端要傳送資料。

2.凡在傳送路徑中所經過的router會很快的將此Path訊息傳給下一個路由協定所選出的端點，且直到接收端收到此Path訊息，路徑上接收到該Path訊息的節點會建立一Path狀態。

3.接收端會再回應一個RESV訊息去向此傳送路徑中的每一個節點要求資源。

4.每個在此路徑中被要求保留資源的節點可以接受或拒絕此保留要求；如果此保留要求被拒絕了，則此router就會傳送一個錯誤的訊息給接收端，然後此互傳訊息的過程就結束了。

若此router接受了，則此router就會為此資料流保留頻寬或相關資源。

圖廿七、RSVP訊息的流向圖

在由Sender所送出的Path訊息中，會包含有關於Sender會傳送資料的封包格式和所要傳送資料的流量特性的資訊。

而Receiver所送出的RESV訊息中會包含有關資料流的格式及特性和有關保留資源的分享條件的資訊。

到底資源的立即保留和預先保留有什麼差異呢？

就如RSVP來說，它的資源保留模式就是屬於資源立即保留，因為它是在使用者需求資源時，才來針對需求的資源做請求的動作，然後系統才會去檢查是否有足夠的資源可以提供使用，足夠就接受此請求，不足則拒絕。

像這種立即保留的方式，不適合用在像遠距教學那樣確定一定要進行的活動中，因為如果到要使用的那個時點才做資源保留，就可能會有要求被拒絕的風險。

而資源的預先保留則是提出一種可以對資源做預約的方式，也就是在真正的資源使用時間之前就先提出請求，這樣就可以免除去承擔要求被拒絕的情形，且可以確定資源究竟有沒有取得，若是有發生資源衝突時，還可以去尋找其它的替代方案，這樣的方式將會有助於更有彈性及有效率的使用資源。

兩者的差別可以從圖廿八中看出，在（a）資源立即保留圖中，首先先對資源請求保留，然後各個節點若接受就會做保留的動作，當請求被答應了，得到了回應的訊息，接著在間隔很短的時間內就會去做使用資源的動作，其實得到回應訊息和真正開始使用資源的兩個時間差距並不會太大，因此他們在圖上表示的點會很相近。

而在（b）資源預先保留圖中，也是一樣先對資源先做要求的動作，然後各個節點若接受則會做保留動作，請求一旦被答應了，一樣也會得到回應的訊息；但是和（a）圖的差別，在於（b）圖上的真正資源開始使用的時間並不是立即性的，而是過了一段不算短的時間後才開始使用。

間隔一大段時間的優點在於做資源預留時，可能會去對之前發出的請求不斷的做修改動作，例如發現不需要保留太多的頻寬時，而再度送出訊息去修改之前的請求，而這段間隔時間則提供了一個緩衝的空間。

圖廿八、資源的立即保留及資源的預先保留

表二、資源預先保留對應RSVP

RSVP中所使用的協商動作，就是路徑上的中間節點對於此資源請求做接受或拒絕的決定，若接受了，則直接保留資源，若拒絕了則繼續做其它的動作。

而在這邊也可能會發生再協商的情形，所謂的再協商動作就是在第一次的協商後，資源保留成功了，但是在經過一段時間後，可能發現其實並不需要那麼多資源或是要調整對資源的需求時，此時所做的調整動作就是再協商，可能會做的調整有對資源頻寬的增減、資源啟始使用時間的往前或延後和資源持有時間的增長或縮短。

資源配置方式是採用動態分配的方式，也就是將在節點中所有的可用資源分割給資源立即保留及資源預先保留，而其中分割的比例則是自行設定，如圖廿九。

而在兩者之間是一個可移動的邊界，這個可移動的邊界定義了兩者之間可以互借多少百分比的資源，假設目前供給預先保留的資源部份不足以提供給某個請求，而在預設中預先保留區可向立即保留區借一些資源來用，若此節點在跟立即資源區借了資源後，可以滿足此請求，則就會接受此請求。

當然，在這項請求的資源使用結束後，就會歸還資源，而此移動邊界就會再移回原來的位置上。

圖廿九、資源的動態分配

比較優先權的方式其實就是以作業系統中所談到的多層次佇列排程法的觀念來作，也就是説當有兩個請求同時到達一個節點時，且資源目前不足的情況下，會先比較他們的優先權，如果其中一個優先權較高的話，則接受它的請求，拒絕優先權低的那一個請求；若是兩個請求的優先權都相等的話，則可能就會比較對於資源要求的持久時間，若其中一個對於資源要持有較久的話，則拒絕它的請求，因為它對於資源持有太久，可能會造成資源無法達成很有效率的應用，或是兩個請求的資源持有時間又一樣的情況下，就會再比較其它部份；何者先比較後比較，或是否拒絕都可自行設定。

通常會開始比較各個請求的優先權高低，是在前面所提到的資源協商及動態分配過後，資源仍顯不足的情形下而採用。

提供建議是因為在前面的各個可能嘗試的步驟都已試過的情況下，也就是資源一直呈現不足的情形，因此再針對這樣的資源衝突情形做解決，提出建議的策略方式有兩種：

1.所提出建議的保留持有時間為等於或小於使用者請求的保有持有時間。

2.所提出建議的保留開始時間為大於、等於或小於使用者請求的保有開始時間。

會提出這樣策略的原因，在於可能receiver所送出的資源請求只是差距一些就可滿足，因此建議使用者另一個也許可接受的建議，這樣就無須去拒絕這個請求了，而且也可省去使用者再一次的資源請求，這種方式將可以使資源的使用更具有彈性。

圖卅、提供建議的方式

提出建議的方式如圖卅所示，是根據receiver可能要求的資源來做建議，Pb為對於頻寬的要求，Ps為資源的啟始使用時間，Pd為對資源的持有時間，三個圓圈分別三種資源要求的情形，當然也可能會發生同時對兩種資源做要求，在圖中則為兩個圓圈交集的部分，或是對這三種資源都做要求的情形，也就是三個圓圈都交集的部分。

因此依各種可能發生的情況，可以看出會有七種可能的組合情形，然後再根據這七種情形去做建議，去除不佳的建議後，再讓receiver去做建議的選擇。

允許一對一的溝通或是一對多的溝通而會保留sender和receiver之間路徑的保留。

RSVP服務就會呼叫應用程式上的網路流量控制以達成控制封包流量的目的。

讓我們以應用程式的行為來說明網路流量控制的作用。

當我們執行一個具有QoS功能的應用程式時，它便會呼叫一些機制來幫它處理資料流量的問題，例如說，每秒鐘只能送出多少的封包，頻寬只能佔用多少，而這一連串的機制在QoS啟動後就會運作了，而這一連串的機制也就是稱為網路流量控制（TrafficControl），然後網路流量控制也會把封包加以分門別類，經由封包分類器以及封包排程器的處理，來依照QoS所設定好的參數把封包一一地傳送到網路上。

請參考圖七的網路流量控制元件：

圖卅一、網路流量控制元件

ResourceReservationProtocol在QoS機制來說是一個非常重要的通訊協定，而這個協定主要也只是用來在網路上傳遞QoS的訊息，而詳細的規格均記錄在RFC2205之中，而RSVP是使用整合性的服務（Intserv）來傳送QoS的訊息，Intserv提供特別的交通流優先權處理，並且還提供機制對於具有QoS功能的應用程式做傳送服務層級的選擇。

整合性服務也會定義QoS訊息來讓網路上的資源可以保留出來。

RSVP是一個第三層的通訊協定，讀者們還記得第三層嗎？

就是網路層，主要做為封包路由之用，而RSVP是非常適合運用在Internet之中的，也因為在第三層運作的緣故，所以RSVP協定並不會受到網路線路種類的限制，所以您就不用擔心對方電腦是存在於那一種網路環境的問題了。

有一點特別值得提的就是QoS連線是以單一方向進行的，也就是說RSVP從A電腦到B電腦來請求QoS時，此時只是針對A到B做QoS機制運做而已，並沒有B電腦到A電腦的方向，所以RSVP協定必須由兩端欲運作QoS的電腦各自發出。

RSVP主要是配合IP交通流的使用，而不限制IPv4或是IPv6，都可以使用。

但讀者別誤以為它跟IP協定有什麼關係，誠如我們之前的內容所說，RSVP只是一個訊息協定而已，只是負責傳送訊息，並不像IP協定還需有路由的功能，而RSVP只是為資料流設定一個保留的傳輸空間，至於網路的路徑如何走，這要依照路由通訊協定所規劃出來的路徑走。

RSVP協定有下列的功能：

∙能與已執行的路由協定配合並且支援數個網路層的通訊協定，當然包含TCP/IP。

∙支援多點傳送與單點傳送。

∙把頻寬保留的訊息傳送給需要的網路設備，如路由器或是交換器等等，以維護傳送端與接收端之間能保有欲設定好的頻寬值。

∙維護每個節點的頻寬保留資訊。

∙對過不支援RSVP協定的網路設備就無條件地通過它。

  假如某個網路設備並不支援RSVP的話，那代表QoS功能也無法在這個網路設備上實行，因此在這個網路節點來說，並沒有QoS的功能，所有的網路流量都是以平常的方式通過。

RSVP訊息：

 RSVP訊息可以分辦出是那一個應用程式和是那一個使用者在請求實行QoS機制，而傳送端、接收端與所需求的頻寬大小也會呼叫起適合的服務層級。

而基於管理者定義好的QoS許可控制原則和網路資源的可用性，QoS請求若不是被拒絕的話要不就透過電腦或是網路設備來實行許可控制原則。

若QoS機制能實行之後，則QoS就會分類網路封包並且把需要進行QoS的封包分到封包排程器中，再經由視優先權的情況，分別地把各個封包傳送到網路上。

 當然，以上我們所提的這些QoS動作，都是靠RSVP協定來傳送訊息達成彼此設備上的運作一致性，而RSVP訊息包含如下：

∙網路交通流分類資訊，包舍有來源位址與目的位址以及埠數（filterspec）。

∙網路交通流參數，使用Intserv的token-bucket模式來決定網路交通流的傳輸速度（flowspec）。

∙服務等級資料，從intserv定義好的服務層級，會針對QoS的請求來傳送網路交通流的需要。

∙原則資訊，允許系統來驗證請求者所要求的資源。

    下列的表格就是RSVP協定使用的訊息種類。

訊息種類 

功能

PATH 

從傳送端的電腦中傳送資料流資訊給接收端電腦。

RESV 

從接收端電腦中傳送保留項目的請求，其中的內容包括了頻寬大小、服務層級以及來源的IP位址。

PATH- 

這是用來回應PATH訊息所產生的錯誤。

RESV- 

這是用來回應RESV訊息所產生的錯誤。

PATH-TEAR 

沿著運作的路徑移除PATH的狀態。

RESV-TEAR 

沿著運作的路徑移除保留項目。

RESV-CONF 

選項設定。

假如接收端需要一個確認訊息，那麼傳送端就會發出這個訊息給接收端。

圖卅二、QoS運作模型

RSVP協定是一個訊息協定，而且是由接收端電腦所發出請求，特別是在多點傳送的環境中，可以感覺的到為何要由接收端來發出請求了。

RSVP協定同時也是一個輕狀態（soft-state）的通訊協定，輕狀態的意思是說它的資訊需要週期性地來更新否則它就會過期，而一旦過期的話，那麼QoS的機制便不會再運作下去。

1.伺服器會傳送PATH訊息要求優先權頻寬給QoS許可控制服務主機。

2.假如QoS許可控制服務主機存在的話，那麼PATH訊息就會經由QoS許可控制服務主機來傳送。

在圖卅二中，QoS許可控制服務主機接收到要求之後就會轉送給用戶端，而PATH訊息就會經由網路設備來決定其網路路徑，最後由接收端來取得這訊息。

3.PATH的狀態會在每個網路設備或是電腦中記錄下來，每一個PATH狀態都包含有PATH訊息的複本與前一個網路設備的IP位址。

4.當PATH訊息到達接收端時，接收端電腦會就回應RESV訊息，沿著PATH訊息的路徑傳回給傳送端。

而接收端電腦建立起RESV訊息代表了它想要從伺服器端那接收資料。

5.RESV訊息會沿著資料路徑傳回給伺服器，而就是利用PATH訊息在每個網路設備中留下的前一個設備的IP位址來達成。

6.透過RESV訊息，每個網路設備就會決定是否要接受訊息中所要求的頻寬資源，若核可的話，那麼實體的網路頻寬就會被保留下來，若這路徑上的所有設備及電腦都核可的話，那麼從伺服器到用戶端的路徑上就會保留有所要求的頻寬，如此一來QoS的機制便建立成功。

7.最後，在資料傳送的時候，伺服器和用戶端仍會持續地以週期性的方式傳送PATH和RESV訊息，以適當地維持保留項目的狀態。

要在Internet上來實行QoS的話，那麼在Internet上並非所有的網路設備都有支援QoS功能，而這種狀態就如我們之前所提的，並不會有任何的影響，只不過在那些不支援QoS設備的網路區段中是不會有QoS的效果產生。

而RSVP協定有一個特點就是它可以動態地接受新的路徑，所以即使在資料傳輸的過程中，當路徑改變時，它也能繼續實行QoS，只不過會花點時間重新傳送PATH以及接收RESV的訊息而己，所以若您的網路是處於動態路由的情形中時，當路由器自動改變路由表時，您也不用擔方QoS的機制會無法運作的問題了，不過若您的網路上有防火牆或是Proxy時，要注意設定，以免把RSVP協定的訊息都給過濾掉了。

使用IEEE802.1p優先權標記方式來讓RSVP訊息對應到網路層第二層的訊息，使得封包的優先權處理可以在網路層第二層中運作，如可以在Switch中運作，而讀者們若對第二層很熟悉的話，那麼您應該就知道IEEE802都是一些第二層的通訊支術，當然就是DLL（DataLinkLayer）與MAC（MediaAccessControlLayer），而其中802.1p就是定義了運作在第二層的網路設備如何利用802.1p的優先權處理方式來處理網路交通流量。

QoS封包排程器必須安裝在執行802.1p優先權標記的電腦上，若某個網路設備或是電腦沒有802.1p的話，那麼當然不會執行封包排程的動作。

在慢速的網路連線上要實行QoS可能需要一些特別的機制來實施TrafficShaping的動作，就是把較大的封包分割成較小的封包以利於在慢速網路上傳輸。

但是這樣子做的話，一定會造成品質上的缺陷，所以為了防止這一類的問題發生，在連結層上網路交通流控制就會分割較大的封包，然後一次只傳送一個封包，而像影像這一類的應用程式，它們的封包就可以安排在幾個較大封包的間隔之間，以儘

量保持其傳送速度以在低速網路上提昇品質。

我們來看下面的圖便可了解：

ISSLOW就是在低速網路上實行封包排程的一種機制，利用ISSLOW機制以儘量降低封包的延遲性，尤其它特別是設計用來實作在數據機或是ISDNB-Channel的較低速連線上。

我們在前面的內容中曾談論到要在Internet上實行QoS是件很難確定的事情，因為我們不敢保證所經過的路徑之網路設備都有支援QoS，所以當我們從某個網路提供者的網路要進入到其它網路提供者的網路時，為了確保QoS能夠繼續維持運作，所以在網路之間勢必要存在一個溝通的管道來了解QoS的情形是如何的，所以兩個網路之間就必須溝通以交換資訊，而就這稱為SLA（ServiceLevelAgreements）。

MH為sender和receiver

Mobilehost是一個接收者

當MH移動到一個新的區域（cellb）的時候他會通知homeagent他現在的位置。

而homeagent得知MH新的位置時會做二件事：

（1）假如foreignagent和他之間沒有RSVPsession通道存在，他會建立一條通道。

（2）CH會將pathmessage透過通道傳送給MH的新的區域。

Mobilehost是一個傳送者

當MH接受到一個errormessage在註冊的程序時和在RSVPsession應該要送一個teardownmessage給其它的端點。

目前乙太網路上的RMON可能不支援IPv6的通訊協定，造成封包無法辨認，因此必須選擇支援IPv6的RMON，或選擇能於近期軟體升級成支援IPv6的RMON。

路由器：

目前只有少數路由器支援IPv6，在選擇路由器時，除了必須可以支援RSVP與multicast的應用外，支援這些功能的MIB也是必須具備的條件，如IPv6RIP6、OSPF6、IPv4tunnel或IPv6tunnel的端點位址等資訊，都應該能從SNMPquery中獲取網管系統。