Caio "Almom" Machado (discussão | contribs)
Sem resumo de edição
Caio "Almom" Machado (discussão | contribs)
Linha 4: Linha 4:
*Os Slices são definidos por uma combinação de portas switch (camada 1), endereço ethernet de source e destino (camada 2), endereço IP de source e destino(camada 3), e porta TCP/UDP de source e destino ou código ICMP (camada 4).
*Os Slices são definidos por uma combinação de portas switch (camada 1), endereço ethernet de source e destino (camada 2), endereço IP de source e destino(camada 3), e porta TCP/UDP de source e destino ou código ICMP (camada 4).
*O FlowVisor impoe um isolamento entre as slices, de modo que uma slice nao afeta no tráfego da outra.
*O FlowVisor impoe um isolamento entre as slices, de modo que uma slice nao afeta no tráfego da outra.
Apesar do OpenFlow ter a capacidade de flexibilizar o controle da rede, apenas um pesquisador pode altera-lo por vez, fazendo-se então necessário um mecanismos para de dividir, separar os recursos de rede de forma que possam usa-los de acordo com suas regras em paralelo, de forma que ações em um grupo não afetam outro, mesmo que estejam sobre o mesmo hardware.<br>
Os aparelhos da rede geram mensagens de protocolo OpenFlow que serão enviadas para o FlowVisor que então roteadas pelos seus devidos slices serão enviadas para seus respectivos pesquisadores. Todas as mensagens enviadas pelos controladores OpenFlow são retidas pelo FlowVisor para garantir assim o isolamento entre os slices antes das mensagens serão enviadas aos switchs.
O FlowVisor atua como um controlador virtual para os switches e como uma rede virtual de switchs para os controladores do pesquisador.<br>
O FlowVisor possui uma arquitetura neutra, visto que não faz nenhuma suposição a respeito da função ou operação, sejam dos switches ou controladores. Ele foi feito como um proxy transparente por três motivos.
*Centralized policy enforcement - Todo controle de trafego, seja do switch ao controlador ou inversamente passa obrigatoriamente pelo FlowVisor, dando a ele uma visão geral do estado da rede e possibilita a ele ignorar ou reescrever as mensagens de controle OpenFlow. Centralizando as politicas de decisão torna mais fácil explicar a razão de um conjunto de ações possíveis e erros de debug que possam ocorrer.<br>
*Delegação Recursiva - Delegação recursiva é a habilidade de re-delegar o controle de um subconjunto de um slice de rede. Por se tratar de um proxy transparente é possível ter um efeito cascata de instancias FlowVisors tornando a delegação recursiva trivial. A Delegação Recursiva é uma importante propriedade em redes virtuais por facilitar a administração overhead de rede e melhorar a alocação de recurso.<br>
*Decouple controle e tecnologias de virtualização - Ao invés de virtualizar via protocolo OpenFLow, o controle e virtualização foram intencionalmente mantidos com aspecto ortogonal. Possibilitando cada tecnologia envolver independentemente, evitando novas formas de ossificação.<br>
As slices do FlowVisor podem ser definidas por negação, união ou até interseção. Acredita-se que estas características podem fazer do FlowVisor uma importante ferramenta para os pesquisadores de rede. O FlowVisor é flexível, suportante redes sem fio e redes wired.<br>
Há um controlador que executa o tradicional algoritmo de aprendizagem  de endereço MAC de switches. Este Slice é definido por padrão,  onde qualquer fluxo que não pertence a qualquer outro slice é enviado a ele. Ele foi incluído para demonstrar como o trafego para pesquisa e o trafego normal da rede podem coexistir.<br>
No experimento foi utilizada uma VM rodando um jogo sensível a latência é migrado entre servers mas matendo o mesmo endereço IP. O servidor e o software do jogo se mantem intacto; um controlador OpenFlow atua dinamicamente no trafego, de forma que a conectividade é mantida. Esta slice é definida como todo trafego de jogo em uma porta UDP especifica.<br>
O Hard Handover mobility agent é um controlador OpenFlow que controla uum conjunto de laptops executando em Stanford, provando que com o OpenFlow é possível é possível re-rotear dinamicamente e troca de uma ponto de acesso 802.11 e uma estação WiMax. Esta slice é definida como os pacotes destinados aos laptops móveis em Stanford pelo seu esdereço MAC. Para conferir o efeito de handover foram utilizados streams de vídeos nos laptops.<br>
O Bicast mobility agente se configura semelhanto ao Hard Handover, sendo responsável pelo controle de trafego de outro conjunto de laptops. Neste caso foi demonstrado o efeito de bi-casting, como por exemplo, duplicando pacotes através de dois diferentes links. Para visualizar o efeito de bicasting.<br>




Linha 10: Linha 25:
**git clone git://gitosis.stanford.edu/flowvisor.git
**git clone git://gitosis.stanford.edu/flowvisor.git


= Fonte =


*http://www.openflow.org/wk/index.php/FlowVisor
*Carving Research Slices Out of Your Production Networks With Openflow; Rob Sherwood, Michael Chan,Glen Gibb, Nikhil Handigol,Te-Yuan Huang,Peyman Kazemian,Masayoshi Kobayashi, David Underhill, Kok-Kiong Yap, Guido Appenzeller, and Nick McKeown; Newsletter, ACM SIGCOMM Computer Communication Review ,Volume 40 Issue 1, January 2010, Pages 129-130.


= Fontes =
= Fontes =


*http://www.openflow.org/wk/index.php/FlowVisor
*http://www.openflow.org/wk/index.php/FlowVisor

Edição das 16h13min de 16 de agosto de 2012

Conteúdo

  • FlowVisor é um controlador OpenFlow com o propósito específico de atuar como um proxy transparente entre os switches OpenFlow e outros controladores OpenFlow. Desta forma ele é capaz de criar slices dos recursos da rede, e delega estes slices para diferentes controladores OpenFlow.
  • Os Slices são definidos por uma combinação de portas switch (camada 1), endereço ethernet de source e destino (camada 2), endereço IP de source e destino(camada 3), e porta TCP/UDP de source e destino ou código ICMP (camada 4).
  • O FlowVisor impoe um isolamento entre as slices, de modo que uma slice nao afeta no tráfego da outra.

Apesar do OpenFlow ter a capacidade de flexibilizar o controle da rede, apenas um pesquisador pode altera-lo por vez, fazendo-se então necessário um mecanismos para de dividir, separar os recursos de rede de forma que possam usa-los de acordo com suas regras em paralelo, de forma que ações em um grupo não afetam outro, mesmo que estejam sobre o mesmo hardware.
Os aparelhos da rede geram mensagens de protocolo OpenFlow que serão enviadas para o FlowVisor que então roteadas pelos seus devidos slices serão enviadas para seus respectivos pesquisadores. Todas as mensagens enviadas pelos controladores OpenFlow são retidas pelo FlowVisor para garantir assim o isolamento entre os slices antes das mensagens serão enviadas aos switchs. O FlowVisor atua como um controlador virtual para os switches e como uma rede virtual de switchs para os controladores do pesquisador.

O FlowVisor possui uma arquitetura neutra, visto que não faz nenhuma suposição a respeito da função ou operação, sejam dos switches ou controladores. Ele foi feito como um proxy transparente por três motivos.

  • Centralized policy enforcement - Todo controle de trafego, seja do switch ao controlador ou inversamente passa obrigatoriamente pelo FlowVisor, dando a ele uma visão geral do estado da rede e possibilita a ele ignorar ou reescrever as mensagens de controle OpenFlow. Centralizando as politicas de decisão torna mais fácil explicar a razão de um conjunto de ações possíveis e erros de debug que possam ocorrer.
  • Delegação Recursiva - Delegação recursiva é a habilidade de re-delegar o controle de um subconjunto de um slice de rede. Por se tratar de um proxy transparente é possível ter um efeito cascata de instancias FlowVisors tornando a delegação recursiva trivial. A Delegação Recursiva é uma importante propriedade em redes virtuais por facilitar a administração overhead de rede e melhorar a alocação de recurso.
  • Decouple controle e tecnologias de virtualização - Ao invés de virtualizar via protocolo OpenFLow, o controle e virtualização foram intencionalmente mantidos com aspecto ortogonal. Possibilitando cada tecnologia envolver independentemente, evitando novas formas de ossificação.

As slices do FlowVisor podem ser definidas por negação, união ou até interseção. Acredita-se que estas características podem fazer do FlowVisor uma importante ferramenta para os pesquisadores de rede. O FlowVisor é flexível, suportante redes sem fio e redes wired.
Há um controlador que executa o tradicional algoritmo de aprendizagem de endereço MAC de switches. Este Slice é definido por padrão, onde qualquer fluxo que não pertence a qualquer outro slice é enviado a ele. Ele foi incluído para demonstrar como o trafego para pesquisa e o trafego normal da rede podem coexistir.
No experimento foi utilizada uma VM rodando um jogo sensível a latência é migrado entre servers mas matendo o mesmo endereço IP. O servidor e o software do jogo se mantem intacto; um controlador OpenFlow atua dinamicamente no trafego, de forma que a conectividade é mantida. Esta slice é definida como todo trafego de jogo em uma porta UDP especifica.
O Hard Handover mobility agent é um controlador OpenFlow que controla uum conjunto de laptops executando em Stanford, provando que com o OpenFlow é possível é possível re-rotear dinamicamente e troca de uma ponto de acesso 802.11 e uma estação WiMax. Esta slice é definida como os pacotes destinados aos laptops móveis em Stanford pelo seu esdereço MAC. Para conferir o efeito de handover foram utilizados streams de vídeos nos laptops.
O Bicast mobility agente se configura semelhanto ao Hard Handover, sendo responsável pelo controle de trafego de outro conjunto de laptops. Neste caso foi demonstrado o efeito de bi-casting, como por exemplo, duplicando pacotes através de dois diferentes links. Para visualizar o efeito de bicasting.



Fonte

  • http://www.openflow.org/wk/index.php/FlowVisor
  • Carving Research Slices Out of Your Production Networks With Openflow; Rob Sherwood, Michael Chan,Glen Gibb, Nikhil Handigol,Te-Yuan Huang,Peyman Kazemian,Masayoshi Kobayashi, David Underhill, Kok-Kiong Yap, Guido Appenzeller, and Nick McKeown; Newsletter, ACM SIGCOMM Computer Communication Review ,Volume 40 Issue 1, January 2010, Pages 129-130.

Fontes