Machine Translated by Google

ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 1

Roteamento de segmentos: uma pesquisa abrangente de

Atividades de Pesquisa, Esforços de Padronização e
Resultados da Implementação
Pier Luigi Ventre, Stefano Salsano, Marco Polverini, Antonio Cianfrani,
Ahmed Abdelsalam, Clarence Filsfils, Pablo Camarillo, François Clad

Revisão R2 - junho de 2020

Resumo—As operadoras de telecomunicações fixas e móveis,
operadoras de rede corporativa e provedores de nuvem se esforçam
para enfrentar as demandas desafiadoras da evolução das redes IP (por
exemplo, enormes requisitos de largura de banda, integração de bilhões
de dispositivos e milhões de serviços na nuvem). Proposta no início de
2010, a arquitetura Segment Routing (SR) ajuda a enfrentar essas
demandas desafiadoras e está sendo adotada e implantada atualmente.
A arquitetura SR é baseada no conceito de roteamento de origem e
possui propriedades de escalabilidade interessantes, pois reduz
drasticamente a quantidade de informações de estado a serem
configuradas nos nós principais para oferecer suporte a serviços
complexos. A arquitetura SR foi implementada primeiro com o plano de
dados MPLS e depois, muito recentemente, com o plano de dados IPv6
(SRv6). A arquitetura IPv6 SR (SRv6) foi estendida do simples
direcionamento de pacotes entre nós para uma abordagem geral de
programação de rede, tornando-a muito adequada para casos de uso
como encadeamento de funções de serviço e virtualização de funções
de rede. Neste artigo apresentamos um tutorial e uma pesquisa
abrangente sobre a tecnologia SR, analisando os esforços de
padronização, patentes, atividades de pesquisa e resultados de
implementação. Começamos com uma introdução sobre as motivações
do Roteamento de Segmentos e uma visão geral de sua evolução e
padronização. Em seguida, fornecemos um tutorial sobre a tecnologia Segment Routing, com foco na nova solução SRv6.
Discutimos os esforços de padronização e as patentes detalhando os
documentos mais importantes e mencionando outras atividades em
andamento. Em seguida, analisamos minuciosamente as atividades de
pesquisa de acordo com uma taxonomia. Identificamos 8 categorias
principais durante nossa análise da situação atual: Monitoramento,
Engenharia de Tráfego, Recuperação de Falhas, Arquiteturas
Centralmente Controladas, Codificação de Caminho, Programação de
Rede, Avaliação de Desempenho e Diversos. Relatamos o status atual
das implantações de SR em redes de produção e de implementações de
SR (incluindo vários projetos de código aberto). Por fim, relatamos
nossa experiência com este trabalho de pesquisa e identificamos um
conjunto de direções de pesquisa futuras relacionadas ao Roteamento de Segmentos.
Termos de indexação—Roteamento de segmento, MPLS, IPv6, SR-MPLS,
SRv6, Roteamento de Origem, Monitoramento, Engenharia de Tráfego, Falha
Recuperação, Codificação de Caminho, Programação de Rede,
Desempenho, Linux, VPP, Plano de Dados, Plano de Controle, Southbound (SRv6). Com SR-MPLS, nenhuma mudança no plano de encaminhamento
PL Ventre está no Departamento de Engenharia Eletrônica da Universidade
de Roma Tor Vergata - Roma, Itália, E-mail: pier.luigi.ventre@uniroma2.it.
APIs, APIs Northbound, Código Aberto, Rede Definida por Software,
SDN, Encadeamento de Funções de Serviço, SFC, Padrões
I. INTRODUÇÃO
Egment Routing (SR) é baseado na fonte solta
S
Conceito de roteamento. Um nó pode incluir uma lista ordenada de
instruções nos cabeçalhos dos pacotes. Essas instruções orientam o
encaminhamento e o processamento do pacote ao longo de seu caminho
na rede.
As instruções únicas são chamadas de segmentos, uma sequência de
instruções pode ser referida como uma lista de segmentos ou como uma
política SR. Cada segmento pode impor um requisito topológico (por
exemplo, passar por um nó) ou um requisito de serviço (por exemplo,
executar uma operação no pacote). O termo segmento refere-se ao fato de
que um caminho de rede para um destino pode ser dividido em segmentos
adicionando waypoints intermediários. A lista de segmentos pode ser
incluída pela fonte original do pacote ou por um nó intermediário. Quando
a lista de segmentos é inserida por um nó intermediário, ela pode ser
removida por outro nó ao longo do caminho do pacote, suportando o
conceito de tunelamento através de um domínio SR de um nó de entrada
para um nó de saída.
A implementação da Arquitetura de Roteamento de Segmentos requer
um plano de dados que seja capaz de transportar as listas de segmentos
nos cabeçalhos dos pacotes e processá-los adequadamente. As operações
do plano de controle complementam a funcionalidade do plano de dados,
permitindo a alocação de segmentos (ou seja, associando um identificador
de segmento a uma instrução específica em um nó) e a distribuição dos
identificadores de segmento dentro de um domínio SR.
Quanto ao plano de dados, duas instâncias da Arquitetura SR foram
projetadas e implementadas, SR sobre MPLS (SR-MPLS) e SR sobre IPv6
MPLS é necessária [1]. O SRv6 é baseado em um novo tipo de cabeçalho
de roteamento IPv6 chamado SR Header (SRH) [2].
Temporariamente, o SR-MPLS tem sido a primeira instância da

S. Salsano é do Departamento de Engenharia Eletrônica da Universidade Arquitetura SR, enquanto o interesse e os desenvolvimentos recentes
de Roma Tor Vergata e do Consórcio Interuniversitário Nacional de estão se concentrando no SRv6. Em particular, o plano de dados IPv6 para
Telecomunicações (CNIT) - Roma, Itália, E-mail: stefano.salsano@uniroma2.it. SR está sendo estendido para suportar o chamado Modelo de Programação

M. Polverini e A. Cianfrani são do Departamento de Engenharia da
Informação, Eletrônica e Telecomunicações da Universidade de Roma
Sapienza - Roma, Itália, E-mail: {marco.polverini, anto nio.cianfrani}
@uniroma1.it.
A. Abdelsalam, C. Filsfils, P. Camarillo e F. Clad são da Cisco Systems, E-
mail: {ahabdels, cfilsfil, pcamaril, fclad}@cisco.com
de Rede SRv6 [3]. De acordo com esse modelo, as funções de roteamento
de segmento podem ser combinadas para atingir um objetivo de rede de
ponta a ponta (ou ponta a ponta) que pode ser arbitrariamente complexo.
Isso é atraente para a implementação de serviços complexos, como o
encadeamento de funções de serviço. SRv6 pode ser usado como um
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
mecanismo de encapsulamento de sobreposição diretamente exposto e
usado por servidores (semelhante ao encapsulamento VXLAN) e como um
mecanismo de transporte de subjacência em backbones de rede (suportando
serviços de Engenharia de Tráfego e Resiliência). Diante disso, o SRv6
pode simplificar as arquiteturas de rede evitando o uso de diferentes
camadas de protocolo.
Já as operações do SR Control Plane podem ser baseadas em uma
arquitetura distribuída, centralizada ou híbrida. Na abordagem distribuída,
os protocolos de roteamento são usados para sinalizar a alocação de
segmentos, e os nós tomam decisões independentes para vincular pacotes
às listas de segmentos. Na abordagem centralizada, um controlador SR
aloca os segmentos, toma a decisão sobre quais pacotes precisam ser
associados a qual política SR e configura os nós de acordo. Muitas vezes,
é utilizada uma abordagem híbrida que consiste na combinação das
estratégias anteriores (ver por exemplo [4]).
O objetivo deste artigo é fornecer uma pesquisa abrangente sobre a
tecnologia de Segment Routing, incluindo todos os resultados alcançados e
o trabalho em andamento. A seguir (seção IA), começamos com o contexto
histórico por trás do desenvolvimento do Segment Routing. Na seção II,
fornecemos uma introdução aos principais conceitos da arquitetura de
Roteamento de Segmentos. Consideramos os planos de dados SR-MPLS e
SRv6, mas focamos mais profundamente no SRv6, que atualmente está
atraindo muito interesse.
Na seção III, fornecemos uma classificação e uma discussão dos esforços
de padronização juntamente com uma análise das patentes mais relevantes.
Fornecemos uma revisão abrangente das atividades de pesquisa na seção
IV, abrangendo 88 artigos científicos.
Os resultados de implementação mais relevantes e o status das
implementações em andamento são relatados na seção V. Na seção VI,
relatamos as lições aprendidas e nossa experiência. Destacamos futuras
direções de pesquisa e questões em aberto na seção VII.
A. Raízes e evolução do roteamento de segmento
A abordagem Source Routing consiste na inclusão da rota do pacote
como uma lista de saltos no cabeçalho do pacote.
Este tem duas variantes. O Strict Source Routing requer a especificação da
sequência completa de saltos da origem ao destino. Roteamento de origem
solto consiste em especificar uma lista de nós que representam pontos de
passagem a serem cruzados (em sua ordem) antes de chegar ao destino.
Essas duas variantes do Source Routing foram consideradas entre as
possíveis soluções para roteamento e encaminhamento de pacotes desde
as fases iniciais do projeto das tecnologias de comutação de pacotes. Em
particular, eles foram considerados na definição original do protocolo IPv4
no final da década de 1970. A RFC 791 [5], que definiu o IPv4 em 1981,
incluiu as opções Strict Source and Record Route (SSRR) e Loose Source
and Record Route (LSRR) no cabeçalho do pacote IPv4. Essas opções
raramente são usadas em redes IPv4, também por questões de segurança.
Os pacotes que carregam as opções SSRR ou LSRR são normalmente
filtrados (descartados) por roteadores IPv4 na Internet.
O Segment Routing segue a variante solta do Source Routing, usando
a mesma abordagem do IPv4 Loose Source Routing, mas é especificamente
baseado em planos de dados MPLS ou IPv6.
As atividades de pesquisa e padronização de Roteamento de Segmentos
tiveram origem no final dos anos 2000. Seu principal objetivo era
2
superar alguns problemas de escalabilidade e limitações [6], que foram
identificadas nas soluções de tráfego de engenharia de Multi Protocol Label
Switching (MPLS-TE) usadas para backbones IP.
Em particular, observou-se que o MPLS-TE requer que o estado explícito
seja mantido em todos os saltos ao longo de um caminho MPLS; isso pode
levar a problemas de escalabilidade no plano de controle e no plano de
dados. Além disso, o modelo de direcionamento de tráfego por conexão do
MPLS-TE não explora facilmente o balanceamento de carga oferecido pelo
roteamento Equal Cost MultiPath (ECMP). Por outro lado, o Segment
Routing pode orientar os fluxos de tráfego ao longo de caminhos projetados
de tráfego sem estado por fluxo nos nós ao longo do caminho e explorar o
roteamento ECMP em cada segmento.
No início de 2010, o IETF iniciou o Grupo de Trabalho “Roteamento de
Pacotes de Origem em Rede” (SPRING WG) para lidar com roteamento de
segmentos. A atividade do SPRING WG incluiu a identificação de Casos de
Uso e Requisitos para Roteamento de Segmentos (por exemplo, [7], [8] e
[9] tornaram-se IETF RFCs). Em julho de 2018, o SPRING WG emitiu o
documento “Segment Routing Architecture” (RFC 8402 [10]) juntamente
com outra RFC informativa sobre monitoramento de casos de uso [11]. Mais
recentemente (dezembro de 2019) outras 3 RFCs foram emitidas, enquanto
muitos outros documentos ainda estão em discussão pelo GT, conforme
será analisado posteriormente neste trabalho.
Olhando para a bibliografia científica, o artigo seminal sobre a Arquitetura
de Roteamento de Segmentos é [12]. Publicado em 2014, fornece uma
visão geral das motivações para SR, descreve um conjunto de casos de uso
importantes e ilustra a arquitetura.
Os conceitos básicos propostos em [12] foram elaborados e refinados na
RFC 8402 [10].
Atualmente, o Segment Routing está recebendo muito interesse das
operadoras por suas aplicações em diferentes tipos de redes (backbones
de transporte, redes de acesso, datacenters e redes 5G).
O plano de dados baseado em MPLS (SR-MPLS) baseia-se na tecnologia
MPLS bem estabelecida. O SR-MPLS pode ser visto como uma melhoria e
uma simplificação do plano de controle MPLS tradicional, por isso é benéfico
para os operadores com uma infraestrutura MPLS já implantada. O plano
de dados baseado em IPv6 (SRv6) está ganhando força, pois oferece a
possibilidade de combinar serviços e recursos de rede overlay e underlay
usando apenas a tecnologia IPv6. O modelo de programação de rede SRv6
oferece flexibilidade sem precedentes no projeto e operação de serviços de
rede, portanto, o SRv6 é uma opção atraente para operadoras que estão
implantando novas redes ou planejando a evolução de suas arquiteturas de
rede.
Concluímos esta breve revisão histórica observando que um número
muito grande de patentes (cerca de 900) foram registradas relacionadas ao
Segment Routing, como é possível verificar com uma rápida pesquisa on-
line. Fornecemos uma visão geral e análise sobre as patentes mais
relevantes na seção III, elas demonstram ainda o alto interesse de
fornecedores e prestadores de serviços na tecnologia SR.
II. A ARQUITETURA DO SEGMENTO DE ROTEAMENTO (SR)
Esta seção inclui um breve tutorial sobre os principais aspectos da
arquitetura SR. Nosso objetivo é fornecer um terreno comum e uma
referência de estrutura conceitual para a pesquisa. RFC
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
8402 [10] representa a fonte de informação mais importante para a arquitetura
SR. O trabalho em [13] (publicado em 2017) fornece uma introdução curta e
eficaz à arquitetura de roteamento de segmentos, com foco no plano de dados
MPLS. O trabalho de pesquisa [14] tem uma seção sobre arquitetura SR, que
tenta fornecer mais detalhes relacionados aos aspectos do plano de dados (para
SR-MPLS) e do plano de controle.
Seguindo a RFC 8402, vamos começar discutindo os conceitos gerais de
SR, que são independentes do plano de dados específico (MPLS ou IPv6). Um
exemplo simples de um caminho SR composto por três segmentos (S1,S2,S3)
é mostrado na Fig. 1. Podemos nos referir à lista de segmentos como uma
política SR: a política de roteamento de segmento P=<S1,S2,S3 > consiste em
direcionar os pacotes pelo nó S1, depois pelo nó S2 e depois até o destino S3.
A lista ordenada de segmentos (lista de segmentos) é inserida nos cabeçalhos
dos pacotes pelo nó de origem da Política SR. O domínio de roteamento de
segmento (domínio SR) é o conjunto de nós que participam do modelo de
roteamento baseado em origem.
Um segmento é descrito por um identificador de segmento (ID de segmento
ou SID). Para o plano de dados MPLS, um SID é um rótulo MPLS, enquanto
para o plano de dados IPv6 um SID é um endereço IPv6.
Conforme mostrado na Fig. 2, a lista de segmentos é adicionada aos cabeçalhos
dos pacotes por um nó headend que direciona os pacotes de um fluxo para a
política SR. O nó headend pode ser o originador do pacote (por exemplo, um
host) ou um nó intermediário que realiza uma classificação do tráfego e associa
as políticas SR aos pacotes (como na Fig. 2). Em outras palavras, os hosts
podem fazer parte de um domínio SR, mas isso não é obrigatório e depende do
cenário geral em que o SR é aplicado. Espera-se que todos os nós em um
domínio SR sejam gerenciados pela mesma entidade administrativa. Por
exemplo, um backbone de provedor de serviços pode constituir um domínio SR
e o nó de headend será o roteador de borda de entrada do backbone (neste
caso, os hosts não fazem parte do domínio SR).
Três operações básicas em SIDs e listas de segmentos foram definidas para
um plano de dados SR genérico: PUSH, NEXT e CONTINUE. Nos exemplos da
Fig. 1 e Fig. 2, assumimos por simplicidade que S1 e S2 representam instruções
topológicas e S3 é o nó de destino da política SR P, de modo que a política P
instrui o pacote a cruzar dois nós identificados pelo SIDs S1 e S2 (nesta ordem)
e depois chegar ao nó identificado pelo SID S3.
A operação PUSH consiste na inserção de um segmento no topo da lista de
segmentos, ou seja, como o novo primeiro segmento da política SR. Para
construir a política SR P descrita acima, o nó headend executa as operações
PUSH nesta ordem: PUSH(S3), PUSH(S2), PUSH(S1). Em um pacote SR, o
segmento que especifica a instrução a ser executada é chamado de segmento
ativo. No exemplo considerado com a política SR P, o nó headend enviará o
pacote com o segmento S1 ativo.
A operação NEXT é executada por um nó que processou o segmento ativo
e considera o próximo segmento da política SR a ser executado. Em nosso
exemplo, o nó identificado com SID S1 recebe o pacote e realiza a operação
NEXT. O próximo segmento é S2, que se torna o segmento ativo para que o
pacote seja encaminhado para S2. A operação NEXT também abrange o caso
do último nó de um
3
Política de SR
P=<S1,S2,S3>
domínio SR
Fig. 1: Política e segmentos de RS
Política de SR
PRÓXIMO
P=<S1,S2,S3> PROSSEGUIR
domínio SR
EMPURRE
S1
S3
Headend
Nó
S2
Fig. 2: Operações de roteamento de segmento
Política SR, na qual a operação NEXT geralmente resulta no processamento do
pacote de acordo com o encaminhamento regular de IP.
Por fim, a operação CONTINUE é realizada pelos nós que estão no caminho
entre dois segmentos. Por exemplo, os nós intermediários no caminho entre S1
e S2 executam a operação CONTINUE. O caminho entre S1 e S2 não é prescrito
pela política SR e será escolhido considerando o roteamento IP regular para o
nó S2 no domínio SR. Se houver vários caminhos de custo igual entre os nós
S1 e S2 (como na Fig. 2) e o mecanismo ECMP (Equal Cost MultiPath) for
suportado pelo roteamento IP no domínio SR, ele pode ser convenientemente
explorado pelo Segment Routing.
Os segmentos podem ser classificados em Segmentos Globais e Segmentos
Locais. Segmentos Globais correspondem a instruções que são globalmente
válidas em um domínio SR. Segmentos locais correspondem a instruções que
são válidas dentro de um único nó.
O exemplo típico de um segmento global é uma instrução para encaminhar
pacotes para uma determinada rede IP de destino ou para um nó IP de destino.
Considerando que um protocolo de roteamento IGP (Interior Gateway Protocol)
(por exemplo, OSPF ou ISIS) é usado no domínio SR, essas instruções são
chamadas de segmento de prefixo IGP e segmento de nó IGP (ou simplesmente
segmento de prefixo e segmento de nó). Todos os nós no domínio SR podem
executar as instruções de segmento de prefixo ou segmento de nó considerando
o caminho para a rede de destino ou nó de destino em sua tabela de roteamento.
O exemplo mais importante de segmento local é a instrução para encaminhar
um pacote para um nó identificado como adjacente pelo protocolo de roteamento
IGP. Isso corresponde ao envio do pacote em uma interface de saída específica
e pode ser executado apenas por um nó específico. Esta instrução é chamada
de Segmento de Adjacência IGP. Graças ao uso de segmentos de Adjacência
IGP, é possível provar que qualquer caminho através de um domínio SR pode
ser expresso por uma Política SR (que pode incluir uma combinação de
segmentos globais e locais) [15]. Segmentos locais também podem ser usados
para representar instruções de serviço a serem executadas em um
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
dado nó. O mapeamento de segmentos globais e locais em identificadores
de segmento (SIDs) e a distribuição dos SIDs em um domínio SR são
diferentes para SR-MPLS e SRv6 e serão discutidos nas próximas
subseções.
O segmento IGP-Anycast é um segmento de prefixo IGP que
corresponde a um prefixo anycast, ou seja, um prefixo anunciado por um
conjunto de roteadores que pode ser usado para fins de alta
disponibilidade ou balanceamento de carga.
O Segmento de Ligação é usado para associar uma política SR (ou
seja, uma Lista de Segmentos) a um SID (chamado SID ou BSID de
Ligação) em um determinado nó. Isso significa que o nó que processa o
Binding SID substitui este segmento por uma Lista de Segmentos: um
pacote recebido com o BSID como segmento ativo será direcionado de
acordo com a política SR associada. Desta forma, a classificação do
pacote pode ser executada por um nó X que adiciona o Binding SID no
SR Header. O nó X não precisa conhecer os detalhes da política SR a
ser aplicada (ou seja, a Lista de Segmentos). Graças ao BSID, o pacote
será encaminhado para um nó Y, que é capaz de aplicar a Política SR.
Como exemplo, o nó X pode classificar o tráfego para uma determinada
rede de destino N que requer “baixa latência” e tráfego para a mesma
rede de destino N que requer “baixa perda”.
O nó Y é um nó de entrada de um backbone que fornece conectividade
para a rede N. Duas políticas SR (“baixa latência” e “baixa perda”) são
usadas para encaminhar o tráfego para a rede N através do backbone.
As respectivas listas de segmentos podem mudar ao longo do tempo,
com base nas considerações da Engenharia de Tráfego.
Após essas alterações, o nó Y é reconfigurado para aplicar a política SR
atual aos pacotes identificados pelo SID de ligação. O nó X não precisa
ser reconfigurado, pois os SIDs de ligação permanecem constantes ao
longo do tempo. Esta abordagem melhora a escalabilidade, resiliência e
independência de serviço das soluções baseadas em Segment Routing.
A Tabela I resume o mapeamento dos conceitos de SR nos dois
planos de dados (MPLS e IPv6) e será discutida nas próximas duas
subseções.
É interessante notar como alguns requisitos que levaram à definição
das soluções de SR são atualmente atendidos por provedores “Over the
top” (OTT) para entregar serviços com menor grau de flexibilidade,
utilizando tecnologias de tunelamento como GRE (Generic Routing
Encapsulation ) [16] e VXLAN (Virtual eXtensible LAN) [17]. Essas
tecnologias permitem encapsular o tráfego e encaminhar pacotes para
nós remotos de acordo com uma topologia lógica de sobreposição.
Infelizmente, eles vêm com uma penalidade, por exemplo, um protocolo
como VXLAN precisa de um underlay L3 para transportar tráfego e perde
recursos completos de encaminhamento L3, como encaminhamento
ECMP [18]. Eles não são realmente formas de roteamento de origem e
não permitem que o usuário defina pontos de passagem para os quais o
tráfego pode ser direcionado. Para elaborar ainda mais, em [18] é
relatado um caso de uso interessante onde multi-tenancy em uma malha
de datacenter foi implementado usando SRv6 como overlay/underlay em
vez das tecnologias comumente usadas, como VXLAN, com uma
simplificação drástica da arquitetura.
Em cenários de Service Function Chaining (SFC), o Network Service
Header (NSH) [19] é uma solução que funciona em cima das tecnologias
de encapsulamento. Portanto, o NSH pode ser usado em conjunto com
o Segment Routing, quando o SR é
4
TABELA I
MAPEAMENTO DE CONCEITOS DE SR EM SR-MPLS E SRV6
SR genérico SR-MPLS SRv6
Lista de segmentos (de
Política de SR Pilha de Etiquetas
endereços IPv6) no cabeçalho SR
Endereço IPv6 indicado no
Rótulo superior do segmento ativo
endereço de destino IPv6
EMPURRE Adicionando um IPv6 no segmento
Empurrar etiqueta
Operação Listar no cabeçalho SR
Decrementando o campo Segment Left,
PRÓXIMO
Etiqueta POP copiando o segmento ativo no IPv6 Destination
Operação
Address
PROSSEGUIR Encaminhamento de acordo com IPv6
Troca de rótulo
Operação Endereço de destino
usado apenas como um mecanismo de tunelamento (aprimorado com
recursos de Engenharia de Tráfego). Por outro lado, o NSH pode ser
visto como uma alternativa ao Segment Routing para implementar a
funcionalidade Service Function Chaining. A este respeito, [20] e [21]
elaboram cenários de Service Function Chaining onde o SRv6 permitiria
uma substituição completa da camada NSH, levando a uma simplificação
da infraestrutura e uma redução na carga sobre os dispositivos.
A. Plano de dados MPLS (SR-MPLS)
O plano de dados MPLS (SR-MPLS) é especificado em [1]. Para SR-
MPLS, o Segment Routing não requer nenhuma alteração no plano de
encaminhamento MPLS. Uma política SR é instanciada através da pilha
de rótulos MPLS: os IDs de segmento (SIDs) de uma lista de segmentos
são inseridos como rótulos MPLS. As funções clássicas de warding
disponíveis para redes MPLS permitem implementar as operações de
SR. A operação PUSH corresponde à função Label Push, ou seja, enviar
um rótulo MPLS em um pacote. A operação NEXT corresponde à função
Label Pop, ou seja, remover o rótulo mais alto. A operação CONTINUE
corresponde à função Label Swap, ou seja, associa um rótulo de entrada
com uma interface de saída e um rótulo de saída e encaminha o pacote
na interface de saída.
O encapsulamento de um pacote IP em um pacote SR-MPLS é realizado
na borda de um domínio SR-MPLS, reutilizando o conceito MPLS
Forwarding Equivalent Class (FEC). Uma classe equivalente de
encaminhamento (FEC) pode ser associada a uma política SR.
O mapeamento de segmentos para etiquetas MPLS (SIDs) é um
processo crítico no plano de dados SR-MPLS. Em casos gerais, diferentes
roteadores no domínio SR podem ter diferentes intervalos de rótulos
disponíveis para serem usados para roteamento de segmento.
Portanto, cada roteador pode anunciar seu próprio espaço de rótulo
disponível para ser utilizado para Segmentos Globais denominados
SRGB - Segment Routing Global Block (em geral, esse espaço de rótulo
pode até ser composto por um conjunto de blocos não contíguos). Por
esta razão, no domínio SR, os Segmentos Globais são identificados por
um índice, que deve ser re-mapeado em um rótulo, levando em
consideração o nó que processará o rótulo. Esta metodologia também foi
coberta pela patente [22] e define o seguinte.
Supondo que o SRGB de um nó seja um intervalo de rótulos a partir
de 10.000, para um Segmento Global com índice X, o nó precisa receber
o rótulo 10.000+X. Como exemplo, na Fig. 3 A, consideramos como
implementar a política de SR descrita em
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 5

A) DIFERENTES SRGBs POR NÓ

S1 : índice = 1, SRGB = 1000 B. Plano de dados IPv6 (SRv6)
S2 : índice = 2, SRGB = 2000

Política de SR S3 : índice = 3, SRGB = 3000

PRÓXIMO PROSSEGUIR
N4 : SRGB = 4000, N5 : SRGB = 5000, Para o plano de dados IPv6 (SRv6), um novo tipo de cabeçalho de extensão
P=<S1,S2,S3>
N6: SGRB = 6000, N7: SRGB = 7000
4002 de roteamento IPv6, chamado Segment Routing Header (SRH) foi definido em
1001 S1 2003
N4 N5
1002 IP [2]. O formato do SRH é mostrado na Fig. 4. O SRH contém a Lista de
2003 3003
EMPURRE
IP 2002 IP Segmentos (Política SR) como uma lista ordenada de endereços IPv6: cada
2003
6002
IP
5003 endereço na lista é um SID. Um campo dedicado, conhecido como Segments
2003 IP
IP 3003 S3 Left, é usado para manter o ponteiro para o SID ativo da Lista de Segmentos.
2002
Headend IP
2003 7003
Nó IP IP
S2
N6 N7
domínio SR Para explicar o plano de dados SRv6, consideramos três categorias de nós:
nós SR de origem, nós de trânsito e nós de terminal do segmento SR. Um nó
B) SRGB IDÊNTICO PARA TODOS OS NÓS SRGB = 1000 (o mesmo para todos os nós)
S1 : índice = 1
Source SR corresponde ao nó headend discutido acima. Pode ser um host
Política de SR
PRÓXIMO PROSSEGUIR
S2 : índice= 2 originando um pacote IPv6 ou um roteador de entrada de domínio SR
P=<S1,S2,S3> S3 : índice = 3
1002 encapsulando um pacote recebido. Na Fig. 5 consideramos o último caso, o
EMPURRE 1001 S1 1003
N4 N5
1002 IP
nó Source SR é um roteador de borda que encapsula um pacote (que pode
1003 1003
IP 1002 IP ser IPv6, IPv4 ou mesmo um quadro da camada 3) em um pacote IPv6 externo
1003
1002
IP
1003 e insere o SR Header (SRH) como um cabeçalho de extensão de roteamento
1003 IP

Headend
IP 1003 S3 no cabeçalho IPv6 externo. O pacote encapsulado é indicado como Payload
1003 IP
1002
Nó
1003 IP
na Fig. 5. A Lista de Segmentos no SRH é composta por S1, S2 e S3 que são
S2
N6 IP
N7 armazenados em ordem inversa (o primeiro SID é S3, o último segmento na
domínio SR
política SR). O campo Segment Left é definido como 2, para que o segmento
ativo seja S1, representado em vermelho na figura.
Fig. 3: Plano de dados SR-MPLS: mapeamento de segmentos para rótulos
usando o SRGB

O nó SR de origem define o primeiro SID da política SR (S1) como endereço

Fig. 2 usando o plano de dados SR-MPLS. Assumimos que diferentes nós
estão usando diferentes SRGBs. Os SRGBs dos nós e o índice de segmento
associado aos segmentos S1, S2 e S3 são mostrados no retângulo cinza. O
nó headend precisa considerar antecipadamente qual é o SRGB dos nós que
realizarão a operação NEXT para os segmentos, pois o rótulo para os próximos
segmentos precisa ser elaborado de acordo. Em particular, o rótulo inicial para
o segmento S2 definido pelo nó headend será 1002, ou seja, o SRGB do nó
S1 (1000) mais o índice para o segmento S2 (2). O nó S1 terá que modificar o
rótulo para 4002 se o pacote for encaminhado para o nó N4 (cujo SRGB é
4000) ou para rotular 6002 se o pacote for encaminhado para o nó N6 (cujo
SRGB é 6000). Ambos os nós N4 e N6 irão remapear (trocar) o rótulo para
2002 ao encaminhar os pacotes para S2. O rótulo inicial para o nó S3 definido
pelo nó headend é 2003, ou seja, o SRGB do nó S2 (2000) mais o índice para
o segmento S3 (3). Este rótulo chegará ao nó S2 sem modificações, então
será processado corretamente pelo nó S2 que o remapeará (troca) considerando
o SRGB do próximo salto no caminho em direção ao nó S3.
Esse processo de remapeamento complica as operações e a solução de
problemas. Existem também serviços (por exemplo, envolvendo segmentos
anycast) que não podem ser realizados se diferentes SRGBs forem usados
por diferentes nós. Por esta razão, [10] recomenda fortemente que um intervalo
idêntico de rótulos (SRGB) seja usado em todos os roteadores, de modo que
um Segmento Global seja sempre mapeado para o mesmo SID (rótulo MPLS)
em todos os nós. Na Fig 3 B apresentamos o mapeamento da mesma política
de SR sob o modo de operação sugerido em que um SRGB idêntico é utilizado
em todos os nós. Observamos que os rótulos MPLS não precisam ser
remapeados, de modo que o mesmo rótulo identifica consistentemente o
mesmo segmento global em todo o domínio SR.
de destino IPv6 do pacote. Estas operações correspondem a uma sequência
das operações PUSH descritas acima.
O nó SR Segment Endpoint recebe pacotes cujo endereço de destino IPv6
está configurado localmente como um segmento.
O nó SR Segment Endpoint inspeciona o cabeçalho SR: ele detecta o novo
segmento ativo, ou seja, o próximo segmento na Lista de Segmentos, modifica
o endereço de destino IPv6 do cabeçalho IPv6 externo e encaminha o pacote
com base na tabela de encaminhamento IPv6. Estas operações correspondem
à operação NEXT descrita acima. Na Fig. 5, podemos ver que S1 é o primeiro
nó SR Endpoint, ele decrementa os campos Segment Left para 1, tornando S2
o segmento ativo, e define S2 como endereço de destino IPv6.
Um nó de trânsito encaminha o pacote contendo o cabeçalho SR como um
pacote IPv6 normal, ou seja, com base no (externo)
Endereço de destino IPv6, porque o endereço de destino IPv6 não corresponde
localmente a um segmento. Essas operações correspondem à operação
CONTINUE. Na Fig. 5, os nós N4, N5, N6 e N7 são nós de Trânsito, que
realizam um encaminhamento regular do pacote para o endereço de destino
IPv6.
Observe que em SRv6 os nós de trânsito não precisam estar cientes de SRv6,
pois cada roteador IPv6 pode atuar como um nó de trânsito SRv6.
No exemplo dado, a operação PUSH é realizada encapsulando um pacote
(IPv6, IPv4 ou frame de camada 2) em um pacote IPv6 externo com um
Segment Routing Header. Outra possibilidade é realizar a inserção de um SRH
como um novo cabeçalho entre o cabeçalho IPv6 e o Next Header (ex: Trasport
Layer Header, TCP ou UDP), sem encapsular o pacote em um novo pacote
IPv6. Esta opção só se aplica a pacotes IPv6 e é especialmente indicada caso
o host de origem esteja atuando como nó Source SR (Nó Headend).
Além das operações básicas (PUSH/ NEXT/ CON-
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 6

diferentes funções que residem em um nó podem compartilhar o mesmo

localizador e ter um código FUNCT diferente, de modo que seus SIDs
sejam diferentes. Do ponto de vista de roteamento, a solução é muito
escalável, pois um único prefixo é distribuído para um nó, que implementa
um número potencialmente grande de funções, com impacto limitado nas
tabelas de roteamento dos nós no domínio SR. Os bits ARG podem ser
usados para fornecer informações (argumentos) a uma função. Eles são
opcionais: se A=0, o SID pode ser simplesmente decomposto em dois
campos como LOC:FUNCT e 128=L+F.

Um SID, que se divide em LOC:FUNCT:ARG, é um segmento global se

o prefixo LOC for roteável no domínio SRv6, que é o caso típico. Também
é possível definir segmentos locais no SRv6, ou seja, SIDs não roteáveis
que podem ser executados por um nó e precisam ser precedidos por um
SID global utilizado para encaminhar o pacote ao nó. Em qualquer caso, o
Fig. 4: Cabeçalho de Roteamento do Segmento uso de tais SIDs locais pode ser evitado, pois a parte FUNCT de um SID
global no formato LOC:FUNCT:ARG pode representar a função local
IPv6 H IPv6 DA = S2 IPv6 H IPv6 DA = S3
necessária.
SR H (S3, S2, S1) SL=1 SR H (S3, S2, S1) SL=0
Carga útil Carga útil

IPv6 H IPv6 DA = S1 IPv6 H IPv6 DA = S2 IPv6 H IPv6 DA = S3

SR H SR H (S3, S2, S1) SL=1 SR H (S3, S2, S1) SL=0
(S3, S2, S1) SL=2
C. Modelo de programação de rede SRv6
Carga útil Carga útil Carga útil

Política de SR
O modelo de programação de rede SRv6 é definido em [3].
PRÓXIMO PROSSEGUIR

P=<S1,S2,S3>
S1 N4
EMPURRE
Nó de
origem SR
Nó de N6
trânsito
Nó de ponto de
DA : Endereço de destino SL : Segmentos à esquerda
Fig. 5: Operações do plano de dados SRv6
TINUE), o modelo de Programação de Rede SRv6 [3] descreve um conjunto
de funções que podem ser associadas a segmentos e executadas em um
determinado nó SRv6. Exemplos de tais funções são: diferentes tipos de
encapsulamento de pacotes (por exemplo, IPv6 em IPv6, IPv4 em IPv6,
Ethernet em IPv6), decapsulação correspondente, operação de pesquisa
em uma tabela de roteamento específica (por exemplo, para suportar
VPNs). A lista de funções descritas em [3] (discutido na seção II-C) não
pretende ser exaustiva, pois qualquer função pode ser associada a um
identificador de segmento em um nó. Obviamente, a definição de um
conjunto padronizado de funções de roteamento de segmento facilita a
implantação de domínios SR com equipamentos interoperáveis de vários
fornecedores.
De acordo com [3], podemos revisitar a noção de Segment IDentifier
(SID) levando em consideração que endereços IPv6 são usados como SIDs
em SRv6. Um SID de 128 bits pode ser dividido logicamente em três
campos e interpretado como LOCATOR:FUNCTION:ARGS (em resumo
LOC:FUNCT:ARG) onde LOC inclui os L bits mais significativos, FUNCT os
seguintes bits F e ARG os bits A restantes, onde 128=L+F+A.
O LOC corresponde a um prefixo IPv6 (por exemplo com comprimento
de 48, 56 ou 64 bits) que pode ser distribuído pelos protocolos de
roteamento e fornece a acessibilidade de um nó que hospeda várias
funções. O comprimento L do localizador não é fixo e pode ser escolhido
por cada operador para seu próprio domínio SR (também independentemente ser uma simples instrução de roteamento, mas também qualquer função de
para nós diferentes). Todos
N5
Consiste em combinar funções que podem residir em diferentes nós para
atingir um objetivo de rede que vai além do mero roteamento de pacotes.
S3
As funções descritas em [3] podem suportar serviços e recursos valiosos,
como VPNs de camada 3 e camada 2, engenharia de tráfego e
reencaminhamento rápido. O modelo de programação de rede oferece a
domínio SR
S2 possibilidade de implementar praticamente qualquer serviço combinando
N7
as funções básicas em um programa de rede que está embutido no
extremidade SR
cabeçalho do pacote.
Conforme mostrado na Fig. 4, o SRH pode incluir uma seção opcional
que carrega objetos Type Length Value (TLV). Esses objetos TLV podem
ser definidos para transportar informações que precisam ser elaboradas
por um ou mais segmentos de uma política SR (Lista de Segmentos). Por
exemplo, o chamado HMAC TLV pode ser adicionado e usado para verificar
se um cabeçalho SRH foi criado por um nó autorizado e se a lista de
segmentos não foi modificada em trânsito. Outro uso potencial de objetos
TLV é para trocar informações de Operação e Manutenção (OAM) entre os
nós do domínio SR.
O rascunho [3] define dois conjuntos diferentes de comportamentos
SRv6, conhecidos como SR policy headend e endpoints. Com referência à
Fig. 5, os comportamentos de headend de política SR são executados nos
nós de origem SR, enquanto os comportamentos de endpoint nos nós de
endpoint SR (por exemplo, S1, S2, S3). Os comportamentos de headend
da política SR direcionam os pacotes recebidos para a política SRv6,
correspondendo aos atributos do pacote. Cada política SRv6 tem uma lista
de SIDs a serem anexados aos pacotes correspondentes. Observe que em
uma versão anterior de [3], os comportamentos de headend da política SR
eram chamados de comportamentos de trânsito, o que era enganoso
porque o mesmo atributo (trânsito) era aplicado aos nós de origem SR e
aos nós de trânsito que não cumpriam nenhuma operação. Por outro lado,
um comportamento de endpoint SRv6, também conhecido como
comportamento associado a um SID, representa uma função a ser
executada em pacotes em um local específico da rede. Essa função pode
rede avançada (por exemplo, firewall, NAT).
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
A Tabela II relata uma lista não exaustiva de comportamentos SRv6,
listando os documentos que fornecem sua descrição. O comportamento
H.Encaps encapsula um pacote IPv6, que vem a ser o pacote interno de um
pacote IPv6-in-IPv6. O cabeçalho IPv6 externo carrega o cabeçalho SRH,
que inclui a lista de SIDs. O comportamento do H.Encaps.L2 é o mesmo do
comportamento do H.Encaps, com a diferença de que o H.Encaps.L2
encapsula todo o quadro da camada 2 recebido em vez do pacote IP
(encapsulamento Ethernet sobre IPv6). O comportamento H.Insert insere
um SRH no pacote IPv6 original imediatamente após o cabeçalho IPv6 e
antes do cabeçalho do nível de transporte. O cabeçalho IPv6 original é
modificado; especificamente, o endereço de destino IPv6 é substituído pelo
endereço IPv6 do primeiro segmento na lista de segmentos, enquanto o
endereço de destino IPv6 original é carregado no cabeçalho SRH como o
último SID da lista de SIDs.
O comportamento End representa a função SRv6 mais básica entre os
comportamentos de endpoint. Ele substitui o endereço de destino IPv6 do
pacote pelo próximo SID na lista de SIDs.
Em seguida, ele encaminha o pacote realizando uma pesquisa do endereço
de destino IPv6 atualizado na tabela de roteamento do nó. Vamos nos
referir à pesquisa na tabela de roteamento como pesquisa FIB, onde FIB
significa Forwarding Information Base.
O comportamento End.T é uma variante do comportamento End, em que a
pesquisa FIB é realizada em uma tabela IPv6 específica associada ao SID
e não na tabela de roteamento principal. O comportamento End.X é outra
variante do comportamento End, no qual o pacote é encaminhado
diretamente para uma adjacência da camada 3 especificada vinculada ao
SID, sem realizar uma pesquisa FIB do endereço de destino IPv6.
O comportamento End.DT6 exibe o encapsulamento SRv6 e executa
uma pesquisa FIB do endereço de destino IPv6 do pacote interno exposto
em uma tabela IPv6 específica associada ao SID. É possível associar a
tabela de roteamento IPv6 padrão ao SID, neste caso os pacotes IPv6
internos serão desencapsulados e então encaminhados com base em seu
endereço de destino IPv6 de acordo com o roteamento padrão do nó. O
comportamento End.DX6 remove o encapsulamento SRv6 do pacote e
encaminha o pacote IPv6 resultante para uma adjacência específica da
camada 3 associada ao SID. End.DT4 e End.DX4 são respectivamente a
variante IPv4 de End.DT6 e End.DX6, ou seja, são usados quando o pacote
encapsulado é um pacote IPv4. O comportamento End.DX2 é usado para
pacotes encapsulados na camada 2 (por exemplo, com H.Encaps.L2). Ele
exibe o encapsulamento SRv6 e encaminha o quadro L2 resultante por
meio de uma interface de saída associada ao SID.
D. Plano de controle para SR e relação com SDN
As operações do Plano de Controle são necessárias para complementar
a funcionalidade do plano de dados e fornecer uma solução completa para
Roteamento de Segmentos. O Plano de Controle pode ser baseado em
uma abordagem totalmente distribuída, na qual os roteadores têm a
capacidade de tomar decisões independentes para configurar e aplicar políticaspara
Ele pode contar com um controlador SR centralizado que toma uma decisão
e instrui os roteadores de acordo com os princípios SDN, ou em uma
combinação das duas abordagens (solução híbrida).
Para o plano de dados SR-MPLS, a definição de uma abordagem
totalmente distribuída foi elaborada dentro do IETF,
7
TABELA II (NÃO EXAUSIVA) LISTA DE COMPORTAMENTOS SRV6
Definido em
srv6-network-programming [3] srv6-
network-programming [3] srv6-
Comportamento network-programming [3] srv6-
H.Encaps network-programming [3] srv6-
H.Inserir network-programming [3] srv6-
H.Encaps.L2 network-programming [3]
End End.T programação de rede srv6 [3]
End.X End.DT4 programação de rede srv6 [3]
End.DT6 programação de rede srv6 [3]
End.DX4 programação de rede srv6 [3]
End.DX6 End.DX2 programação de rede srv6 [3]
Fim.AS programação de serviço (SFC) [23]
Fim.AD serviço -programação (SFC) [23]
Fim.AM programação de serviço (SFC) [23]
TMTmap plano móvel [24] plano móvel
End.M.GTP4.E [24] plano móvel [24] plano
End.M.GTP6.D móvel [24]
End.M.GTP6.E
com a definição de extensões para os protocolos de roteamento IGP (OSPF,
ISIS, veja [25] [26] [27]). Essas extensões dos protocolos de roteamento
são usadas por cada roteador para anunciar os diferentes tipos de
segmentos IGP (prefixo, nó, adjacência, anycast) e para distribuir alguns
dados de configuração SR. Todos os outros roteadores no domínio SR
receberão essas informações por meio do protocolo de roteamento IGP.
Esta informação é necessária para mapear os segmentos incluídos em uma
política SR em SIDs representados como rótulos MPLS no plano de dados
SR-MPLS. Conforme discutimos na subseção II-A, no caso geral, cada
roteador pode alocar diferentes faixas de rótulos a serem usados para
Segmentos Globais. A faixa de rótulos usada para os segmentos globais
por um roteador, chamada SRGB - Segment Routing Global Block, está
entre as informações de configuração do SR anunciadas usando o protocolo
de roteamento. Relembramos que é fortemente recomendado utilizar uma
gama idêntica de etiquetas (SRGB) em todos os routers.
Para o plano de dados IPv6, o processo de publicidade dos segmentos
IGP-prefix, IGP-node e IGP-anycast é simplificado graças ao uso de
endereços IPv6 como SIDs. Em particular, não há necessidade de estender
os protocolos de roteamento IGP para distribuir esses tipos de segmentos,
pois eles são distribuídos nativamente pelos protocolos de roteamento.
Também não é necessária a definição de um Bloco Global de Roteamento
de Segmento como no SR-MPLS, e as operações relacionadas a Segmentos
Globais podem contar com endereços IPv6 que são roteáveis globalmente
no domínio SR. Isso significa que o Plano de Controle para SRv6 pode usar
os protocolos de roteamento IGP regulares (OSPF, ISIS) para suportar as
operações básicas, enquanto as extensões ainda são necessárias ([28]
[29]) para distribuir segmentos de Adjacência IGP e outras informações de
configuração do SR.
A definição do plano de controle para o Segment Routing começou a
partir do plano de dados SR-MPLS e, em seguida, o plano de dados SRv6
herdou a maior parte da funcionalidade, que foi adaptada ao novo plano de
dados. Observamos que um objetivo original do projeto do plano de controle
de SR.
Roteamento de Segmentos foi apoiar a abordagem totalmente
distribuída, na qual os roteadores são capazes de tomar decisões
autônomas. Isso permite oferecer a mesma funcionalidade de uma rede
MPLS tradicional, que não necessita de um controlador SDN centralizado
para sua operação. Por outro lado, observamos agora uma tendência a
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
foco em uma abordagem híbrida na qual protocolos de roteamento
distribuídos coexistem com um controlador SR. Essa abordagem híbrida
está alinhada com a visão de Software Defined Networking, que visa
remover a complexidade dos dispositivos e centralizar a função do plano
de controle em controladores SDN.
À luz disso, a arquitetura Segment Routing pode ser implantada
buscando o equilíbrio certo entre controle distribuído e centralizado. O
controle distribuído é utilizado pelos roteadores para trocar informações
de acessibilidade e avaliar os caminhos mais curtos de forma tradicional;
sem necessidade de interagir com o controlador centralizado.
Observamos que esta é a melhor abordagem para fornecer conectividade
em redes de longa distância em que as conexões de controle entre os
nós e os controladores SDN são afetadas por latência e probabilidade
de falha não desprezíveis. O Segment Route ainda pode ser usado para
Fast Reroute pré-configurando políticas de SR que fornecem caminhos
alternativos em caso de falha de link ou nó, e estes são ativados
automaticamente pelo nó quando a falha ocorre.
O pré-cálculo dessas políticas de SR pode ser realizado de forma
distribuída ou pode ser centralizado em um controlador; esses conceitos
também foram explorados em [30], que patenteia um método para a
orquestração de WANs baseadas em SR. Básico
informações de topologia e informações adicionais para Engenharia de
Tráfego precisam ser transmitidas ao controlador, bem como informações
relacionadas ao serviço que são anunciadas por nós usando protocolos
de roteamento distribuídos. O controlador SDN pode receber essas
informações de diferentes maneiras. Por exemplo, ele pode participar do
protocolo de roteamento IGP ou pode interagir com roteadores de
maneira proprietária para extrair seus bancos de dados IGP. Caso
contrário, ele pode receber informações de roteadores usando extensões
para BGP LS (BGP-Link State) [31]. Qualquer que seja o mecanismo
usado para recuperar as informações necessárias dos nós, o controlador
SDN é responsável por tomar decisões sobre as políticas de SR que
implementam recursos ou serviços avançados, como Engenharia de
Tráfego, VPNs ou Encadeamento de Funções de Serviço.
Essa abordagem permite o claro desacoplamento das operações do
plano de dados da lógica de serviço que opera no plano de controle.
Os mecanismos e protocolos para que o controlador SDN imponha
as políticas SR configurando os nós são deixados em aberto na definição
da arquitetura SR. Como mencionado em [10], algumas opções são
Network Configuration Protocol (NET CONF), Path Computation Element
Communication Protocol (PCEP) [32], e BGP. O protocolo OpenFlow
pode ser usado como mecanismo para configurar as políticas SR apenas
para SR-MPLS, enquanto o processamento do cabeçalho SRv6 não é
suportado pela versão padrão mais recente do protocolo. Uma
implementação Open Source de uma API SouthBound para SRv6
baseada em gRPC é relatada em [4]. A principal característica da
solução Segment Routing em comparação com outras soluções SDN é
que apenas os nós de borda precisam ser configurados para aplicar uma
determinada política de SR, enquanto os nós internos não precisam
manter o estado por política de SR. Esse recurso oferece uma melhoria
substancial em termos de escalabilidade.
E. Motivações de roteamento de segmento e casos de
uso Conforme antecipado na seção de introdução, o RFC 5439 [6]
identificou alguns problemas de escalabilidade do MPLS tradicional
8
TABELA III
CLASSIFICAÇÃO DAS ATIVIDADES DE NORMALIZAÇÃO
DOCUMENTOS
Arquitetura [1], [3], [10], [23], [33]–[36] [7]–[9],
Caso de uso e requisitos [24], [37]–[44] [45]–[47] [ 11], [48],
Reencaminhamento rápido (FRR) [49], [49]–[51] [52]–[56]
OAM
Medição de desempenho
SR-MPLS [57]–[61]
Plano de dados
SRv6 [2], [62], [63]
BGP [64]–[66]
Protocolo BGP-LS [67]–[74]
Extensões IS-IS [27], [28], [75]–[79] [25], [26], [29],
Plano de controle
[80] [75], [76], [81] [32],
OSPF
[82] ] [83]
PCEP
LISP
redes com suporte de Engenharia de Tráfego. Esses problemas deram
origem ao interesse em definir uma solução mais escalável, como o
Segment Routing, no final dos anos 2000. Vários casos de uso e
requisitos para Roteamento de Segmento foram coletados em vários
documentos.
Em [7], os principais casos de uso identificados são: tunelamento
MPLS (ou seja, para suporte a serviços VPN), Fast ReRoute (FRR) e
Engenharia de Tráfego (classificado em vários casos de uso mais
específicos). Um conjunto de casos de uso de Resiliência é descrito em [8].
Em [9], os casos de uso do Segment Routing para redes IPv6 são
considerados com um conjunto de ambientes de implantação exemplares
para SRv6: Small Office, Access Network, Data Center, Content Delivery
Networks e Core Networks.
III. ATIVIDADES DE PADRONIZAÇÃO E PATENTES
Nesta seção propomos uma classificação e descrição da atividade de
padronização relacionada ao Segment Routing e a análise das patentes
mais relevantes. Classificamos 14 Request For Comment (RFC) e 50
Rascunhos da Internet. Nossa taxonomia é baseada em 7 categorias e
o resultado da classificação é apresentado na Tabela III.
A seguir, discutimos as categorias da classificação e, na próxima
subseção, relatamos uma visão geral das principais atividades de
padronização. A primeira categoria é Arquitetura, onde são considerados
todos os documentos referentes à descrição da arquitetura geral de uma
rede de Roteamento de Segmentos. A RFC 8402 [10] se enquadra nessa
categoria e descreve as principais características do SR, como a ideia
do paradigma de roteamento de origem, o conceito de SID e a definição
dos dois planos de dados suportados. Na categoria Caso de Uso e
Requisitos são inseridos os documentos que descrevem cenários de
casos de uso para SR, por exemplo, uso de SR em WANs, redes de
data center, mobilidade e fatiamento de rede. Especificamente, nesta
categoria existem três RFCs: i) RFC 7855 [7] introduzindo o Source
Packet Routing in Networking (SPRING), ii) RFC 8355 [8] relacionado à
resiliência de rede usando SR, e iii) RFC 8354 [9] que descreve como
direcionar pacotes IPv6 ou MPLS sobre a arquitetura SPRING.
A terceira categoria é FRR one, ou seja, Fast Reroute realizado
através de SR. A principal atividade de padronização nesta categoria
está relacionada à recuperação rápida após uma falha de link, e
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
é referido como Topology Independent Loop Free Alternate (TI-LFA), descrito
em [45]. Nenhuma RFC foi publicada nesta categoria. Operações, Administração aproveitando os planos de dados MPLS ou IPv6, para orientar os fluxos de
e Manutenção (OAM) é a quarta categoria definida, onde incluímos todas as
atividades de padronização relacionadas às ferramentas utilizadas para
manutenção da rede. Como exemplo, a RFC 8287 [48] foca na implementação
das ferramentas de ping e traceroute no SR-MPLS, enquanto [49] faz o mesmo
para o SRv6. Na categoria Medição de Desempenho consideramos todos os
documentos que descrevem procedimentos de medição relacionados a
parâmetros de desempenho, como atraso e perda de pacotes, em uma rede
SR. Incluímos nesta categoria também as duas especificações RFC 6374 [55]
e RFC 7876 [56] que explicam como medir o atraso e a perda de pacotes em
MPLS. Apesar de esses dois documentos não terem sido produzidos durante
as atividades de padronização da RS, decidimos incluí-los na Tabela III por
serem massivamente utilizados nas minutas de monitoramento do desempenho
da RS.
Finalmente, a categoria Protocol Extensions abrange dois conjuntos diferentes
de documentos relacionados a extensões de protocolos legados: i) extensões
de protocolos de plano de dados e ii) extensões de protocolos de plano de
controle. Quanto ao plano de dados, incluímos o rascunho que descreve o SR-
MPLS [1] e o RFC 8754 que descreve o SRv6 [2]. Quanto ao plano de controle,
consideramos os documentos sobre modificações no protocolo de roteamento
(ex. BGP e OSPF) para distribuição dinâmica dos SIDs na rede SR, ou
protocolo de controle para comunicação entre um controlador central (no caso
de plano de controle) e os dispositivos no plano de dados (por exemplo, PCEP).
Quanto às patentes, reportamos 18 documentos. Nossa análise cobriu
diferentes tipos de documentos, incluindo patentes orientadas por casos de
uso. A Seção III-B detalha os documentos pesquisados. Entre estas, existem 4
patentes que cobrem os princípios fundadores do Segment Routing: [84], [85],
[86] e [87]. Outro grupo de patentes está relacionado às extensões dos
protocolos de roteamento que são necessários para transportar configurações
relacionadas ao SR [31], [88] e [89]. Então, há um grande grupo de documentos
que abrangem mecanismos específicos e casos de uso: [90], [91], [92], [93],
[30], [22], [94] e [95]. Finalmente, durante nossa pesquisa encontramos uma
série de documentos recentes como [96], [97] e [98] que mostram a centralidade um proxy SRv6 estático e um dinâmico para Virtual Network Function (VNF)
do Segment Routing também na implantação de futuras redes.
A. Principais esforços de padronização
Nesta subseção, fornecemos uma visão geral dos esforços de padronização
mais importantes, considerando 9 documentos entre os quase 70 listados na
Tabela III. [10] e [33] definem os principais princípios da arquitetura SR e
discutem os benefícios trazidos pela SR em termos de escalabilidade,
privacidade e segurança. [23], [40] e [24] elaboram mais sobre o suporte de
casos de uso chave como NFV/SFC, SD-WAN e próxima geração de redes
móveis. [3] estende os conceitos básicos de SR e [45] fornece mecanismos de
reencaminhamento rápido (FRR) contra falhas simples. Por fim, [46] e [75]
analisam as melhorias na estabilidade de roteamento e extensões aos
protocolos de roteamento.
[10] descreve a arquitetura do Segment Routing e seu projeto geral. Ele
define o conceito de segmento como uma instrução de rede e apresenta os
tipos básicos de segmentos: prefixo SID, adjacência-SID, peering-SID e
vinculação-SID. Isso também
9
explica como esses segmentos podem ser anexados a pacotes de dados,
tráfego em qualquer caminho da rede sem exigir nenhum estado por fluxo na
malha.
[33] detalha o conceito de uma política de RS. Ele explica como os
Caminhos Candidatos são definidos como listas SID explícitas ou como
caminhos computados dinamicamente com base em alguns critérios de
otimização e como o Caminho Candidato ativo é selecionado. Além disso,
apresenta várias maneiras de direcionar o tráfego para uma política SR,
automaticamente colorindo rotas de serviço BGP, remotamente usando um
Binding-SID ou estaticamente com políticas de rota. Os conceitos descritos
neste rascunho aplicam-se igualmente aos planos de dados MPLS e SRv6.
A arquitetura SR é estendida do simples direcionamento de pacotes entre
nós para uma abordagem geral de programação de rede em [3]. Usando esta
estrutura, é possível codificar instruções arbitrárias e não apenas locais em
uma lista SID. Cada SID está associado a uma função a ser executada em um
local específico da rede. Um conjunto de funções básicas é definido em [3],
mas outras funções podem ser definidas pelos operadores de rede para
atender às suas necessidades particulares. Além disso, os argumentos SID
permitem que as funções recebam contexto adicional ou que seu comportamento
seja ajustado por fluxo. [23] define os SIDs de serviço e descreve como
implementar a programação de serviço (ie Service Function Chaining) em redes
habilitadas para SR-MPLS e SRv6. O princípio fundamental é associar um
SID a cada função de rede (física ou virtual). Esses SIDs de serviço podem ser
combinados em uma lista SID e programados com precisão, aproveitando o
conceito de programação de rede. Eles também podem ser combinados com
outros tipos de SIDs para fornecer engenharia de tráfego ou serviços de VPN.
Segmentos de serviço podem ser associados a appliances legados (VNFs
inconscientes de SR, ou seja, VNFs sem recursos de SRv6), graças aos
mecanismos de proxy de SR que realizam o processamento de SR e ocultam
as informações de SR do VNF. Os três comportamentos de terminal que foram
definidos em [23] para suporte ao encadeamento de funções de serviço são:
End.AD, End.AS e End.AM. Os dois primeiros implementam respectivamente
sem reconhecimento de SR. Eles suportam pacotes IPv6 SR no modo
H.Encaps. O proxy SRv6 intercepta pacotes SR antes de ser entregue ao VNF
que não reconhece SR, portanto, pode remover o encapsulamento SR dos
pacotes.
Para pacotes que retornam do VNF sem reconhecimento de SR, o proxy SR
pode restaurar o encapsulamento SRv6 atualizando o SRH corretamente. A
diferença entre os proxies estáticos e dinâmicos é que as informações SR que
precisam ser empurradas de volta nos pacotes são configuradas estaticamente
no primeiro caso e são aprendidas dos pacotes recebidos no caso dinâmico.
Em vez disso, o End.AM implementa o proxy de mascaramento que oferece
suporte a pacotes SR viajando no modo H.Insert.
[40] explica como a tecnologia SR permite Acordos de Nível de Serviço
(SLA) subjacentes para uma VPN de forma escalável e segura, garantindo a
opacidade do serviço. As VPNs baseadas em SR são analisadas considerando
o caso de um único provedor e de vários provedores. Além disso, o rascunho
aborda os aspectos do plano de controle dessa solução, que são gerenciados
por um controlador SD-WAN over-the-top. Por fim, são analisados os benefícios
trazidos pela tecnologia SR aos serviços VPN em termos de
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 10

escalabilidade, privacidade, gerenciamento de faturamento e segurança. uma atividade de padronização correspondente (por exemplo, um rascunho da
[24] descreve a aplicabilidade do SRv6 ao plano de usuário de redes móveis. Internet ou uma RFC) promovida pelo mesmo fornecedor que produziu a patente.
Três modos são abordados: modo tradicional, modo aprimorado e modo aprimorado

com interfuncionamento. Começaremos analisando [87], [84], [85] e [86] que

No modo tradicional, o plano de usuário móvel permanece inalterado, exceto pelo
uso de SRv6 como transporte em vez de GTP-U [99]. O modo avançado usa apenas
SRv6 e sua estrutura de programação. Por fim, o modo aprimorado com
interfuncionamento usa SRv6, mas também fornece funcionalidade de
interfuncionamento com componentes herdados que ainda usam GTP. O documento
descreve um mecanismo para fatiamento de rede de ponta a ponta e define os
comportamentos SRv6 para o plano de usuário móvel SRv6. Dentre esses
comportamentos, os mais importantes definem as funções para a coexistência de
GTP-U [99] e SRv6. Em particular, o TMTmap converte um pacote GTP-U sobre
IPv4 em um pacote SRv6. Sua contraparte é End.M.GTP4.E, que mapeia um pacote
SRv6 para um pacote GTP-U sobre IPv4. Finalmente, End.M.GTP6.D e
End.M.GTP6.E definem respectivamente a tradução do pacote GTP-U sobre IPv6
para um pacote SRv6 e do pacote SRv6 para um pacote GTP U sobre IPv6.
cobrem os principais princípios da arquitetura SR.
Apesar do nome referir-se a MPLS e SR, [86] patenteia uma arquitetura primitiva
para Segment Routing. Provavelmente foi uma das primeiras patentes relacionadas
ao Segment Routing e basicamente descreve um mecanismo para mapear portas
de saída dos roteadores para rótulos, anunciar esses dados com um protocolo de
estado de link e encaminhar pacotes de dados na rede com essas informações
anexadas.
[84] está relacionado à RFC8402 [10], e inclui a definição de uma lista SID e
explica como um nó pode construir tal pilha de rótulos; ele mostra o comportamento
de encaminhamento dos nós SR e faz uma distinção clara entre as operações de
um roteador IP, roteador Label/MPLS e roteador SR. Além disso, a patente abrange
os diferentes tipos de SIDs, e para cada um deles é fornecida uma definição.
Finalmente, diferentes casos de uso para SR são ilustrados.

O Alternativo Sem Loop Independente de Topologia (TI-LFA) [45] fornece

[85] é outro documento fundamental, que compartilha muitos conceitos com [2].
mecanismos de Reencaminhamento Rápido (FRR) protegendo contra falhas de link,
Ele patenteia o uso de um cabeçalho de extensão IPv6 para implementação nativa
nó ou Grupos de Link de Risco Compartilhados (SRLGs) locais em redes habilitadas
de Segment Routing em redes IP. O documento também descreve o cabeçalho de
para SR. Para cada destino na rede, um caminho de backup é pré-calculado e
extensão SRv6 juntamente com as operações realizadas pelos nós para atualizar o
instalado na tabela de encaminhamento, para que esteja pronto para ser ativado
cabeçalho de extensão e o cabeçalho IPv6 na recepção de um pacote. Em vez
assim que uma falha for detectada. Para cada destino, o caminho de backup
disso, [87] descreve a aplicabilidade do Segment Routing em um cenário onde uma
corresponde ao caminho pós-convergência, que é seguido pelo tráfego após a
rede de computadores foi particionada em várias sub-redes.
convergência da rede. O rascunho também analisa os benefícios do uso do Segment
Routing em relação às soluções tradicionais de FRR.

O segundo grupo de documentos descreve principalmente as extensões dos

protocolos de roteamento. Por exemplo, [31] descreve extensões para BGP-LS para
[46] descreve um mecanismo que alavanca SR para evitar inconsistências
sinalizar SIDs dentro de um domínio IGP. [88] descreve um método para a criação
transitórias de roteamento durante o período de convergência que segue uma
e manutenção de políticas SR através do protocolo BGP. O método depende do
modificação na topologia da rede. Em vez de convergir diretamente para um novo
recebimento de mensagens de atualização do BGP com metadados adicionais
próximo salto após uma modificação de topologia, um nó pode direcionar
referentes a uma política SR. [89] abrange vários cenários relativos à publicidade de
temporariamente o tráfego impactado por meio de um conjunto de políticas SR sem
identificadores de segmento de adjacência. O método se aplica tanto a links ponto a
loop, evitando assim que ele seja afetado por inconsistências de roteamento. Depois
ponto quanto a segmentos de LAN.
que a rede convergiu totalmente, as políticas de SR temporárias são removidas sem
nenhum impacto no tráfego.
A grande maioria das patentes se baseia no suporte de casos de uso importantes,
como TE, SD-WAN, monitoramento de rede, NFV/SDN, SFC e assim por diante. [90]
[75] define um conjunto de extensões para os protocolos de roteamento IGP que
descreve métodos e uma arquitetura para o monitoramento de caminhos de rede
permitem que Prefix-SIDs sejam associados a algoritmos de caminho mais curto
que alavancam a tecnologia SR. De acordo com a patente, os nós podem montar
definidos pelo operador, chamados SR Flexible Algorithms (Flex Algo). Esses
uma lista SID com o objetivo de testar/monitorar um caminho de rede específico. É
algoritmos são definidos como uma métrica de otimização (IGP, TE ou atraso) e um
possível encontrar muitas semelhanças com os trabalhos da seção IV-A.
conjunto de restrições (por exemplo, recursos a serem excluídos do caminho). Cada
nó participante de um Flex-Algo calcula os caminhos mais curtos para os Prefix-SIDs
desse Flex-Algo e os instala em sua tabela de encaminhamento. Os algoritmos
[91] descreve como o SR pode ser usado em um domínio do Label Distribution
flexíveis SR permitem que o tráfego seja direcionado ao longo de caminhos de
engenharia de tráfego, como caminho disjunto de baixa latência ou de plano duplo Protocol (LDP) e como os nós MPLS podem coexistir com os nós que são habilitados

com um único prefixo-SID. para SR. A patente também inclui a definição de nós híbridos que são capazes de
operar tanto como nós habilitados para LDP quanto como roteadores com
reconhecimento de SR.

Três patentes estão relacionadas a mecanismos de redirecionamento rápido e

B. Patentes relevantes
Nesta seção revisamos 18 entre quase 1.000 patentes que podem ser
encontradas em motores de busca de patentes. É interessante notar que SR é a
tecnologia central da patente apenas em cerca de 200 das 1000 patentes. Para a
maioria das patentes existe
prevenção de loops. Em [92], um método para detectar e evitar loops em caminhos
de tráfego SR é descrito. Baseia-se na ideia de definir para cada túnel um segundo
caminho, que é explorado quando o tráfego é recebido de um nó interno à rede. Em
vez disso, [93] define vários métodos para loop
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
evitar falhas de rede. Finalmente, [94] descreve mecanismos de FRR
para redes baseadas em Roteamento de Segmento.
[30] define um método para a orquestração de serviços de
conectividade em uma WAN habilitada para SR. O controlador é
considerado fora da rede. Ele é capaz de monitorar o estado atual da
WAN e utiliza um solver para realizar a engenharia de tráfego.
As decisões tomadas pelo solver são aplicadas usando a tecnologia
SR. [22] descreve um método para a atribuição dos SIDs, que se baseia
na atribuição de um valor de índice global a cada nó e na transmissão
de um valor base para calcular os identificadores do segmento final Aÿ
ÿ
descreve um algoritmo para "AIJtranslate" caminho explícito em umÿI. [95]
conjunto de SIDs (como os trabalhos da seção IV-E). A idéia principal
do algoritmo proposto é calcular, a partir do nó fonte, o caminho mais
curto para o nó mais distante sem ambiguidade, ou seja, sem múltiplos
caminhos de custo igual: um SID da Lista de Segmentos resultante é
associado a cada nó mais distante.
Uma análise das patentes mais recentes destaca que SR representa
uma tecnologia chave também para a implantação de futuras redes em
muitos cenários diferentes: i) em [96], é proposta a implementação de
um mecanismo de fatiamento de rede explorando um algoritmo flexível
de SR; ii) [97] propõe um mecanismo para reportar informações de
localização de nós móveis em redes 5G usando SR; iii) em [98], a
flexibilidade de codificação de caminho fornecida pelo SR é explorada
para definir um procedimento de migração de Máquina Virtual com perda
zero [100].
4. ATIVIDADES DE PESQUISA
Nesta seção, descrevemos as atividades de pesquisa relacionadas
às RS e fornecemos duas classificações diferentes para caracterizar os
trabalhos de pesquisa com base em seu escopo principal. Também
mostramos como extrair informações úteis sobre a atividade de pesquisa
em SR em andamento a partir da análise da relação entre as duas
classificações propostas.
A primeira classificação proposta baseia-se na identificação de sete
categorias principais de pesquisa, conforme apresentado na Tabela IV.
A primeira é a categoria Monitoramento, reunindo todos os trabalhos
que descrevem e implementam ferramentas relacionadas às atividades
de monitoramento da rede. Alguns exemplos incluem as medições do
atraso fim a fim sobre uma determinada rota de entrada ou a avaliação
do volume dos fluxos de tráfego.
A segunda categoria é a Engenharia de Tráfego, onde incluímos todos
os trabalhos que propõem estratégias avançadas de roteamento para
otimizar o desempenho da rede. A terceira categoria é a Recuperação
de Falhas, abrangendo soluções para fornecer recuperação rápida da
rede no caso de falha de nó/link. Devido às restrições de escala de
tempo, os trabalhos desta categoria são baseados em mecanismos
locais, ou seja, não envolvendo o controlador central. A quarta categoria
definida é Arquiteturas Centralmente Controladas, incluindo todos os
trabalhos com foco na implementação de uma rede SR com um plano
de controle centralizado realizado em cima de uma rede underlay (IP,
SDN, MPLS). Aqui destacamos que, apesar de alguns trabalhos
classificados como Engenharia de Tráfego serem baseados em
arquiteturas controladas centralmente, eles não estão incluídos na
categoria Arquiteturas Controladas Centralmente. Isso se deve ao fato
de que seu escopo principal continua sendo otimizar uma meta de TE
próximo, e que o menor número de
(como a redução do congestionamento ou a minimização do consumo de energia).
11
TABELA IV
CLASSIFICAÇÃO #1 COM BASE EM CATEGORIAS DE PESQUISA
Categoria Referências
Monitoramento (MON) [101]–[108]
Engenharia de Tráfego (TE) [109]–[130]
Recuperação de Falha (FR) [131]–[139]
Controlado Centralmente
[4], [140]–[154]
Arquiteturas (CCA)
Codificação de Caminho (PEN) [15], [155]–[161] [21],
Programação de Rede (NP) [100], [162]–[167] [168]–[171]
Avaliação de Desempenho (PEV) [14], [172]–[180]
Diversos (MISC)
20
15
10
5
0
MONTAGEM FR CCA PEN NP PEV MISC
Fig. 6: Número de referências para cada categoria da taxonomia definida.
Na categoria Path Encoding, agrupamos todos os trabalhos que propõem
algoritmos visando traduzir caminhos de rede em um SL. Especificamente,
tomamos como entrada um caminho na forma de uma sequência de nós
e links que o algoritmo genérico de codificação de caminho fornece
como saída uma sequência de SIDs a serem empurrados no cabeçalho
do pacote para orientar o pacote ao longo do caminho de entrada. A
sexta categoria é a Programação em Rede, onde inserimos trabalhos
científicos propondo soluções que exploram o recurso de programabilidade
do SR. ou seja, usando SIDs baseados em serviço para definir as
funções a serem executadas em pacotes que cruzam uma lista de
segmentos específica. Um exemplo significativo de trabalhos que se
enquadram nessa categoria incluem trabalhos relacionados ao
encadeamento de funções de serviço. Por fim, definimos uma categoria
Diversos, onde colocamos todos os trabalhos que não pertencem às categorias anterio
Na Fig. 6 podemos ver um histograma mostrando o número de
referências que se enquadram em cada uma das categorias definidas.
Analisando a Fig. 6, fica evidente que Engenharia de Tráfego e
Arquiteturas de Controle Centralizado são os assuntos mais investigados,
enquanto as demais categorias foram abordadas por quase o mesmo
número de trabalhos. Esse comportamento é bastante esperado, pois a
principal característica do SR é definir caminhos de roteamento de forma
bastante flexível e fazer uso de planos de dados amplamente implantados.
Este fenômeno é realmente atraente para a definição de novas soluções
para problemas de TE e para a realização de redes sobrepostas. Ao
contrário, o número de artigos relacionados à Programação em Rede
pode indicar um baixo interesse por um tema tão novo entre a
comunidade de pesquisa. Acreditamos que a Programação em Rede
representa um tema de pesquisa altamente interessante para um futuro
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 12

papéis é apenas devido ao seu estado de definição inicial. Monitoramento

Para melhor investigar a atividade de pesquisa relacionada às RS, propomos (8)

uma segunda classificação baseada nos tópicos específicos de RS considerados

Roteamento Tráfego Direção SR
nos trabalhos de pesquisa. A nova classificação relacionada ao SR é relatada na Política
Flexibilidade Engenharia (22)

Tab. V. Os diferentes tópicos de RS também são agregados em três grupos (15) (5)

principais: Fonte Falha Rec.

Comprimento
• Exploração do recurso SR; • Roteamento Resiliência
SL (14)
(31) (9)
Otimização das funções SR; • Extensões
SR. Centralmente
Programa. (10)
Contr. Arco.
O grupo de exploração de recursos SR abrange todos os trabalhos que utilizam (16)

recursos SR para resolver problemas clássicos de rede, como otimização de

Novas funções
recursos de rede e melhoria de desempenho. O primeiro tópico do SR é a Outros Codificação de Caminho

(21) (8) (8)

flexibilidade de roteamento, ou seja, a possibilidade de direcionar um pacote por
um caminho não trivial (por exemplo, contendo ECMP, loops, etc.). A segunda Rede

característica é o roteamento de origem, ou seja, a capacidade do SR de instruir Programação (8)

apenas o nó de origem para a configuração de um caminho de rede específico. O

terceiro recurso do SR é a programabilidade, ou seja, a possibilidade de forçar um
pacote a passar por uma função usando SIDs específicos. Todos os recursos Fig. 7: Gráfico mostrando a relação entre as categorias de pesquisa e os temas

restantes do SR estão incluídos no outro tópico. Aqui, unimos os seguintes tópicos: das RS.

i) os Adj-SIDs, usados para forçar um pacote a ser encaminhado em uma porta de

saída específica; ii) o ECMP, ou seja, a capacidade do SR de equilibrar o tráfego
no centro da figura) ou um tópico de RS (dividido em retângulos vermelho, azul e
em vários caminhos fornecidos pelos protocolos de roteamento IGP; iii) o Type
verde na borda da figura), e uma aresta entre uma categoria e um tópico de RS
Length Value (TLV) usado para adicionar dados opcionais ao cabeçalho SR; iv) o
está presente somente se ambos estiverem presentes na mesma obra. Além disso,
Binding SID (BSID) que permite ao usuário definir túneis SR em um nó de trânsito;
a espessura de uma borda depende do número de artigos que cobrem o par
v) os contadores de tráfego SR (Base Pcounters e TM Pcounters), que coletam
categoria/tópico específico. O gráfico da Fig. 7 mostra vários resultados
estatísticas de tráfego com base no segmento ativo transportado nos cabeçalhos
interessantes: i) os trabalhos relacionados à categoria Monitoramento exploram
dos pacotes; e vi) a política de spray, que permite a duplicação de um pacote de
principalmente a flexibilidade de roteamento e o paradigma de roteamento de
entrada em várias portas de saída e usando diferentes SLs.
origem; ii) o mesmo resultado é obtido para os trabalhos de Engenharia de Tráfego,
mas neste caso também são abordados tópicos de política de direção de SR e
comprimento de SL; iii) para fornecer soluções de Recuperação de Falhas,
geralmente novas funções precisam ser definidas; iv) o roteamento de origem é o
recurso SR mais utilizado para soluções de Arquitetura de Controle Centralizado,
No grupo de otimização de funções de RS, destacam-se as atividades de
pois permite a redução da comunicação entre o controlador central e os dispositivos
pesquisa voltadas ao aprimoramento das funções internas de uma rede de RS. O
da rede; v) como esperado, os trabalhos de Path Encoding estão principalmente
primeiro tópico do grupo é a SR Steering Policy, ou seja, a definição das políticas
focados na otimização do comprimento do SL (é de qualquer forma interessante
a serem instaladas nos dispositivos de rede para anexar o SL adequado a cada
notar que o Adj-SID é o principal recurso do SR usado para atingir esse escopo);
pacote recebido. O segundo tópico é o comprimento do SL, ou seja, o número de
vi) por fim, os trabalhos da categoria Programação em Rede sempre exploram o
SIDs de uma lista de segmentos, que tem impacto na inserção e no processamento
recurso de programabilidade do SR e, em alguns casos, novas funções precisam
do cabeçalho SR.
ser definidas.

O último grupo, ou seja, extensões do SR, é representado por um único tópico

(novas funções) e está relacionado à nova funcionalidade implementada no SR
para suporte a serviços avançados.
Na Fig. 7, relatamos para cada categoria/tópico SR o número
Aba. V relata a classificação dos trabalhos de pesquisa de acordo com os
de referências relacionadas.
temas das RS. Diferente da Tab. IV, onde a mesma referência pode aparecer
Nas próximas subseções, descrevemos brevemente todas as pesquisas
apenas uma vez, na Tab. V, pode ser classificado em diferentes categorias. Por
trabalhos, considerando a classificação proposta na Tab. 4.
exemplo, [159] usa o recurso Adj-SIDs SR para realizar a otimização das funções
SR do ponto de vista do comprimento do SL.
A. Monitoramento

Aba. V mostra que o recurso de SR mais utilizado é o de roteamento de origem,
embora ainda haja uma quantidade limitada de trabalhos com foco na
programabilidade da rede e na definição de novas funções.
Para obter mais informações sobre a atividade de pesquisa em RS, definimos
uma maneira de mostrar a relação entre as classificações relatadas na Tab. IV e
Tab. V, respectivamente. Na Fig. 7 podemos ver um gráfico que é definido da
seguinte forma: cada nó representa uma categoria de pesquisa (retângulos violetas
Foram definidos oito trabalhos de pesquisa propondo soluções de monitoramento
capazes de explorar SR, conforme apresentado na Tabela VI. Estas obras foram
classificadas com base no seu objetivo principal:
• medições de atraso, visando obter o atraso para enlaces e roteadores explorando a
possibilidade de modificação do SL nos nós de origem, ou seja, recurso SR de
roteamento de origem; • verificação de integridade dos dispositivos de rede,
visando monitorar o estado da rede explorando a capacidade do SR na definição de
rotas ad-hoc, ou seja, recurso de flexibilidade de roteamento.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 13

TABELA V
CLASSIFICAÇÃO #2 COM BASE EM TÓPICOS SR

Exploração de recursos SR Otimização de funções SR Estender SR

Flexibilidade de roteamento Roteamento de Programabilidade Outros Política de direção SR Comprimento SL Novas funções
origem [101],[102],
[103] [104],[109],
[110] [111],[114], BSID:[131],[139],[148],[149],[151] [154] [15],[109]
[116] [117],[118], [114],[121]
[102],[105],[106],[110] [112], [21],[108],[138],[162] [163], [15], [108]
[119] [121], [123], ECMP:[116],[122],[123] [122],[126]
[113],[115],[118] [119],[122], [164],[165] [166],[167] [111],[119],[121] [135],[136]
[124] [125],[126], TLV:[108],[131],[138],[141] [127],[155]
[127],[128] [129], [ 130], [100] [160],[161] [137],[161]
[135] [140],[141], Adj-SID:[15],[121],[156],[158],[159] [156],[157]
[154] [165],[100]
[142] [143],[144], Pulverizar:[132],[133] [158],[159]
[145] [146],[147], Contadores de tráfego:[107] [160],[161]
[148] ] [149],[150],
[151] [152]

15 componentes, que injetam e recebem testes com carimbo de data/hora

rt flex
src rt roteados de acordo com a lista de segmentos SR imposta. O segundo
tipo de medição requer sincronização entre os terminais, mas também
programar outros

SR direção pl
permite a medição do atraso unidirecional, o que é mais útil quando é
10 SL necessário implantar serviços na rede. Juntamente com a maioria dos
comprimento novo fnc
trabalhos relacionados, o projeto compartilha o objetivo de reduzir a
complexidade do plano de controle através do SR. No entanto, no artigo
5
não está claro qual implementação os autores usaram para SR, ou se
eles confiaram em alguma solução de fornecedor.

As capacidades de direcionamento de tráfego do SR foram utilizadas

0
MINHA A FR CANETA CCA POR EXEMPLO
no SCMon [102], uma nova solução para monitoramento contínuo do
plano de dados. Ele permite que o usuário rastreie a saúde de todos os
Fig. 8: Histograma mostrando a relação entre as Classificações roteadores e links: i) forçando “probes de monitoramento a percorrerem
definidas na Tab. IV e Tab. V.
ciclos”; e (ii) testar “links paralelos e pacotes em uma granularidade por
link”. O principal insight é que os nós de rede calculam um segundo
TABELA VI
gráfico de rede e calculam rotas nessa topologia de monitoramento,
CLASSIFICAÇÃO DAS REFERÊNCIAS RELACIONADAS AO MONITORAMENTO.
que abrange todos os links de rede. Os nós então selecionam
cuidadosamente os caminhos ECMP e impõem o encaminhamento de
Referências
pacotes por meio de ciclos, aproveitando o SR para detectar/localizar
Objetivo
Medições de atraso [101],[108] falhas e sobrecarga de links únicos/múltiplos. Um protótipo de
Verificação de implementação do SCMon foi avaliado em topologias publicamente
[102],[103],[104]
integridade de dispositivos de rede
disponíveis e redes emuladas. No primeiro experimento, a razão do
Medições de tráfego [105],[106],[107]
Traceroute [108] número de ciclos sobre o número de arestas é avaliada para analisar a
porcentagem das redes cobertas. Os autores avaliam então o tempo
para detectar buracos negros, mostrando que a maioria deles é
detectada em menos de 100 ms. Os resultados do trabalho são muito
• medições de tráfego, visando avaliar a matriz de tráfego de uma rede explorando a

flexibilidade de roteamento e contadores SR; • traceroute, com o objetivo de implementar

interessantes e podem ser aplicados em casos de uso reais.
o conhecido utilitário tracer oute no SR.
No entanto, uma implementação de código aberto não está disponível
no momento da escrita.

Nos parágrafos a seguir, apresentamos uma breve visão geral
as referências classificadas como trabalhos relacionados ao monitoramento.
[101] propõe um novo sistema de monitoramento alimentado por
Segment Routing (SR), que é usado para o provisionamento de
baseada em ciclos permite economizar recursos de rede e monitorar a
serviços de rede com reconhecimento de atraso abrangendo vários domínios.
Com base nos princípios SR-MPLS, ele permite medições de atraso
em várias rotas candidatas sem exigir sessões de sinalização LSP
relacionadas. Os autores consideram dois tipos de sondas usando SR-
MPLS. O primeiro tipo é originado e terminado por estações da rede,
permitindo a recuperação apenas de medições de ida e volta. Eles
também têm menos precisão. Além disso, eles são normalmente
usados para medições de desempenho em um único link. Em vez
disso, o segundo tipo depende de monitoramento externo
Em [103], os autores focam em esquemas de monitoramento
eficientes em largura de banda baseados em ciclos. Eles propõem
quatro algoritmos diferentes para computar ciclos que são projetados
para percorrer/cobrir todos os enlaces da rede. Essa otimização
rede a partir de um único ponto de vantagem.
O Segment Routing é usado como tecnologia de transporte para
encaminhar as sondas ao longo da rede. O artigo baseia-se nos
resultados de [102]: os autores aproveitam a fase 1 do SCMon para
construir a topologia de monitoramento da rede e, em seguida, aplicam
seus algoritmos de duas fases para minimizar o comprimento de
cobertura do ciclo. A avaliação de desempenho mostra a eficácia
desses algoritmos em termos de duração da cobertura do ciclo, lista de segmentos
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
profundidade e melhorias em relação à linha de base (SCMon).
Em vez disso, [104] baseia-se em [103], propondo três formulações
de ILP para a construção de ciclos de monitoramento. Uma primeira
formulação ILP resolve de forma otimizada o problema de cobrir cada
link na rede usando ciclos de monitoramento com comprimento mínimo
de cobertura de ciclo. Para conservar ainda mais a largura de banda da
rede, a primeira formulação é estendida para minimizar conjuntamente
o tamanho total da lista de segmentos necessária. Finalmente, como o
tempo necessário para detectar uma falha na rede é afetado pelo ciclo
mais longo, a primeira formulação também é estendida para minimizar
a duração do ciclo mais longo conjuntamente. [105] explora a flexibilidade endereço de destino especificado no SRH todos os próximos saltos do
do SR para realizar medições de tráfego e obter a Matriz de Tráfego.
Uma medição de tráfego
é realizado reencaminhando um fluxo e verificando as variações de
carga causadas nos links de rede. Embora a ideia de medir o tráfego
por meio de perturbações de roteamento não seja nova, SR acaba
sendo uma tecnologia capacitadora para a aplicabilidade de tal
abordagem. De fato, enquanto no passado os fluxos de tráfego eram
reencaminhados agindo nos pesos dos enlaces OSPF, causando
instabilidade de roteamento e degradação de desempenho, o SR
permite a modificação de um caminho simplesmente atuando no nó de
ingresso, reduzindo o impacto de um reencaminhamento. Em [105], o
problema de avaliar a TM minimizando as perturbações de roteamento
é formulado como um ILP e um algoritmo heurístico denominado
SERPENT é apresentado. Devido à alta complexidade computacional
do SERPENT, uma heurística gulosa mais leve chamada PaCoB é
proposta em [106].
Uma característica atraente do SR é a introdução de contadores de
interface específicos que permitem obter estatísticas sobre os fluxos de
tráfego da rede. Se este recurso estiver incluído no projeto de hardware
do roteador, a atualização dos contadores de tráfego pode ser associada
ao processamento normal no plano de dados SR, tendo assim um
impacto insignificante no desempenho do roteador.
O tipo mais simples de contadores SR, denominado Base Pcounters,
coleta estatísticas de tráfego (byte/pacotes) que passam por um roteador
e possuem um segmento ativo específico. Contadores SR aprimorados,
denominados Pcounters TM (Traffic Matrix), permitem que o usuário
distinga entre o tráfego interno ao domínio SR e os fluxos injetados no
domínio SR. Especificamente, um TM Pcounter coleta estatísticas de
tráfego de fluxos de tráfego recebidos por uma interface marcada como
externa (esta é uma opção de configuração para a operadora de rede).
Como o TM Pcounters pode discriminar pacotes com base na interface
de entrada, o uso do TM Pcounters fornece uma granularidade mais
fina em relação ao uso do Base Pcounters e facilita a estimativa da
Matriz de Tráfego. A partir da disponibilidade deste novo tipo de
informação relacionada ao tráfego, em [107] o problema de Avaliação
da Matriz de Tráfego foi estendido para incluir contramedidas SR. Os
autores mostram que, dependendo da estrutura das Listas de Segmentos
utilizadas na rede, a Matriz de Tráfego pode ser avaliada sem erros.
[108] estende o kernel Linux para executar programas eBPF como
em funções de rede anexadas aos SIDs SRv6; mais detalhes sobre a
implementação são fornecidos na Seção V. Os autores demonstram a
eficácia de sua abordagem construindo três aplicativos diferentes. O
primeiro oferece uma solução de monitoramento passivo de atrasos de
rede (links diretos ou caminhos fim-a-fim) [53]. A ideia de alto nível é
que um pequeno por
14
porcentagem de tráfego é encapsulada com um SRH especial que
carrega informações adicionais, como carimbos de data e hora. Esses
carimbos de data/hora são então usados pelos nós destinatários para
calcular atrasos unidirecionais ou de ida e volta. O segundo aplicativo
realiza um grupo de agregação de links usando SRv6. Em particular,
um escalonamento round robin de peso é realizado para agregar a
largura de banda de dois links diferentes. Por fim, foi realizada uma
versão aprimorada do traceroute, implementando um novo
comportamento do SRv6, o chamado End.OAMP. Esse comportamento,
quando acionado, realiza uma pesquisa fib no nó e retorna para um
ECMP. Se possível, essa função é aproveitada em cada salto, caso
contrário, o programa reverte para o mecanismo ICMPv6 legado.
Nos parágrafos seguintes apresentamos uma comparação das obras
classificadas na categoria Monitorização.
Em relação às soluções relacionadas às medidas de atraso, ambas
([101] e [108]) permitem obter o atraso unidirecional fim a fim entre dois
pontos da rede. Enquanto o primeiro requer o uso de uma ferramenta
de monitoramento externa para gerar testes com registro de data e hora
(o uso do SR é limitado à criação do caminho de ponta a ponta), o
segundo não. De qualquer forma, [108] é adequado apenas para redes
realizadas por meio de roteadores SRv6 baseados em Linux, pois
explora a definição de programas eBPF para realizar a medição.
Existem duas ferramentas de monitoramento baseadas em SR para
verificar o status de integridade dos links de rede. A primeira é ([102], e
a segunda é uma ferramenta proposta em [103] e [104]). A abordagem
que eles seguem é semelhante, ou seja, a criação de caminhos cíclicos
através do SR onde as mensagens de teste são enviadas. Com relação
a [102], [103] e [104] otimizam o uso dos recursos de monitoramento
necessários para verificar o estado de todos os elementos da rede. Em
qualquer caso, [103] e [104] não suportam pacotes de links, enquanto
[102] sim.
Entre as ferramentas de medição de tráfego baseadas em SR, duas
abordagens diferentes podem ser identificadas em [105]–[107]. A
primeira abordagem visa medir os fluxos de tráfego causando variação
de carga do link por meio de operações de reencaminhamento. Isto é
explorado em [105], [106]. A segunda abordagem é baseada no uso de
contadores de tráfego específicos, disponíveis em nós habilitados para
SR. Isso é explorado em [107]. Embora ambas as abordagens ofereçam
desempenhos comparáveis em termos de qualidade da Matriz de
Tráfego avaliada, a solução baseada em contador não afeta o
desempenho da rede. Isso é diferente das duas soluções baseadas em
reencaminhamento.
B. Engenharia de Tráfego
Devido às suas características atraentes em termos de flexibilidade de roteamento, o
SR é amplamente utilizado para enfrentar problemas relacionados à Engenharia de Tráfego.
Durante nossa investigação, encontramos vinte e dois artigos explorando
SR para fornecer soluções avançadas de TE. Todos os trabalhos de
pesquisa TE empregam a estrutura clássica de um problema de
otimização: i) uma função objetivo deve ser minimizada/maximizada, ii)
levando em consideração um conjunto de parâmetros e iii) considerando
um cenário de rede específico. Três diferentes objetivos de TE têm sido
abordados pela literatura, ou seja, a minimização do consumo de
energia da rede, a otimização do congestionamento e a minimização do
número de requisições rejeitadas.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
TABELA VII
CLASSIFICAÇÃO DAS REFERÊNCIAS RELACIONADAS A
ENGENHARIA DE TRÂNSITO .
Energia
[112],[113]
Consumo
Objetivo
[109], [110],[111],[114],[115] [116],
[117],[118],[119],[121] [122],[123],
Largura de banda do link
[124], [125],[126] [127],[128][129],
[130] [109],[118] [110],[118],
Solicitações rejeitadas [126],[127] [109],[111] ,
Leva em Atraso [121],[122],[123] [124],[125],[126],
conta
Impacto SR [127] [109],[111],[112],[113],[114]
(sobrecarga, estado de fluxo) [115], [116],[117],[118],[120]
[122],[124],[125],[126],[127] [129]
[110],[121],[130]
SR completo
Cenário
SR parcialmente implantado
A alta flexibilidade de roteamento permitida pelo SR pode causar a presença
de caminhos de rede longos e complexos. Por isso, ao otimizar o roteamento
de acordo com um objetivo específico, é importante levar em consideração o
impacto que soluções de roteamento excessivamente complexas podem ter
no desempenho da rede. Além do atraso fim a fim, alguns dos trabalhos
revisados também levam em consideração o overhead relacionado ao SR,
tanto em termos de largura de banda desperdiçada devido à inserção nos
pacotes do cabeçalho SR, quanto no número de políticas de direcionamento
do SR a serem configuradas no os roteadores de borda. Finalmente, a rede
considerada pode ser uma rede SR completa, ou seja, todos os nós são
capazes de SR, ou uma SR parcialmente implantada, onde apenas um
subconjunto de nós pode processar o cabeçalho SR.
A Tabela VII mostra a classificação das referências relacionadas ao TE.
É interessante notar que a maioria dos trabalhos considera a minimização do
congestionamento como o objetivo principal, e que são poucas as soluções
que podem funcionar também em um cenário de rede híbrida.
Nos parágrafos a seguir, apresentamos uma breve visão geral
as referências classificadas como trabalhos relacionados ao TE.
[109] implementa um algoritmo TE com SR em uma infraestrutura SDN
que constrói um caminho com garantias de largura de banda e minimiza ao
mesmo tempo a possibilidade de rejeição de demandas de tráfego. Com
relação a outras soluções, leva em consideração a “criticidade do link” e não
apenas a largura de banda residual do link.
Citando [109]: “A criticidade do link é baseada no conceito do método de
roteamento de interferência mínima”. Minimiza a possibilidade de rejeitar
solicitações quando a rede fica sobrecarregada. O algoritmo proposto não
apenas atinge o objetivo de balancear a carga de tráfego da rede, mas
também promete reduzir os custos da rede. Por se basear nos princípios de
SR, a solução proposta também considera a sobrecarga de rede extra
causada pelos rótulos de segmento nos cabeçalhos dos pacotes. O
comprimento do caminho foi modelado como uma restrição da heurística,
adotando uma limitação de salto extra para economizar recursos de rede -
largura de banda extra utilizada pelas listas de segmentos nos cabeçalhos
dos pacotes. Segundo os autores, a complexidade de tempo do algoritmo
pode atender aos requisitos de roteamento dinâmico online. No entanto, não
há implementações de código aberto disponíveis, e apenas os resultados da
simulação são fornecidos pelos autores.
15
Bahnasse et ai. [110] propõem uma arquitetura baseada em SDN para
gerenciamento de redes Diffserv-aware de Engenharia de Tráfego MPLS,
que baseia seu encaminhamento nos princípios SR-MPLS. Essa arquitetura
também deve suportar implantações híbridas em que equipamentos SDN
coexistem com dispositivos legados, garantindo os mesmos recursos de
encaminhamento. Os dispositivos legados são confinados no núcleo da rede,
enquanto os recursos SDN precisam ser suportados por dispositivos de
borda. Desta forma, uma vez que o controlador calculou os caminhos que
atendem aos parâmetros SLA dos fluxos, ele programa a rede interagindo
com a borda e configurando os caminhos SR. Então, ao longo do tempo, o
controlador monitora a rede e gerencia dinamicamente os SR-LSPs para
garantir que o roteamento realizado pelos segmentos não viole as restrições
de QoS de ponta a ponta.
Segment Routing e Multicast são combinados em [111].
Os autores propõem uma solução de roteamento para Multicast baseada em
SR e uma heurística para cálculo de árvore Multicast com garantias de largura
de banda, que leva em consideração a carga dos links, o número de pontos
de ramificação e o estado na rede. O objetivo é minimizar o número de
solicitações rejeitadas. Em particular, o controlador SDN calcula uma árvore
Multicast explícita usando a heurística mencionada acima e, em seguida,
programa o nó de origem da árvore e seus pontos de ramificação: cada vez
que um pacote atinge um ponto de ramificação, ele precisa ser duplicado e
encaminhado em diferentes caminhos, e uma modificação das listas de
segmentos é executada. Os resultados da simulação mostram que o método
proposto supera outros algoritmos de roteamento, embora uma implementação
de código aberto não esteja disponível e uma análise mais profunda não seja
viável.
[112] também trata de TE baseado em SR. Em particular, os autores
projetam um método de Engenharia de Tráfego on-line com eficiência energética.
Eles usam o controlador SDN para desligar seletivamente e colocar em modo
de suspensão um subconjunto de links. Eles então adaptam dinamicamente
o número de links ativados à carga de tráfego. Neste trabalho, o SR é usado
para redirecionar dinamicamente o tráfego. Primeiro, uma técnica de link
menos congestionado é executada para identificar os links elegíveis que
podem ser desativados. Neste ponto, novas rotas são calculadas, resolvendo
assim, via heurística, o “Problema de Fluxo Multicommodity”. Finalmente, o
controlador SDN impõe novos caminhos por meio de SR ou o encaminhamento
IGP é aproveitado se a rota corresponder ao caminho mais curto. Neste
ponto, não é necessário desligar os links. Similarmente a outros trabalhos, o
problema é resolvido identificando primeiro os caminhos hop-by-hop e depois
mapeando-os em caminhos SR mantendo a restrição do roteamento fixo
sobre o caminho hop-by-hop dado. Os autores desses trabalhos fornecem
uma análise interessante implementando a solução no simulador OMNET++.
No entanto, apenas resultados numéricos são fornecidos e, até onde
sabemos, uma implementação de código aberto não está disponível.
A flexibilidade na seleção de caminhos alcançada pelo Segment Routing
é explorada em [113] para propor uma nova estratégia de roteamento de
eficiência energética. O foco principal do trabalho é desligar um subconjunto
de links de rede selecionando adequadamente caminhos alternativos para o
tráfego atualmente direcionado pelos links de destino.
Claramente, os novos caminhos devem ter recursos de largura de banda
suficientes para lidar com o novo tráfego. A fim de melhor explorar a
capacidade disponível, diferentemente de outras estratégias de roteamento
conscientes da energia que funcionam ao nível dos fluxos de tráfego, em [113] a alternativa
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
a seleção de caminho é realizada no nível por pacote. Isso permite
definir uma estratégia de divisão de tráfego mais precisa, o que torna
mais eficiente o uso da largura de banda disponível, aumentando assim
o número de links desligados.
Os autores em [114] propõem uma arquitetura que combina SDN
com TE baseado em SR. Uma implementação de código aberto do SR-
MPLS é fornecida juntamente com a realização de um plano de controle
SDN que lida com o cálculo dos caminhos SR ótimos na rede. Os
autores começam a implementar uma heurística básica de TE, que
resolve de maneira aproximada o problema de atribuição de fluxo. Este
último permite que o congestionamento geral da rede seja minimizado.
Este primeiro procedimento também é usado como controle de admissão
para a próxima fase onde os caminhos admitidos são mapeados em
caminhos SR usando uma heurística de atribuição (que foi descrita
extensivamente em [15] - Seção IV-E). A avaliação de desempenho
analisa a distribuição dos comprimentos dos caminhos comparando os
caminhos TE com os caminhos mais curtos e a distribuição dos
comprimentos das listas de segmentos, mostrando assim que a maioria
dos caminhos pode ser implementada usando 1 ou 2 SIDs. Todo o
código desenvolvido é open source e está disponível em [181]
Uma análise teórica da complexidade computacional dos problemas
de Engenharia de Tráfego em redes habilitadas para Segment Routing
é fornecida em [115]. Dois problemas diferentes de TE são considerados:
i) a maximização do throughput e ii) a minimização da carga máxima do
enlace. Em primeiro lugar, considera-se o paradigma General Segment
Routing. Nesse cenário, os segmentos não são restritos a seguir os
caminhos mais curtos, mas podem representar qualquer caminho
complexo (possível). A resolução de ambos os problemas de TE
mencionados resulta ser NP-difícil. Essa constatação fornece uma
fundamentação teórica para o motivo pelo qual, no Roteamento de
Segmentos, os caminhos mais curtos são considerados para cada
segmento. Em seguida, estuda-se a complexidade dos problemas de TE
para o caso de Roteamento de Segmentos com o caminho mais curto.
Um resultado interessante desta análise é que, quando o número de
segmentos a serem usados para cada lista de segmentos é fixo, o
problema de minimizar a utilização máxima do enlace pode ser resolvido
em tempo polinomial fraco. Apesar disso, quando o comprimento das
listas de segmentos é apenas limitado superiormente (não fixo), os
problemas de TE investigados caem novamente na classe NP-difícil.
Em [116], os autores tratam de soluções de projeto de TE baseadas
em SR para a alocação ótima de demandas de tráfego usando uma
abordagem com reconhecimento de ECMP. Os autores propõem duas
soluções ótimas para otimização online e offline usando uma alocação
de 2 segmentos, ou seja, limitando o comprimento das Listas de
Segmentos a dois SIDs. Este último consiste no cálculo para cada fluxo
da lista de segmentos ótimos de dois segmentos com o objetivo de
minimizar o congestionamento geral da rede. A ideia-chave deste
trabalho é minimizar a utilização do link no pior caso, considerando o
encaminhamento do ECMP no caso offline. Já no caso on-line, os
valores de divisão de tráfego são calculados adequadamente também
para minimizar as rejeições de solicitações. A avaliação de desempenho
mostra que o problema de roteamento de n segmentos (“Problema de
Fluxo de Multicommodities”), ou seja, sem restrições no comprimento
das Listas de Segmentos, é apenas um pouco melhor do que o problema
de roteamento de 2 segmentos, mas a complexidade computacional é
maior devido a mais graus de liberdade .
16
[117] propõe uma extensão dos modelos apresentados em [116]. Em
particular, os autores propõem os 3 segmentos para warding
demonstrando que o definido em [116], usando dois segmentos, não é
suficiente para determinar os caminhos ótimos e leva ao desperdício de
largura de banda.
DEFO (Declarative and Expressive Forwarding Optimizer) é uma
arquitetura de duas camadas, descrita em [118], que é realizada sobre
uma rede de comunicação física, visando fornecer uma infraestrutura de
rede flexível e altamente programável. Na parte inferior da arquitetura
há uma camada de conectividade, que se encarrega de fornecer
caminhos padrão entre os roteadores da rede. No DEFO, a camada de
conectividade é representada por um Interior Gateway Protocol (IGP).
Por meio de uma camada de otimização, os caminhos de roteamento
de um subconjunto de demandas de tráfego são desviados pelo
comportamento padrão, fornecido pela camada de conectividade, e são
direcionados através de um conjunto de caminhos otimizados. O DEFO
explora a flexibilidade do Segment Routing para implementar a camada
de otimização e configurar caminhos otimizados sobre os caminhos de
roteamento subjacentes. O Provedor de Serviço pode programar a rede,
alavancando assim uma interface de alto nível que permite definir
objetivos específicos de rede através do uso de Domain Specific
Languages (DSL). O DEFO possibilita que um operador de rede defina
várias funções de custo a serem otimizadas. No caso básico, denominado
ÿ
“AIJClassic Traffic Engineering” Aÿ ÿI, a utilização máxima do enlace é
minimizada; no caso Aÿ ÿI, o objetivo da função 'AIJTactical Traffic
ÿ
combinação da utilização máxima do enlace eEngineering'
o número deé caminhos
uma
modificados. Uma vez especificado o objetivo, o DEFO inicia o cálculo
dos caminhos otimizados, executando um algoritmo que explora os
conceitos de roteamento de ponto médio (MR) e programação de
restrições (CP).
[119] enfrenta o problema de reagir rapidamente a mudanças
repentinas de tráfego. De fato, esses eventos inesperados, que ocorrem
em baixa escala de tempo, podem criar congestionamento temporário
nos links, degradando assim o desempenho da rede. Soluções clássicas
para este problema são baseadas em modelos MILP ou Programação
de Restrições, veja [116] e [118]. Infelizmente, essas abordagens sofrem
com o alto tempo de computação, pois funcionam em uma escala de
tempo de segundos ou minutos, fornecendo estratégias de roteamento
TE que, em média, permitem a redução do congestionamento da rede,
mas que podem incorrer em sobrecarga no link devido a picos repentinos de tráfego .
Por esta razão, em [119] os autores apresentam um algoritmo que visa
mitigar o congestionamento do link sob uma restrição de tempo difícil. A
solução proposta explora o SR para redirecionar um subconjunto de
fluxos de forma rápida e flexível, a fim de diminuir a utilização máxima
do link. A restrição de tempo é considerada sob duas perspectivas
diferentes: i) é considerada diretamente como uma restrição rígida
durante a execução do algoritmo, ou seja, é uma condição de término,
e ii) a estratégia de roteamento selecionada deve ser a mais próxima
possível da restrição de tempo. o atual para minimizar o número de
reconfigurações necessárias para fazê-lo funcionar. Esses dois requisitos
são atendidos simultaneamente pela proposição de uma heurística
baseada em Busca Local (LS), que toma como entrada uma solução
inicial e vai iterativamente dessa solução para outra, aplicando mudanças
locais chamadas de movimentos, até que um critério de parada seja
atendido ( por exemplo, a solução é boa o suficiente, ou um limite de
tempo). Os resultados mostram que o algoritmo proposto supera o MILP
ou Constraint Program-
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
heurística baseada em ming, permitindo uma redução significativa do
congestionamento da rede com tempos de execução inferiores a 1 segundo.e implementa um encaminhamento hop-by-hop. Finalmente, o terceiro é
A variável Segment Routing Path é introduzida em [120] com o
objetivo de reduzir o espaço de memória e o tempo de computação para
formular e resolver problemas de TE em redes SR.
De fato, enquanto o espaço de memória necessário para instanciar
formulações clássicas de problemas de TE com base em variáveis de
links, caminhos ou nós não se adapta bem ao tamanho da rede
considerada e com o número de demandas a serem roteadas, as
variáveis de caminho SR prometem aumentar a eficiência na resolução
do problema. As variáveis SR Path são baseadas no conceito de
Forwarding Graph (FG). Um FG é um gráfico acíclico direto (DAG) que
se origina de um nó s e termina em um nó sorvedouro t. O caminho
seguido por uma demanda na rede é codificado como uma sequência de
FGs, e essa sequência é armazenada em uma variável de caminho SR.
Conjuntos esparsos baseados em array são usados para implementar
variáveis de caminho SR. Uma abordagem Large Neighborhood Search
é usada para calcular caminhos otimizados para as demandas.
A idéia é melhorar iterativamente a melhor solução até agora tentando
reatribuir o valor de um subconjunto de variáveis de caminho SR,
relacionadas a demandas que são críticas (por exemplo, todas as que
estão atualmente roteadas pelo link mais carregado). [121] investiga o
problema de migrar uma rede IP para uma rede totalmente habilitada
para SR. A ideia é que o processo de atualização do sistema de
roteadores IP para habilitar os recursos de SR seja realizado de forma
incremental para reduzir a chance de introduzir possíveis erros de
configuração ou causar a indisponibilidade do serviço. Para fazer isso, o
Segment Routing Domain (SRD) é definido como o subconjunto de nós
capazes de SR.
Dependendo se o SRD é um conjunto conectado ou não, dois modelos
diferentes são propostos: SRD Único ou SRD Múltiplo. Duas vantagens
principais do modelo S-SRD são que ele limita o número de estados de
fluxo a serem mantidos nas bordas do SRD, e o comprimento médio da
lista de segmentos é restrito. Como principal desvantagem existe uma
diminuição potencial na flexibilidade na definição de caminhos de rede.
Pelo contrário, o M-SRD permite que caminhos mais complexos sejam
definidos ao custo de ter um maior número de estados de fluxo e um
maior comprimento médio de lista de segmentos. O problema de Projeto
de Domínio de Roteamento de Segmentos é formulado como um ILP,
onde o objetivo principal é maximizar as oportunidades de Engenharia
de Tráfego, ou seja, a identificação de um subconjunto de nós, de um
determinado tamanho, a serem atualizados com capacidades de SR, de
modo que o maior flexibilidade é alcançada no balanceamento da carga
dos links na rede. A formulação proposta é capaz de capturar modelos S-
SRD e M-SRD. O trabalho compartilha vários princípios de design com
outros trabalhos relatados nesta pesquisa, por exemplo, considera
implantações incrementais de SR e trata da codificação com
reconhecimento de caminho da lista de segmentos para garantir que o
caminho do SR seguirá exatamente o hop-by-hop caminho decidido pela
heurística TE. Com relação a outros trabalhos, os autores também
propõem uma solução de encaminhamento flexível, em que os pacotes
pertencentes ao mesmo fluxo podem cruzar a rede por diferentes
caminhos. [122] propõe modelos ILP e heurísticas para aplicações TE
em redes baseadas em SR. Três modelos ILP são propostos e são
utilizados apenas como referência para as heurísticas devido à sua
alta complexidade computacional. O primeiro é capaz de
17
aproveitando o encaminhamento ECMP, o segundo calcula rotas únicas
capaz de alavancar toda a capacidade do Segment Routing. Uma
heurística foi implementada, pois algumas instâncias dos modelos ILP
requerem muito tempo para serem resolvidas. A heurística calcula uma
rota única para cada fluxo e tenta manter a utilização total e máxima da
rede o mais baixa possível. Além disso, é capaz de garantir que o valor
máximo da profundidade da lista de segmentos não seja excedido. [123]
propõe uma solução de TE para computação de caminhos que,
aproveitando no máximo três rótulos, é capaz de otimizar os recursos
do link e evitar congestionamentos na rede. Em primeiro lugar, o
controlador SDN aborda o problema de calcular corretamente os pesos
do protocolo IGP Link State usando algoritmos evolucionários. Em
seguida, a distribuição do tráfego é calculada por meio de Divisão de
Fluxo Distribuído Exponencialmente Ponderado (DEFT) ou Divisão de
Fluxo Exponencial de Penalização (PEFT), que atribui os fluxos a um
próximo salto com uma probabilidade que diminui exponencialmente com
o comprimento extra do caminho ( em relação ao caminho mais curto).
O SR é usado para obter desvios e implementar a divisão de tráfego. A
avaliação de desempenho mostra que a solução TE oferece um menor
congestionamento em relação ao OSPF/ECMP com configurações
otimizadas e é capaz de usar todos os links disponíveis.
A flexibilidade do SR na seleção de caminhos, juntamente com o
maior throughput fornecido pelo Multi Path TCP (MPTCP), são explorados
em [124] a fim de otimizar o throughput para grandes fluxos e lidar com
o crescimento explosivo do tráfego multimídia em redes 5G . A arquitetura
proposta utiliza um plano de controle centralizado, com um controlador
central responsável por gerenciar a Qualidade da Experiência de cada
conexão MCTCP. Em particular, o controlador central encontra vários
caminhos para cada conexão, verifica os requisitos de largura de banda
e instala regras de fluxo específicas nos nós de entrada da rede 5G
considerada. Quando uma nova conexão MPTCP é estabelecida, o
controlador deve encontrar um caminho para cada um dos subfluxos
pertencentes a essa conexão. Para cada subfluxo, ele verifica primeiro o
caminho do fluxo e o banco de dados de recursos, a fim de verificar se
já existe um caminho pré-calculado com largura de banda suficiente para
suportar o novo subfluxo. Se esta verificação falhar, o controlador calcula
um novo caminho, codifica-o em uma lista de segmentos e instala uma
nova entrada de fluxo no switch de ingresso. O algoritmo usado para
calcular os novos caminhos, denominado QoE-Centric Multipath Routing
Algorithm (QoMRA), tenta encontrar vários caminhos disjuntos
considerando os requisitos de QoE. [125] propõe o uso do Multi Path
TCP (MPTCP) em conjunto com o SR-MPLS para maximizar o throughput
dos fluxos de tráfego em uma rede de Data Center. O MPTCP permite
que uma única conexão seja dividida em vários caminhos, aumentando
assim a taxa de transferência total. As soluções MPTCP baseadas em
SDN são consideradas pelos autores para obter controle de granularidade
fina sobre conexões TCP. No entanto, isso aumenta drasticamente o
número geral de fluxos de tráfego que precisam ser armazenados nos
dispositivos, causando problemas de escalabilidade. O SR é usado para
reduzir o número de regras de fluxo necessárias para direcionar as
conexões TCP únicas em caminhos disjuntos e economizar espaço
precioso na Memória Endereçável de Conteúdo Ternary (TCAM) do
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
dispositivos. A arquitetura prevê uma abordagem reativa para alocação de
fluxo: cada vez que um novo subfluxo é “gerado” pelo MPTCP, um Packet-In
é enviado ao controlador SDN que aloca um novo caminho disjunto sempre
que possível, e então instala as regras de fluxo necessárias para suportar este
subfluxo nos dispositivos de borda. O SR permite que o estado no dispositivo
principal seja reduzido. Infelizmente, no artigo não está claro como os autores
podem evitar a explosão do estado na borda da rede devido às condições de
correspondência na camada de transporte.
Em [126], ELEANOR, uma aplicação norte para o controlador OpenDayLight
(ODL) Software Defined Network (SDN) é apresentada. ELEANOR considera
um plano de dados MPLS-SR, onde uma restrição de Profundidade Máxima
de Empilhamento (MSD), ou seja, um limite superior no número de sids que
podem ser empilhados em uma lista de segmentos, deve ser considerada. Os
principais componentes do ELEANOR são: i) um módulo de cálculo de
caminho, e ii) um módulo de otimização da pilha de rótulos. Quando uma nova
solicitação chega ao controlador, ele primeiro encontra um caminho adequado
para atender a requisitos específicos de QoS (largura de banda, atraso etc.),
então o SL apropriado é produzido.
Em [127], os autores propõem dois algoritmos de roteamento baseados em
SR para realizar aplicações TE em redes SDN. Esses algoritmos buscam uma
seleção apropriada dos pesos dos links para otimizar os custos de caminho e
balancear a carga nos links. Isto é obtido através do algoritmo de otimização
de enxame de partículas de objetivo múltiplo (MOPSO). Duas funções objetivo
são usadas para medir o custo do caminho e o balanceamento de carga,
respectivamente. Segundo os autores, seus algoritmos não apenas reduzem
o custo dos caminhos, equilibram melhor a carga da rede e diminuem a taxa
máxima de utilização do link, mas também podem melhorar a taxa de satisfação o objetivo principal de uma estratégia de TE é encontrar uma configuração de
em relação ao caminho mais curto primeiro (SPF), caminho mais curto e mais
largo (SWP), caminho mais curto (WSP), algoritmo de roteamento de
interferência mínima (MIRA) e algoritmo de Lee. [128] propõe a restrição
Bounded Stretch para aumentar a resolução do problema SR-TE. O Bounded
Stretch é usado para reduzir o conjunto de candidatos a nós intermediários,
que são selecionados durante a construção do SL. Isso permite que o
espaço das soluções seja reduzido. A ideia de alto nível do Bounded Stretch é
que quando um nó intermediário está muito longe de um nó de origem i para
um nó de destino j então este nó não deve ser considerado como candidato.
A seleção é obtida comparando o comprimento dos caminhos intermediários
mais curtos com o comprimento dos caminhos de ponta a ponta escalados por
uma determinada constante. Os autores demonstram através de experimentos
que a restrição ajuda a reduzir o tempo de computação ao custo de ter uma
utilização um pouco maior sobre os links.
Em [129], o problema de TE com restrição de nó é definido e analisado, e
SR é reivindicado como uma tecnologia capacitadora para tais estratégias de
roteamento. Este problema consiste na otimização de um destes dois objetivos:
maximizar o throughput da rede ou minimizar o congestionamento máximo.
Diferentes estratégias de roteamento são consideradas. No caso mais geral,
os caminhos de ponta a ponta são restritos a passar por um conjunto de
pontos médios, deixando a liberdade de escolher qualquer caminho entre dois
pontos médios. Este problema é formulado e provado ser NP-difícil. Em
seguida, a região de viabilidade é limitada forçando o caminho entre dois
pontos médios a ser o mais curto.
18
A formulação do problema derivado acaba por ser resolvida em tempo
polinomial fraco. De qualquer forma, como as soluções do problema anterior
podem conter loops de roteamento (o mesmo link é cruzado duas vezes), os
autores de [129] também consideram uma variante em que a solução é restrita
a selecionar apenas caminhos fim a fim acíclicos. Esta última variante do
problema de TE com restrição de nó se mostra NP-difícil. Outra contribuição
de [129] é a proposição do conceito de centralidade de fluxo como parâmetro
de projeto para selecionar os pontos médios mais adequados.
A centralidade do fluxo é expressa como a porcentagem máxima de tráfego
que pode passar por um nó. Esse conceito é aprimorado ainda mais pela
definição da centralidade do fluxo de grupo, que é uma generalização da
centralidade do fluxo sobre um conjunto de N pontos médios.
O trabalho em [130] propõe uma solução de engenharia de tráfego
(computação de caminhos e alocação de largura de banda) para uma rede IP/
SR híbrida capaz de maximizar uma função de utilidade refletindo a satisfação
do usuário. A satisfação do usuário é calculada como uma função logarítmica
da largura de banda atribuída aos fluxos. Os caminhos de roteamento são
restritos a serem os mais curtos no domínio IP, enquanto os roteadores SR
podem escolher entre um conjunto de caminhos permitidos no domínio SR.
Após a definição do problema de otimização, um algoritmo iterativo de duas
etapas é proposto: a cada etapa da iteração, os pesos dos links dentro do
domínio SR são atualizados. Duas suposições principais são feitas: i) cada
fluxo pode ser encaminhado em um único caminho, e i) um pacote não pode
cruzar o domínio SR mais de uma vez.
Independentemente do objetivo da otimização e das restrições consideradas,
roteamento para um determinado conjunto de demandas de entrada. Aqui
destacamos algumas das diferenças entre os trabalhos de pesquisa
relacionados a RS classificados na categoria Engenharia de Tráfego.
Especificamente, apontamos cinco critérios diferentes para compará-los: i) o
tipo de abordagem (baseada em otimização, baseada em heurística, ambas),
ii) o nível de granularidade da demanda (Origem Destino ou Ingress-Egress),
iii) a estratégia de computação do caminho , iv) como o roteamento TE é
traduzido em um conjunto de SLs, ev) a política de divisão de tráfego (SL único
ou SLs múltiplos).
A maioria dos trabalhos de Engenharia de Tráfego com SR propõe um
algoritmo heurístico para determinar um conjunto de caminhos para satisfazer
um determinado objetivo. Somente em [115], [116], [121], [122], [128] e [130]
uma formulação do problema também é apresentada. Outra diferença
interessante entre os trabalhos de pesquisa em Engenharia de Tráfego é o
modelo considerado para descrever as demandas de tráfego. De fato, enquanto
[114], [129], [118], [119], [124], [125], [126] e [128] consideram um modelo
Origem-Destino (OD), onde múltiplas demandas podem entram e saem da
rede a partir do mesmo par de nós Ingress-Egress (IE), todos os outros
assumem um modelo IE (há uma única demanda entre cada par de nós IE
que é representativa da agregação de muitos fluxos OD).
Isso afeta tanto a flexibilidade da solução, permitindo uma otimização mais
fina, quanto a complexidade dos algoritmos, uma vez que precisam lidar com
um número maior de variáveis.
Diferentes estratégias são usadas para criar os caminhos de ponta a ponta.
Alguns deles são baseados na definição de parâmetros capazes de capturar
o status atual da rede. Os caminhos são então selecionados de acordo com
uma regra de menor custo. Como exemplo, em [109] são definidos a
“criticidade” do link e o índice de congestionamento do link,
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
TABELA VIII
CLASSIFICAÇÃO DAS REFERÊNCIAS RELACIONADAS A
RECUPERAÇÃO DE FALHA .
Falha de nó [132],[133],[134],[135],[136],[137] [131],[132],[133],
[135],[136],[137] [138 ],[139]
Falha no link
[114] define o conceito de tempo de cruzamento de rede, [129] reduz o
espaço de caminho viável impondo que apenas nós com alta centralidade
podem ser usados como pontos médios. Em [130] o roteamento de caminho
único é considerado, e a função objetivo do problema de otimização é a
satisfação do usuário calculada como uma função logarítmica da largura de
banda alocada aos fluxos do usuário. Além disso, também em [124] a
estratégia de busca de caminho é baseada na criticidade do enlace, enquanto
[125] explora o conceito de índice de atraso. Os demais trabalhos utilizam
técnicas mais sofisticadas, como programação de restrições ([118], [120]),
busca baseada em ILP ([112], [113], [116], [117], [121], heurística de busca
local ( [119]) e algoritmos restritos de caminho mais curto ([126]).
Outra diferença interessante das estratégias de seleção de caminhos
adotadas pelos trabalhos da categoria Engenharia de Tráfego está relacionada
à forma como geram os SLs associados ao determinado caminho.
Especificamente, duas abordagens diferentes são geralmente usadas: i) o
caminho é encontrado e então codificado em um SL ([112], [121], [122], [124]–
[126], ou ii) o caminho é construído diretamente como SL ([116]–[120], [123],
[128], [129]).
A comparação final que propomos está relacionada à possibilidade de
dividir as demandas de tráfego em vários SLs.
Esta opção, que é permitida pela configuração adequada das políticas SR, é
explicitamente utilizada nos algoritmos descritos em [116], [117], [121], [124],
[125], [182]. Claramente, ter a possibilidade de dividir o mesmo fluxo em
vários SLs aumenta a flexibilidade da estratégia de roteamento ao custo de
aumentar as informações a serem armazenadas nos nós de head end, onde
as políticas de SR são instaladas.
C. Recuperação de Falha
Nove trabalhos de pesquisa sobre SR para recuperação de falhas e
resiliência de rede foram publicados nos últimos anos.
A solução proposta pode ser classificada de acordo com o tipo de falha da
qual eles são capazes de se recuperar:, ielink ou falhas de nó.
A Tabela VIII mostra a classificação dos artigos abordados. Nos parágrafos
seguintes apresentamos uma breve visão geral das referências classificadas
como trabalhos relacionados com a Recuperação de Falhas.
[131] trata do encaminhamento de SR resiliente. Em particular, os autores
se concentram em soluções de failover rápido estático para roteamento de
segmento, não exigindo nenhuma interação com o plano de controle.
O algoritmo proposto, referido como Topology Independent Multi-Failure
Alternate (TI-MFA), é uma melhoria do Topology Independent Loop Free
Alternate (TI-LFA), descrito em [45] e elaborado na Seção III-A. O TI MFA
tem garantias de desempenho interessantes e também é resiliente a várias
falhas, enquanto o failover rápido de SR tradicional baseado em TI-LFA pode
funcionar apenas com um número limitado de falhas. Em primeiro lugar, os
autores demonstram que o TI-LFA faz loops indefinidamente também para
duas falhas de link. Então, um robusto, mas
19
Apresenta-se brevemente soluções ineficientes que pré-computam regras de
roteamento considerando destinos, falhas de incidentes e portas de entrada
dos pacotes. Mesmo que essa solução possa fornecer melhores garantias de
resiliência, ela apresenta algumas ineficiências (em termos de comprimentos
de caminho), mesmo que ocorra apenas uma falha de link.
Por fim, os autores apresentam sua solução que propõe basicamente
armazenar as falhas já atingidas no cabeçalho do pacote e, cada vez que
uma nova falha é enfrentada na rede, a lista de segmentos é recalculada
usando as entradas da tabela local pré-computadas e o estado armazenado
nos pacotes.
A duplicação de tráfego através de caminhos disjuntos é explorada em
[132]. Em particular, os autores aproveitam o SRv6 para realizar um serviço
de duplicação de tráfego que pode garantir um esquema de proteção 1+1
através do uso de caminhos disjuntos. A principal diferença de outros
mecanismos de proteção é que com proteção 1+1 ambos os canais estão
ativos e os dados são enviados por ambos os caminhos. Os autores usam o
comportamento de espelhamento no kernel do Linux para realizar a duplicação
de tráfego. O trabalho baseia-se nos resultados de [183], em particular,
aproveita a implementação Linux do SRv6. Em seguida, os autores propõem
um algoritmo capaz de computar caminhos disjuntos com a menor latência e
que pode ser implementado com um número k de segmentos (eles
estabelecem um limite superior em seu número e usam apenas segmentos
de nós).
[133] baseia-se em [132] com a introdução de caminhos robustamente
disjuntos. Os autores construíram, estendendo a teoria de roteamento e
alavancando a síntese de configuração, um compilador automatizado que é
proativo, rápido e autorrecuperável (sem necessidade de intervenção externa):
ele calcula pares de caminhos disjuntos para determinadas origens e
roteadores de destino, que são robustos em a maneira como eles permanecem
desconexos mesmo após um conjunto de falhas.
Isto é conseguido sem necessidade de qualquer intervenção graças à
tecnologia SR. De fato, SR permite que sequências de segmentos sejam
escritas, que mapeiam para diferentes caminhos disjuntos mesmo quando há
mudanças topológicas. Finalmente, aproveitando os resultados de [132],
Aubry et al. adicionado ao compilador a capacidade de limitar o número de
segmentos (ou seja, problema de codificação de caminho) e caminhos de
computação que não degradam o desempenho do plano de dados
(encontrando caminhos SR de baixa latência - abordando também aspectos TE).
Em [134], Hao et al. propor um modelo de programação linear para
otimizar a restauração em redes baseadas em SR. A ideia-chave da
restauração otimizada é compartilhar a largura de banda restante
adequadamente quando ocorrerem várias falhas. Isso é resolvido através de
uma configuração ótima dos segmentos iniciais, conhecendo antecipadamente
a matriz de tráfego e a topologia da rede. Em particular, os autores
desenvolvem um algoritmo dual primal eficiente, que pode lidar com falhas
de link único e falhas de vários links lógicos ao mesmo tempo (incluindo
falhas de nó). Além disso, com um esquema de arredondamento aleatório
simples, eles também podem levar em consideração o encaminhamento de
ECMP na rede.
Uma implementação logicamente centralizada do plano de controle SR
(baseado em SDN) é aproveitada em [135], [136] e [137].
Eles descrevem um método para recuperar a rede de falhas de link ou nó
dinamicamente. O mecanismo de failover prevê uma tabela de failover para
cada interface do nó e, quando uma porta cai automaticamente, a tabela
secundária relacionada é usada para implementar um caminho de backup
sem loop desde o ponto de falha até o nó de destino. Em primeiro lugar, o nó
pops todos
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 20

TABELA IX
os rótulos na lista de segmentos, exceto o último rótulo (que representa
CLASSIFICAÇÃO DAS REFERÊNCIAS RELACIONADAS A
o destino final), e então o processamento do pacote é passado para a
tabela de failover correta. Os autores fornecem uma implementação ARQUITETURAS CENTRALMENTE CONTROLADAS .

baseada no protocolo OpenFlow (OF) aproveitando o recurso de

conceito SR [146],[147],[151],[154]
tabelas OF Group para ações de monitoramento e backup. ([184] plano de dados SR [140],[141],[142],[143]
SR-MPLS
explica como usar OF Fast-Failover Group). Em [137] e em [136], o [144],[145],[150],[152]
SRv6 [4],[ 148],[149],[153]
algoritmo de codificação de caminho SR pode levar a listas de
Sul Fluxo aberto [140],[144],[145],[147]
segmentos mais longas do que a gerada pelo algoritmo proposto em PCEP [141],[142],[143],[150]
Interface
[135]. Em geral, é necessário um número baixo de rótulos para Outro [4],[150],[152] ]
implementar a maioria dos caminhos de backup. [137] e [136] IP/MPLS [141],[142],[144]
Plano de
[145],[150] [4],
implementam um desvio simples do nó detectando a falha para o dados subjacente
[140],[146],[147],[148] [149],
IP/SDN
próximo salto ou o próximo salto. [153]

Os mesmos autores de [108] propõem uma implementação de

SR para se recuperar de falhas de rede, existem apenas dois trabalhos
código aberto do SRv6 TI-LFA em [138] usando o framework Berkeley
([131], [139]) que visam lidar com falhas múltiplas. Enquanto o primeiro
Packet Filter extensível (um artigo completo explicando conceitos de
é mais focado em aspectos de implementação, o segundo é mais
eBPF no kernel Linux é relatado aqui [185]).
teórico e focado na definição de algoritmos para encontrar estratégias
A solução de reencaminhamento rápido é implementada como um
de reencaminhamento sem loops.
programa BPF personalizado compilado em tempo real e anexado a
Nem todos os outros mecanismos de recuperação são declarados
uma rota. Em particular, um programa é carregado no kernel para
explicitamente como capazes de lidar com esse cenário de falha.
cada link a ser protegido. A lista de reparo associada à rota é
Outra diferença interessante entre as soluções de recuperação de
computada pelo plano de controle e então codificada no programa
falhas é o método em que se baseiam. Especificamente, a maioria
eBPF, que é posteriormente compilado e instalado no kernel. A
deles ([131], [135]–[139]) é baseada em uma estratégia de
solução foi complementada com uma arquitetura robusta de detecção
reencaminhamento, ou seja, os pacotes são desviados por um
de falhas, que implementa o modo de eco Bidirectional Forwarding
caminho alternativo pré-computado quando um link é declarado como
Detection (BFD) [186] usando SRv6. Em particular, a arquitetura prevê
falho. Por outro lado, [132], [133] são baseados em um esquema de
para cada link um nó mestre, enviando periodicamente sondas que
duplicação de tráfego. Sem entrar em detalhes, a principal diferença
podem ativar o mecanismo de reencaminhamento rápido descrito até
entre [131], [139] e [135]–[138] está no número de falhas simultâneas
agora. As sondas são enviadas com uma lista de segmentos especial
das quais eles permitem a recuperação.
que permite o redirecionamento do tráfego para um programa BPF
especial (escravo BPF) no peer remoto e o loop de volta das sondas
para o mestre. D. Arquiteturas Controladas Centralmente
O escravo BPF, rodando no peer remoto, manipula os pacotes prob e A definição de Arquiteturas Centralmente Controladas explorando
pode ativar o mecanismo SRv6 TI-LFA para seu lado do link. O mestre a arquitetura SR tem sido amplamente investigada na literatura,
usa o valor do comprimento do tipo SRv6 para inserir números de resultando em dezesseis trabalhos diferentes. A solução proposta foi
sequência e carimbos de data/hora, que também permitem que o peer classificada com base em três aspectos diferentes, conforme relatado
remoto detecte falhas. A avaliação no trabalho considera o número de na Tabela IX. Considerando o plano de dados SR, um grande número
falsos positivos devido a uma CPU sobrecarregada, a implementação de trabalhos utiliza o plano de dados SR-MPLS enquanto apenas três
do BPF dos nós pares reduz os falsos positivos quase a zero, mesmo trabalhos são baseados em SRv6. Além disso, alguns trabalhos não
quando a detecção de falhas é inferior a 10ms. Em vez disso, o nó consideram explicitamente uma implementação específica do SR,
mestre ainda é amplamente afetado pela sobrecarga da CPU, pois mas simplesmente exploram a possibilidade do SR de inserir o estado
usa um processo de espaço do usuário para enviar as sondagens. do fluxo no cabeçalho do pacote. Outro aspecto utilizado para
[139] estudam o problema de definir um esquema de caminho de classificar os trabalhos de pesquisa é o protocolo utilizado para a
backup que seja robusto à presença de múltiplas falhas de link. comunicação Southbound entre os dispositivos de rede e o controlador
central. Os protocolos considerados são Openflow, PCEP ou outros.
Especificamente, as principais contribuições são: i) a introdução de
O último componente que diferencia as arquiteturas propostas é a
um algoritmo de reencaminhamento rápido em tempo polinomial que rede underlay. Especificamente, os dispositivos de rede podem ser
permite definir um esquema de caminho de backup para resiliência roteadores IP/MPLS ou switches Openflow. A seguir, fornecemos uma
sob k falhas simultâneas de link, em particular no caso de uma breve visão geral das referências classificadas como obras relacionadas
topologia de hipercubo, e ii) a formalização, por meio de uma a Arquiteturas Centralmente Controladas. [140] implementa uma
formulação ILP, do problema de definir um esquema de caminho de arquitetura SR-MPLS baseada em SDN em uma rede óptica de
backup que maximize o número de falhas de enlace simultâneas pacotes multicamada. Em particular, os autores demonstram desvio
permitidas em grafos gerais. óptico em variações de carga de tráfego sem exigir operações GMPLS.
Façamos uma comparação entre os trabalhos classificados na O controlador RYU SDN [187] foi estendido para controlar a
categoria de Recuperação de Falhas. [138] propõe uma implementação configuração da pilha de rótulos nos nós de borda (baseado em Open
do mecanismo TI-LFA [45] em um nó SRv6 baseado em Linux. [131] vSwitch). O controlador SDN utiliza OF 1.3 para programar os
estende o mecanismo TI-LFA adicionando a capacidade de lidar com dispositivos de borda. O Open vSwitch foi modificado para aumentar
várias falhas. Entre as soluções baseadas em a profundidade máxima da pilha MPLS
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
de 3 a 15 etiquetas. O protocolo OF também foi modificado para enviar
todos os rótulos necessários como uma única entrada de fluxo e com uma
única ação. Os dispositivos ROADM (Comercial Reconfigurable Optical Add-
Drop Multiplexer) têm sido usados para fornecer um desvio óptico entre nós
e fornecer caminhos alternativos durante o cálculo do caminho. Na avaliação
de desempenho, os autores avaliam por meio de emulação a influência da
deep stack de 15 rótulos, avaliando o tempo de configuração dos fluxos e o
encaminhamento de pacotes nos dispositivos. Este último não é influenciado, foram registradas e o tempo de recuperação ficou em torno de 170ms.
enquanto o tempo de configuração é quase o triplo.
Mais tarde em [141], o SR foi implementado em uma rede multicamada
usando uma arquitetura PCE em vez de SDN/OF. Neste cenário, os nós
consistem em roteadores IP/MPLS disponíveis comercialmente e o SR
Controller é uma versão estendida de um PCE.
plano de controle com estado. Extensões ao protocolo PCE permitem que
um PCE centralizado controle a configuração de empilhamento de etiquetas.
O PCC (cliente de PC - dispositivos) usa o valor de comprimento de tipo
SR-PCE-CAPABILITY para especificar a capacidade de lidar com Caminhos
comutados de rótulo habilitados para SR e a capacidade de executar
computação de SR. O Explicit Routing Object (ERO) realizado na mensagem nos princípios SR-MPLS.
Path Computation Reply contém a lista de SIDs computados e/ou o Node
ou Adjacency Identifier dependendo do tipo de SID. No dispositivo, o agente
coleta as informações derivadas do protocolo IGP e configura as entradas
de caminho mais curto relacionadas e os rótulos SID. Quando uma nova
mensagem de repetição do PC é recebida, a pilha de etiquetas está
configurada corretamente. Além disso, esta implementação de SR usando
PCE é capaz de realizar reencaminhamento dinâmico de pacotes (com
recursos de bypass óptico), impondo diferentes listas de segmentos no nó
de origem, sem qualquer protocolo de sinalização e sem perda de pacotes.
Em [142] Segment Routing é proposto como uma solução para realizar
Network Service Chaining (NSC) em um cenário de rede metro-core, onde
as requisições da cadeia de serviço são representadas pelos chamados
microfluxos, ou seja, um grande número de bits baixos ou médios -taxa de
fluxo. Nesse cenário, as soluções clássicas baseadas em MPLS ou SDN
puro falham devido a problemas de escalabilidade. Ao contrário, o SR move
o estado do fluxo para o cabeçalho do pacote, reduzindo os custos de
configuração (e tempo) para a instalação da regra de encapsulamento no
ponto de ingresso da rede (aquele usado para adicionar a lista de segmentos para o ISP mais adequado, e iii) os pontos de inflexão de roteamento que
a cada pacote da rede). fluxo considerado). Com base nesta consideração,
[142] descreve um SR Path Computation Element (SR-PCE) que é
responsável por orquestrar a configuração/liberação/modificação da
conexão, e é composto por dois módulos principais: i) o elemento de
computação de fluxo, tendo o objetivo de encontrar um caminho com
recursos disponíveis para atender um micro fluxo e ii) a API de
direcionamento de fluxo que é responsável por instalar a regra de
encapsulamento SR no nó de ingresso. Uma avaliação experimental da
arquitetura proposta é proposta em [143]. [144] propõe uma arquitetura de
rede definida por software (SDN) baseada em SR que é capaz de realizar
balanceamento de carga entre rotas ECMP e não ECMP em redes
multicamadas, incluindo uma camada IP/MPLS sobre uma camada de rede
óptica.
Em particular, são descritas duas soluções: i) SR Centralizado; ii) SR pré-
configurado. O primeiro aproveita um controlador SDN para direcionar o
tráfego por caminhos alternativos em caso de falhas de rede.
Em vez disso, a segunda solução usa grupos de balanceamento de carga
OpenFlow para encaminhar ativamente o tráfego em várias rotas. Com
21
a segunda solução a camada de plano de dados pode reagir autonomamente
a uma deficiência da rede removendo a porta de saída com falha, enquanto
a primeira solução sempre requer a intervenção do controlador SDN, mas
os resultados são mais genéricos em relação à segunda. Ambas as
soluções enviam o SID do nó de destino e aproveitam os caminhos ECMP
disponíveis. A propriedade de recuperação da arquitetura foi validada
simulando falhas de rede. Segundo os autores, algumas perdas de pacotes
O projeto SPRING-OPEN [145] é um caso de uso ONOS [188], que
fornece uma implementação de SR baseada em SDN de código aberto.
Sua arquitetura é baseada em um plano de controle logicamente
centralizado, construído sobre o ONOS, e elimina drasticamente o Plano
de Controle IP/MPLS da rede. Papel
deste trabalho convergiu mais tarde no projeto Trellis [189], um tecido leaf-
spine baseado em SDN, construído usando hardware bare-metal, software
de código aberto dos projetos OCP [190] e ONOS, e OpenFlow-Data Plane
Abstraction (OF -DPA) [191], uma API aberta da Broadcom [192] para
programar ASICs de silício comercial. O tecido folha-espinha é baseado
No entanto, ele não implementa uma arquitetura SR completa, pois apenas
usa Node-SIDs significativos globais. Esses rótulos MPLS são configurados
estaticamente no plano de controle SDN e são usados para identificar
globalmente os switches ToR da malha, roteando o tráfego para eles
usando um único rótulo MPLS.
A fim de fornecer resiliência contra falhas de link e nó para Cloud Service
Provides (CSPs), uma infraestrutura de sobreposição realizada por meio de
Roteamento de Segmento e plano de controle de Rede Definida por
Software é proposta em [146]. A ideia principal da arquitetura proposta é
substituir a infraestrutura física dedicada que interliga os Data Centers de
um CSP, por uma rede overlay realizada em cima de uma infraestrutura
underlay, representada pela interconexão de várias redes de Provedores
de Serviços de Internet (ISP). O pré-requisito é a disponibilidade de
conexões multihomed para cada Data Center do CSP. Assim, os
componentes lógicos da infraestrutura overlay proposta incluem: i) um
controlador central que monitora o status da rede underlay e determina
novos caminhos em caso de falha, ii) os pontos de saída que são
responsáveis por rotear os fluxos de tráfego que saem de um Data Center
são nós especiais que gerenciam o roteamento entre dois Data Centers
distantes, utilizando encapsulamento SR. [147] propõe o uso de SR em
uma rede IP/SDN híbrida como uma técnica para mitigar o problema de
espaço de armazenamento limitado nas tabelas de fluxo de switches SDN.
O objetivo principal é usar SR para otimizar o uso das tabelas de fluxo e
capacidade do link. No cenário considerado, cada nó suporta as operações
OpenFlow e as operações normais de encaminhamento de IP. Quando um
pacote entra em um nó, ele é primeiro classificado para decidir por qual
pipeline ele deve ser direcionado e, em seguida, é processado de acordo.
As operações atribuídas ao pipeline IP normal são decididas usando um
protocolo de roteamento (por exemplo, OSPF). Alternativamente, o caminho
a ser seguido pelos fluxos de tráfego direcionados através do OpenFlow
Switching Layer (OFSL) é decidido pelo controlador SDN central. Para
limitar o número de entradas de fluxo a serem instaladas para configurar
um caminho, o SR é explorado. Desta forma, uma parte da informação do
estado de fluxo é movida do
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
a tabela de fluxo dos switches para o cabeçalho do pacote. Para inserir
as informações relacionadas ao SR, ou seja, a lista de segmentos, no
cabeçalho do pacote, [147] propõe o uso de campos não utilizados (ex.
tag VLAN ou campos opcionais).
Software Resolved Networks (SRNs) é uma nova arquitetura SDN
proposta recentemente para redes corporativas IPv6 [148][149]; mais
detalhes sobre a implementação são fornecidos na Seção V. A rede é
gerenciada por um controlador logicamente centralizado, que interage
com os hosts finais por meio de um protocolo DNS estendido: os
aplicativos podem incorporar requisitos de tráfego e/ou caminho em suas
solicitações, e o controlador é capaz de retornar o caminho apropriado
para os aplicativos que satisfaçam suas necessidades. O SRv6 é usado
como tecnologia de plano de dados para direcionar o tráfego em um
caminho específico de acordo com as políticas de rede. Cada componente Na primeira abordagem, a lista de segmentos já contém o caminho de
que pode ser alcançado pela rede é sempre referenciado por meio de
um nome DNS. O resolvedor de DNS padrão nos hosts é modificado
para interagir com o controlador da arquitetura. O SRN também fornece
um mecanismo para o registro dinâmico dos pontos finais. Dessa forma,
o banco de dados DNS pode ser atualizado corretamente e a resolução
de nomes pode ser realizada pelos clientes. As conexões são sempre
unidirecionais, portanto, é necessário estabelecer dois caminhos para
possibilitar a comunicação entre os terminais. Um segmento de ligação é
usado para implementar uma identificação de caminho e é
automaticamente traduzido em uma política SRv6 no nó de acesso. A
segmentação de caminhos é realizada usando o algoritmo ilustrado em
[102], que permite que uma determinada política seja correspondida e a
lista mínima de segmentos seja garantida. A fim de otimizar a interação
com o controlador, mediante solicitação, o controlador calcula os dois
caminhos para suportar a comunicação e, em seguida, instrui o dispositivo que o SR por domínio é capaz de codificar 60% dos caminhos usando no
de acesso de um nó a adicionar também o segmento de ligação reversa
no SRH. Desta forma, a resposta pode ser simplesmente ecoada de volta.
O Software Resolved Network foi implementado em hosts finais,
roteadores e controladores Linux.
Em [4] uma nova arquitetura SDN é proposta para a tecnologia SRv6;
A Seção V fornece mais informações sobre a implementação e onde é
possível baixar o código. O plano de dados é constituído por nós SRv6
baseados em Linux construídos a partir de componentes de código
aberto que expõem uma API aberta para o controlador SDN. Como
resultado, os nós se tornam híbridos, pois prevêem a coexistência de um
plano de controle IP legado com um plano de controle SDN. Os autores
apresentam o projeto e implementação da API Southbound entre o
controlador SDN e os dispositivos SRv6, que é utilizada para instanciar
políticas SRv6 na rede. Especificamente, eles propõem um modelo de
dados e fornecem quatro diferentes implementações da API,
respectivamente baseadas em gRPC, REST, NETCONF e interface de
linha de comando remota (CLI).
A descoberta de topologia também é abordada pela extração ativa do
banco de dados de topologia dos daemons de roteamento IP em
execução nos nós da rede.
Um plano de controle multidomínio hierárquico para redes SDN
baseadas em SR foi demonstrado em [150]. O plano de controle é
composto por um aplicativo orquestrador, que é executado em vários
controladores SDN e aproveita suas APIs NB para criar serviços
baseados em SR de vários domínios. BGP LS e PCEP são usados como
southbound nos controladores SDN.
22
Eles fornecem topologia de rede respectivamente e a criação de túneis
MPLS SR. IS-IS é usado dentro do domínio para trocar informações de
acessibilidade e SIDs entre nós.
Os controladores SDN não trocam nenhuma informação de acessibilidade
nem SIDs. O orquestrador interage com os controladores SDN e constrói
uma visão de rede global que será usada para realizar o cálculo do
caminho e instanciar os serviços SR. Uma demonstração prática foi
realizada usando roteadores de software.
Em [151] duas soluções para SR multidomínio são propostas:
Roteamento de Segmento fim-a-fim e Roteamento de Segmento por
domínio. Ambos os métodos alavancam uma interface leste/oeste não
padrão entre controladores de pares, contando assim com uma arquitetura
de plano de controle plano e não usando sessões de sinalização no plano de dados.
ponta a ponta que cruza vários domínios. O domínio originador envia
uma solicitação ao domínio de destino. O controlador de destino calcula
a lista de segmentos para alcançar o destino de seu roteador de entrada
e a envia de volta ao domínio anterior. Cada domínio intermediário aplica
o mesmo procedimento costurando a lista de segmentos computada pelo
downstream até que a resposta seja recebida de volta pelo originador.
Por outro lado, na segunda abordagem o caminho de ponta a ponta é
obtido costurando vários caminhos SR: em cada domínio a lista de
segmentos contém um rótulo virtual como o fundo da pilha, o que
desencadeia uma modificação da lista de segmentos no nó de fronteira
de ingresso do próximo domínio. Nesse caso, não há uma visão global
da rede e os controladores não conhecem a sequência de domínio para
chegar ao destino. A escalabilidade dos esquemas propostos é avaliada
em termos de profundidade da lista de segmentos. Os resultados mostram
máximo 3 rótulos, enquanto o SR de ponta a ponta apenas 12%. Em
geral, a profundidade média do SL é de 5,34 e 3,36 respectivamente para
SR de ponta a ponta e SR por domínio. [152] propõe um avanço da
arquitetura Carrier Ethernet e prevê uma abordagem misturando
tecnologias SR e SDN.
Isso resulta em uma troca entre planos de controle totalmente distribuídos
e abordagens centralizadas: um banco de dados de inventário é mantido
no controlador SDN com a configuração de cada dispositivo. O controlador
SDN fornece a configuração de IP e configuração de SR, como endereço
de loopback, rótulo do nó, intervalo de rótulos, informações do rótulo do
gateway por meio de uma API Southbound, como NETCONF/Yang. Para
qualquer comunicação dentro do domínio, a rede usará o encaminhamento
baseado em IGP por design sem a necessidade do controlador SDN e
imporá ao tráfego um único rótulo MPLS (loopback SID). Vários rótulos
podem ser usados para realizar aplicações TE. Em vez disso, em um
cenário de vários domínios, vários controladores SDN são implantados e
trocam informações de acessibilidade para programar adequadamente
os nós de borda. Dessa forma, um caminho entre domínios pode ser
estabelecido simplesmente com uma pilha de rótulos que inclui rótulos
de roteador de borda local e remoto, além do rótulo do nó final. Assim
como em outros trabalhos, análises adicionais não são possíveis, pois o
código do plano de controle não é open source. Quanto ao plano de
dados, a solução conta com hardware Carrier Ethernet.
Busoni [153] é um framework de orquestração para redes baseadas
em Segment Routing, que automatiza e simplifica muitos aspectos do
gerenciamento de rede. Do ponto de vista arquitetônico, a Busoni fica
em cima de um controlador SDN e se beneficia
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
das informações exportadas pelo controlador para alimentar seu armazenamento
de dados. O último é um banco de dados gráfico, que é usado para persistir
dados. Em particular, a Busoni o aproveita para acompanhar os SIDs anunciados
na rede, as políticas instaladas e para responder a qualquer evento dinâmico. A
estrutura fornece aos usuários ferramentas de programação para compor e
gerenciar políticas de SR.
Ele opera com eficiência mesmo em ambientes de multilocação.
Por fim, o Busoni atualiza automaticamente os nós e as bordas do banco de
dados do grafo sempre que há uma atualização na rede e reflete essas alterações
nas políticas instaladas. Isso permite que sua resiliência a eventos dinâmicos
seja mantida. [154] propõe uma arquitetura controlada centralizada escalável
para o gerenciamento de SFC Routing e Cloud Bandwidth resource Allocation
(SRCBA) baseado em SR. A solução proposta é pensada para ser aplicada
em um cenário multidomínio, onde uma rede de transporte interliga um conjunto
de infraestruturas de nuvem privada, possivelmente pertencentes a diferentes
provedores.
Em particular, em vez de usar abordagens clássicas para resolver o problema
SRCBA, que exigem um conhecimento detalhado da rede de transporte ou da
infraestrutura de nuvem, a arquitetura proposta explora o conceito BSID para
abstrair os serviços fornecidos por uma única infraestrutura de nuvem à rede
externa . O orquestrador resultante é então dividido em dois componentes
lógicos: i) um Network Service Orchestrator (NSO) centralizado, que é responsável
por coletar as solicitações SFC e gerenciar a largura de banda na rede de
transporte, além de decidir a qual datacenter atribuir o processamento de as
solicitações recebidas, ii) e um conjunto de orquestradores de recursos locais
que são responsáveis por gerenciar os recursos de rede e nuvem no contexto
de uma única infraestrutura. Desta forma, o NSO centralizado pode contar com
informações resumidas para tomar decisões enquanto resolve o problema
SRCBA.
Isso permite uma grande redução do tempo de computação, ao mesmo tempo
em que garante desempenho comparável em termos de eficiência no uso dos
recursos.
Nos parágrafos a seguir apresentamos uma comparação entre as obras
classificadas na categoria Arquitetura de Controle Centralizado. Um aspecto
interessante para comparar os trabalhos de pesquisa que se enquadram nessa
categoria está relacionado à forma como eles utilizam as RS. Por exemplo,
algumas soluções exploram a RS para superar algumas limitações existentes
quando outras tecnologias são adotadas. Outras arquiteturas controladas
centralmente fazem uso do SR para realizar funções específicas, que são mais
complexas se realizadas por meio de outros paradigmas. Por fim, alguns
trabalhos que se enquadram nesta categoria têm como objetivo propor uma
implementação e demonstrar a viabilidade e o desempenho alcançado.
Entre os trabalhos que exploram a RS para superar limitações de outras
abordagens existentes, estão [142], [147], [153], [154].
Especificamente, em [142] SR permite a redução na complexidade de configurar
e atualizar o caminho para uma requisição SFC recebida, graças ao paradigma
de roteamento de origem adotado. Em [147], eles exploram o mesmo princípio
para mostrar que, adotando SR, a restrição de tamanho TCAM pode ser
superada.
Finalmente, [153] propõe um framework de orquestração para simplificar o
gerenciamento de políticas. Da mesma forma, [154] propõe uma arquitetura
controlada centralizada escalável para o gerenciamento do
23
TABELA X
CLASSIFICAÇÃO DAS REFERÊNCIAS RELACIONADAS AO CAMINHO
CODIFICAÇÃO.
uniforme
[155],[156],[157]
Pesos IGP
Caminho a ser
codificado
arbitrários
[158],[15],[159],[160],[161]
Pesos IGP
ECMP
[15],[155],[157],[158]
não permitido
ECMP
[156],[159],[160],[161]
permitido
[155],[156],[157] [158],
Requer não
[15],[159] [160],[161]
configuração adicional
sim [155],[156],[157],[158]
[15],[160] ],[161] vários SLs
único SL
Caminho codificado [159]
Roteamento SFC e alocação de largura de banda de interconexão em nuvem.
Diferentes funções no nível da rede são realizadas em arquiteturas controladas
centralmente propostas em [144], [146], [151]. Como exemplo, em [151] SR é
usado para realizar um bypass óptico, enquanto é explorado para superar falhas
de nó e link em [144]. Finalmente, uma rede de sobreposição para interconectar
DCs distribuídos geográficos é realizada através de SR em [146].
Como já foi salientado, alguns dos trabalhos que se enquadram na categoria
de Arquitetura de Controle Centralizado têm como objetivo propor possíveis
implementações de SR e fornecer uma demonstração. Este é o caso em [4],
[145], [150]. Em [4], os nós SRv6 baseados na implementação Linux são
considerados no plano de dados, enquanto os demais trabalhos são focados em
SR-MPLS.
Além disso, [150] demonstra como construir caminhos de ponta a ponta em uma
rede SR multidomínio, enquanto em [145] um cenário de domínio único é
considerado.
E. Codificação de Caminho
A tradução de um caminho de rede, resultante de um objetivo específico de
TE, em uma sequência de SIDs, ou seja, uma Lista de Segmentos, é uma
operação fundamental para a implantação de SR em uma rede real.
Essa operação é geralmente chamada de codificação de caminho. Oito artigos
diferentes foram definidos para a definição de uma solução adequada para o
problema de codificação de caminho. Os diferentes algoritmos diferem de acordo
com a natureza do caminho da rede, ou seja, o caminho a ser codificado.
Especificamente, o caminho de entrada pode ser calculado no topo de uma rede
com peso de enlace uniforme ou arbitrário. Além disso, pode ou não incluir ECMP.
Outro aspecto para os algoritmos de codificação de caminho é a possibilidade
de exigir configurações adicionais de dispositivos, como a inserção de uma nova
política. Finalmente, os algoritmos de codificação de caminho podem diferir
dependendo da possibilidade de codificar o caminho de entrada com um ou mais
SLs. A Tabela X mostra a classificação dos artigos de acordo com os aspectos
mencionados. A seguir, fornecemos uma breve visão geral das referências
classificadas como trabalhos relacionados ao Path Encoding.
Em [155], implementações baseadas em SDN e PCE do controlador SR
compartilham um mecanismo de caminho comum, que executa a computação
de caminho salto a salto e a atribuição de caminho SR. No que diz respeito ao
mecanismo de cálculo de caminho, o controlador seleciona o caminho menos
congestionado em um conjunto de caminhos candidatos. Então,
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
o algoritmo de atribuição de caminho SR proposto fornece a lista de
segmentos mais curta considerando um caminho único para o destino e
evitando o balanceamento de carga por meio do ECMP. O algoritmo usa dois
ponteiros, i e j, para navegar no caminho de destino da origem ao destino.
Primeiramente, j é incrementado até que o subcaminho considerado não seja
mais o único caminho mais curto.
Neste ponto, o SID do nó j ÿ 1 é inserido na lista de Segmentos, os dois
ponteiros são definidos como j ÿ 1 e, em seguida, o procedimento é reiniciado.
Este ciclo é repetido até que o nó j seja igual ao destino. Os algoritmos
fornecem a lista de segmentos de profundidade mínima, mas a solução
considera apenas o Node-SID global e, portanto, não pode ser aplicado a
topologias com custos de enlace IGP arbitrários.
Os autores de [156] propõem um algoritmo de codificação de lista de
segmentos para expressar um determinado caminho, que minimiza
(reforçando um determinado limite) a profundidade da lista de segmentos em
redes baseadas em SR. Ele considera o encaminhamento de ECMP por
padrão, mas também pode introduzir restrições para dar suporte a um
caminho determinístico de salto a salto. Com relação a outros esforços (como
[15]), a solução não é capaz de suportar caminhos hop-by-hop arbitrários
quando custos arbitrários de link IGP são usados. O núcleo do algoritmo
consiste na criação de um grafo, cujos arcos modelam as instruções
relacionadas ao SR (SIDs de nós e adjacências). Especificamente, um arco
conectando dois nós representa o caminho mais curto na rede original entre
o mesmo par de nós. O chamado grafo auxiliar é construído primeiramente
usando as ligações físicas dos caminhos, que são computadas por uma
heurística TE externa.
Subsequentemente, links virtuais são adicionados representando os caminhos
ECMP entre dois nós. Cada link virtual é anotado com as métricas e o número
de ECMPs entre os dois nós. Usando este gráfico auxiliar, um novo cálculo
de caminho é realizado adicionando uma nova restrição relacionada ao
número de saltos: cada caminho com um número de salto maior que a
profundidade máxima da lista de segmentos é rejeitado. Os caminhos
candidatos são então classificados primeiro de acordo com suas métricas
originais, em segundo lugar de acordo com seu comprimento e, em seguida,
de acordo com o número de ECMPs. Por fim, os caminhos são traduzidos
em SIDs usando esta abordagem: os links físicos são alterados com seus
respectivos SIDs de Adjacência, os links virtuais são mapeados com o Node
SID do nó de destino. Se o SID de Adjacência não for local o algoritmo
primeiro insere o SID do Nó da origem e depois o SID de Adjacência.
[157] propõe dois algoritmos para o cálculo da lista de segmentos; os
algoritmos são ótimos em termos de profundidade da pilha quando um
caminho único salto a salto foi calculado.
A ideia chave é considerar a cada iteração subcaminhos maiores e verificar
se existe um único caminho mais curto. Se existir, substitua o sub-caminho
pelo SID do nó de cauda antes de passar para a parte restante do caminho.
A principal diferença entre os algoritmos é como variar a amplitude dos
subcaminhos até considerar o caminho original hop-by-hop. O primeiro
algoritmo navega no caminho de destino a partir do nó de origem em direção
ao destino, enquanto o segundo aproveita a direção oposta. A análise da
sobrecarga nos cabeçalhos dos pacotes mostra que o algoritmo reverso
apresenta menos sobrecarga em comparação com o algoritmo direto, pois a
lista de segmentos computados normalmente inclui nós que estão próximos
à origem.
Outros trabalhos (por exemplo [15], [114]) compartilham o mesmo objetivo
24
de reduzir a sobrecarga dos cabeçalhos dos pacotes, mas com relação às
soluções descritas acima, eles começam a partir do caminho salto a salto
original e, em seguida, avaliam a redução da amplitude dos subcaminhos em
cada iteração.
Em [158], dois algoritmos para uma codificação eficiente de caminhos são
propostos. Os algoritmos, denominados SR-LEAs, tomam como entrada um
caminho mais curto explícito e então computam a lista de segmentos relativos
tendo como restrição uma dada profundidade máxima de lista de segmentos.
São compostos por duas etapas principais: i) cálculo dos caminhos mínimos
sucessivos; ii) substituição da etiqueta. Especificamente, eles computam os
subcaminhos do caminho mais curto original e levam em consideração a
limitação do hardware para reduzir o número de subcaminhos. Na segunda
etapa, os subcaminhos compostos por três ou mais nós são substituídos pelo
Node-SID de seu tailnode. SR-LEA substitui dois subcaminhos de nó usando
Adj-SID. A variante SR-LEA-A é muito semelhante ao algoritmo acima, mas
aproveita o Adj-SID global para reduzir ainda mais a profundidade da pilha de
rótulos. Obviamente, é necessário o anúncio desses SIDs para funcionar
corretamente. Os resultados da simulação mostram que os algoritmos são
capazes de calcular listas de segmentos com comprimento médio inferior a 3.
O SR-LEA-A oferece melhores resultados e pode melhorar o cálculo da lista
de segmentos em comparação com o SR-LEA, mas o ganho é de cerca de
5% em termos de comprimento médio.
Os autores de [15] propõem um algoritmo de atribuição de caminho SR
ótimo e provam que ele é ótimo em termos do número de segmentos
utilizados. O algoritmo toma como entrada um caminho hop-by hop resultante
de um algoritmo TE e define um caminho SR para ele composto pelo número
mínimo de segmentos.
O algoritmo de atribuição SR avalia a cada iteração se existe um caminho
mais curto entre a fonte atual e o destino atual, considera diferentes
subcaminhos e atualiza a fonte atual ou o destino atual. Cada vez que um
novo segmento é encontrado, a origem atual é atualizada com o destino
anterior e o destino atual é substituído pelo destino do caminho salto a salto
original. Na pior das hipóteses, o link entre a fonte atual e seu próximo salto
é avaliado e, se o link não fizer parte do caminho mais curto, um segmento
de adjacência será inserido na lista de segmentos.
Os autores de [159] propõem um método de duas etapas para traduzir
um determinado caminho de Engenharia de Tráfego (TE) em um SL. Na
primeira etapa, um gráfico auxiliar é criado. O objetivo do gráfico auxiliar é
representar todos os caminhos do Interior Gateway Protocol (IGP) disponíveis,
ou seja, caminhos de encaminhamento, para o caminho TE específico a ser
codificado. Na segunda etapa, um problema MILP sobre o grafo auxiliar é
definido: o problema MILP permite a minimização do comprimento total da
Lista de Segmentos dado o caminho TE alvo. Uma das principais
características da solução proposta é o suporte a multicaminhos, ou seja, a
capacidade de dividir um fluxo de origem e destino entre um conjunto
ponderado de listas de segmentos.
Em [160] é estudado o problema de otimizar o desempenho de uma rede
SR sob a restrição máxima de Profundidade da Lista de Segmentos (max
SLD). De fato, especialmente quando o SR é realizado no topo do plano de
dados MPLS, a restrição no max-SLD é particularmente limitante. Uma
possível solução é criar novos LSPs, aumentando assim a disponibilidade de
caminhos alternativos na rede underlay e, consequentemente, permitindo a
escrita de listas de segmentos mais curtas. Apesar do fato de que
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 25

TABELA XI
a criação de novos LSPs reduz o comprimento das listas de segmentos, sua
CLASSIFICAÇÃO DAS REFERÊNCIAS RELACIONADAS A
principal desvantagem é o aumento do número de regras de encaminhamento
PROGRAMAÇÃO DE REDE .
necessárias a serem instaladas nas tabelas de encaminhamento dos
roteadores. A fim de mitigar este efeito negativo, [160] define o conceito de
Função de serviço
encaminhamento baseado em painel: um painel refere-se a um conjunto de [21],[162],[163],[164],
Encadeamento

LSPs desconectados de nós que podem ser representados pelo mesmo Função Operacional [165],[166],[167],[100]

rótulo. Além disso, uma formulação ILP é proposta para resolver o problema
de codificação de caminho, minimizando tanto o número de novos LSPs
definidos quanto as regras instaladas, respeitando a restrição max-SLD. F. Programação de Rede

Apesar de a Programação em Rede ser a característica mais atrativa e

inovadora da RS, encontramos apenas oito artigos relacionados a este tema.
Para superar a restrição de Profundidade Máxima da Pilha (MSD) no SR-
Conforme apresentado na tabela XI, esses trabalhos podem ser classificados
MPLS, um novo tipo de SID, denominado Targeted SID (TSID), é definido em
em relacionados ao encadeamento de funções de serviço, ou função
[161]. Um TSID é um segmento local que está associado a uma sequência de
operacional. Estes últimos visam implementar funções operacionais, como
SIDs. A instrução relacionada a um TSID consiste em substituí-lo no SL pela
firewall, balanceador de carga e ferramenta de migração de VM com perda
sequência de SIDs associada. Usando um TSID, é possível reduzir o
zero, explorando o recurso de programação de rede do SR. Nos parágrafos
comprimento de um SL ao custo de introduzir um novo estado de fluxo no nó
seguintes apresentamos uma breve visão geral das referências classificadas
que implementa a instrução relacionada ao TSID. Por esta razão, [161] propõe
como trabalhos relacionados com a Programação de Redes.
dois problemas de otimização diferentes que permitem um trade-off entre os
benefícios e os custos da ferramenta TSID. O primeiro problema de otimização
Em [162] a implementação do Linux SRv6 descrita em [183] é aprimorada
toma como entrada o conjunto de caminhos com um SL superando o limite
introduzindo o suporte para Service Function Chaining. Mais detalhadamente,
do MSD e visa minimizar o número de TSIDs definidos. O foco é então a
o kernel Linux fornece uma API para mapear um segmento de serviço, ou
redução do número de estados de fluxo extras a serem mantidos pelos nós
seja, o identificador de um serviço de rede rodando em uma Máquina Virtual.
da rede. Um segundo problema de otimização é apresentado com o objetivo
A avaliação experimental mostra que o impacto das operações de SR e
de minimizar as sessões PCEP que devem ser mantidas entre o controlador
processamento de segmentos de serviço na capacidade de encaminhamento
central (responsável pela instalação do TSID) e os nós onde os TSIDs devem
de pacotes é limitado, ou seja, com redução inferior a 10%.
ser instalados. Nesse caso, a ideia principal é instalar o maior número possível
de TSIDs no mesmo nó.
A arquitetura de um domínio de rede que suporta o Service Function
Chaining (SFC) através do SRv6 é investigado em [163]. Os autores focam
principalmente na implementação de um nó VNF capaz de hospedar múltiplas
instâncias VNF. Os principais componentes dos nós VNF são o conector SR/
VNF, responsável por conectar logicamente o roteamento SR com VNFs
Uma possível chave para comparar as técnicas de codificação de SL
locais, e os VNFs, suportando funções específicas da rede.
existentes é focar no método que elas usam para obter a lista final de SIDs.
Em particular, dois métodos diferentes são explorados.
Os VNFs podem ser SR-aware ou SR-unware: i) VNFs SR-aware podem
A primeira é baseada no princípio de Bellman-Ford, que afirma que cada
processar as informações contidas no cabeçalho SR (SRH) dos pacotes
subcaminho contido em um caminho mais curto é em si um caminho mais
recebidos; ii) VNFs que não reconhecem SR não são capazes de lidar com o
curto. Com base nessa consideração, esses algoritmos exploram o caminho
SRH. Assim, para aplicar corretamente o VNF ao pacote original, o conector
a ser codificado, partindo do nó de origem até um intermediário. Até que o
SR/VNF deve pré-processar o pacote removendo o encapsulamento SR e,
caminho entre a fonte e o nó intermediário seja considerado o caminho mais
curto, eles seguem em frente considerando o próximo nó no caminho. em seguida, reaplicá-lo quando o pacote for retornado pelo VNF. Os autores
propõem uma implementação baseada em Linux de um nó VNF que suporta

Quando esta condição não se verifica, o primeiro SID é encontrado. O VNFs SR-aware e SR-unware. Mais detalhadamente, usando a estrutura
netfilter, um novo módulo de kernel chamado srext (Segment Routing
processo continua até que o caminho completo seja explorado. As ferramentas
EXTensions) é implementado para atuar como um conector SR/VNF e para
de codificação SL apresentadas em [15], [155], [157], [161] usam essa abordagem.
dar suporte a VNFs que não reconhecem SR. Um testbed virtualizado baseado
Além disso, é interessante ressaltar que todos os trabalhos que utilizam essa
em Virtualbox e Vagrant é realizado para avaliar a sobrecarga de
abordagem não permitem o uso de ECMP no underlay.
processamento introduzida pela implementação proposta em relação a uma
solução clássica de encaminhamento IPv6.
O segundo tipo de abordagem consiste na criação de um grafo auxiliar
para representar os caminhos de subjacência. Especificamente, um arco do
gráfico auxiliar é um caminho inteiro na subjacência. Este tipo de abordagem SRV6Pipes [164] é uma extensão da implementação IPv6 do Segment
é usado em [156], [159]. A principal diferença entre as soluções apresentadas Routing no kernel Linux, que permite o encadeamento e operação de funções
nestes dois trabalhos é que, em [156] o caminho fim a fim é codificado na rede operando em streams. O SRv6 é usado para impor um caminho de
aplicando o algoritmo de Dijkstra sobre o grafo auxiliar, enquanto em [159] o ponta a ponta entre o cliente e o servidor passando pelo equipamento que
problema é modelado como um Multi Commodity Flow sobre o gráfico auxiliar. hospeda as funções de rede. A lógica por trás do SRv6Pipes está no fato de
Como consequência, [159] também permite o uso de múltiplos SLs para que algumas funções de rede precisam incluir uma implementação TCP para
direcionar um único fluxo. funcionar nos fluxos. SRv6 Pipes
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
aproveita “a pilha TCP que já está presente no kernel do Linux” e
implementa um proxy TCP transparente para descarregar as
funcionalidades TCP para ele e encerrar as conexões TCP onde uma
função de rede é implantada. Dessa forma, é possível expor às
funções de rede os bytestreams que elas precisam processar. O
endereçamento especial é usado para especificar funções de rede e
seus parâmetros. Em particular, cada proxy expõe um prefixo 80. Os
primeiros 80 bits são usados para percorrer o proxy, os 16 bits
seguintes são usados para identificar a função de rede e os restantes
são usados para especificar os parâmetros da função. [165] define o
conceito de SR Aware VNF, como uma aplicação que é capaz de
processar as informações de SR no pacote. Além disso, [165]
também propõe a implementação de uma aplicação SR Aware
(SERA) Firewall. O SERA Firewall pode funcionar tanto como firewall
legado (modo básico), quanto definir regras de filtragem que também
incluem condições nos campos SR (modo avançado). No modo
básico, ele pode aplicar o processamento normal de firewall aos
pacotes originais, mesmo que tenham um encapsulamento SFC
baseado em SR. Isso significa que as regras de filtragem são
aplicadas aos valores originais do cabeçalho do pacote (os campos
relacionados ao SR são transparentes). No modo avançado, o SERA
oferece novos recursos de correspondência e novas ações específicas
de SR que permitem a modificação de campos no cabeçalho SR.
O Balanceamento de Carga de Roteamento de Segmento (SRLB)
[166] é um balanceador de carga com reconhecimento de aplicativo
que evita custos devido a tarefas de monitoramento. Pensa-se que
funcione no contexto de uma rede de Data Center, onde várias
instâncias de uma mesma aplicação são instanciadas em diferentes
máquinas host. Cada máquina host é equipada com um roteador
virtual baseado em VPP que despacha pacotes entre NICs físicos e
interfaces virtuais vinculadas a aplicativos. O Load Balancer (LB) está quando a VM fica disponível em B, os pacotes em buffer, bem como
localizado na borda da rede do Data Center. Uma solicitação para um
aplicativo é representada pelo primeiro pacote enviado do cliente para forma, é possível implementar a migração ao vivo da VM sem perda
o servidor de aplicativos (geralmente uma mensagem syn). Quando
uma nova requisição chega ao LB, é executada a função Service
Hunting, que consiste em encontrar um servidor que possa atender a
requisição atual. O LB explora o SR para consultar um subconjunto
de servidores que hospedam o aplicativo solicitado. Especificamente,
o LB codifica o conjunto de servidores potenciais selecionados
aleatoriamente na lista de segmentos antes de encapsular o primeiro
pacote da solicitação. Quando o primeiro servidor recebe o pacote,
ele pode decidir se vai entregá-lo à aplicação e, consequentemente,
atribuir a ele o processamento dessa solicitação, ou pode encaminhar
o pacote para o próximo servidor da lista de segmentos. A decisão de
aceitar/recusar uma solicitação é tomada de acordo com uma política
de aceitação de conexão que leva em consideração o estado interno
do aplicativo (uso de CPU, uso de memória etc.). [167] propõe uma
nova arquitetura para o Content Delivery Networks (CDNs) com
base nos resultados de [166]. Nesse novo paradigma, as decisões de
CDN (cache vs servidores de origem) são transferidas para o plano
de dados. Essa arquitetura é baseada em duas peças fundamentais:
i) endereçamento de conteúdo em nível de bloco e ii) seleção de
servidor na rede. A primeira é realizada atribuindo um endereço IPv6
exclusivo e globalmente roteável a cada bloco. Em vez disso, a
seleção do servidor na rede aproveita esses identificadores expostos
como endereços IP para tomar decisões de encaminhamento em
banda, que são posteriormente vinculadas a uma política de direção SRv6.framework netfiler, enquanto as soluções anteriores
26
Em particular, na chegada de uma solicitação em um proxy CDN, o
identificador IPv6 é usado pelo mecanismo de previsão para realizar
a admissão de cache, estimando a popularidade de solicitações com
um filtro Least-Recently-Used (LRU). Se isso não estiver disponível
(cache miss), 6LB [166] é usado para encaminhar solicitações
diretamente para os servidores de origem em vez de fazer proxy deles no cache.
Segundo os autores, este mecanismo permite reduzir a carga no
edge cache e evitar efeitos negativos na Qualidade da Experiência.
[100] propõe uma técnica de migração ao vivo baseada em SR que
alcança zero perda de pacotes. O ponto de partida é uma rede de
data center habilitada para SRv6. Duas novas funções SR são
definidas e usadas no processo de migração ao vivo da VM. O
primeiro é encaminhado para local se estiver presente, que é uma
versão condicional do comportamento END descrito na seção II-C.
Especificamente, caso o último SID no SL esteja disponível localmente,
o pacote é processado diretamente, ignorando possíveis SIDs
intermediários. O segundo é buffer e encaminhamento para local.
Isso força o nó a inspecionar o último SID e, se não estiver disponível
localmente, o pacote é armazenado em buffer até que o SID fique
disponível. Assumindo que uma VM é migrada do host A para o host
B, todas as solicitações recebidas pelo gateway do data center são
então encapsuladas durante o processo de migração usando um SL
em que: i) o primeiro SID aponta na função forward to local if present
implementada em A , ii) o segundo SID aponta para o buffer e
encaminha para a função local implementada em B, e iii) o último SID
é encaminhado para a VM. Desta forma, até que a VM esteja
disponível em A, os pacotes são entregues diretamente à VM graças
à função forward to local if present. Então, durante o tempo de
inatividade, os pacotes direcionados à VM são armazenados em
buffer em B graças ao buffer e encaminhados para o local. Finalmente,
os recém-chegados, são entregues diretamente à VM em B. Desta
de pacotes.
SRNK [21] é um SR-proxy para VNFs legados que desconhecem
a tecnologia SRv6 e esperam processar pacotes IP tradicionais.
SRNK estende a implementação do SRv6 no kernel Linux [193]
adicionando o suporte para os comportamentos End.AS e End.AD. O
desempenho da solução proposta foi avaliado pelos autores, que
identificaram uma escalabilidade ruim em relação ao número de VNFs
a serem suportados dentro de um nó NFV. Com um aprimoramento
da estrutura Linux Policy Routing, eles forneceram um segundo
design SRNKv2, que não depende do número de VNFs com suporte
em um nó. Eles compararam o desempenho com um cenário de
referência não realizando a operação de encapsulamento e
desencapsulamento e demonstraram que o overhead do SRNKv2 é
muito pequeno, da ordem de 3,5%. [21], [162]–[164] têm em comum
o tópico de encadeamento de funções de serviço. Ao mesmo tempo,
existem algumas diferenças importantes que devem ser destacadas.
[162] adiciona uma API na implementação SRv6 do kernel Linux para
mapear os segmentos de serviço. Ele lida principalmente com VNFs
com reconhecimento de SR.
Em vez disso, [21] propõe um SR-proxy para VNFs SR-unware. [163]
implementa uma solução capaz de lidar com VNFs SR-aware e SR-
unware, mas com relação aos trabalhos anteriores ele estende o
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
são extensões da implementação SRv6 no kernel Linux.
Por fim, [164] ainda é uma extensão da implementação do SRv6 no
kernel Linux, mas permite o encadeamento de funções na rede operando
em fluxos, trabalhando assim em um nível superior (camada de
transporte) em relação aos trabalhos anteriores.
G. Avaliação de desempenho
Nesta subseção, relatamos quatro artigos que tratam da
avaliações de desempenho de implementações SRv6.
SRPerf [168] [171] é uma estrutura de avaliação de desempenho
para implementações de software e hardware do SRv6. O SR Perf é
capaz de realizar diferentes testes de benchmarking, como throughput
e latência. No momento da escrita, a estrutura suporta implementações
de kernel Linux e VPP de SRv6. A arquitetura do SRPerf pode ser
facilmente estendida para suportar novas metodologias de benchmarking, explicitamente baseado em SR, propõe o conceito de path let [173],
bem como diferentes implementações de SRv6. A estrutura oferece
suporte a duas métricas diferentes para caracterizar a taxa de
transferência de um nó habilitado para SRv6: No-Drop Rate (NDR) e
Partial Drop Rate (PDR). O PDR é definido como a maior taxa de
transferência alcançada sem descartar pacotes além de um limite
predefinido. NDR, que corresponde ao Throughput definido pela RFC
1242 [194], pode ser descrito como PDR com um limite de 0%. A
estrutura orquestra todos os aspectos de um experimento, desde a
configuração do testbed até a aplicação das configurações SRv6,
aliviando assim o experimentador de um esforço significativo de
configuração.
O SRPerf tem sido usado para avaliar o desempenho das
implementações do SRv6 no kernel Linux e no VPP. Além disso, em
[171], os autores propõem a avaliação de um kernel Linux aprimorado,
que foi obtido adicionando a implementação de comportamentos
ausentes e corrigindo a implementação de
uns.
[169] apresenta uma solução em que funções de rede de baixo
nível, como encapsulamento SRv6, são transferidas para placas
programáveis Intel FPGA. Em particular, os autores descarregam
parcialmente o processamento SRv6 de um roteador de software VPP
para as NICs dos servidores, aumentando assim o desempenho do
caminho de dados e, ao mesmo tempo, economizando recursos. Esses
preciosos ciclos de CPU são disponibilizados para VNFs ou para outras
cargas de trabalho em execução nos servidores. Os resultados dos
testes do caso de uso End.AD mostram no pior cenário uma economia
de CPU de 67,5%. Além disso, a taxa de transferência máxima
alcançada por uma solução VPP pura com 12 núcleos é obtida pela soluçãonoacelerada
núcleos.
[170] estuda o SRv6 como protocolo de plano de usuário alternativo
ao GTP-U [99]. Primeiramente, os autores propõem uma implementação
das funções GTP-U encap/decap e dos comportamentos de tradução
sem estado do SRv6 definidos em [24]. Esses comportamentos
garantem a coexistência dos dois protocolos, o que é crucial para uma
implantação gradual. Os autores usaram switches programáveis de data
center para implementar essas funcionalidades de plano de dados.
Como é difícil obter a telemetria de um gerador de tráfego comercial
quando ocorre uma tradução, os autores injetaram timestamp com uma
resolução de nanossegundos para medir a latência dos comportamentos
SRv6. Finalmente, eles mediram a taxa de transferência e a perda de
pacotes sob condições de tráfego leve e pesado em um ambiente local.
Os resultados não mostram uma grande queda de desempenho
27
devido à tradução SRv6. Além disso, a latência dos comportamentos
do SRv6 é semelhante às funções de encap/decap do GTP-U.
H. Diversos
Nesta seção, incluímos todos os trabalhos que não pertencem às
categorias anteriores. Em geral, esses trabalhos são muito diferentes
entre si e possuem apenas o Segment Routing em comum.
[14] fornece um tutorial sobre Segment Routing e um levantamento
sobre a atividade de pesquisa abrangendo mais de 50 artigos científicos.
A parte do tutorial se concentra na parte do plano de dados SR-MPLS
e não considera o plano de dados SRv6 recente. Esforços de
padronização de SR, atividades de implementação e implantações não
são especificamente analisados em [14].
O Control Exchange Point (CXP) definido em [172], ainda que não
que se assemelha muito à ideia da lista de instruções presente na
arquitetura SR. O principal objetivo do Control Exchange Point (CXP) é
fornecer serviços com restrições de QoS entre domínios. Isso é
conseguido costurando os pathlets que são caminhos parciais
anunciados pelos domínios. Um ISP abstrai sua rede como um conjunto
de pathlets conectando as bordas da rede e os anuncia no sentido norte.
Mais especificamente, esta abstração é realizada com túneis
instanciados com OF, MPLS, caminhos ópticos e assim por diante. A
abstração do pathlet é empacotada com propriedades que o ISP
fornece, como latência, custos, largura de banda disponível e assim por
diante. Um CXP é uma entidade externa que atua como camada de
intermediação e fornece coordenação de roteamento entre domínios
com base em APIs SDN. A ideia geral parece estar alinhada com a
arquitetura SR apresentada até agora, e pode ser implementada usando
tecnologias de plano de dados SR.
[174], [175] e [176] propõem uma implementação alternativa da
arquitetura SR através da Omnipresent Ethernet (OE), que é uma
modificação da arquitetura Carrier Ethernet. Ele é baseado em rótulos
roteados de origem e binários incorporados em um quadro Ethernet.
[176] fornece detalhes sobre o cabeçalho SR implementado. Os autores
dos trabalhos mencionados abordam questões de escalabilidade de SR
no contexto de cenários multidomínio ios de dois pontos de vista
diferentes: tamanho do cabeçalho do pacote e o número de entradas
de tabela necessárias nos nós de borda. Realizam também um testbed
para validar a implementação dos esquemas propostos. No entanto,
uma análise mais aprofundada não é possível, pois a solução se baseia
hardwareusando
Carrier apenas 6
Ethernet.
[177] analisa o problema de TE para SR sob uma perspectiva
diferente: os autores avaliam a influência das métricas utilizadas para
definir o custo dos enlaces. As principais descobertas do estudo indicam
que a métrica de roteamento pode influenciar o TE baseado no caminho
mais curto. Métricas muito simples e razoáveis, como capacidade
inversa, funcionam bem como uma métrica complexa otimizada. Eles
permitem que isso esteja próximo do ótimo em relação ao objetivo mais
comum da engenharia de tráfego de minimizar a utilização máxima. Por
fim, se outros objetivos forem introduzidos além de otimizar a utilização
do link, a escolha da métrica é mais importante e há diferenças
significativas entre as métricas. Embora [177] trate de Engenharia de
Tráfego, ele não fornece uma nova heurística nem uma forma diferente
de abordar o problema, mas é simplesmente um estudo sobre a
influência do
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
métricas de roteamento. Portanto, não o classificamos na categoria TE.
Em [178], os autores aproveitam o Segment Routing para construir um
mecanismo de entrega Multicast baseado em SR para fornecer eficientemente
serviços de streaming de vídeo ao vivo para usuários 5G. O SR é usado para
aliviar a sobrecarga de atualização de regras e evitar a explosão de tabelas
de roteamento nos dispositivos. O trabalho se baseia em um problema
interessante, embora não forneça muitos detalhes sobre a implementação da
RS. O trabalho foca principalmente no problema de construção de uma
árvore Multicast eficiente para reduzir ainda mais a atualização de regras
devido aos movimentos do usuário (árvore Multicast consciente de Handover).
[179] considera um cenário de IoT Industrial (Internet das Coisas) com um
número extremamente grande de objetos a serem conectados, levando
também em conta sua mobilidade. A solução proposta conta com o Segment
Routing para permitir escalabilidade e flexibilidade no encaminhamento de
pacotes. Isto é, em particular, para contornar os links sobrecarregados e
alcançar o equilíbrio de carga.
[180] propõe um novo modelo de processamento distribuído para IoT,
baseado na extensão do Modelo de Programação de Rede SRv6. A ideia é
que cada nó IoT ofereça uma máquina abstrata que pode ser programada
usando uma Arquitetura de Conjunto de Instruções. O programa pode ser
incorporado em uma lista de segmentos SRv6. Um pacote SRv6 carrega o
programa e o estado de execução. Ele pode viajar pelos nós IoT, lendo e
gravando as portas de E/S do dispositivo e executando cálculos conforme
ditado pelo programa no próprio pacote.
V. IMPLEMENTAÇÕES E IMPLANTAÇÕES DE SR
Nesta seção, descrevemos os resultados da implementação relacionados
ao SR. Vamos nos concentrar principalmente na versão SRv6, que está
atraindo muito interesse e esforços de desenvolvimento.
A versão SR-MPLS já está em uma fase madura de desenvolvimento, bem
suportada pelos principais fornecedores de roteadores principais (por exemplo,
Cisco, Huawei, Juniper). O SR-MPLS pode ser implementado de forma
incremental nos backbones IP-MPLS atuais, pois requer apenas atualizações
de software para dispositivos de rede. Os operadores podem migrar para o
SR-MPLS para simplificar as operações do plano de controle e melhorar a
escalabilidade. Quanto ao plano de dados SRv6, existem duas principais
implementações de plano de dados Open Source para roteadores de
software: a implementação do kernel Linux (descrita na Subseção VA) e a
implementação feita pelo projeto FD.io VPP (descrita na Subseção VB). A
seção VC apresenta outras implementações de código aberto, principalmente
relacionadas a atividades de pesquisa. Finalmente, na Subseção VD,
analisamos brevemente as implementações de hardware do SRv6, os
esforços de interoperabilidade feitos por vários fornecedores e as atuais
implementações do SRv6 em grandes redes de produção.
A. Kernel do Linux
Os recursos do SRv6 foram adicionados pela primeira vez no kernel Linux
4.10 [193]. O kernel 4.10 inclui o suporte para alguns comportamentos de
cabeçalho de política SRv6 (anteriormente conhecidos como comportamentos
de trânsito) (por exemplo, H.Insert e H.Encaps). Os comportamentos do
SRv6 Policy Headend são implementados como Linux Lightweight Tunnel (LWT).(tanto MPLS quanto IPv6) e associar um BindingSID a ela nem instanciar
A implementação do utilitário de espaço do usuário iproute2 [195] é estendida
para suportar a adição de um localsid associado a um SRv6
28
Comportamento do Headend da política [196]. Localsids SRv6 com
comportamento SRv6 Policy Headend são adicionados como entradas IPv6
FIB na tabela de roteamento principal do kernel. Kernel 4.14 é outro marco
importante para o suporte SRv6 no Linux: um conjunto de comportamentos
de endpoint SRv6 foi implementado adicionando um novo tipo de LWT [197].
Os comportamentos de endpoint SRv6 suportados são End.X, End.T,
End.DX2, End.DX4. End.DX6, End.DT6, End.B6 e End.B6.Encaps. Alguns
novos comportamentos de Headend de Política SRv6 foram adicionados (por
exemplo, H.Encaps.L2). A implementação do iproute2 também foi estendida
[195] [198]. Os recursos do SRv6 no kernel Linux foram estendidos no kernel
4.16 [199] para incluir o framework netfilter [200]. Uma nova extensão de
correspondência do iptables, chamada srh, foi adicionada ao kernel para
suportar a correspondência de campos SRH. A extensão srh match faz parte
do firewall SERA [165] e suporta a correspondência de todos os campos do
SRH. A implementação do utilitário iptables user space [201] é estendida
com uma nova biblioteca compartilhada (libip6t_srh) que permite definir
regras do iptables com opções srh.
O Linux Kernel 4.18 [202] adicionou mais alguns recursos tanto na pilha
SRv6 principal quanto na estrutura netfilter.
Na estrutura do netfilter, a correspondência srh é estendida para fornecer a
correspondência do SID anterior, do próximo SID e do último SID do SRH. O
utilitário de espaço do usuário iptables também é atualizado para suportar as
novas opções de correspondência. Em vez disso, um novo recurso é
adicionado à pilha Linux SRv6 para suportar funções de rede SRv6
personalizadas implementadas como pequenos programas eBPF [185]. [108]
estende [3] introduzindo um novo comportamento End, o chamado End.BPF.
Do ponto de vista da implementação, um novo gancho para BPF é adicionado
à infraestrutura SRv6 que pode ser usado por operadores de rede para
anexar pequenos programas escritos em C a SIDs SRv6 que têm acesso
direto aos quadros Ethernet. Além disso, auxiliares específicos do SRv6-BPF
foram fornecidos para permitir que as funções End.BPF executem ações
básicas do SRv6 (End.X, End.T e muitas outras) ou adicionem TLVs. Isso
permite que comportamentos de Headend de política SRv6 personalizados
sejam implementados (principalmente para estender políticas de
encapsulamento SRv6 implementadas pelo kernel). O tutorial sobre extensões
eBPF para SRv6 está disponível em [203]. O código-fonte dos aplicativos de
amostra descritos em [108] está disponível gratuitamente em [204]. Em vez
disso, os esquemas de detecção de falhas e redirecionamento rápido
baseados em eBPF descritos em [138] estão disponíveis em [205].
O SR-MPLS não recebeu a mesma atenção da implementação do SRv6
no kernel Linux. Todos os recursos disponíveis estão principalmente
relacionados ao encaminhamento MPLS bem estabelecido. Eles foram
disponibilizados a partir da versão 4.1 do kernel. Em particular, o kernel v4.1
viu a introdução do comportamento do MPLS Label Switching Router (LSR).
Os recursos MPLS foram estendidos posteriormente no kernel v4.3. A
estrutura LWT e o túnel MPLS foram adicionados permitindo a implementação
do comportamento do MPLS Label Edge Router (LER). Finalmente, a
funcionalidade multipath MPLS foi adicionada apenas na versão 4.5 do kernel.
Em geral, o kernel Linux não tem o suporte da estrutura de política SR,
que está disponível para implementação do FD.io VPP (Subseção VB). Isso
significa que no momento da escrita não é possível criar uma política SR
regras de direcionamento SR-MPLS/SRv6 apontando para SR-MPLS/SRv6
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
políticas.
B. FD.io VPP
A plataforma FD.io Vector Packet Processing (VPP) [206] é uma
estrutura extensível que fornece funcionalidade de switch/roteador de
qualidade de produção pronta para uso que pode ser executada em
CPUs comuns. O VPP 17.04 incluiu o suporte para os comportamentos
SRv6 Policy Headend (anteriormente conhecido como trânsito) e a
maioria dos comportamentos de endpoint definidos em [3]. Esses
comportamentos são implementados em nós de gráfico VPP dedicados.
Os nós do gráfico SRv6 executam os comportamentos SRv6
necessários, bem como o processamento IPv6 (por exemplo, diminui o
limite de saltos). Sempre que um segmento SRv6 é instanciado, uma
nova entrada IPv6 FIB é criada para o endereço do segmento apontando em nós baseados em Linux.
para o nó do gráfico VPP correspondente. A versão 17.04 também Quando foi projetado, o kernel do Linux oferecia apenas o
trouxe recursos de headend de SR para o VPP ao introduzir o conceito
de política de SR na implementação do SRv6. No VPP, uma política
SR é identificada exclusivamente por seu endereço BindingSID, que
serve como chave para uma política SR específica. Isso não é
compatível com a definição de política SR [33], mas um atalho razoável
considerando a ausência de recursos de plano de controle no VPP.
As políticas SR no VPP oferecem suporte a várias listas SID com
balanceamento de carga ponderado do tráfego entre elas. Quando
uma nova lista de segmentos é especificada para uma política SR, o
VPP pré-computa a string de reescrita que será usada ao direcionar o
tráfego para essa lista SID, seja por meio de um comportamento SR
Policy Headend ou de um BindingSID. O VPP então inicializa uma
entrada FIB para a política SR BindingSID no FIB e uma entrada em
uma tabela FIB oculta para o tráfego IPv6 direcionado para a política
SR por meio de um comportamento SR Policy Headend. Cada uma
dessas entradas FIB aponta para o objeto de política SR, que por sua
vez se repete nas listas de segmentos ponderados.
O tráfego pode ser direcionado para uma política SR enviando-o
para o BindingSID correspondente ou configurando uma regra,
chamada política de direção, que direciona todo o tráfego em trânsito
para um determinado prefixo IP ou interface L2 em uma política SRv6.
O último mecanismo é implementado como entrada FIB para o tráfego
direcionado no FIB principal a ser resolvido através da entrada FIB da
política SR na tabela FIB oculta. Desta forma, uma estrutura FIB
hierárquica é realizada: o tráfego não é direcionado diretamente sobre
uma política SR, mas direcionado para uma entrada FIB oculta
associada à política. Isso permite que a política de SR seja modificada
sem exigir nenhuma alteração nas regras de direção que apontam para
ela.
A versão 17.04 também viu a introdução do SRv6
Estrutura de desenvolvimento LocalSID e implementação do SR-
MPLS. A primeira é uma API que permite aos desenvolvedores criar
novos comportamentos de endpoint SRv6 usando a estrutura de plug-
in do VPP. O princípio é que o desenvolvedor apenas codifica o
comportamento real, ou seja, o nó do gráfico VPP. Em vez disso, a
instanciação, listagem e remoção do segmento são realizadas pelo
código SRv6 existente. A estrutura SR-MPLS está focada nas políticas
de SR, bem como em sua direção. Da mesma forma no SRv6, uma
política SR é definida por um rótulo MPLS que representa o BindingSID
e um conjunto ponderado de pilhas de rótulos MPLS.
As políticas de spray são um tipo específico de políticas SR-MPLS em
que o pacote é replicado em todas as listas SID, em vez de carregar
29
equilibrado entre eles. Para direcionar pacotes em trânsito para uma
política SR MPLS, o usuário deve criar uma política de direção SR-
MPLS. Em vez disso, outros recursos do SR-MPLS, como, por exemplo,
SIDs de adjacência, podem ser obtidos usando a implementação
regular do VPP MPLS. Na versão 18.04, os comportamentos de proxy
de programação de serviço End.AS, End.AD e End.AM foram
introduzidos como plug-ins do VPP, aproveitando a estrutura descrita anteriormente.
C. Outras implementações de código aberto
Vários esforços de pesquisa analisados na seção IV liberaram os
componentes e as extensões realizadas para SR como código aberto.
Alguns deles se baseiam nas implementações descritas nas Subseções
anteriores, enquanto outros propõem soluções alternativas. O módulo
SREXT ([163]) fornece uma implementação complementar do SRv6
processamento básico do SRv6 (comportamento do End). O SREXT
complementou a implementação do kernel Linux SRv6 fornecendo um
conjunto de comportamentos que ainda não eram suportados.
Atualmente, a maioria dos comportamentos implementados no SREXT
são suportados pela linha principal do kernel Linux (com exceção dos
comportamentos do proxy SR). O SREXT fornece uma tabela SID local
adicional que coexiste com a mantida pelo kernel do Linux.
O módulo SREXT se registra como uma função de retorno de chamada
no gancho de pré-roteamento do framework netfilter [200]. Como sua
posição está no início do processamento do netfilter, ele é invocado
para cada pacote IPv6 recebido. Se o endereço IPv6 de destino
corresponder a uma entrada na tabela SID local, o comportamento
associado será aplicado, caso contrário, o pacote seguirá o
processamento normal do subsistema de roteamento. O código fonte
do SREXT junto com a caixa Vagrant estão disponíveis em [207].
Usando a caixa Vagrant, é possível inicializar um pequeno testbed em
poucos minutos e iniciar os experimentos nos recursos do SREXT.
FRRouting (FRR) [208] é uma pilha de protocolos de roteamento de
código aberto para Linux bifurcada de Quagga [209]. Em FRR, há um
suporte experimental [210] do rascunho [25] que define as extensões
OSPFv2 para Segment Routing (SR-MPLS). No momento da escrita,
não há suporte para SRv6.
O projeto SPRING-OPEN [145] fornece uma implementação baseada
em SDN de SR-MPLS. A arquitetura é baseada em um plano de
controle SDN clássico (centralizado logicamente), construído sobre o
ONOS. Parte deste trabalho convergiu mais tarde em Trellis [189], um
tecido multifuncional de código aberto que suporta redes de acesso
distribuído, NFV e aplicativos de nuvem de borda.
O Trellis também inclui o suporte de dispositivos P4/P4Runtime [211]
[212] bem como dispositivos habilitados para Stratum [213]. Trellis tem
sido usado como tecido underlay/overlay no projeto CORD [214] que
visa redesenhar arquiteturas de escritórios centrais.
Recentemente, foi integrado no projeto SEBA [215] que visa redes de
acesso residencial. Toda a pilha de software e a documentação estão
disponíveis gratuitamente em [216].
Além disso, um tutorial junto com uma VM pronta para uso pode ser
baixado de [217].
PMSR ([15] e [114]) fornece uma implementação de código aberto
de SR-MPLS juntamente com a realização de um plano de controle
SDN. O plano de dados aproveita a arquitetura OSHI ([218], [219]) que
combina um plano de dados SDN,
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
implementado com Open vSwitch [220], e lógica de controle OSPFv2,
realizado com Quagga. Esta arquitetura é estendida no PMSR com a
introdução de uma entidade de extração de rotas que se conecta ao
Quagga e recebe atualizações de rotas usando a interface FPM
fornecida pelo Quagga [209]. Essas rotas são então traduzidas em
SIDs e instaladas no plano de dados SDN como regras de
encaminhamento OpenFlow MPLS. Os autores fornecem um conjunto
de ferramentas de gerenciamento [221] que auxiliam os experimentadores sem a necessidade de alterações de configuração. A implementação
e os aliviam de um enorme esforço de configuração. Um tutorial para
começar a trabalhar com PMSR está disponível em [222]; em vez disso,
uma VM pronta para uso com todas as dependências instaladas pode
ser baixada em [223].
Software Resolved Network (SRN) (descrito em [148] e [149]) é uma
variante da arquitetura SDN. O controlador de rede é logicamente
centralizado e co-localizado com um resolvedor de DNS e usa extensões
do protocolo DNS para interagir com os hosts finais. O Open vSwitch
Database Management Protocol (OVSDB) [224] é utilizado para
possibilitar a comunicação entre o controlador SDN e os nós da rede: i)
este último preenche o banco de dados distribuído com as informações
de topologia e metadados TE; ii) o primeiro, uma vez calculado o
caminho, mediante solicitação, preenche a instância OVSDB com a
lista de segmentos SRv6 correspondente aos requisitos desejados.
Finalmente, isso é puxado pelo dispositivo de acesso que permite a
comunicação dos hosts finais. O código fonte está disponível
gratuitamente em [225].
Uma visão geral da arquitetura pode ser encontrada em [226]. Uma VM
pronta para uso com experimentos empacotados pode ser criada
usando as instruções em [227]. [4] propõe uma arquitetura SDN clássica
para a tecnologia SRv6: uma lógica centralizada toma decisões
sobre as Listas de Segmentos que precisam ser aplicadas para
implementar os serviços, então o controlador SDN, usando uma API
southbound, interage com os dispositivos habilitados para SR para
impor a aplicação de tais Listas de Segmentos. O código relacionado à
arquitetura SDN, ou seja, as quatro diferentes implementações da API
Southbound e a descoberta da topologia, podem ser baixados da página
do projeto [228]. Além disso, os autores, para apoiar os aspectos de
desenvolvimento e teste, criaram um sistema de emulação baseado em
Intent para construir experimentos realistas e reprodutíveis, aliviando
os experimentadores de um enorme esforço de configuração. As
ferramentas de emulação estão disponíveis em [229].
SRV6Pipes [164] é uma extensão da implementação SRv6 no
kernel Linux [193] que permite o encadeamento e operação de funções
na rede operando em streams.
As políticas SRv6 são instaladas usando a arquitetura SRN [148]
descrita anteriormente nesta seção. No entanto, os componentes SRN
não são obrigatórios, pois as políticas SRv6 podem ser instaladas nos
nós de borda usando o utilitário iproute. O SRv6Pipes é composto por
vários componentes que necessariamente precisam ser instalados nas
máquinas de destino: proxy TCP, Kernel com patch e utilitários de
espaço do usuário. Os componentes mínimos podem ser baixados do
repositório do projeto [230]. O código completo dos experimentos junto
com um passo a passo pode ser encontrado em [231].
SRNK [21] estende a implementação do SRv6 no kernel Linux [193]
adicionando o suporte para os comportamentos End.AS e End.AD. O
código fonte está disponível gratuitamente em [232], onde é possível
baixar o Linux corrigido
30
kernel (a partir da ramificação 4.14.0) e o iproute2 corrigido (a partir da
tag iproute2-ss171112). Em vez disso, as etapas detalhadas de
configuração do SR-proxy são relatadas nos Apêndices A e B de [21].
[133] descreve a implementação de um elemento de cálculo de
caminho capaz de computar caminhos SR robustos disjuntos que
permanecem disjuntos mesmo após um conjunto de falhas de entrada
java dos algoritmos, as topologias públicas utilizadas para os
experimentos, os resultados experimentais e um passo a passo
detalhado para replicar os experimentos do artigo estão disponíveis em [233].
D. Implementações de hardware, esforços de interoperabilidade e
implementações para SRv6
[234] fornece uma visão geral das implementações de roteamento
de segmento IPv6, descreve alguns cenários de interoperabilidade que
foram demonstrados em eventos públicos e relata uma lista de
implementações recentes de SRv6 em redes de produção.
Com relação às implementações de hardware [234] menciona 8
fornecedores que declaram suporte à produção de SRv6 em seu
hardware. As plataformas ASR 1000, ASR 9000, NCS 5500, NCS 540
e NCS 560 são relatadas como as plataformas de roteamento Cisco
que suportam o processamento SRH; ASR 9000 e NCS 5500 sendo
implantados em redes de produção. Quanto à Huawei, as plataformas
relatadas são: ATN, CX600, NE40E, ME60, NE5000E, NE9000 e NG-
OLT MA5800, todas com código de envio VRPV8. Os dispositivos
programáveis baseados no chipset Tofino [235] podem ser programados
para suportar o processamento SRH.
Isso também é verdade para a implementação de software de referência
dos dispositivos P4 [236], os dispositivos baseados em Stratum [213] e
todos os chipsets programáveis (Cavium Xpliant [237] para dar um
exemplo). Outras implementações de hardware SRv6 são relatadas
para a família Prestera de switches Ethernet da Marvell, para o roteador
SkyFlux UAR500 da UTStarcom. Spirent e Ixia também suportam SRv6,
respectivamente em suas plataformas de teste TestCenter e IxNetwork.
Finalmente, conforme relatado em [2], as NPUs Trio e vTrio da Juniper
possuem um suporte experimental de SRH (modo de inserção SRH e
processamento final de endereços de interfaces).
Três eventos de interoperabilidade estão listados em [234]. Os
primeiros cenários de teste de interoperabilidade (em ordem cronológica)
foram apresentados na conferência SIGCOMM de 2017 [238]. O
conjunto de experimentos incluiu um cenário de VPN L3 aumentado
com funcionalidade TE e processamento de encadeamento de funções de serviços.
Os roteadores SREXT, VPP, Linux kernel, Barefoot Tofino, Cisco
NCS5500 e Cisco ASR1000 foram os dispositivos de rede que
implementaram os comportamentos SRv6. Iptables (firewall) e Snort
(Intrusion Detection System) foram usados como funções de serviço.
Finalmente, o Wireshark e o tcpdump foram aproveitados para verificar
as operações adequadas da rede. O segundo conjunto de cenários de
teste de interoperabilidade foi executado em março de 2018 pelo
European Advanced Networking Test Center (EANTC) e seus resultados
[239] foram apresentados na conferência MPLS + SDN + NFV World
Congress em abril de 2018. Nesses testes, as implementações da
CISCO e UTStarcom e as plataformas de teste da Ixia e Spirent
estiveram envolvidas. Os testes envolveram VPNs IPv4 de camada 3
baseadas em SRv6 (incluindo também recursos de Engenharia de
Tráfego no underlay SRv6)
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
e mecanismos de redirecionamento rápido independentes de topologia (TI-
LFA) baseados em SRH. O terceiro conjunto de cenários de teste de
interoperabilidade foi executado em março de 2019 e seus resultados [239]
foram apresentados na conferência MPLS + SDN + NFV World Congress em
abril de 2019. Nesses testes, uma plataforma de roteamento da Cisco (NCS
5500) e duas da Huawei (NE9000-8 e NE40E F1A) estavam envolvidos. Os
testes envolveram VPNs IPv4 e IPv6 de camada 3 baseadas em SRV6, a
validação de alguns comportamentos SRv6, reencaminhamento rápido baseado
em SRv6 e procedimentos OAM (Ping e traceroute) baseados em [49].
Oito implementações em grande escala do SRv6 estão listadas em [234],
envolvendo as seguintes redes de operadoras em todo o país: Soft bank
(Japão), China Telecom (China), Iliad (Itália), LINE Corporation (Japão), China
Unicom (China), CERNET2 (China), MTN Uganda Ltd (Uganda), Rede NOIA.
Encaminhamos o leitor a [234] para obter detalhes sobre essas implantações.
A minuta [234] trata também das aplicações open source que suportam o
processamento do cabeçalho IPv6 Segment Routing, entre as quais podemos
citar os conhecidos Wireshark [240], tcpdump [241], iptables [242], nftables
[243] e bufo [244]. [169] relata a implementação de uma solução que transfere
o encapsulamento SRH, as operações de decapsulação e o manuseio do
cache SRv6 dos servidores para as placas programáveis Intel FPGA. Open
Programmable Accelerator Engine [245] desenvolvido pela Intel e o software
roteador VPP são usados como frameworks básicos. Os autores definiram
uma nova divisão funcional dos comportamentos do SRv6 entre o hardware e
o software e o interfuncionamento é realizado introduzindo novos nós de grafos
no VPP. Essas extensões para o gráfico VPP são capazes de codificar/
decodificar/processar metadados trocados entre o VPP e as placas Intel. Por
exemplo, na direção de entrada, o cartão executa uma pesquisa SID e, com
base no resultado da pesquisa, pode remover os cabeçalhos IPv6/SRH
externos e adicionar seu próprio cabeçalho de metadados. Como o VPP é
aumentado com novos nós é capaz de processar este meta-cabeçalho e os
pacotes internos. Como explicado acima, a solução descarrega parcialmente
as funções para o hardware, por exemplo, Route lookup e, em geral, as
funções do plano de controle ainda são feitas em software pelo VPP,
aproveitando a CPU dos servidores.
VI. LIÇÕES APRENDIDAS
Nesta seção, descrevemos os principais resultados aprendidos
durante a atividade de pesquisa. Primeiro nos concentramos em algumas
considerações gerais, depois elaboramos os resultados relacionados à pesquisa.
Apesar do conceito de Source Routing já ter sido proposto
´ no passado (final
de 70âÿ Z), sua implantação em redes IPv4 não foi suportada, principalmente
por questões de segurança. A nova arquitetura SR oferece uma solução segura
para a implantação do conceito de roteamento de origem nas redes das
operadoras. O SR também fornece uma solução escalável: i) o número de
estados de fluxo a serem mantidos nos nós da rede é altamente reduzido, ii)
apenas os nós de fronteira são envolvidos por procedimentos de classificação
e os nós de trânsito não mantêm nenhuma informação de estado de fluxo.
SR-MPLS foi a primeira implantação de conceitos SR, somente nos últimos
anos a arquitetura SRv6 foi definida. A arquitetura SR MPLS tem, a nosso ver,
o principal mérito de não
31
exigindo qualquer alteração no plano de encaminhamento MPLS. Desta forma,
o SR-MPLS representa uma solução simples para o provedor de serviços com
infraestrutura IPv4. As mesmas considerações se aplicam ao SRv6, a estratégia
de transição de uma rede IPv6 clássica para uma SRv6 pode ser realizada em
etapas sucessivas sem interrupção do serviço.
Também notamos que a implementação do SR-MPLS não recebeu a
mesma atenção que o SRv6 está recebendo da comunidade de pesquisa.
Acreditamos que a disponibilidade de diferentes implementações de código
aberto (kernel Linux e VPP) desde o início contribuiu decisivamente para isso.
Outra razão deve ser encontrada nas extensões do plano de controle
necessárias.
Embora o SR-MPLS tenha sido a primeira implementação, os pesquisadores
tiveram que lutar para ter algo com que trabalhar. A implementação do plano
de dados MPLS tem sido instável por muito tempo no kernel Linux, e uma
implementação completamente revisada foi mesclada recentemente.
Finalmente, o SR MPLS requer extensões para os protocolos de roteamento e
não existiam tais extensões no momento em que o SR estava sendo
inicialmente estudado.
Uma das principais características do SR é o suporte nativo de cenários
NFV/SFC. Além disso, o modelo de programação de rede do SRv6 oferece a
possibilidade de virtualizar qualquer serviço combinando as funções básicas
em um programa de rede que está embutido no cabeçalho do pacote
(implementar um modelo de programação de rede no plano de dados MPLS
não seria escalável, apesar de sua viabilidade). Neste contexto, acreditamos
que o SRv6 pode simplificar as arquiteturas de rede em relação ao SR-MPLS,
uma vez que o uso de diferentes soluções de tunelamento pode ser evitado.
Como tal, o SRv6 é uma opção atraente para operadoras que estão implantando
novas redes ou planejando a evolução de suas arquiteturas de rede.
Durante a revisão dos Internet Drafts, RFCs e patentes notamos que há
uma clara tendência nas atividades de padronização de “seguir” patentes. De
fato, a maioria das patentes também foi padronizada posteriormente ou foi
incluída em vários
atividades de padronização lideradas pelos mesmos fornecedores. As patentes
mais recentes também destacam que o SR pode ter um papel significativo na
implantação de tecnologias centrais de rede, como fatiamento de rede, 5G e
rede baseada em nuvem.
Com relação aos resultados da atividade de pesquisa e seguindo a
classificação fornecida na Seção IV, descreveremos brevemente as lições
mais significativas provenientes de diferentes categorias de pesquisa.
A atividade de pesquisa relacionada à categoria Monitoramento (seção IV-
A) destaca um interesse significativo em soluções para melhorar as ferramentas
de monitoramento existentes ou para definir novas ferramentas explorando
recursos de SR. Contrariamente, faltam trabalhos focados no monitoramento
de falhas de SR, como configurações incorretas, SIDs indefinidos, buracos
negros relacionados a SR, perda de pacotes, etc.
Passando para a categoria Engenharia de Tráfego (seção IV-B), o principal
resultado da atividade de revisão é que uma das características interessantes
do roteamento SR, ou seja, a capacidade de dividir o tráfego em vários SLs,
não é explorada na prática. Este resultado inesperado pode ser motivado pela
capacidade de obter uma alta flexibilidade de roteamento também com um
único SL para cada fluxo; em qualquer caso, o uso de vários SL por fluxo pode
ser considerado no futuro para melhorar ainda mais as soluções de TE.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
Uma consideração adicional vem da categoria Centrally Controlled Architecture
(seção IV-D): a comunidade científica é orientada para um plano de controle
centralizado para redes SR-MPLS, mesmo que um plano de controle distribuído
também seja suportado. No entanto, esta abordagem requer extensões nos
protocolos de roteamento no caso do MPLS, o que representou uma grande
barreira, fazendo com que muitos trabalhos decidissem alavancar a abertura da
abordagem SDN para superar tais limitações. Também é interessante notar que a
mesma tendência não pode ser encontrada com trabalhos relacionados ao SRv6,
onde tais extensões em protocolos de roteamento não são estritamente necessárias.
Os trabalhos relacionados ao Path Encoding (seção IV-E) destacam dois
resultados interessantes. Em primeiro lugar, o grande esforço realizado pelos
pesquisadores na redução da sobrecarga nos cabeçalhos dos pacotes demonstra
que é visto como um fator limitante para implantações de SR. Duas escolas de
pensamento podem ser encontradas: i) otimizar a tradução dos caminhos em LSs;
ii) reduzir seu impacto usando uma codificação mais inteligente dos caminhos em
listas de segmentos.
A segunda lição aprendida está relacionada aos adj-sids; eles são amplamente
usados por trabalhos de codificação de caminho para aumentar a flexibilidade de
roteamento, enquanto não são totalmente explorados em trabalhos de TE: a razão
pode ser que a inclusão de adj-sids leva a um aumento na complexidade dos
modelos de otimização usados por algoritmos de TE.
Será interessante investigar o impacto de adj-sids em novas soluções de TE
baseadas em SR, tanto em termos de desempenho quanto de complexidade.
Os trabalhos relacionados à categoria Network Programming (seção IV-F)
sugerem que esse recurso SRv6 abre um amplo leque de oportunidades de
pesquisa: pode ser aplicado em diferentes casos de uso, desde o Service Function
Chaining até a implementação de operações complexas (como como o
gerenciamento de migração de VM em uma rede DC). Acreditamos que a
programação em rede atrairá atenção significativa nos próximos anos.
Por fim, uma interessante consideração da categoria Avaliação de Desempenho
(seção IV-G) está relacionada aos temas dos trabalhos analisados. Todos os
artigos concentram-se no plano de dados, enquanto o único trabalho que estuda
o desempenho do plano de controle é [4] (na verdade, apenas uma avaliação de
desempenho de diferentes implementações de southbound foi conduzida).
VII. DIREÇÕES DE PESQUISA FUTURA
A maioria dos trabalhos de SR que revisamos se concentrou na definição de
novas soluções para problemas clássicos de rede (como Monitoramento,
Engenharia de Tráfego e Recuperação de Falhas) ou na otimização de
procedimentos específicos de SR (como Path Encoding). Em geral, esses trabalhos
mostraram que a RS pode trazer melhorias significativas em relação a outras
soluções e acreditamos que ainda há espaço e interesse em ampliar os resultados
alcançados nessas áreas. Além disso, tentamos identificar e discutir um conjunto
de direções de pesquisa para roteamento de segmentos que definitivamente vale
a pena explorar em um futuro próximo: i) suporte a encadeamento de funções de
serviço, ii) aspectos de implementação de host final SRv6, iii) orquestração em
nuvem, iv) Integração com Aplicativos, v) 5G, vi.) IoT. Todas essas áreas de
pesquisa são baseadas no SRv6, ou seja, no Segment Routing sobre o plano de
dados IPv6, pois acreditamos que a evolução futura do Segment Routing será
baseada no SRv6.
32
A. Suporte ao encadeamento de funções de serviço
O recurso de Programabilidade do SRv6 representa um fator de habilitação
para a implementação de Network Function Virtualization (NFV) e Service Function
Chaining (SFC) em redes de provedores. Nesse sentido, novos modelos de
abstração para o gerenciamento de Funções de Rede por meio de procedimentos
de controle SRv6 dedicados podem ser estudados.
B. Aspectos de implementação de host final SRv6
Outro tópico interessante está relacionado à implementação do SRv6 em hosts
finais. Um aspecto está relacionado à movimentação de funções SRv6 em hosts
finais do software para mais perto do hardware com SmartNICs. NICs programáveis
permitem implementar o processamento de tráfego de rede no NIC em vez de
usar a CPU dos nós/dispositivos finais. Outro aspecto está relacionado à
exploração dos recentes avanços nas redes do kernel Linux para processamento
rápido de pacotes, nomeadamente eBPF [185] e XDP [246] para implementação
de funções SRv6.
C. Orquestração em Nuvem
A terceira oportunidade de pesquisa diz respeito à integração da tecnologia
SRv6 em orquestradores de nuvem como OpenStack [247] e Kubernetes [248].
Considerando cenários de rede de Data Center, será possível substituir o
mecanismo de plano de dados real baseado em mecanismos de encapsulamento
legados como VXLAN por SRv6, com uma simplificação drástica da pilha de rede:
as informações necessárias serão integradas em SIDs SRv6 e/ou no Campo TLV,
sem necessidade de cabeçalhos dedicados para tunelamento.
D. Integração com Aplicativos
Permitir a interação direta de aplicativos com recursos SRv6 pode possibilitar
serviços inovadores e melhorar a eficiência dos já existentes. As aplicações
podem usar SIDs SRv6 para expressar seus requisitos de serviço e interagir com
recursos de rede, participando dinamicamente na definição/composição de
serviços de rede. Para alcançar essa interação, primeiro as APIs do sistema
operacional (por exemplo, Linux) precisam ser estendidas e, em seguida, os
aplicativos compatíveis com SRv6 precisam ser desenvolvidos.
E. 5G
O SRv6 está sendo considerado para o plano de dados de futuros lançamentos
de redes 5G graças aos seus recursos de programação e direcionamento de
tráfego sem estado. Por um lado, o SRv6 pode suportar recursos 5G, como
fatiamento de rede, por outro lado, será importante avaliar o desempenho do plano
de dados baseado em SRv6, para verificar se as restrições estritas de 5G na
latência são atendidas.
F. Internet das Coisas
Considerando o espaço de problemas da Internet das Coisas, que inclui
aspectos de escalabilidade, aspectos de roteamento, interações entre as camadas
de rede e de aplicação, a aplicação da arquitetura SRv6 parece bastante
promissora.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
VIII. CONCLUSÃO
A tecnologia Segment Routing é baseada em paradigmas de
roteamento de origem e encapsulamento. O Segment Routing suporta
serviços como Engenharia de Tráfego, Redes Privadas Virtuais,
Restauração Rápida em backbones IP e datacenters, e provou ser
flexível no suporte a novos casos de uso. Além disso, a arquitetura SR
reduz a quantidade de informações de estado que precisam ser
configuradas nos nós principais.
SR-MPLS e SRv6 são as duas instâncias de plano de dados da
arquitetura SR. Este é o primeiro tutorial e trabalho de pesquisa que
cobre em detalhes a nova solução SRv6 (ou seja, SR sobre plano de
dados IPv6), que representa a implementação mais promissora para
atividades de pesquisa futuras. O SRv6 fornece uma solução consistente
para resolver problemas de longo prazo em redes IP, simplificando
pilhas de protocolos e melhorando a escalabilidade em relação às
soluções atuais.
Na pesquisa abordamos trabalhos de padronização, patentes e
atividades de pesquisa relacionadas ao Roteamento de Segmentos.
Também consideramos as recentes implantações de SR em redes reais
e implementações de SR existentes, com foco nas ferramentas de
código aberto que podem apoiar atividades de pesquisa e desenvolvimento de SR.
Quanto às atividades de pesquisa, cobrimos cerca de 90 artigos
científicos relacionados às RS e propusemos uma taxonomia para sua
classificação. Um dos principais resultados da classificação foi identificar
as relações entre as características da RS e os tópicos de pesquisa.
Por exemplo, o paradigma de roteamento de origem acabou sendo o
principal recurso de habilitação para a implementação de soluções de
Engenharia de Tráfego em uma rede SR, enquanto o recurso de
flexibilidade de roteamento é usado principalmente para realizar
ferramentas de monitoramento de rede. Também identificamos os
documentos de padronização de RS mais interessantes e fornecemos
uma taxonomia para sua classificação. Várias patentes relacionadas ao
Segment Routing também foram discutidas.
A revisão das implementações de SR destacou a maturidade das
soluções de código aberto baseadas no kernel Linux e VPP. Tanto o
Linux quanto o VPP, amplamente utilizados pela comunidade de
pesquisadores e desenvolvedores, permitem a fácil implantação de um
playground SR virtual. Como parte de nossa atividade de pesquisa,
também relatamos nossa visão e nossa experiência em termos de
lições aprendidas e tópicos de pesquisa futuros.
Esperamos que este tutorial e trabalho de pesquisa atraia mais
atenção da comunidade de pesquisa para a tecnologia Segment Routing
e motive novos pesquisadores a participar do desenvolvimento de
novos casos de uso e esforços de padronização. Antecipamos direções
de pesquisa futuras que podem ser tomadas como pontos de partida.
Novas versões desta pesquisa estarão disponíveis em [249].
Além disso, incentivamos fortemente a comunidade a fornecer feedback
e atualizações à medida que novos trabalhos de pesquisa e implantações
de SR surgem e a tecnologia evolui. Por isso criamos um repositório
público1 , onde pesquisadores interessados
esta documentação.
podem contribuir e atualizar
AGRADECIMENTOS
Este trabalho recebeu financiamento da Cisco University
Fundo do Programa de Pesquisa e da UE H2020 5G-EVE
1https://github.com/netgroup/sr-survey
33
projeto.
REFERÊNCIAS
[1] A. Bashandy et al., “Segment Routing with MPLS data plane”, Internet
Engineering Task Force, Internet-Draft draft-ietf-spring-segment routing-
mpls, março de 2019, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls [2] C. Filsfils,
D. Dukes (eds.) et al., “IPv6 Segment Routing Header (SRH )”, RFC 8754,
março de 2020. [Online]. Disponível: https://tools.ietf.org/html/rfc8754 [3]
C. Filsfils et al., "Programação de Rede SRv6", Força Tarefa de Engenharia
da Internet, Internet-Draft draft-ietf-spring-srv6-network-programming , janeiro
de 2020, trabalho em andamento. [Conectados]. Disponível : https://
tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
[4] P. Ventre et al., “SDN Architecture and Southbound APIs for IPv6 Segment
Routing Enabled Wide Area Networks”, IEEE Transactions on Network
and Service Management, 2018.
[5] J. Postel (ed.), “Internet Protocol”, Internet Requests for Comments, RFC
Editor, RFC 791, setembro de 1981. [Online]. Disponível: https://
tools.ietf.org/html/rfc791 [6] A. Farrel, O. Komolafe e S. Yasukawa, “An
Analysis of Scaling Issues in MPLS-TE Core Networks,” IETF RFC 5439, fev.
2009.
[Conectados]. Disponível: https://tools.ietf.org/html/
rfc5439 [7] S. Previdi et al., “Source Packet Routing in Networking (SPRING)
Declaração do problema e requisitos,” Internet Requests for Comments,
RFC Editor, RFC 7855, maio de 2016. [Online]. Disponível: https://
tools.ietf.org/html/rfc7855 [8] C. Filsfils et al., “Resiliency Use Cases in
Source Packet Routing in Networking (SPRING) Networks”, IETF RFC 8355,
março de 2018.
[Conectados]. Disponível: https://tools.ietf.org/html/
rfc8355 [9] J. Brzozowski et al., “Use Cases for IPv6 Source Packet Routing in
Networking (SPRING)”, IETF RFC 8354, março de 2018. [Online ].
Disponível: https://tools.ietf.org/html/rfc8354
[10] S. Previdi et al., “Segment Routing Architecture,” IETF RFC 8402, Jul. 2018.
[Online]. Disponível: https://tools.ietf.org/html/rfc8402/ [11] R. Geib et al.,
“A Scalable and Topology-Aware MPLS Data-Plane Monitoring System”, RFC
8403, julho de 2018. [Online ]. Disponível: https://tools.ietf.org/html/rfc8403
[12] C. Filsfils et al., “The Segment Routing Architecture,” Global
Communications Conference (GLOBECOM), 2015 IEEE, pp. 1–6, 2015 .
[13] A. Farrel e R. Bonica, "Segment Routing: Cutting Through the Hype and
Finding the IETF's Innovative Nugget of Gold", IETF Journal, vol. 13, 1 de
julho de 2017. [On-line]. não.
Disponível : https://www.ietfjournal.org/
segment-routing-cutting-through-the-hype-and-finding-the-ietfs-innovative-nugget-o
[14] IAZN Abdullah e I. Hussain, “Segment Routing in Software Defined Networks:
A Survey”, IEEE Communications Surveys & Tutorials, 2018.
[15] S. Salsano et al., “PMSR-Poor Man's Segment Routing, uma abordagem
minimalista para Segment Routing e um caso de uso de Engenharia de
Tráfego”, em Network Operations and Management Symposium (NOMS),
2016 IEEE/IFIP. IEEE, 2016, pp. 598–604.
[16] D. Farinacci, T. Li et al., "Encapsulamento de Roteamento Genérico (GRE)",
Internet Requests for Comments, RFC Editor, RFC 2784, março de
2000. [Online]. Disponível: https://tools.ietf.org/html/rfc2784 [17] M.
Mahalingam, D. Dutt et al., “Virtual eXtensible Local Area Network
(VXLAN): A Framework for Overlaying Layer 2 Networks over Layer
3 Networks,” Internet Requests for Comments, RFC Editor, RFC
7348, agosto de 2014. [Online]. Disponível: https://tools.ietf.org/html/
rfc7348 [18] H. Ichihara, T.Tsuchiya. Rede de datacenter LINE com
SRv6. [Conectados]. Disponível : https://speakerdeck.com/line_developers/
line-data-center-networking-with-srv6
[19] P. Quinn, U. Elzur, C. Pignataro, (eds.), “Network Service Header (NSH),”
Internet Requests for Comments, RFC Editor, RFC 8300, janeiro de 2018.
[Online]. Disponível: https://tools.ietf.org/html/rfc8300 [20] O 5G significa
que podemos finalmente atualizar o protocolo do plano de dados móveis.
[Conectados]. Disponível: https://www.metaswitch.com/blog/ does-5g-mean-
we-can-finally-update-the-mobile-data-plane-protocol [21] A. Mayer et al.,
“An Efficient Implementação do kernel Linux do encadeamento de funções de
serviço para VNFs herdados com base no roteamento de segmento IPv6”,
na 5ª Conferência Internacional IEEE sobre Software de Rede (NetSoft
2019). IEEE, 2019.
[22] C. Filsfils et al., "ID de segmento indexado", US9559954B2 - 2014.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
[23] F. Clad et al., "Programação de Serviço com Roteamento de Segmento", Internet
Força-Tarefa de Engenharia, Internet-Draft draft-ietf-spring-sr-service programming-01,
outubro de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-spring-sr-service-programming
[24] S. Matsushima et al., “Segment Routing IPv6 for Mobile User Plane,”
Força-Tarefa de Engenharia da Internet, rascunho da Internet-ietf-dmm-srv6-
mobile-uplane, março de 2019, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane
[25] P. Psenak et al., "Extensões OSPF para Roteamento de Segmento", Internet
Força-Tarefa de Engenharia, extensões de roteamento do segmento de rascunho da
Internet-ietf-ospf, dezembro de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[26] P. Psenak e S. Previdi, “Extensões OSPFv3 para
Segment Routing,” Internet Engineering Task Force, Internet Draft draft-ietf-ospf-ospfv3-
segment-routing-extensions, janeiro de 2019,
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-ietf-ospf-ospfv3-segment-routing-extensions
[27] S. Previdi et al., "Extensões IS-IS para roteamento de segmento", Internet
Força-Tarefa de Engenharia, extensões de roteamento do segmento de rascunho da
Internet-ietf-isis, maio de 2019, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions
[28] P. Psenak et al., “IS-IS Extensions to Support Routing over IPv6
Dataplane,” Internet Engineering Task Force, Internet-Draft draft ietf-lsr-isis-srv6-
extensions, maio de 2019, trabalho em andamento. [Conectados].
Disponível: https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions
[29] Z. Li et al., "Extensões OSPFv3 para SRv6", Engenharia de Internet
Task Force, Internet-Draft draft-li-ospf-ospfv3-srv6-extensions, mar.
2019, obra em andamento. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-li-ospf-ospfv3-srv6-extensions
[30] C. Filsfils et al., "Orquestração de rede de longa distância baseada em roteamento de
segmento em um ambiente de rede", US9647944B2 - 2014.
[31] H. Gredler, "BGP Link-State Extensions for Segment Routing,"
US9660897B1 - 2014.
[32] S. Sivabalan et al., "Extensões PCEP para Roteamento de Segmentos",
Força-Tarefa de Engenharia da Internet, roteamento de segmento de rascunho da
Internet-ietf-pce, outubro de 2018, trabalho em andamento. [Conectados]. Disponível: https:
//tools.ietf.org/html/draft-ietf-pce-segment-routing
[33] C. Filsfils et al., “Segment Routing Policy Architecture,” Internet
Força-Tarefa de Engenharia, Política de Roteamento do Segmento de Mola da IETF,
rascunho da Internet, outubro de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy
[34] C. Filsfils et al., “Considerações de Implementação e Implementação de Políticas de SR”,
Força-Tarefa de Engenharia da Internet,
Projeto de Internet-rascunho-filsfils-spring-sr-política-considerações, outubro de 2018,
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
rascunho-filsfils-spring-sr-política-considerações
[35] K. Raza et al., “YANG Data Model for Segment Routing Policy,”
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-raza-spring sr-policy-yang,
maio de 2019, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-raza-spring-sr-policy-yang
[36] C. Filsfils et al., "Ilustrações para Programação de Rede SRv6", Força-Tarefa de
Engenharia da Internet, Internet-Draft draft-filsfils-spring-srv6-
net-pgm-illustration, fevereiro de 2019, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration
[37] C. Filsfils et al., "Segmento de prefixo BGP em data centers de grande escala",
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-ietf-spring segment-routing-
msdc, novembro de 2018, trabalho em andamento. [Conectados]. Disponível: https://
tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc
[38] C. Filsfils et al., “BGP Centralizado de Roteamento de Segmento
Peer Engineering," Internet Engineering Task Force, Internet Draft draft-ietf-spring-
segment-routing-central-epe, dezembro de 2017,
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-ietf-spring-segment-routing-central-epe
[39] C. Filsfils et al., “Interconectando milhões de terminais com
Roteamento de segmento”, RFC 8604, junho de 2019. [Online]. Disponível:
https://rfc-editor.org/doc/rfc8604
[40] D. Dukes et al., "SR para SDWAN - VPN com SLA Underlay,"
Força-Tarefa de Engenharia da Internet, rascunho da Internet-Dukes-spring sr-for-
sdwan, dezembro de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan
[41] P. Camarillo et al., “Segment Routing IPv6 for mobile user-plane
PoCs,” Internet Engineering Task Force, Internet-Draft draft-camarillo dmm-srv6-mobile-
pocs, outubro de 2018, trabalho em andamento. [Conectados]. Disponível: https://
tools.ietf.org/html/draft-camarillo-dmm-srv6-mobile-pocs
[42] Z. Ali et al., “Blocos de construção para fatiar no segmento
Routing Network”, Força-Tarefa de Engenharia da Internet, Internet Draft draft-ali-spring-
network-slicing-building-blocks, março de 2019,
34
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-ali-spring-network-slicing-building blocks
[43] C. Filsfils et al., "Segment Routing Traffic Accounting Counters,"
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-filsfils-spring sr-traffic-
counters, junho de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-filsfils-spring-sr-traffic-counters
[44] M. Anand et al., "Integração Óptica de Pacotes no Roteamento de Segmentos",
Força-Tarefa de Engenharia de Internet, rascunho de Internet-Draft-anand-spring poi-
sr, janeiro de 2019, trabalho em andamento. [Conectados]. Disponível: https:
//tools.ietf.org/html/draft-anand-spring-poi-sr
[45] S. Litkowski et al., “Topology Independent Fast Reroute
usando Segment Routing”, Força-Tarefa de Engenharia da Internet,
Rascunho da Internet-ietf-rtgwg-segment-routing-ti-lfa, março de 2019,
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-ietf-rtgwg-segment-routing-ti-lfa
[46] A. Bashandy et al., "Evitação de loop usando roteamento de segmento", Internet
Força-Tarefa de Engenharia, Internet-Draft draft-bashandy-rtgwg-segment routing-uloop,
setembro de 2018, trabalho em andamento. [Conectados]. Disponível: https:
//tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-uloop
[47] S. Hegde et al., "Evitação de micro-loop usando SPRING",
Força-Tarefa de Engenharia da Internet, rascunho da Internet-Draft hegde-rtgwg-
microloop-avoidance-using-spring, julho de 2017, trabalho
em andamento. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-hegde-rtgwg-microloop-avoidance-using-spring/
[48] N. Kumar et al., “Label Switched Path (LSP) Ping/Traceroute
para Segment Routing (SR) IGP-Prefixo e IGP-Adjacency Segment
Identificadores (SIDs) com Planos de Dados MPLS,” IETF RFC 8287, Dec.
2017. [On-line]. Disponível: https://tools.ietf.org/html/rfc8287
[49] Z. Ali et al., “Operações, Administração e Manutenção (OAM)
em Redes de Roteamento de Segmento com Plano de Dados IPv6 (SRv6)”,
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-ietf-6man-spring srv6-
oam-03, dezembro de 2019, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03
[50] Z. Ali et al., "Contabilidade de Tráfego em Redes de Roteamento de Segmento",
Força-Tarefa de Engenharia de Internet, Internet-Draft draft-ali-spring-sr traffic-
accounting, junho de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting
[51] Z. Ali et al., “Detecção de encaminhamento bidirecional (BFD) para segmento
Políticas de Roteamento para Engenharia de Tráfego”, Engenharia de Internet
Task Force, Internet-Draft draft-ali-spring-bfd-sr-policy, outubro de 2018,
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-ali-spring-bfd-sr-policy
[52] R. Gandhi et al., "Medição de desempenho em banda para segmento
Routing Networks with MPLS Data Plane,” Internet Engineering
Task Force, Internet-Draft draft-gandhi-spring-rfc6374-srpm-mpls, 2 de fevereiro de 2018.
2019, obra em andamento. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-gandhi-spring-rfc6374-srpm-mpls
[53] R. Gandhi et al., “Medição de desempenho em banda usando
Caminho UDP para Redes de Roteamento de Segmento”, Engenharia da Internet
Task Force, Internet-Draft draft-gandhi-spring-rfc6374-srpm-udp, fev.
2019, obra em andamento. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-gandhi-spring-rfc6374-srpm-udp
[54] R. Gandhi (Ed.) et al., “Medição de Desempenho Usando TWAMP
Light for Segment Routing Networks,” Tarefa de Engenharia da Internet
Força, rascunho da Internet-gandhi-spring-twamp-srpm, dezembro de 2019,
trabalho em progresso. [Conectados]. Disponível: https://tools.ietf.org/html/
draft-gandhi-spring-twamp-srpm
[55] D. Frost e S. Bryant, “Packet Loss and Delay Measurement for
MPLS Networks,” IETF RFC 6374, set. 2011. [Online]. Disponível:
https://tools.ietf.org/html/rfc6374
[56] S. Bryant, S. Sivabalan e S. Soni, “UDP Return Path for Packet
Medição de Perda e Atraso para Redes MPLS,” IETF RFC 7876,
Jul. 2016. [Online]. Disponível: https://tools.ietf.org/html/rfc7876
[57] A. Bashandy et al., “Segment Routing interworking with LDP,” Internet
Força-Tarefa de Engenharia, Internet-Draft draft-ietf-spring-segment routing-ldp-interop,
setembro de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop
[58] P. Sarkar et al., "Segmentos Anycast no Roteamento de Segmento Baseado em MPLS,"
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-ietf-spring-mpls anycast-
segments, janeiro de 2018, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments
[59] C. Filsfils et al., "Informações recursivas de roteamento de segmento",
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-filsfils-spring sr-recursing-
info, junho de 2017, trabalho em andamento. [Conectados]. Disponível:
https://tools.ietf.org/html/draft-filsfils-spring-sr-recursing-info
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 35

[60] H. Sitaraman et al., "Recomendações para RSVP-TE e Roteamento de Segmento (SR) Label
Switched Path (LSP) Coexistence", RFC 8426, julho de 2018. [Online]. Disponível: https://
tools.ietf.org/html/rfc8426 [61] X. Xu et al., “SR-MPLS over IP,” Internet Engineering Task
Force, Internet-Draft draft-ietf-mpls-sr-over -ip, junho de 2019, trabalho em andamento.
[Conectados]. Disponível: https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip [62] D. Voyer
et al., “Inserção de cabeçalhos de roteamento de segmento IPv6 em um domínio
controlado”, Internet Engineering Força-Tarefa, inserção de cabeçalho de rascunho-
voyer-6man-extension-header na Internet, junho de 2018, trabalho em andamento. [Conectados].
Disponível: https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion [63] K.
Raza et al., “YANG Data Model for SRv6 Base and Static,”
[79] S. Previdi et al., "Extensões Métricas de Engenharia de Tráfego IS-IS (TE)",
IETF RFC 7810, maio de 2016. [Online]. Disponível: https://tools.ietf.org/html/rfc7810 [80]
J. Tansura et al., “Signaling Maximum SID Depth (MSD )
Usando OSPF”, RFC 8476, dezembro de 2018. [Online]. Disponível: https: //
tools.ietf.org/html/rfc8476 [81] S. Giacalone et al., “OSPF Traffic Engineering
(TE) Metric Extensions,” IETF RFC 7471, Mar. 2015. [Online]. Disponível: https://
tools.ietf.org/html/rfc7471 [82] S. Sivabalan et al., “Carrying Binding Label/
Segment-ID in PCE-based Networks,” Internet Engineering Task Force,
Internet-Draft draft- sivabalan-pce-binding-label-sid, fevereiro de 2019, trabalho em
andamento. [Conectados]. Disponível : https://tools.ietf.org/html/draft-
sivabalan-pce-binding-label-sid

Força-Tarefa de Engenharia da Internet, Internet-Draft draft-raza-spring srv6-yang, março

de 2018, trabalho em andamento. [Conectados]. Disponível: https://tools.ietf.org/html/draft- [83] AR Natal et al., “LISP Control Plane for SRv6 Endpoint Mobility”, Internet Engineering Task
raza-spring-srv6-yang [64] S. Previdi et al., “Segment Routing Prefix SID extensions for Force, Internet-Draft draft rodrigueznatal-lisp-srv6, janeiro de 2019, trabalho em andamento.
BGP,” Internet Engineering Task Force, Internet- Draft draft-ietf-idr bgp-prefix-sid, junho de 2018, [Conectados].
trabalho em andamento. [Conectados]. Disponível: https://tools.ietf.org/html/draft-ietf-idr- Disponível: https://tools.ietf.org/html/draft-rodrigueznatal-lisp-srv6 [84] C. Filsfils et
bgp-prefix-sid-27 [65] S. Previdi et al., “Advertising Segment Routing Policies in BGP,” al., “Técnicas de roteamento de segmentos”, US9929946B2 - 2013.
[85] S. Previdi e C. Filsfils, "Cabeçalhos de extensão de roteamento de segmento",
US10063475B2 - 2014.
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-ietf-idr-segment [86] D. Frost et al., "roteamento de segmento MPLS", US9049233B2 - 2013.
routing-te-policy, julho de 2018, trabalho em andamento. [Conectados]. [87] C. Filsfils et al., "Roteamento de segmento sem costura", US9450829B2 - 2013.
Disponível: https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy [88] C. Filsfils et al., “Criando e mantendo políticas de engenharia de tráfego roteado de segmento
[66] G. Dawra et al., “Serviços de sobreposição baseados em SRv6 BGP”, Internet via protocolo de gateway de fronteira”, US10454821B2 - 2017.
Engineering Task Force, Internet-Draft draft-dawra-bess-srv6-services, março
de 2019, trabalho em andamento. [Conectados]. Disponível : https://
[89] S. Previdi et al., "Anúncio de identificadores de segmento de adjacência",
tools.ietf.org/html/draft-dawra-bess-srv6-services
US9565160B2 - 2014.
[67] S. Previdi et al., "BGP Link-State Extensions for Segment Routing,"
[90] C. Filsfils et al., “Método e sistema para monitoramento de caminho usando
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-ietf-idr-bgp-ls segment-routing-
roteamento de segmento,” US9369371B2 - 2015.
ext, maio de 2018, trabalho em andamento. [Conectados]. Disponível: https://tools.ietf.org/
[91] C. Filsfils et al., “Segment routing into a label distribution protocol domain”, US9749187B2 -
html/draft-ietf-idr-bgp-ls-segment-routing-ext [68] S. Previdi et al., “Distribution of Traffic
2014.
Engineering (TE) Policies and State usando BGP-LS,” Internet Engineering Task Force, Internet-
[92] T. Saad et al., "Detecção de loop e prevenção para caminhos de engenharia de tráfego
Draft draft-ietf-idr-te-lsp-distribution, junho de 2018, trabalho em andamento. [Conectados].
roteados de segmento", US10182000B2 - 2016.
[93] P. Francois et al., "Evitação de loop durante a convergência de rede em redes comutadas",
Disponível: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution [69] S.
US9401858B2 - 2014.
Previdi et al., “BGP-LS extensions for Segment Routing BGP Egress Peer
[94] S. Previdi e C. Filsfils, "Reencaminhamento rápido para tráfego de roteamento de segmento",
Engineering,” Internet Força-Tarefa de Engenharia, Internet-Draft draft-ietf-idr-
US9485150B2 - 2016.
bgpls-segment-routing-epe, março de 2018, trabalho em andamento.
[95] C. Filsfils et al., "Codificando caminhos explícitos como listas de segmentos de roteamento
[Conectados]. Disponível : https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-
de segmento", US9979601B2 - 2018.
routing-epe
[96] C. Filsfils et al., "Enfileiramento baseado em fatias de rede escalável usando algoritmo flexível
[70] J. Tansura et al., “Signaling Maximum SID Depth using Border Gateway Protocol Link-State”,
de roteamento de segmento", US10601724B1 - 2020.
Internet Engineering Task Force, Internet-Draft draft-ietf-idr-bgp-ls-segment-routing-msd,
[97] SA Dodd-noble et al., “Fornecendo indicação de informações de localização do equipamento
outubro de 2018. 2017, obra em andamento. [Conectados]. Disponível: https://tools.ietf.org/
do usuário no plano do usuário”, US10285155B1 - 2019.
html/draft-ietf-idr-bgp-ls-segment-routing-msd [71] L. Ginsberg et al., “BGP - Link State
[98] Y. Desmouceaux et al., "Mobilidade de carga de trabalho com perda zero com roteamento de
(BGP-LS) Advertisement de Extensões de Métricas de Desempenho de Engenharia de
segmento para máquinas virtuais", US10635480B2 - 2019.
Tráfego IGP”, RFC 8571, março de 2019. [Online]. Disponível: https://tools.ietf.org/html/rfc8571
[72] G. Dawra et al., “BGP Link State Extensions for IPv6 Segment Routing (SRv6)”,
[99] Especificação GTP-U. [Conectados]. Disponível: https://www.3gpp.org/
Internet Engineering Task Force, Internet-Draft draft-ietf -idr-bgpls-srv6-ext, março de 2018,
dynareport/29281.htm
trabalho em andamento. [Conectados]. [100] MTY Desmouceaux e T. Clausen, “Zero-Loss Virtual Machine Migration with IPv6 Segment
Routing”, no 1º Workshop sobre Segment Routing and Service Function Chaining (SR+SFC
2018) no CNSM 2018, Roma, Itália, 2018.
Disponível: https://tools.ietf.org/html/draft-dawra-idr-bgpls-srv6-ext [73] K. Talaulikar et
al., “BGP Link-State Extensions for BGP-only Fabric,” [101] F. Paolucci et al., “Interoperable multi-domain delay-aware provisioning using Segment
Força-Tarefa de Engenharia da Internet, Internet-Draft draft-ketant-idr-bgp ls- Routing Monitoring and BGP-LS Advertising”, em ECOC 2016; 42ª Conferência Europeia
bgp-only-fabric, março de 2018, trabalho em andamento. [Conectados]. de Comunicação Óptica; Processo de. VDE, 2016, pp. 1–3.
Disponível: https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-bgp-only-fabric
[74] G. Dawra et al., “BGP-LS Advertisement of Segment Routing Service Segments, [102] F. Aubry et al., “SCMon: Leveraging Segment Routing para melhorar o monitoramento de
” Força-Tarefa de Engenharia da Internet, Internet-Draft draft-dawra-idr-bgp- rede”, em Comunicações de Computador, IEEE INFOCOM 2016-The 35th Annual IEEE
ls-sr-service-segments, janeiro de 2019, trabalho em andamento. [Conectados]. International Conference on. IEEE, 2016, pp. 1–9.
Disponível: https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments
[75] P. Psenak et al., “IGP Flexible Algorithm,” Internet Engineering Task [103] X. Li e K. Yeung, “Algoritmos de monitoramento de rede eficientes em largura de banda
Force , Internet-Draft draft-ietf-lsr-flex-algo, novembro de 2018, trabalho em baseados em roteamento de segmento”, Redes de Computadores, 2018.
andamento. [Conectados]. Disponível : https://tools.ietf.org/html/draft-ietf-lsr- [104] X. Li e K. Yeung, “Formulação de ILP para construção de ciclo de monitoramento usando
flex-algo roteamento de segmento”, em 2018 IEEE 43rd Conference on Local Computer Networks
(LCN). IEEE, 2018, pp. 485-492.
[76] M. Rasool, SS, MS Negi, “YANG Model for IGP Flexible Algorithm”, Internet Engineering Task [105] M. Polverini et al., "Routing Perturbation for Traffic Matrix Evaluation in a Segment Routing
Force, Internet-Draft draft rasool-lsr-flex-algo-yang, abril de 2019, trabalho em andamento. Network", IEEE Transactions on Network and Service Management, 2018.
[Conectados].
Disponível: https://tools.ietf.org/html/draft-rasool-lsr-flex-algo-yang [77] J. Tansura et [106] MPA Cianfrani e T. Nalawade, “A Heuristic Approach to Assessment the Traffic Matrix of an
al., “Signaling Maximum SID Depth (MSD) ISP Exploiting Segment Routing Flexibility”, em 2018 30th International Teletraffic Congress
Usando IS-IS”, RFC 8491, novembro de 2018. [Online]. Disponível: https: // (ITC 30), vol. 1. IEEE, 2018, pp. 194-199.
tools.ietf.org/html/rfc8491 [78] L. Ginsberg et al., “Advertising L2 Bundle
Member Link Attributes in IS-IS,” Internet Engineering Task Force, Internet-Draft [107] ACM Polverini e M. Listanti, “Contadores de interface no roteamento de segmento v6: um
draft-ietf isis -l2bundles, maio de 2017, trabalho em andamento. [Conectados]. instrumento poderoso para avaliação da matriz de tráfego”, em 2018 9ª Conferência
Disponível: https://tools.ietf.org/html/draft-ietf-isis-l2bundles Internacional sobre a Rede do Futuro (NOF).
IEEE, 2018, pp. 76-82.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE
[108] FMXhonneux e O. Bonaventure, “Leveraging eBPF for programmable network
functions with IPv6 Segment Routing”, em Anais da 14ª Conferência Internacional
sobre Experiências e Tecnologias de Rede emergentes. ACM, 2018, pp. 67-72.
[109] M. Lee e J. Sheu, "Um algoritmo de roteamento eficiente baseado em roteamento
de segmento em redes definidas por software", Redes de Computadores, vol. 103,
pp. 44-55, 2016.
[110] A. Bahnasse et al., “Novel SDN architecture for smart MPLS Traffic Engineering-
DiffServ Aware management”, Future Generation Computer Systems, 2018.
[111] J. Sheu e Y. Chen, “Um algoritmo multicast escalável e eficiente em largura de banda
baseado em roteamento de segmento em redes definidas por software”, em
Comunicações (ICC), Conferência Internacional IEEE 2017 em. IEEE, 2017, pp. 1–
6.
[112] OGR Carpa e L. Lefevre, “Engenharia de tráfego baseada em roteamento de
segmento para redes de backbone energeticamente eficientes”, em Advanced
Networks and Telecommuncations Systems (ANTS), 2014 IEEE International
Conference on. IEEE, 2014, pp. 1–6.
[113] K. Ghuman e A. Nayak, “Abordagem de roteamento de segmento consciente por
pacote baseado em energia para redes de data center com SDN”, em
Telecomunicações (ICT), 24ª Conferência Internacional de 2017. IEEE, 2017, pp.
1–6.
[114] L. Davoli et al., “Engenharia de tráfego com roteamento de segmento: projeto
arquitetônico baseado em SDN e implementação de código aberto”, em Soft ware
Defined Networks (EWSDN), 2015 Fourth European Workshop on. IEEE, 2015,
pp. 111-112.
[115] G. Trimponias et al., “On Traffic Engineering with Segment Routing in SDN based
WANs”, pré-impressão arXiv arXiv:1703.05907, 2017.
[116] R. Bhatia et al., “Engenharia de tráfego de rede otimizada usando roteamento de
segmento”, em Computer Communications (INFOCOM), 2015 IEEE Conference
on. ImplsEEE, 2015, pp. 657-665.
[117] H. Roomi e S. Khorsandi, "Roteamento de Segmento Semi-Oblivious with Bounded
Traffic Fluctuations", em Engenharia Elétrica (ICEE), Conferência Iraniana em.
IEEE, 2018, pp. 1670-1675.
[118] R. Hartert et al., "Uma abordagem declarativa e expressiva para controlar caminhos
de encaminhamento em redes de nível de operadora", em ACM SIGCOMM
Computer Communication Review, vol. 45. ACM, 2015, pp. 15–28.
[119] HRS Gay e S. Vissicchio, “Espere o inesperado: Otimização de subsegundos para
roteamento de segmento”, em INFOCOM 2017-IEEE Conference on Computer
Communications, IEEE. IEEE, 2017, pp. 1–9.
[120] R. Hartert et al., "Resolvendo problemas de roteamento de segmento com técnicas
de programação de restrição híbrida", na Conferência Internacional sobre Princípios
e Prática de Programação de Restrição. Springer, 2015, pp. 592-608.
[121] MLA Cianfrani e M. Polverini, "Implantação incremental de roteamento de segmento
em uma rede ISP: uma perspectiva de engenharia de tráfego",
IEEE/ACM Transactions on Networking, vol. 25, não. 5, pp. 3146-3160, 2017.
[122] ABE Moreno e F. Cugini, "Engenharia de tráfego em redes de roteamento de
segmento", Redes de Computadores, vol. 114, pp. 23-31, 2017.
[123] MRV Pereira e P. Sousa, “Optimizing Segment Routing using Evolutionary
Computation,” Procedia Computer Science, vol. 110, pp. 312-319, 2017.
[124] A. Barakabitze et al., “A Novel QoE-Centric SDN-based Multipath Routing Approach
for Multimedia Services over 5G Networks”, em 2018 IEEE International Conference
on Communications (ICC). IEEE, 2018, pp. 1–7.
[125] XFJ Pang, G. Xu, "rede de centro de dados baseado em SDN com colaboração de
TCP multipath e roteamento de segmento", IEEE Access, vol. 5, pág. 9764-9773,
2017.
[126] O. Dugeon et al., “Demonstração de roteamento de segmento com otimização de
pilha de rótulo baseada em SDN”, em Inovações em Nuvens, Internet e Redes
(ICIN), 20ª Conferência em 2017. IEEE, 2017, pp. 143-145.
[127] MWX Hou e M. Zhao, "Um algoritmo de roteamento de otimização baseado em
roteamento de segmento em redes definidas por software", Sensors, vol. 19, não.
1, pág. 49, 2019.
[128] T. Settawatcharawanit et al., “Segment Routed Traffic Engineering with Bounded
Stretch in Software-Defined Networks”, em 2018 IEEE 43rd Conference on Local
Computer Networks (LCN). IEEE, 2018, pp. 477-480.
[129] G. Trimponias et al., “Engenharia de Tráfego Constrangido por Nó: Teoria e
Aplicações”, Transações IEEE/ACM em Rede, 2019.
[130] P. Zhang et al., “Bandwidth Allocation with Utility Maximization in the Hybrid Segment
Routing Network”, IEEE Access, 2019.
[131] K. Foerster et al., “TI-MFA: mantenha a calma e reencaminhe os segmentos
rapidamente”, no IEEE INFOCOM 2018-IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS). IEEE, 2018, pp. 415-420.
36
[132] F. Aubry et al., "Duplicação de tráfego através de caminhos disjuntos segmentáveis",
em IFIP Networking Conference (IFIP Networking), 2015.
IEEE, 2015, pp. 1–9.
[133] F. Aubry et al., “Robustly disjoint paths with segment routing”, nos Anais da 14ª
Conferência Internacional sobre Experiências e Tecnologias de Rede emergentes.
ACM, 2018, pp. 204-216.
[134] MKF Hao e T. Lakshman, “Optimizing restore with Segment Routing”, em
Comunicações de Computador, IEEE INFOCOM 2016-The 35th Annual IEEE
International Conference on. IEEE, 2016, pp. 1–9.
[135] A. Giorgetti et al., "Segment Routing for Effective Recovery and Multi Domain Traffic
Engineering", Journal of Optical Communications and Networking, vol. 9, não. 2,
pp. A223–A232, 2017.
[136] A. Giorgetti et al., "Demonstração de restauração dinâmica em redes SDN
multicamadas de roteamento de segmento", em Optical Fiber Communication
Conference. Optical Society of America, 2016, pp. Th4G–4.
[137] A. Giorgetti et al., “Reliable Segment Routing”, em Reliable Networks Design and
Modeling (RNDM), 2015 7th International Workshop on.
IEEE, 2015, pp. 181-185.
[138] M. Xhonneux e O. Bonaventure, “Detecção flexível de falhas e redirecionamento
rápido usando eBPF e SRv6”, em 2018 14ª Conferência Internacional sobre
Gerenciamento de Rede e Serviços (CNSM). IEEE, 2018, pp. 408-413.
[139] KT Foerster et al., “Local Fast Segment Rerouting on Hypercubes”, 2018. [Online].
Disponível: http://eprints.cs.univie.ac. at/5837/11/2018-hypercubes.pdf [140] A.
Sgambelluri et al., “Primeira demonstração de roteamento de segmento baseado
em SDN em redes multicamadas”, em Optical Fiber Communications Conference and
Exhibition (OFC), 2015. IEEE, 2015, pp. 1–3.
[141] A. Sgambelluri et al., “Implementações SDN e PCE para roteamento de segmento”,
em Networks and Optical Communications-(NOC), 2015 20th European Conference
on. IEEE, 2015, pp. 1–4.
[142] F. Paolucci, "Encadeamento de serviços de rede usando roteamento de segmento
em redes multicamadas", IEEE/OSA Journal of Optical Communications and
Networking, vol. 10, não. 6, pp. 582–592, 2018.
[143] F. Paolucci et al., "Serviço de encadeamento em redes multicamadas usando
Segment Routing e BGP FlowSpec estendido", em Optical Fiber Communication
Conference. Optical Society of America, 2017, pp.
W4J – 3.
[144] P. Castoldi et al., “Segment Routing in multi-layer networks”, em Trans parent
Optical Networks (ICTON), 2017 19th International Conference on. IEEE, 2017, pp.
1–4.
[145] Projeto Aberto de Primavera. https:// Disponível conectados no
wiki.onosproject.org/display/ONOS10/Segment+Routing.
[146] A. Fressancourt e M. Gagnaire, “A arquitetura de rede baseada em SDN para
resiliência em nuvem”, em Consumer Communications and Networking Conference
(CCNC), 2015 12th Annual IEEE. IEEE, 2015, pp. 479-484.
[147] Z. Li et al., “Segment Routing in Hybrid Software-Defined Networking”, em
Communication Software and Networks (ICCSN), 2017 IEEE 9th International
Conference on. IEEE, 2017, pp. 160-165.
[148] D. Lebrun et al., "Redes resolvidas por software: Repensando redes corporativas
com roteamento de segmento IPv6", em Anais do Simpósio sobre Pesquisa SDN.
ACM, 2018, pág. 6.
[149] MJF Duchene e O. Bonaventure, “Explorando vários casos de uso para roteamento
de segmento IPv6”, em Anais da Conferência ACM SIGCOMM 2018 sobre pôsteres
e demonstrações. ACM, 2018, pp. 129-131.
[150] N. Kukreja et al., “Demonstração de orquestração baseada em SDN para redes de
roteamento de segmento de vários domínios”, em Transparent Optical Networks
(ICTON), 2016 18th International Conference on. IEEE, 2016, pp. 1–4.
[151] A. Sgambelluri et al., "Demonstração experimental de roteamento de segmento multi-
domínio", em Comunicação Óptica (ECOC), 2015 Conferência Europeia sobre.
IEEE, 2015, pp. 1–3.
[152] AWD Cai e S. Wei, “Evolve carrier Ethernet architecture with SDN and Segment
Routing”, em World of Wireless, Mobile and Multimedia Networks (WoWMoM),
2014 IEEE 15th International Symposium on a. IEEE, 2014, pp. 1–6.
[153] O. Barakat et al., “Busoni: Composição de Políticas e Interface Norte para Redes de
Roteamento de Segmento IPv6”, em 2019 IEEE 27th International Conference on
Network Protocols (ICNP). IEEE, 2019, pp. 1–4.
[154] V. Eramo et al., "Eficácia da tecnologia de roteamento de segmento na redução da
largura de banda e tempos de provisionamento de recursos de nuvem em
arquiteturas de virtualização de funções de rede", Future Internet, vol. 11, não. 3,
pág. 71, 2019.
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 37

[155] A. Sgambelluri et al., “Demonstração experimental de roteamento de segmento”, [178] T. Chi et al., “Multicast de vídeo ao vivo para usuários dinâmicos via roteamento de
Journal of Lightwave Technology, vol. 34, nº. 1, pp. 205-212, 2016. segmento em redes 5G”, em 2018 IEEE Global Communications Conference
(GLOBECOM). IEEE, 2018, pp. 1–7.
[156] F. Lazzeri et al., “Efficient label encoding in Segment-Routing Enabled Optical Networks”, [179] J. Cao, X. Wang, M. Huang e X. Zhou, "A Mobility-Supported Routing Mechanism in
em Optical Network Design and Modeling (ONDM), 2015 International Conference Industrial IoT Networks", IEEE Access, vol. 7, pág. 25 603–25 615, 2019.
on. IEEE, 2015, pp. 34–38.
[157] A. Giorgetti et al., “Path encoding in Segment Routing”, na Global Communications [180] A. Mayer et al., “The Network as a Computer with IPv6 Segment Routing: a Novel
Conference (GLOBECOM), 2015 IEEE. IEEE, 2015, pp. 1–6. Distributed Processing Model for the Internet of Things”, no 1st International Workshop
on Next-Generation Operating Systems for Cyber-Physical Systems (NGOSCPS ), na
[158] R. Guedrez et al., “Label encoding algoritmo for MPLS Segment Routing”, em Network CPS-IoT Week 2019, 15 de abril de 2019, Montreal, Canadá, 2019.
Computing and Applications (NCA), 2016 IEEE 15th International Symposium on.
IEEE, 2016, pp. 113-117. [181] SDN-TE-SR. Disponível online em https://github.com/netgroup/SDN-TE
SR.
[159] MLA Cianfrani e M. Polverini, “Traduzindo o resultado da engenharia de tráfego em
[182] V. Pereira, M. Rocha e P. Sousa, “Segment Routing Single Link Failure Congestion
caminhos de roteamento de segmento: o problema de codificação”, em Workshops
Optimization”, in ICETE (1), 2018, pp. 242–249.
de comunicações de computador (INFOCOM WKSHPS), 2016 IEEE Conference on.
[183] D. Lebrun, “A implementação do kernel Linux de roteamento de segmento com IPv6”,
IEEE, 2016, pp. 245-250.
em Workshops de comunicações de computador (INFOCOM WKSHPS), 2016 IEEE
[160] H. Liaoruo et al., “Optimizing Segment Routing with the Maximum SLD Constraint using
Conference on. IEEE, 2016, pp. 1019-1020.
Openflow”, IEEE Access, 2018.
[184] Como trabalhar com grupos OpenFlow de failover rápido. https://
[161] R. Guedrez et al., “Um novo método para codificação de caminhos de roteamento de Disponível: floodlight.atlassian.net/wiki/spaces/
segmento MPLS TE”, em Network of the Future (NOF), 2017 8th International
[Conectados]. floodlightcontroller/pages/7995427/
Conference on the. IEEE, 2017, pp. 58–65.
How+to+Work+with+Fast\ discricionário{-}{}{}
[162] D. Lebrun, “Leveraging IPv6 Segment Routing for Service Function Chaining”, em Proc. Failover+OpenFlow+Groups [185] Uma introdução completa ao eBPF. [Conectados].
CoNEXT Stud. Workshop, 2015, pp. 1–15. Disponível: https: //lwn.net/Articles/740157/
[163] A. Abdelsalam et al., “Implementação do encadeamento de funções de rede virtual por [186] D. Katz e D. Ward, "Detecção de encaminhamento bidirecional (BFD)",
meio de roteamento de segmento em uma infraestrutura NFV baseada em linux”, em IETF RFC 5880, junho de 2010. [Online]. Disponível : https://tools.ietf.org/
2017 IEEE Conference on Network Softwarization (NetSoft), julho de 2017, pp. 1–5. html/rfc5880/
[187] Projeto RYU. Disponível online em http://osrg.github.io/ryu/.
[164] DLF Duchêne e O. Bonaventure, “SRv6Pipes: enable in network bytestream functions,” [188] Fundação de Rede Aberta. Projeto ONOS. Disponível online em https://onosproject.org.
in IFIP Networking 2018, 2018.
[165] A. Abdelsalam et al., “SERA: Segment Routing Aware Firewall for Service Function [189] Treliça. Open Source SDN L2/L3 Spine Leaf Switching Fabric para trabalho em rede.
Chaining cenários”, em IFIP Networking 2018. Disponível online em https://www.opennetworking.org/trellis.
IEEE, maio de 2018. [190] Projeto de Computação Aberta. Disponível conectados no
[166] Y. Desmouceaux et al., "SRLB: The Power of Choices in Load Balancing with Segment em http://www.opencompute.org.
Routing", em Distributed Computing Systems [191] Broadcom. Abstração de caminho de dados OpenFlow. Disponível online em (ICCDCS), 2017 IEEE 37th International Conference
on. IEEE, 2017, https://github.com/Broadcom-Switch/of-dpa. pág. 2011–2016.
[192] Broadcom. Disponível online em https://www.broadcom.com.
[193] D.
et al., "A Content-aware Data-plane for Efficient and in the Linux Kernel", em Proceedings of the Applied Lebrun e Scalable
Networking O. Bonaventure, "Implementing
Video Delivery”, IPv6
em 2019 SegmentSymposium
IFIP/IEEE Routing [167]
on Y. Desmouceaux
Integrated
Research Workshop. ACM, 2017, pp. 35–41.
Gerenciamento de Rede e Serviços (IM). IEEE, 2019, pp. 10–18.
et al., “Performance of IPv6 Segment Routing in Linux Devices,” Internet Requests for Comments, [194] S. Bradner,
RFC Editor, RFC “Benchmarking Terminology
1242, Kernel,” em 1º Workshopfor sobre
Network Interconnection
Roteamento [168] A. Abdelsalam
de Segmentos e Função
Chaining (SR+SFC 2018) no CNSM 2018, Roma, Itália, 2018. de Serviço Julho de 1991. [Online]. Disponível: https://tools.ietf.org/html/rfc1242

[195] Linux
Solution Team e C. Tato. Roteamento de segmento //wiki.linuxfoundation.org/networking/iproute2 sobre Foundation
aceleração Wiki - iproute2.
IPv6 usando [Conectados].
Intel R FPGA Disponível:
programável https:
[196] SRv6 [169] HCL SRv6do
- implementação
kernel Linux - configuração básica. [Na placa de aceleração N3000.Configuratio
Disponível: https://www. linha]. Disponível: https://segment-routing.org/index.php/Implementation/intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/ [Conectados].
wp-
card-n3000. 01295 -hcl-segment-routing -over-ipv6-acceleration-using-intel-fpga-programmable-acceleration-

[197] D. Lebrun. (2017) Colhendo os benefícios do IPv6 Segment pdf Routing.

[Conectados]. Disponível : https://inl.info.ucl.ac.be/system/files/phdthesis-lebrun.pdf
[170] C. Lee et al., “Avaliação de Desempenho de GTP-U e SRv6 State less Translation”, no
2º Workshop sobre Segment Routing and Service Function Chaining (SR+SFC 2019)
[198] SRv6 - Implementação do kernel Linux - configuração avançada.
no CNSM 2019, Halifax, Canadá, 2019.
[Conectados]. Disponível: https://segment-routing.org/index.php/
Implementation/ AdvancedConf
[171] A. Abdelsalam et al., “SRPerf: uma estrutura de avaliação de desempenho para
[199] Iniciantes do Kernel Linux - Linux 4.16. [Conectados]. Disponível: https: //
roteamento de segmento IPv6”, pré-impressão arXiv arXiv:2001.06182, 2020.
kernelnewbies.org/Linux_4.16 [200] Hacking de filtro de rede Linux.
[172] V. Kotronis et al., "Controle eXchange Points: Fornecendo serviços de ponta a ponta
[Conectados]. Disponível: https://www.netfilter.org/
habilitados para Qos via orquestração de roteamento entre domínios baseada em SDN",
documentação/HOWTO/netfilter-hacking-HOWTO-3.html
LINX, vol. 2429, nº. 1093, pág. 2443, 2014.
[201] Arch Wiki - iptables. [Conectados]. Disponível: https://wiki.archlinux.org/index.php/
[173] P. Godfrey et al., "Roteamento Pathlet", ACM SIGCOMM Computer
iptables [202] Linux Kernel Newbies - Linux 4.18 . [Conectados]. Disponível: https: //
Revisão de Comunicação, vol. 39, nº. 4, pp. 111–122, 2009.
kernelnewbies.org/Linux_4.18 [203] Programando ações de rede com BPF. [Conectados].
[174] S. Bidkar et al., "Roteamento de Segmento Escalável: um novo paradigma para redes Disponível:
de provedores de serviços eficientes usando avanços Ethernet de operadora",
IEEE/OSA Journal of Optical Communications and Networking, vol. 7, não. 5, pp. https://segment-routing.org/index.php/Implementation/BPF [204] SRv6-
445–460, 2015. BPF. [Conectados]. Disponível: https://github.com/Zashas/ Tese-
[175] AGS Bidkar e A. Somani, “Uma estrutura escalável para roteamento de segmento em SRv6-BPF
redes de provedores de serviços: A abordagem Ethernet onipresente”, em High [205] SRv6-BFD. [Conectados]. Disponível: https://github.com/Zashas/SRv6-BFD [206] O que
Performance Switching and Routing (HPSR), 2014 IEEE 15th International Conference é VPP? https://wiki.fd.io/view/VPP.
on. IEEE, 2014, pp. 76–83. [207] SRv6-net-prog. [Conectados]. Disponível: https://netgroup.github.io/SRv6-net-
[176] S. Bidkar et al., “Field trial of a Software Defined Network (SDN) using Carrier Ethernet prog/ [208] FRRouting . Disponível online em https://frrouting.org.
and Segment Routing in a tier-1 provider”, na Global Communications Conference
(GLOBECOM), 2014 IEEE. [209] Projeto Quagga. [Conectados]. Disponível: https://www.quagga.net
IEEE, 2014, pp. 2166-2172. [210] Roteamento de segmento OSPFv2. [Conectados]. Disponível: https://
[177] T. Schüller et al., “Sobre a irrelevância prática de métricas na otimização de engenharia github.com/FRRouting/frr/blob/master/doc/developer/ospf-sr.rst [211] P4
de tráfego de roteamento de segmentos”, em 2018 IEEE 43rd Conference on Local Language Consortium . [Conectados]. Disponível: https://p4.org [212] P4 Runtime.
Computer Networks (LCN). IEEE, 2018, pp. 640-647. [Conectados]. Disponível: https://p4.org/p4-runtime/ [213] Projeto Stratum.
[Conectados]. Disponível: https://stratumproject.org
Machine Translated by Google
ENVIADO PARA PESQUISAS E TUTORIAIS DE COMUNICAÇÕES IEEE 38

[214] Projeto OpenCORD. [Conectados]. Disponível: https://opencord.org

[215] Projeto SEBA. [Conectados]. Disponível: https://guide.opencord.org/profiles/
Eu mesmo/

[216] Documentação da treliça. Disponível online em https://docs.trellisfabric.org.

[217] Tutorial de Treliça. [Conectados]. Disponível: http://bit.ly/trellis-p4-slides
[218] S. Salsano et al., “OSHI-Open Source Hybrid IP/SDN networking (and its
emulation on Mininet and on Distributed SDN testbeds)”, em Redes Definidas
por Software (EWSDN), 2014 Terceiro Workshop Europeu sobre. IEEE,
2014, pp. 13–18.
[219] S. Salsano et al., “Redes híbridas IP/SDN: ferramentas abertas de
implementação e gerenciamento de experimentos”, IEEE Transactions on
Network and Service Management, vol. 13, não. 1, pp. 138–153, 2016.
[220] Abra o vSwitch. Disponível online em http://openvswitch.org.
[221] S. Salsano et al., “Mantoo-um conjunto de ferramentas de gerenciamento para
controlar experimentos SDN”, em Software Defined Networks (EWSDN),
2015 Fourth European Workshop on. IEEE, 2015, pp. 123-124.
[222] Tutorial PMSR. [Conectados]. Disponível: https://github.com/netgroup/
Ferramentas SDN-TE-SR
[223] Página inicial da OSHI. [Conectados]. Disponível: http://netgroup.uniroma2.it/
OSHI
[224] B. Pfaff e B. Davie, “The Open vSwitch Database Management Protocol”, RFC
7047, dezembro de 2013. [Online]. Disponível: https: //rfc-editor.org/rfc/rfc7047.txt
[225] SRN. [Conectados]. Disponível: https://github.com/segment-routing/srn
[226] SRN Overview. [Conectados]. Disponível: https://segment-routing.org/index. php/
SRN/SRN [227] Usando SRN. [Conectados]. Disponível: https://segment-routing.org/
index.

php/SRN/UsingSRN
[228] SRv6-SDN. [Conectados]. Disponível: https://netgroup.github.io/srv6-sdn/ [229]
ROSE. [Conectados]. Disponível: https://netgroup.github.io/rose/ [230] SRv6Pipes.
[Conectados]. Disponível: https://github.com/segment-routing/ SRv6Pipes [231]
SRv6Pipes Passo a passo. [Conectados]. Disponível: https://segment-routing.

org/index.php/SRv6Pipes/SRv6Pipes
[232] SRNK. [Conectados]. Disponível: https://netgroup.github.io/srnk/ [233]
RobustlyDisjointPathsCode. [Conectados]. Disponível: https://bitbucket.org/
franaubry/robustlydisjointpathscode
[234] S. Matsushima et al., “SRv6 Implementation and Deployment Status”, Internet
Engineering Task Force, Internet Draft draft-matsushima-spring-srv6-deployment-
status, maio de 2020, trabalho em andamento. [Conectados]. Disponível: https://
tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status [235] Barefoot
Networks . [Conectados]. Disponível: https://www.barefootnetworks.

com
[236] Comutador BMv2. [Conectados]. Disponível: http://www.bmv2.org
[237] Cavium. [Conectados]. Disponível: https://www.cavium.com
[238] Demonstração de interoperabilidade SRv6. [Conectados]. Disponível: https://
blogs.cisco.com/sp/ segment-routing-ipv6-interoperability-demo-is-already-
there [239] EANTC, “MPLS+SDN+NFVVORD@PARIS2018 Interoperability
Showcase,” EANTC, Tec. Rep., abril de 2018, MPLS
World Congress, [Online]. Paris. Disponível :
http://www.eantc.de/fileadmin/eantc/downloads/events/2017-2020/MPLS2018/
EANTC-MPLSSDNNFV2018-WhitePaper-final.pdf
[240] Wireshark. [Conectados]. Disponível: https://www.wireshark.org [241]
tcpdump. [Conectados]. Disponível: http://www.tcpdump.org [242] iptables.
[Conectados]. Disponível: https://www.netfilter.org [243] nftables.
[Conectados]. Disponível: https://wiki.nftables.org/wiki-nftables/
index.php/Main_Page
[244] bufar. [Conectados]. Disponível: https://www.snort.org
[245] Open Programmable Acceleration Engine (OPAE). [Conectados]. Disponível:
https://opae.github.io
[246] Caminho de dados expresso. [Conectados]. Disponível: https://en.wikipedia.org/
wiki/ Express_Data_Path [247] OpenStack. [Conectados]. Disponível: https://
www.openstack.org [248] Kubernetes. [Conectados]. Disponível: http://kubernetes.io
[249] P. Ventre et al., “Segment Routing: A abrangente survey of research activity,
standardization forces and deployment results,” arXiv preprint arXiv:1904.03471,
2019.