本計畫所選擇的開放架構 EPON 系統常見的組態如圖十所示。主要組成元件包括 了三種不同的卡板：(1)EPON Blade：是符合 IEEE 802.3ah 的 EPON OLT 卡板，每個 EPON OLT port 可以連接到 16 個用戶端 ONU；(2)Management Blade：提供給系統管 理員來管理 EPON OLT blade 與 Switch Blade；(3) Switch Blade：提供整個系統的 data path switching center，並且提供上行的連接介面。
圖十、ATCA-based EPON 局端系統與服務網路的建置
在整個 EPON 局端系統中，management blade 及 switch blade 必須提供備援保護。
若只有單一的 Management Blade 且發生故障，整個系統就無法管理；若只有單一的 Switch Blade 且發生故障，整個系統就無法送收資料；這都是局端設備所不允許的。利 用 ATCA 架構提供的備援硬體機制，再搭配 Middleware，將可達成備援硬體間的協調 與資料同步。在 Management Blade protection 方面，其作法如圖十一所示。兩張 Management Blade 將透過 ATCA 背板來做 1:1 的保護機制。當一張 Management Blade fail 時，能切換到另一張 management blade 繼續執行。在每張 management blade 上，將 執行 carrier grade Linux 之作業系統，以提供一個 reliable OS 的環境。在此 carrier grade Linux 上，將經由 Middleware 來提供 management protection 的功能。此處我們將以 SNMP agent 作為管理功能方面分析研究與驗證的案例。
圖十一、EPON System Management Blade Protection
另一方面，在 Switch Blade protection 的作法如圖十二所示。與 management blade 作法相似，兩張Ｓwitch Blade 將透過 ATCA 背板來做 1:1 的保護機制。當一張卡 fail 時，能切換到另一張 switch blade 繼續執行。在每張 switch blade 上，將執行 carrier grade Linux 之作業系統，以提供一個 reliable OS 的環境。在此 carrier grade Linux 上，我們 將以 IEEE 802.1d Spanning Tree 作為資料交換功能方面分析研究與驗證的案例。
圖十二、EPON System Switch Blade Protection
為驗證架構設計與效能分析的結果，本計畫將採購符合開放平台標準的 EPON 設 備，來建置一個試運轉與可靠度測試的環境，如圖十三所示。在此試運轉環境中，將 提供 Voice, Video 及 Data 等 triple play services，以測試 EPON OLT 及 ONU 是否能夠很 穩定的提供這些服務。在可靠度方面的測試重點包括了：
z Management Blade Protection /failover：
當一張 management blade fail 時，能順利切換到另一張 management blade 且不 會造成 internal 和 external control data exchange 的中斷。
z Switch Blade Protection/failover
當一張 switch blade fail 時，能順利切換到另一張 switch blade 且不會造成 data plane forwarding 的中斷。
Optical
圖十三、High Availability EPON OLT 系統 Field Trial 環境
第 3 章、Fast recovery mechanisms of routing paths for HA middleware
3.1 研究背景及文獻探討
由於近年來寬頻網路的蓬勃發展，促使網際網路服務商對於基礎網路的建設 更加重視，此外網路的使用也從最基本的資料交換到即時的影音傳送，如視訊會 議( video conference)、網路電話( Voice IP)，網路通訊正朝向多媒體的資訊網路發 展，隨著人們對於網路傳輸的日益依賴，基礎網路上之路由器的可靠度及連續性 服務的需求也越來越迫切。現階段當網路路由器若發生服務中斷，處理方式可能 由網管軟體透過 SNMP (Simple Network Management Protocol)協定偵測，再通知給 網管人員，再由網管人員解決問題，如此，網路服務的中斷時間可能達數十分鐘 甚至數小時，此處理方式對於電信等級之網路服務品質是不夠的。因此，本研究 將根據 SA Forum 所提出之 HA Middleware Generic Functionality 並加入 Enhanced Functionality 相關服務讓基礎網路上之網路路由器能提供更高的網路可靠度。
基礎網路是由一個以上之路由器所組成的，每個資料封包將由路由器轉送至
因此，在圖十四中 Backup Router 如何立即接手封包轉送之工作是能否達到電信等級高
可用度要求之重要部份。本研究擬結合本年度所實現的 Novel K-U bridge schemes for HA middleware 為基本架構，針對 Kernel space 中的 routing table 提出一個共同介面，讓各個不 同的 routing protocol 可以透過此介面來進行 routing table 的管理以及備援，以達到高可靠度 之目的來進行研究討論。並希望其效能能超越其他不同作法的國內外相關研究，簡要敘述 如下：
¾ Graceful Restart, RFC 3623
若網路中的 Router 暫時中斷服務時，Neighbor Router 將不會立即更新 Routing Information 以 及 發 送 新 的 Routing table 給 網 路 上 所 有 的 Router ， 而 是 會 等 待 LSRefreshTime(1800 秒)之後，若原本服務的 Router 依舊無法服務，才會認定其已經中 斷服務，再重新計算路由資訊並且向網路上所有節點發送新的路由資訊。若在 LSRefreshTime 之間，中斷服務的 Router 可以恢復服務，則 Neighbor Router 依舊將其 視為正確的路由節點，因此網路上所有路由節點的 Routing Table 皆可全部保留無需重 新計算。
缺點：
9 網路中所有的 Router 皆必須支援 Graceful Restart 協定。
9 在 Graceful Restart 進行期間，網路拓蹼不能有所改變，否則 Graceful Restart 就算 失敗，網路上所有 Router 必須重新計算路由資訊。
9 當 Neighbor Router 沒有接收到 Router 的 HELLO 訊息才能得知路由節點的服務中 斷，HELLO 訊息的預設發送間隔為 10 秒鐘，因此當路由節點中斷服務時，Neighbor Router 將隔一段時間才能進行 Graceful Restart。
9 因為有 Router 中斷服務，因此網路上有些資料封包無法被轉送至正確的目的地。
¾ VRRP (Virtual Router Redundancy Protocol), RFC 3768
利用多個 Router 構成一個路由器組，由此路由器組來轉送網路上的封包，在任一 時間內，此路由器組中只會有一台 Router 用來服務轉送封包，路由器組會共同擁有一 組虛擬 MAC 以及 IP 位置，因此，在此路由器組所服務的範圍之內的網路節點都會傳 送封包至此虛擬 MAC 及 IP，當目前服務的 Router 中斷服務時，路由器組會決定出一 Router 用來接手先前 Router 的工作。
缺點：
9 本協定為硬體備援，所以需要有特殊的硬體來支援 VRRP。
9 因為在同一時間內，只有一個路由節點服務，因此，不具有負載平衡的功能。
¾ HSRP (Hot Standby Routing Protocol), RFC 2281
同 VRRP，但此規格是 Cisco 公司的專利，若要使用須先取得同意。
¾ Redundant Node
在網路的路由節點上，利用 Redundant Router 作備援。當原本服務的 Router 中斷 服務時，Redundant Router 就會立刻被啟用，用來接手原本路由節點的工作。
缺點：
9 需要多餘的設備作備援
9 Failover 之後，所有的路由資訊必須重新計算。
9 因為路由節點組並沒有交換任何 Routing 資訊，因此無法實行負載平衡。
9 Failover 之後，整個網路 Routing Table 重新計算所花之成本過高。