在研究領域中最廣泛採用的BGP資料分析軟體是libBGPdump，它是一個開源的C庫，提供了一個簡單的API來解析MRT格式的RIB dumps，並將MRT記錄反序列化為自定義資料結構。它與命令列工具bgpdump一起工作，bgpdump從ASCII格式檔案中讀取資訊並輸出MRT資訊。通常研究人員直接使用命令列工具將整個RIB dumps轉換成文字，然後解析ASCII輸出以進一步處理或儲存資料。儘管在過去十年中bgpdump已經是非常有用的BGP資料分析工具，但是它缺少我們在下一節中討論的高階特性（例如，合併和排序來自多個檔案和資料來源的資料、支援實時處理、可伸縮性等）
已經存在幾個實時處理BGP測量資料的專案，由工業界（例如，Dyn Research）和學術界（例如，PHAS）開發，但是它們的方法要麼是不公開的，要麼是特定於特定應用的（即，它們不是通用框架）。一個例外是BGPmon，這是一個分散式監控系統，它透過建立具有多個AS的BGP會話來檢索BGP資訊，並以XML格式提供實時BGP資料流（它也封裝原始MRT資料）。儘管BGPmon能夠實現實時監控工具的快速原型化，但是它目前僅提供了對有限數量的探測點（與連線到RIPE RIS和RouteViews基礎設施的大量VP相比）的訪問，並且它不能用於處理歷史資料
BGP資料的實時流化
另一方面，在實時監視的背景下，諸如RouteViews和RIPE RIS等流行的公共資料來源的主要問題是它們是基於檔案的分發系統，因此使得收集到的資料在可用的延遲時間內。我們的測量表明，除了由於檔案迴圈持續時間而導致的5分鐘和15分鐘的延遲之外，由於釋出給基礎設施還有少量的可變延遲。然而，在去年99%的Updates dump可以在不到20分鐘後。由於這些延遲足夠低，可以支援幾個近實時監視應用程式，因此我們開始開發支援這些資料來源的BGPStream
BGPStream核心
BGPStream框架是有多個層次構成（圖1）。在本節中，我們將討論核心層（元資料提供程式和libBGPStream），而在本文的其餘部分中，我們將透過案例研究說明上層。元資料提供者提供關於來自資料提供者（本地或遠端）的資料的可用性和位置的資訊，這些資料提供者是BGPStream專案外部的資料來源。框架的主要庫libBGPStream提供了以下功能：（1）併發處理不同專案的多個收集器收集的RIB和Updates；（2）實時資料處理；（3）資料提取、註釋和錯誤檢查；（4）生成BGP測量資料的時間順序流；（5）使用者可以透過API接收資料流。
BGPStream可分為幾個獨立模組：BGPReader，一個命令列工具，以ASCII格式輸出請求的BGP資料；pybgpstream，Python實現的libbgpstream API；bgpcorsaro是一個工具，採用模組化的外掛架構提取統計或彙總資料，輸出到規則時間倉內。
圖1 BGPStream架構
目標與挑戰
BGPStream的目標
1） 高效處理大量分佈的BGP資料
在第2節中，我們強調了利用大量全球分佈的探測點執行分析的重要性。然而，處理如此大量的資料以及探測帶你的分散式和多樣性（不同的定時、格式等）特性帶來了一系列技術挑戰。
2） 從多個數據源提供基於記錄的時序資料流
BGPStream旨在提供來自多個收集器的統一排序的資料流。記錄級排序（而不是交錯轉儲檔案）在至少兩種情況下是重要的：（1）在分析長時間間隔時，該時間間隔內不能緩衝整個輸入實現時間對齊；（2）當輸入的資料來源提供連續的資料流（而不是離散的轉儲檔案），因為這樣的流不能在轉儲檔案級別上進行交叉提取。
3） 提供歷史和近實時資料處理
我們考慮兩種操作模式：（1）歷史模式 - 在程式啟動之前請求的所有BGP資料都是可用的；（2）實時模式 - 在程式執行時請求的BGP資料變得可用。在實時模式下，BGPStream堆疊加上使用者應用程式，處理資料必須比收集器生成數更快。我們最小化BGPStream處理的延遲，從而最大化近實時的使用者應用程式的可用時間來執行實時網際網路監視和測量。
實時模式還介紹了多個收集器排序記錄的問題。這個問題涉及到：（1）緩衝區的大小，（2）應用程式可用資料的完整性，（3）延遲。根據使用者應用程式的特定目標和資源來評估這種權衡，因此我們設計BGPStream可以在實時模式下執行盡力而為的記錄交叉提取，並且根據應用程式的特定目標來選擇特定的解決方案。
4） 支援大量應用和使用者
BGPStream在網路監測與故障診斷以及科學資料分析等領域具有廣闊的應用前景。目標使用者不應侷限於高效能計算和叢集基礎設施的可用性上。BGPStream框架提供了一套適合不同應用程式和開發正規化（例如，歷史資料分析、快速原型、指令碼編寫、實時監控）的工具和API。
5） 可伸縮性
由於BGP的探測點的關鍵目的是監視和理解網際網路基礎設施，因此收集器專案支援的探測點的數量會不斷增加。同時，技術挑戰（例如，對複雜的中間人攻擊的近實時檢測）需要滿足日益複雜的計算需求的解決方案。我們設計了BGPStream來支援在分散式和“大資料分析”環境中的部署：例如，Spark本身支援Python，使得BGPStream可以在這種開箱即用的環境中使用。
6） 方便擴充套件
儘管我們的解決方案被設計成與當前標準和最流行的可用資料來源一起工作，但我們設計了一個堆疊和模組化的框架，便於對新技術和資料來源的支援。BGPStream是一個正在演進的專案，需要與資料提供者、互補技術的開發人員和使用者的協調一起以推進BGP監測和測量資料分析的最新進展。
BGPStram元資料提供商
分析BGP測量資料面臨的挑戰之一是識別和獲取相關資料RouteViews和RIPE RIS都可以透過HTTP提供資料，並將基本目錄列表樣式索引新增到資料中。識別用於大規模分析的適當檔案（跨多個收集器和長時間段）包括手動瀏覽和下載，或者編寫適合每個專案儲存庫結構的爬蟲指令碼。下載資料本身可能需要相當長的時間（例如，在2014中收集的所有資料是2TB）。此外，由於兩個專案在收集新資料時不斷向其歸檔中新增新資料，因此近實時監視需要定製指令碼來定期從網站並下載新資料。BGPStream透過元資料提供程式隱藏了這些複雜性：以元件的形式提供對本地或遠端資料儲存庫（資料提供程式，例如，RouteViews和RIPE RIS資料庫）生成檔案資訊的訪問。
我們實現了這樣一個元資料提供者，稱為BGPStream Broker的Web服務。其功能（1）向libBGPStream提供元資料，（2）負載平衡，（3）用於過載保護的響應視窗，（4）支援實時資料處理。這個Broker連續地提取資料從提供者儲存庫，將關於新檔案的元資料儲存到SQL資料庫中，並回答HTTP查詢以識別匹配一組引數的檔案的位置。Broker的一個例項託管在聖地亞哥大學聖地亞哥分校的聖地亞哥超級計算機中心，預設情況下由libBGPStream進行安裝，允許在任何網際網路連線的機器上“開箱即用”地使用BGPStream。
Broker只儲存官方儲存庫上可用檔案的元資料，而不是檔案本身。這種方法最小化了瓶頸的可能性，因為對Broker的查詢和來自Broker的響應都是輕量級的，實際資料由外部資料提供程式提供。這種配置還使得新增額外資料提供者、負載平衡和冗餘變得簡單，因為Broker可以在多個映象伺服器之間透明地迴圈或者採用更復雜的策略（例如，從聖地亞哥大學聖地亞哥分校機器傳送的請求是通常指向校園映象）。
雖然Broker Data Interface是主要的資料訪問介面，但我們還提供了三個用於分析本地檔案的其他介面：單檔案、CSV檔案和SQLite。以下部分假設Broker被用作資料介面。
