12 docs tagged with "Floodlight"

這邊簡單紀錄一下一種QoS的使用方法，實驗流程如下

Introduction

本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以瞭解每個開放出來的 Restful API 該怎麼使用。相對於文件的更新速度，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。

這篇文章用來介紹在 Fllodlight 中是如何去完成下列事情, 1)不使用 Spanning Tree Protocol 的方式也能夠正確的在有迴圈的網路拓樸中來傳輸封包，2) 針對任意兩個點對點的網路節點，能夠找到一條最短的路徑用來傳輸封。 這些事情在該控制器中，其實是透過計算一個 Tree 的方式來完成所謂的 Broadcast Tree, 藉此避免廣播風暴的問題，同時透過 Djikstra 的演算法來在拓樸中找到一個最短路徑來傳輸封包。

問題來源:

Floodlight把module分成core跟application兩個方向為主

本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部是如何轉送封包的，藉由 Topology 模組提供的 Global Topology 資訊, Floodlight 可以從該資訊中對於任何一個點到點的之間的連線找到一條傳送路徑。接者針對這傳送路徑上所有的交換機輸入對應的 Openflow 規則來幫忙轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。

本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部關於網路拓樸的處理，這些拓樸除了影響 Controller 怎麼看待整個網路之外，也會間接的影響該 Controoler 要如何去正確的轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。

在Openflow的協定中，有時候會想要知道每條`link`的`capacity`,然後就可以藉由當前的rate來判斷這個Link是否壅塞。 本文嘗試使用 `Floodlight` Controller 作為範例來展示如何使用透過預設的 API 來取得每個 Port 的資訊，並且從中計算出當前這條 Link 是否屬於壅塞或是閒置。 這類型的機制與資訊對於想要完成 Traffic Engineering 的開發者來說非常重要，畢竟這是其中一種可以幫每條連線加上權重的一種方式

Question

Introduction

Introduction