Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Orientador:
Prof. Doutor Pedro Renato Tavares Pinho
Jri:
Presidente: Prof. Doutor Mrio Pereira Vstias
Vogal-Arguente: Prof. Doutor Antnio Lus de Jesus Teixeira
Vogal-Orientador: Prof. Doutor Pedro Renato Tavares Pinho
Novembro de 2015
Agradecimentos
iii
Resumo
Palavras-Chave
v
Abstract
This thesis aims to study the various types of survival schemes in high-
capacity optical networks, in particularly in WDM networks (Wavelenth Division
Multiplexing).
This was done initially carried out a literature review, which is structured
in two stages. First is shown an overview of optical transport networks highlighted
the evolution of WDM networks and its network components. Then, an overview
of the survivable techniques in NGNs (Next Generation Networks) is shown. After
a brief concepts exposure are shown the most important techniques in regard to
the protection and restoration schemes for high capacity transmission systems.
They are also addressed the Control Plane, Data Plane and Management Plane of
GMPLS (Generalized Multiprotocol Label Switching) in the context of survivability
of NGN.
Using a WDM network simulation model, based on ns-3, are analyzed three
failure scenarios. They are, single-link failure, multiple-link failure and node failure.
Thus, it was possible to verify the behavior of the RWA algorithm (Routing and
Wavelength Assignment), in such event of failure.
The RWA algorithm have allowed in the three failure scenarios, rerouting
the channels to an alternate path, and thus ensures the continuity of transmission.
Keywords
vii
ndice
Agradecimentos ................................................................................................................iii
Resumo ..............................................................................................................................v
Abstract ........................................................................................................................... vii
ndice ................................................................................................................................ix
ndice de Figuras ............................................................................................................ xiii
1.1 Enquadramento.............................................................................................................................. 2
1.2 Motivao ....................................................................................................................................... 3
1.3 Objectivos ....................................................................................................................................... 4
1.4 Organizao do Documento ......................................................................................................... 5
ix
ndice
x
ndice
xi
ndice
Bibliografia .....................................................................................................................131
xii
ndice de Figuras
xiii
ndice de Figuras
xiv
ndice de Figuras
Figura 4.15 - Medida de potncia ptica para o canal DWDM ID-1 e ID-5, entre o
OXC-5 e OXC-0. ........................................................................................... 116
Figura 4.16 - Medida de potncia ptica para o canal DWDM ID-1, ID-2, ID-3 e
ID-5, entre o OXC-5 e OXC-4. ..................................................................... 116
Figura 4.17 - Falha nos links, entre o OXC-0 e OXC-5, OXC-2 e OXC-3 e OXC-4
e OXC-5. ....................................................................................................... 117
Figura 4.18 - Medida de potncia ptica para o canal DWDM ID-1, ID-2, ID-3 e
ID-5, entre o OXC-1 e OXC-2. ..................................................................... 120
Figura 4.19 - Medida de potncia ptica para o canal DWDM ID-1, ID-2 e ID-5,
entre o OXC-2 e OXC-4................................................................................ 121
Figura 4.20 - Falha no OXC-2. ............................................................................ 122
Figura 4.21 - Medida de potncia ptica para o canal DWDM ID-1 e ID-5, entre o
OXC-5 e OXC-0. ........................................................................................... 124
Figura 4.22 - Medida de potncia ptica para o canal DWDM ID-1, ID-2 e ID-5,
entre o OXC-4 e OXC-5................................................................................ 125
xv
ndice de Tabelas
xvii
ndice de Tabelas
xviii
Acrnimos
Acrnimo Designao
3R Reamplification, Retiming, Reshaping
ABT-IT ATM Block Transfer with Immediate Transmission
ADSL Asymmetric Digital Subscriber Line
AIS Alarm Indication Signal
API Application Programming Interface
ASON Automatically Switched Optical Networks
ATM Asynchronous Transfer Mode
BER Bit Error Rate
CAPEX Capital Expenditures
CATV Cable Television
CBR Constant Bit Rate
CD Chromatic Dispersion
CM Cable Modem
CO Central Office
CR-LDP Constraint-Based Routing Label Distribution Protocol
DCC Data Communication Channel
DCF Dispertion Compensated Fiber
DCN Data Communication Network
DLCI Data Link Connection Identifier
DLE Dynamic Lightpath Establishment)
DOCSIS Data Over Cable Service Interface Specification
DWDM Dense Wavelength Division Multiplexing
EDFA Erbium-Doped Fiber Amplifier
FC Fiber Channel
FDL Fiber Delay Line
FEC Forward Error Correction
xix
Acrnimos
xx
Acrnimos
xxi
Acrnimos
RF Rdio Frequncia
ROADM Reconfigurable Optical Add/Drop Multiplexing
RRL Resilient Routing Layer
RSVP-TE Resource Reservation Protocol with Traffic Engineering
RWA Routing and Wavelength Assignment
SCN Signaling Communication Network
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
SLE Static Lightpath Establishment
SONET Synchronous Optical Networking
SRLG Shared Risk Link Groups
SRS Stimulated Raman Scattering
SSMF Standard Single-Mode Fiber
TCP Transmission Control Protocol
TDM Time Dividsion Multiplexing
TE Traffic Engineering
TED Traffic Engineering Database
UDP User Datagram Protocol
UNI User-to-Network Interface
VCI Virtual Circuit Identifier
VDSL Very-High Speed Digital Subscriber Line
VPI Virtual Path Identifier
VPN Virtual Private Network
WA Wavelength Assignment
WAN Wide Area Network
WCC Wavelength Continuity Constraint
WDM Wavelenth Division Multiplexing
WSS Wavelength Selective Switching
xDSL Digital Subscriber Line tecnologies
xxii
1
Introduo
1
Captulo 1 - Introduo
1.1 Enquadramento
2
Captulo 1 - Introduo
1.2 Motivao
3
Captulo 1 - Introduo
1.3 Objectivos
1
O termo wavelength tipicamente utilizado em dois contextos diferentes: primeiro, refere-se a um canal de
luz; segundo, refere-se ao ponto especfico no espectro de luz onde o canal est centrado (e.g., 1550 nanome-
tros) [3].
4
Captulo 1 - Introduo
5
2
Redes pticas
7
Captulo 2. Redes pticas
exemplo, esta camada inclui routers IP, switches Ethernet, switches ATM (Asyn-
chronous Transfer Mode), switches SONET (Synchronous Optical Network-
ing)/SDH(Synchronous Digital Hierarchy), e switches OTN. Cada um destes pro-
tocolos tem um mtodo particular para transportar os dados da origem para o des-
tino.
Os payloads da camada elctrica so passados para a camada ptica, onde
so transportados em comprimentos de onda. A camada ptica baseada na tecno-
logia WDM e utiliza switch pticos que so capazes de encaminhar os comprimen-
tos de onda dinamicamente. Deste modo, a camada inferior deste modelo pode
tambm ser referida como camada WDM reconfigurvel [3].
DADOS
MULTIMDIA
CAMADA DE APLICAES ACESSO VOZ
PTICO VIDEO
LAN IMAGEM
IP
Sw.
ptico Sw.
ptico
CAMADA PICA (Camada Sw.
WDM reconfigurvel) ptico
Sw. Sw.
ptico ptico
8
Captulo 2. Redes pticas
9
Captulo 2. Redes pticas
Flexgrid
1
Uma Matriz de Trfego ou Traffic Matrix representa o volume de trfego que entra e sai de uma rede num
determinado intervalo de tempo [58].
10
Captulo 2. Redes pticas
11
Captulo 2. Redes pticas
1
CAPEX (Capital Expenditures), diz respeito ao custo associado ao equipamento de rede [3].
12
Captulo 2. Redes pticas
13
Captulo 2. Redes pticas
CORE
- milhares de km
- malha
OXC
REGIONAL
- centenas a milhares de km
- malha
Central Office
METRO
- dezenas a centenas de km
- anel
ACESSO
- alguns km
Cliente Final
14
Captulo 2. Redes pticas
dados
E1
POTS
DSL
dados ISDN
ONU PON
OLT
ONU
PBX E1
100/10 BT
GbE Router
Ethernet 100/10 BT
Figura 2.4 - Estrutura genrica de uma rede de telecomunicaes moderna (adaptado de [15]).
15
Captulo 2. Redes pticas
16
Captulo 2. Redes pticas
1
Um cable headend designado pelos provedores de servio como sendo o CO ou um n de core. Est locali-
17
Captulo 2. Redes pticas
so: o OLT (Optical Line Terminal), localizado no CO, e a ONU (Optical Network
Unit) localizado no (ou perto do) utilizador final [12]. A rede de acesso PON usa
pelo menos dois comprimentos de onda, um comprimento de onda para downs-
tream, tipicamente 1490nm, e um para upstream, tipicamente 1310nm. Um segun-
do lambda de downstream tambm pode ser usado para o vdeo RF overlay, nor-
malmente 1550nm. A distncia tpica de uma rede de acesso PON FTTH de
20km. A largura de banda em downstream disponibilizada por uma ligao PON
FTTH, por subscritor, normalmente 80Mbps por GPON, ou 2.5Gbps divididos
por 32 subscritores. A largura de banda de upstream, por subscritor, tipicamente
40Mbps, ou 1.25Gbps divididos por 32 subscritores [17].
18
Captulo 2. Redes pticas
Desde os meados dos anos 90, foi introduzida uma nova tcnica nas redes de
comunicao ptica que permite a transmisso de dezenas de sinais pticos numa
nica fibra. Esta tcnica, designada WDM, alm de oferecer uma grande capacida-
de de transmisso por fibra ptica, tem possibilitado a realizao de redes de
encaminhamento de comprimentos de onda (Wavelength routed networks) com a
utilizao de ns com comutao elctrica ou ns baseados em comutao ptica
(ver seco 2.7.6). O alcance ptico desta tcnica sem regenerao optoelectrnica
19
Captulo 2. Redes pticas
ronda os 600km usando SSMF (Standard Single-Mode Fiber) com DCFs (Disper-
tion Compensated Fibers) distribudas periodicamente ao longo do caminho com o
intuito de restringir o impacto da CD (Chromatic Dispersion) [18]. Redes de
encaminhamento ptico de mltiplos comprimentos de onda (WDM) constituem a
segunda gerao de redes pticas [9] e que se dividem em trs geraes de evoluo
descritas nas seces 2.5.1, 2.5.2 e 2.5.3 (Figura 2.5).
Encaminhamento e Sinalizao:
Gerao de esttico para dinmico
OPS
3
Connectionless WDM
OBS
OLS
Connection-oriented WDM
PON
OXS
2
OXC
OADM
WDM Ponto-a-ponto
OAMP
1
DXC
Granularidade do Trfego:
de grande para mdio para pequeno
DXC Digital Crossconnect (TDM) OXS Optical 'x' Switching (Tecnologias de Comutao ptica)
OAMP Optical Amplifier PON Passive Optical Networks
OADM Optical Add/Drop Multiplexer OLS Optical Label Switching
OXC Optical Crossconnect OBS Optical Burst Switching
OPS Optical Packet Switching
20
Captulo 2. Redes pticas
1
Termo usado para definir redes pticas de longa distncia, tipicamente designadas de redes core ou redes de
backbone inter-regionais [3];
21
Captulo 2. Redes pticas
estarem preparados para lidar com o grande volume de trfego sem constrangimen-
tos [3].
22
Captulo 2. Redes pticas
B
Amplificadores pticos
A C D
Span Span
Ns
Link
1
Redes de bypass ptico ou Optical-bypass-enabled networks, so redes puramente pticas, cuja converso O-
E-O no existe [3];
23
Captulo 2. Redes pticas
Norte Este
Through
Oeste Este
ROADM
ROADM
ROADM
Add/Drop Through
OLT
Add/Drop
Oeste
Sul
a) Sul b)
Uma rede ptica que tire partido da tecnologia WDM geralmente usa uma
fatia restrita do espectro de luz. A Figura 2.8 representa a poro do espectro elec-
tromagntico de trabalho dos sistemas de transmisso baseados na tecnologia
WDM. A escolha deve-se s baixas perdas de atenuao na fibra ptica de slica
nesta zona do espectro. Esta faixa espectral est dividida em trs regies: a banda
convencional designada de Banda-C [1530-1565nm]; a banda de comprimento de
onda longo ou Banda-L [1565-1625nm]; e a banda de comprimento de onda curto
ou Banda-S [1460-1530nm]. A maioria dos sistemas WDM usa a Banda-C, no
entanto estes sistemas tm-se expandido para a Banda-L e Banda-S para aumentar
a sua capacidade [3]. Os comprimentos de onda devem ser escolhidos entre um con-
junto de grelhas de frequncias (12.5, 25, 50 ou 100GHz de espaamento [22]) defi-
nidas pela ITU.
0.30
Perdas na fibra de slica (dB/km)
0.25
0.20
24
Captulo 2. Redes pticas
Tendo como base a Figura 2.6, nesta seco sero descritos em detalhes as
caractersticas dos equipamentos usados em redes WDM, nomeadamente os Ampli-
ficadores pticos, OLTs, OLAs (Optical Line Amplifiers), OADMs, ROADMs e
OXCs.
25
Captulo 2. Redes pticas
Fibra dopada
com Erbium Isolador
Sinal de entrada Sinal de sada
1550 nm
26
Captulo 2. Redes pticas
Laser Bomba
Raman
Transmissor Receptor
Amplificador de Amplificador de
Pr-Amplificador
Potncia Linha
27
Captulo 2. Redes pticas
2.7.2 OLT
Transponder
no ITU 1 ITU
Router IP O-E-O
3 ITU Laser
SONET/ Receptor
SDH
2.7.3 OLA
28
Captulo 2. Redes pticas
Conpensador de
Disperso
1, 2, . . ., W
OADM
OSC OSC
Estgio de Ganho Estgio de Ganho
Laser
Bomba Receptor Laser
Raman
2.7.4 OADM
29
Captulo 2. Redes pticas
a)
N A N B N C
OLT OADM OLT
Passthrough ptico
b)
Transponder Add/Drop Transponder
Figura 2.14 - Exemplo de uma rede para ilustrar o papel de um OADM (adaptado de [1]).
30
Captulo 2. Redes pticas
2.7.5 ROADM
2.7.6 OXC
Os OADMs so teis para lidar com topologias de rede simples, tais como a
topologia linear mostrada na Figura 2.14 ou a topologia em anel, e um nmero
relativamente modesto de comprimentos de onda. O OXC capaz de lidar com
topologias de rede mais complexas como a topologia em malha e um grande nme-
ro de comprimentos de onda, lidando com enormes quantidades de trfego. O OXC
tambm um elemento de rede importante em redes pticas reconfigurveis, onde
os caminhos de luz podem ser implementados ou removidos quando se quiser, sem
haver a necessidade de serem estaticamente implementados. Embora se use o ter-
mo ptico, o switch fabric de um OXC pode ser puramente ptico ou elctrico [1].
A comutao do sinal ptico no domnio elctrico a primeira abordagem
para realizar um OXC designado de OXC elctrico ou OXC opaco (Opaque cross-
connect), sendo a segunda abordagem baseada apenas na comutao no domnio
ptico (All-optical cross-connects ou O-O-O cross-connect), designado tambm de
OXC transparente ou PXC [23]. Nas seces 2.7.6.1 e 2.7.6.2 so descritos em
detalhe a diferena entre os dois tipos de comutadores.
31
Captulo 2. Redes pticas
O-E-O O-E-O
c) O-E-O Ncleo O-E-O
O-E-O ptico O-E-O
O-E-O O-E-O
d) Ncleo OXC
ptico Transparente
32
Captulo 2. Redes pticas
33
Captulo 2. Redes pticas
34
Captulo 2. Redes pticas
OXC Switching
Controller
E/O
Conver. de
Durao da Ligao: Tempo de comutao:
minutos/horas/... >> ms
Rede OCS
Links WDM
Caminhos de luz
Redes de
Cliente
35
Captulo 2. Redes pticas
In-band signalling
Tamanho do pacote:
Dezenas B kB Tempo de comutao:
ns
Cabealhos
Pacotes de controlo
Rede OPS
Links WDM
Redes de
Cliente
36
Captulo 2. Redes pticas
37
Captulo 2. Redes pticas
burst chegar. A Figura 2.18 tambm ilustra a utilizao do tempo de offset. Neste
tipo de redes, a sinalizao implementada Out-of-band, quer seja por um com-
primento de onda dedicado ou por uma rede de controlo separada [19]. Isto signifi-
ca que a sinalizao separada dos canais de dados. Esta separao permite a
implementao electrnica do caminho de controlo de sinalizao enquanto man-
tm completamente transparente o caminho ptico dos dados para transmisso a
alta velocidade [21].
OBS core node
Reservation
Manager Out-of-band signalling
Assembler Canais de
Controlo Offset
Canais de
Tamanho do burst: kB MB Tempo de comutao: Dados
ns ms
Rede OBS
Links WDM
Redes de
Cliente
No final dos anos 90, a ITU-T comeou a trabalhar na OTN para melhorar
as necessidades das redes pticas e das redes multisservio. A hierarquia de trans-
porte e formato associado esto definidos na norma ITU-T G.709 [3]. Estas redes
foram desenhadas para transportar trfego por pacotes tais como o IP e Ethernet
sobre fibras pticas, assim como o trfego legacy e em particular o SONET/SDH.
38
Captulo 2. Redes pticas
OTN
Bit rate nominal SONET/SDH Bit rate nominal
(G.709)
OTU1: 2.666 Gb/s STS-48/STM-16: 2.488 Gb/s
OTU2: 10.709 Gb/s STS-192/STM-64 9.953 Gb/s
OTU3: 43.018 Gb/s STS-786/STM-128: 39.813 Gb/s
OTU4: 111.810 Gb/s N.A N.A
Tabela 2.1 - Comparativo entre os bit rates OTN e SONET/SDH (adaptado de [1] e [3])
Tabela 2.2 - Hierarquia de bit rate para a comutao/multiplexagem OTN (adaptado de [3])
39
Captulo 2. Redes pticas
STM-16
OTU1
CBR2G5
ODU1 X8
X4
CBRX
GFP data
ODUflex ODU2
X40
X32
STM-64
CBR10G
ODU2 OTU2
X16
X10
ODU4
100GBASE-R ODU4 OTU4
40
Captulo 2. Redes pticas
41
Captulo 2. Redes pticas
Hierarquia OTN
42
Captulo 2. Redes pticas
Associated
Overhead
Wrapper
Elctrico OH ODUk Optical Channel Data Unit
a)
ODU
Domnio
Elctrico OTU OTU
OCH OCH
Domnio OMS OMS OMS
ptico
OTS OTS OTS OTS
Figura 2.20 a) Hierarquia OTN (adaptado de [1], [18] e [62]); b) Camadas OTN (adaptado de
[1]).
43
3
Sobrevivncia em Redes pticas
A falha num elemento de rede, quer por problemas electrnicos ou por pro-
blemas na ligao de fibra ptica, pode causar a falha de diversos caminhos de luz,
e desta forma a perda de enormes quantidades de trfego e de receita. Os meca-
nismos de recuperao de falha, conhecidos como mecanismos de proteco e de
restauro, so essenciais numa rede para sobreviver a tais falhas. Se os recursos de
backup esto pr-calculados e reservados, tais como rotas e comprimentos de onda,
so designados de esquemas de proteco. Caso estes recursos no estejam j
determinados e reservados quando ocorre uma falha, e necessitem portanto de ser
dinamicamente descobertos por cada ligao interrompida, ento so designados de
esquemas de restauro. Geralmente, os esquemas dinmicos de restauro so mais
eficientes na utilizao dos recursos de rede porque estes no tm alocado a priori
um caminho alternativo, e providenciam resilincia contra diferentes tipos de falha
(incluindo mltiplas falhas); mas os esquemas de proteco tm um tempo rpido
de recuperao e conseguem garantir o restabelecimento de servios interrompidos
(garantia esta que no pode ser providenciada pelos esquemas de restauro) [13].
45
Captulo 3. Sobrevivncia em Redes pticas
46
Captulo 3. Sobrevivncia em Redes pticas
47
Captulo 3. Sobrevivncia em Redes pticas
O SLE referido tambm como RWA esttico, pode ser formulado como
um ILP (Integer Linear Program) onde o objectivo maximizar o nmero de
ligaes que so encaminhadas com sucesso. Para mais detalhes consultar [29],
[30].
48
Captulo 3. Sobrevivncia em Redes pticas
49
Captulo 3. Sobrevivncia em Redes pticas
usada geralmente para converter uma mtrica multiplicativa numa mtrica aditiva.
A maior disponibilidade de um link corresponde a uma mtrica de link menor;
assim, a execuo do algoritmo shortest-path com esta mtrica produz o caminho
com a disponibilidade mais alta. Como demostrado neste ltimo exemplo, a mtri-
ca pode no estar relacionada com a distncia; assim o termo shortest-path , em
geral, inapropriado [3].
Um algoritmo shortest-path bem conhecido o algoritmo Dijkstra, onde as
entradas para o algoritmo so a topologia de rede, a origem, e o destino do cami-
nho. Trata-se de um greedy algorithm (ou algoritmo ganancioso) que garante o
caminho mais curto entre a origem e o destino, assumindo que existe um caminho.
Os greedy algorithms prosseguem escolhendo a opo ideal em cada passo, sem
considerar os passos seguintes. No caso do algoritmo Dijkstra, esta estratgia pro-
duz o resultado global ptimo (em geral, no entanto estes algoritmos nem sempre
produzem a soluo ptima.) [3].
50
Captulo 3. Sobrevivncia em Redes pticas
1
Uma rede WDM multi-fibra, consiste numa rede WDM onde cada link constitudo por mltiplas fibras, e
cada fibra transporta a informao de mltiplos comprimentos de onda. O WCC menos problemtico em
rede de multi-fibra porque um comprimento de onda que no possa continuar numa fibra pode ser comutado
para outra usando OXC, desde que o comprimento de onda esteja disponvel na outra fibra [29].
51
Captulo 3. Sobrevivncia em Redes pticas
52
Captulo 3. Sobrevivncia em Redes pticas
Plano de Gesto
Sistema de Sistema de
Gesto Gesto
Plano de Controlo
Figura 3.1 - Planos funcionais das redes ASON e GMPLS (adaptado de [4]).
53
Captulo 3. Sobrevivncia em Redes pticas
Isto significa que cada pacote, trama, ou clula deve transportar um identificador
que seja usado pelos ns de rede para encaminhar o pacote. Em cada salto ao lon-
go da rede, o pacote encaminhado com base no valor da etiqueta recebida e des-
pachado para o destino com uma nova etiqueta. A etiqueta trocada (swapped) e
os dados so comutados com base no valor da etiqueta, que d origem a dois ter-
mos: troca de etiqueta (label swapping) e comutao de etiqueta (label switching).
Numa rede MPLS, os pacotes so etiquetados atravs da adio de uma
informao adicional designada de shim header que se encontra entre o cabealho
de rede e o cabealho IP, tal como representado na Figura 3.2.
O shim header MPLS transporta uma etiqueta de 20 bits que usada para
determinar o caminho que o pacote deve seguir. Cada elemento de rede, designado
de LSR (Label Switch Router), mantm uma tabela de informao LFIB (Label
Forwarding Information Base) que permite determinar o prximo salto. A LFIB
contm o mapeamento da {interface de entrada, etiqueta de entrada} para a
{interface de sada, etiqueta de sada}. Isto , quando um pacote recebido, o LSR
determina em que interface chega o pacote e pesquisa a etiqueta no seu shim hea-
der. O LSR com base no valor da etiqueta de entrada, pesquisa na LFIB a interfa-
ce de sada a usar para encaminhar o pacote, alterando a etiqueta de entrada por
uma nova etiqueta de sada. A Figura 3.3 representa o caminho que um pacote
MPLS segue ao longo da rede, designado de LSP (Label Switched Path). Uma vez
que um pacote tenha sido etiquetado no comeo de um LSP (no ingress), o seu
caminho para o egress bem conhecido e estvel por causa do mapeamento feito
nas LFIBs de cada LSR, sendo este tambm bem conhecido e estvel. Assim, a
complexidade apenas existente no ingress onde cada pacote deve ser classificado de
acordo com o seu destino e o servio fornecido (baseado no tipo de aplicao, ou
QoS exigido) e associado a um LSP especfico [32].
54
Captulo 3. Sobrevivncia em Redes pticas
Edge Core Core Edge
Ingress Label Switch Label Switch Label Switch Engress Label Switch
Endereo In Out In Out Endereo IP
Label1 Label3 do prximo
IP-1 Label Label Label Label
Endereo Atribuir salto-2 Endereo
Label1 Label Label2 Label Label3 Remover
IP-1 Transporte Label Transporte IP-2
Layer 2 Inicial Swapping Swapping Label
Layer 2
55
Captulo 3. Sobrevivncia em Redes pticas
RSVP-TE OSPF
Informao de Informao da Actualizao de
Encaminhamento Topologia Recursos
56
Captulo 3. Sobrevivncia em Redes pticas
Dados
IP Dados
IP com MPLS Dados
ATM
IP com GMPLS Dados
SONET/SDH SONET/SDH
pouco SONET/SDH IP com GMPLS
57
Captulo 3. Sobrevivncia em Redes pticas
que so elementos caractersticos do GMPLS para uma rede com uma estrutura de
camadas complexa. Alm disso, o peer model permite executar proteco ou res-
tauro extremo-a-extremo mesmo existindo mltiplas camadas.
Contudo, como o estado dos links de todas as camadas so anunciadas para
cada n, so transferidas grandes quantidades de informao atravs do plano de
controlo. Alm disso, se o TE multicamada executado considerando o estado dos
links de todas as camadas, a quantidade de clculos necessrios torna-se enorme.
Devido a estes problemas de escalabilidade, difcil de realizar um peer model per-
feito. Em contrapartida, o overlay model consegue resolver este problema de esca-
labilidade.
O peer model pode explorar em pleno as vantagens do GMPLS, como o TE
multicamada, mas no interesse de preservar a escalabilidade, o overlay model res-
tringe a utilizao total das funes do GMPLS atravs da separao do plano de
controlo em duas camadas. O overlay model considerado como um passo introdu-
trio para a aplicao das redes GMPLS. As vantagens do TE multicamada do
peer model e a vantagem da escalabilidade com planos de controlo independes do
overlay model so contrabalanadas [36].
Uma outra aproximao um hybrid model que combina os dois modelos
acima descritos. Alguns edge devices servem como peers para a rede ptica e parti-
lham a mesma instncia de um plano de controlo comum com essa rede. Outros
edge devices poderiam ter o seu prprio plano de controlo (ou uma instncia de
plano de controlo separado da rede de core), e interface com a rede ptica atravs
da UNI. Isto representa a soluo mais desejvel oferecendo aos operadores e pres-
tadores de servios uma flexibilidade essencial para implementar o modelo mais
rentvel s suas necessitadas [35].
Isto permite tambm que a escolha entre os modelos seja impulsionada por
consideraes comerciais e de engenharia, em vez de serem limitados pela aborda-
gem da estratificao de sub-redes dentro dos domnios da tecnologia. Ao mesmo
tempo, desenvolver um plano de controlo comum com a reutilizao e a extenso
dos protocolos de encaminhamento e de sinalizao existentes, evita a necessidade
de reinventar a roda, reduzindo assim os riscos associados com o desenvolvimen-
to de novos protocolos e o time to makert para novos equipamentos de comutao
ptica. Algumas melhorias so claramente necessrias aos protocolos de encami-
nhamento e sinalizao existentes no MPLS, para tratar as caractersticas peculia-
res das redes de transporte pticas. Estas extenses de protocolos foram normali-
58
Captulo 3. Sobrevivncia em Redes pticas
zadas pela IETF no mbito do GMPLS e que sero descritas e detalhadas na sec-
o 3.4 [33].
a) b)
Embora a extenso dos protocolos MPLS para a gesto de redes pticas possa
parecer possvel e desejvel, no se deve deixar de ter em conta o facto de existi-
rem diferenas significativas entre redes de comutao de pacotes e redes de comu-
tao de circuitos. Por exemplo, em redes MPLS, as mensagens do Plano de Con-
trolo e os pacotes do Plano de Dados partilham o mesmo meio de transmisso, e
consequentemente, a mesma fiabilidade. Uma falha tanto afecta o encaminhamento
do pacote de dados como o encaminhamento do pacote de controlo e vice-versa.
Em contraste, o Plano de Dados e o Plano de Controlo em redes pticas no so
assim to dependentes um do outro. Na realidade, estes no necessitam de parti-
lhar a mesma topologia. Por exemplo, as mensagens trocadas entre OXCs podem
ser enviadas out-of-band (ou out-of-fiber configuration [31]), por bits de overhead
dos canais TDM (Time Dividsion Multiplexing), ou por um comprimento de onda
dedicado numa fibra ptica de interligao entre os ns (estes ltimos designados
tambm de in-fiber configuration [31]) (em detalhe na seco 3.4.3). Este canal de
comunicao pode falhar independentemente do Plano de Dados. Do mesmo modo,
um OXC tipicamente constitudo por um switching fabric (referido como n de
Plano de Dados) e um processador de Plano de Controlo (referido como n de Pla-
no de Controlo), o n de Plano de Controlo pode falhar independentemente do n
de Plano de Dados. Alm disso, a topologia do Plano de Dados e de Controlo no
precisam de ser idnticas. Dois OXCs que sejam adjacentes no Plano de Dados
podem no ser do ponto de vista do Plano de Controlo.
A Figura 3.7 mostra na parte inferior a topologia do Plano de Dados e na
parte superior a topologia do Plano de Controlo. Tendo em conta as exigncias
rigorosos da fiabilidade das ligaes pticas, fundamental que as falhas no Plano
de Controlo no devam resultar em nenhuma interrupo dentro do Plano de
Dados [37].
59
Captulo 3. Sobrevivncia em Redes pticas
Controlo Controlo
IP IP
Controlo
IP Plano de
Controlo
IP Controlo
Cliente
UNI
Cliente
Cliente OXC
Cliente
Cliente Plano de
Dados
3.4 GMPLS
60
Captulo 3. Sobrevivncia em Redes pticas
61
Captulo 3. Sobrevivncia em Redes pticas
62
Captulo 3. Sobrevivncia em Redes pticas
da rede. Este mdulo usa tambm a informao recebida dos outros ns da rede
para construir uma representao local da topologia da rede ptica. Esta represen-
tao usada para executar a seleco do caminho quando as ligaes so estabe-
lecidas. Posto isto, a topologia do Plano de Dados e o Plano de Controlo no preci-
so de ser iguais, o protocolo de encaminhamento responsvel por anunciar estas
duas topologias para que cada n possa manter uma viso consistente das topolo-
gias de rede. A topologia do Plano de Dados usada para a seleco do caminho
durante o estabelecimento da ligao, enquanto que a topologia do Plano de Con-
trolo usada para construir a tabela de encaminhamento de mensagens de controlo
IP.
Para garantir uma viso completa da topologia da rede ptica em todos os
ns da rede, o protocolo de encaminhamento deve garantir a entrega da informa-
o topolgica da rede. O protocolo de encaminhamento deve ser tambm escalvel
para evitar falhas no protocolo resultantes da excessiva troca de informao de
encaminhamento em redes de grande dimenso. As redes pticas podem ser com-
postas por centenas a milhares de ns de rede, com componentes do Plano de
Dados potencialmente contendo milhares de portos fsicos. Uma aproximao para
um protocolo de encaminhamento escalvel minimizar a informao global, man-
tendo a informao e tomadas de deciso localmente nos ns. Por exemplo, links
paralelos individuais com caractersticas comuns podem ser agregados num bundled
link, que esconde os detalhes individuais de cada link. Dessa forma, atravs do pro-
tocolo de encaminhamento, s distribuda para toda a rede, a informao resumi-
da desses links. Para lidar com a escalabilidade em termos de nmero de ns de
rede, o protocolo de encaminhamento deve ser capaz de suportar encaminhamento
hierrquico, atravs da sumarizao de endereos e topologias. Por exemplo, o pro-
tocolo OSPF suporta uma nica routing rea de backbone, e mltiplas reas non-
backbone. Os border routers entre as reas, podem sumarizar a informao anun-
ciada sobre a topologia da rea com o intuito de reduzir, quer o overhead das men-
sagens de encaminhamento, quer a quantidade de estados que tm de ser mantidos
nos routers. Em redes pticas de grandes dimenses, constitudas por mltiplas
sub-redes, o protocolo de encaminhamento pode tambm ser desenhado para anun-
ciar uma representao abstracta da topologia da sub-rede. Estas tcnicas podem
ser directamente aplicadas s redes pticas, desde que a perda de informao devi-
do ao encaminhamento hierrquico e sumarizao no afectem de forma adversa a
eficcia das rotas seleccionadas para ligaes [37].
63
Captulo 3. Sobrevivncia em Redes pticas
64
Captulo 3. Sobrevivncia em Redes pticas
65
Captulo 3. Sobrevivncia em Redes pticas
66
Captulo 3. Sobrevivncia em Redes pticas
67
Captulo 3. Sobrevivncia em Redes pticas
numa rota alternativa usado para os pacotes de controlo, em caso de falha. Nesse
sentido, se a rede de Plano de Controlo estiver bem desenhada, uma pequena falha
nos links de Plano de Controlo no deve afectar a operao bsica da rede ptica.
Na soluo de reencaminhamento na camada IP, o protocolo de encami-
nhamento IP assumido para automaticamente descobrir a nova topologia de rede
do Plano de Controlo aps a falha num link de Plano de Controlo. Se o endereo
usado nas mensagens do protocolo de encaminhamento e de sinalizao for o ende-
reo do n em vez dos endereos das interfaces actualmente usadas pelo RSVP-TE,
as mensagens sero encaminhadas para o destino desejado. A comunicao de vizi-
nhana no ser perdida enquanto a rede de Plano de Controlo estiver conectada e
as tabelas de encaminhamento convergido. Esta soluo pode ser aceitvel se o
tempo de convergncia no for um problema e se a rede de Plano de Controlo esti-
ver desenhada com redundncia suficiente para lidar com as falhas. Se isto no for
aceitvel, uma das outras duas possibilidades devem ser utilizadas. De notar que,
se os vizinhos de Plano de Controlo perderem toda a conectividade entre si, no
ser possvel criar ou remover ligaes entre esses ns. Neste tipo de cenrios, o
estado do Plano de Controlo deve ser sincronizado depois da reparao da falha no
link de Plano de Controlo [37].
68
Captulo 3. Sobrevivncia em Redes pticas
69
Captulo 3. Sobrevivncia em Redes pticas
disponveis, em vez de se retirar os anncios dos links anunciados pelo processo que
falhou, prefervel permitir que os ns continuem a utilizar a informao desactua-
lizada [37].
Foi assumido pela comunidade cientfica que estudava o tema que o Plano
de Controlo era muito fivel e, dessa forma, as tcnicas de recuperao de falha
concentravam-se apenas no Plano de Dados. No entanto, com o intuito de manter
as ligaes estabelecidas no Plano de Dados, os mecanismos de proteco no Plano
de Controlo so tambm bastante importantes. Nesse sentido, um Plano de Con-
trolo fivel necessrio para funcionamento adequado das NGNs, uma vez que este
responsvel pelo encaminhamento, encaminhamento de mensagens e gesto das
ligaes e recursos. Alm disso, a maioria dos mecanismos de proteco e de res-
tauro no Plano de Dados precisam de uma sinalizao eficiente do Plano de Con-
trolo [4].
Foram descritos nas seces subjacentes seco 3.4.1.3 os mtodos para
recuperar cada um dos tipos de falha no Plano de Controlo. Nesta seco sero
descritos de uma forma genrica os passos para recuperar este plano em caso de
falha e os tipos de mecanismos de proteco e de restauro usados de forma sinteti-
zada.
Como mostrado na Figura 3.9, os principais passos para neutralizar uma
falha no Plano de Controlo so os seguintes: detectar, localizar, notificar e comutar
(proteco e/ou restauro), como representado pela sequncia superior na figura, e a
reverso opcional (optional reversion), representada pela sequncia inferior na figu-
ra. Alguns procedimentos de ciclos de recuperao mostrados na Figura 3.9, tais
como a fault detection e fault hold-off, devem ser dependentes de protocolos de
camada inferior. O primeiro deve incluir procedimentos de deteco de falha de
camada inferior como o TCP (Transmission Control Protocol) timeout, e o ltimo
geralmente um tempo de espera para a camada inferior tomar uma aco proac-
tiva, que poderia substituir o mecanismo de proteco do Plano de Controlo. Mais
uma vez, durante o ciclo de reverso, o fault clearing o perodo de tempo neces-
srio para detectar (tambm pelos mecanismos de camada inferior) que o recurso
que estava com problemas foi recuperado, e o clear hold-off o tempo de espera
70
Captulo 3. Sobrevivncia em Redes pticas
Start of Recovery
Network Fault Start of recovery operation Path traffic Control Plane
impairment detected notification operation complete recovered recovered
71
Captulo 3. Sobrevivncia em Redes pticas
72
Captulo 3. Sobrevivncia em Redes pticas
Uma caracterstica chave existente em redes pticas e que deve ser preser-
vada nas redes GMPLS capacidade de resilincia de rede, que , a capacidade de
recuperar as ligaes em caso de falhas na rede. A resilincia de rede pode ser
garantida usando ou mecanismos de proteco ou de restauro, que so a relao de
compromisso entre o tempo de recuperao com a eficincia dos recursos, respecti-
vamente [38].
Existem dois tipos de falhas bsicas numa rede ptica, falha na ligao de
fibra ptica e falha no n. A principal causa para o primeiro problema so os cor-
tes na fibra ptica, que ocorrem com bastante frequncia, apesar de existir um
esforo considervel na proteco fsica dos cabos [40]. Segundo [7], para cada 10
km de fibra, expectvel um corte aproximadamente a cada 12 anos. Os factores
que contribuem para este tipo de problemas incluem os trabalhos de construo
civil (backhoe fade1), roedores, fogo ou erro humano. Os problemas que esto na
causa da falha de um n so tipicamente problemas causados por falha de energia
elctrica, hardware [4] ou at mesmo de software [3].
1
Termo usado na indstria de telecomunicaes para definir um corte de fibra causado acidentalmente [59].
73
Captulo 3. Sobrevivncia em Redes pticas
74
Captulo 3. Sobrevivncia em Redes pticas
75
Captulo 3. Sobrevivncia em Redes pticas
76
Captulo 3. Sobrevivncia em Redes pticas
<100%
Disjoint
RRLs
paths
Protection
IPFRR
cycles
<100%
Redundant
p-cycles trees
Figura 3.10 - Taxonomia dos principais esquemas de recuperao de falha em NGNs (adaptado de [4]).
1 g1 g2
3 1 2
2
4 3 4
3 4
g g
a) b)
Figura 3.11 - Exemplo de quadro SRLGs (i.e., g1, g2, g3 e g4) adaptado de [31]).
77
Captulo 3. Sobrevivncia em Redes pticas
A H I J K L M N Z
Caminho Primrio
T
O S
a) P Q R
A H I J K L M N Z
T
O S
b) P Q R
78
Captulo 3. Sobrevivncia em Redes pticas
n receptor selecciona o canal com o melhor sinal para o canal primrio. Uma vez
que o processo de seleco controlado apenas pelo n receptor, no existe a
necessidade de sinalizao adicional para realizar a comutao. Outro modo de
operao chamado de 1+1 bidireccional, que requer a coordenao entre ns,
para que ambos seleccionem o mesmo canal primrio. Isto requer uma troca de
mensagens adicional entre os ns. No que diz respeito ao GMPLS, o n de recepo
deve notificar o n de transmisso (e.g., usando as mensagens Channel Status do
LMP) quando uma falha detectada [38].
Para a proteco de span M:N, M canais de proteco so partilhados entre
N canais primrios. A Figura 3.13b) mostra o caso especial da proteco de span
1:1. Uma vez que os dados no so replicados nos dois canais (primrio e de pro-
teco), a falha deve ser primeiro localizada, o n de recepo pode iniciar local-
mente a proteco de span atravs do envio da mensagem RSVP Path Refresh.
Estas mensagens so uma caracterstica distinta do RSVP que permitem aos ns
intermdios actualizar o estado de um LSP. Esta caracterstica permite a comuta-
o do canal primrio para o canal de proteco. De notar que o benefcio de tro-
car antecipadamente a configurao de proteco partilhada usando o LMP que
este processo minimiza o potencial conflito de canal (label) de proteco quando a
proteco comuta. Quando o n de recepo recebe uma mensagem RSVP Path
com o novo objecto, verifica os parmetros, actualiza o estado de sinalizao e, ou
responde com uma mensagem RSVP Resv (detalhes das mensagens RSVP em [42])
com uma nova label ou gera uma mensagem de erro [33].
(2)
(1)
Proteco Backup
A B A B
Figura 3.13 - a) Proteco de link 1+1; b) Proteco de link 1:1 (adaptado de [33]).
79
Captulo 3. Sobrevivncia em Redes pticas
Caminho Primrio
A H I J K L M N Z
T
O S
P Q R
Caminho de Proteco
80
Captulo 3. Sobrevivncia em Redes pticas
que a proteco do tipo 1+1. Como na proteco de span 1+1, esta a proteco
mais rpida em caso de falha. Da mesma forma, requer o dobro dos recursos e pode
necessitar de troca adicional de mensagens entre os extremos se os dois ns de um
LSP bidireccional forem obrigados a seleccionar os mesmos caminhos, um como
primrio e outro como proteco.
Um aspecto comum da proteco M:N de caminho quando M caminhos de
proteco SRLG-disjoint esto preestabelecidos para proteger N caminhos prim-
rios SRLG-disjoint. De notar que, desde que os recursos estejam preestabelecidos,
todos os caminhos M+N devem ser inicializados (e terminados) no mesmo n de
origem (e destino). Isto protege contra falhas no caminho primrio. Os caminhos
protegidos so estabelecidos como LSPs primrios; trfego extra de baixa priorida-
de deve ser encaminhado por estes caminhos de proteco desde que tenham a
mesma origem e destino. Quando uma falha detectada ao longo do caminho pri-
mrio, o LMP pode ser usado para localizar a falha. Uma vez localizada a falha, a
mensagem RSVP Notify enviada para o n origem. Aps a notificao, o caminho
de proteco re-sinalizado usando a mensagem RSVP Path com o objecto Admi-
nistartive Status a indicar que o LSP de proteco est agora activo como um LSP
primrio [38].
Origem Destino
N Trnsito - N Trnsito -
Working Working
81
Captulo 3. Sobrevivncia em Redes pticas
teco til para proteger contra uma falha no span, n, ou numa particular por-
o da rede usada pelo LSP. Este tipo de proteco/restauro referido como Pro-
teco de Segmento e Restauro de Segmento, ou como Recuperao de Segmento,
no caso colectivo. Um LSP que disponibilize a proteco ou o restauro referido
como um LSP de Proteco de Segmento ou um LSP de Restauro de Segmento. O
termo LSP de Recuperao de Segmento usado para referenciar os dois tipos
[44].
Um caminho primrio dividido em multiplos segmentos, sendo o caminho
de proteco disponibilizado de forma independente para cada segmento. Dividir
um caminho em mltiplos segmentos mais pequenos, o tempo de recuperao da
falha reduzido, comparando com a proteco de caminho [3].
B C D E F G
Caminho Primrio
A H I J K L M N Z
Proteco de
T Segmento 3
O S
P Q R
a) Proteco de Segmento 1 Proteco de Segmento 2
Proteco de Segmento 2
B C D E F G
Caminho Primrio
A H I J K L M N Z
T
O S
P Q R Proteco de
Segmento 3
b)
Proteco de Segmento 1
82
Captulo 3. Sobrevivncia em Redes pticas
83
Captulo 3. Sobrevivncia em Redes pticas
Para suportar restauro de linha, onde o trfego comutado via rota alterna-
tiva em torno da falha, seleccionado um novo caminho num n intermdio. Isto
envolve a passagem do trfego atravs de ns trnsito adicionais. O restauro de
linha pode ser benfico para ligaes que atravessem mltiplos saltos e/ou grandes
distncias porque a latncia incorrida pela notificao de falha pode ser significati-
vamente reduzida. Neste caso, em vez do caminho inteiro apenas alguns segmentos
da ligao que so reencaminhados. O restauro de linha, no entanto, pode que-
brar os requisitos TE se uma rota explcita strict-hop definida para a ligao.
Alm disso, as restries usadas para o encaminhamento da ligao devem ser
encaminhadas. Isto permite que um n intermdio que faa restauro de linha seja
capaz de calcular uma rota alternativa adequada. Isto similar ao problema do
estabelecimento/manuteno de requisitos TE que abranjam mltiplas reas [33].
84
Captulo 3. Sobrevivncia em Redes pticas
das optimizaes para apressar o processo de restauro; por exemplo, as rotas alter-
nativas podem ser pr-computadas pelos extremos do caminho e memorizadas para
uso futuro. Um caminho de restauro pode reutilizar ns do caminho primrio e/ou
incluir ns intermdio adicionais. Como representado na Figura 3.17, aps a recep-
o de uma notificao de falha, o n origem calcula o caminho de forma dinmica
a ser usado e sinaliza para uma nova ligao ser estabelecida. De notar que o sinal
original no enviado em simultneo sobre os dois caminhos at ao destino. Deve
ser salientado tambm que os recursos nos ns transmissores so reutilizados (par-
tilhados) sempre que possvel, e os recursos nos ns intermdios que no so mais
necessrios so libertos. Esta partilha de recursos aumenta a hiptese das ligaes
terem os recursos necessrios quando o reencaminhamento est em progresso. Se os
caminhos forem pr-calculados e os recursos pr-atribudos, isto permite um rpido
reencaminhamento desde que esses recursos estejam garantidos, a no ser que eles
falhem ou sejam pedidos por ligaes de alta prioridade [33].
Notify Notify
Origem Destino
85
Captulo 3. Sobrevivncia em Redes pticas
86
4
Simulao de uma rede ptica
87
Captulo 4. Simulao de uma rede ptica
Nesta seco ser feita uma pequena abordagem ao sistema operativo usado
como suporte ao ns-3. So descritos os detalhes relativos aos componentes e mdu-
los que constituem o ns-3, com especial foco no mdulo WDM.
88
Captulo 4. Simulao de uma rede ptica
Utilitrios
Dispositivos Protocolos
visualizer
bridge spectrum applications aodv
config-store
csma tap-bridge internet energy dsdv
flow-monitor
emu uan mpi olsr
virtual-net- netanim
point-to-point network mobility click
device
stats
lte wifi core propagation nix-vector
topology-read
mesh wimax openflow
BRITE
89
Captulo 4. Simulao de uma rede ptica
90
Captulo 4. Simulao de uma rede ptica
Para se poder interagir com os mdulos WDM a melhor forma atravs das
helper API (Application Programming Interface) e atributos de cada mdulo
[57].
As helper API disponibilizam um conjunto de classes e mtodos que reali-
zam operaes comuns mais facilmente do que as APIs de baixo nvel. Estas hel-
per API consistem em container objects e helper classes, e so implementadas
usando APIs de baixo nvel [51].
O mdulo WDM define trs helper API, representadas abaixo, que permi-
tem a interaco com os restantes componentes do mdulo.
wdm-helper.{cc,h}
wdm-osa-helper.{cc,h}
wdm-rwa-helper.{cc,h}
91
Captulo 4. Simulao de uma rede ptica
//Criar os Nodes
NodeContainer oxcNodes;
NodeContainer muxNodes;
oxcNodes.Create(6);
muxNodes.Create(6);
//Criar os Nodes
NodeContainer txRxNodes;
txRxNodes.Create(8);
wdmHelper->SetTxRxDataRate("10Gbps");
wdmHelper->SetTxPower(0.01); //10mW //10dBm
92
Captulo 4. Simulao de uma rede ptica
channelID = 2;
wdmHelper->InstallTxRxDevice(txRxNodes.Get(1), channelID);
wdmHelper->InstallTxRxDevice(txRxNodes.Get(4), channelID);
channelID = 3;
wdmHelper->InstallTxRxDevice(txRxNodes.Get(2), channelID);
wdmHelper->InstallTxRxDevice(txRxNodes.Get(5), channelID);
channelID = 5;
wdmHelper->InstallTxRxDevice(txRxNodes.Get(6), channelID);
wdmHelper->InstallTxRxDevice(txRxNodes.Get(7), channelID);
wdmHelper->Connect(txRxNodes.Get(0), muxNodes.Get(0));
wdmHelper->Connect(txRxNodes.Get(1), muxNodes.Get(1));
wdmHelper->Connect(txRxNodes.Get(2), muxNodes.Get(2));
wdmHelper->Connect(txRxNodes.Get(3), muxNodes.Get(3));
wdmHelper->Connect(txRxNodes.Get(4), muxNodes.Get(4));
wdmHelper->Connect(txRxNodes.Get(5), muxNodes.Get(5));
wdmHelper->Connect(txRxNodes.Get(6), muxNodes.Get(0));
wdmHelper->Connect(txRxNodes.Get(7), muxNodes.Get(4));
93
Captulo 4. Simulao de uma rede ptica
wdmHelper->Connect(muxNodes.Get(0), oxcNodes.Get(0));
wdmHelper->Connect(muxNodes.Get(1), oxcNodes.Get(1));
wdmHelper->Connect(muxNodes.Get(2), oxcNodes.Get(2));
wdmHelper->Connect(muxNodes.Get(3), oxcNodes.Get(3));
wdmHelper->Connect(muxNodes.Get(4), oxcNodes.Get(4));
wdmHelper->Connect(muxNodes.Get(5), oxcNodes.Get(5));
MUX/DEMUX-17
PortID: 1 PortID: 0 PortID: 8 PortID: 1
TxRx-9 OXC-3
channelID=1
PortID: 0 PortID: 0 PortID: 8 PortID: 0
wdmHelper->Connect(oxcNodes.Get(0), oxcNodes.Get(1));
wdmHelper->Connect(oxcNodes.Get(1), oxcNodes.Get(2));
wdmHelper->Connect(oxcNodes.Get(2), oxcNodes.Get(3));
wdmHelper->Connect(oxcNodes.Get(3), oxcNodes.Get(4));
wdmHelper->Connect(oxcNodes.Get(4), oxcNodes.Get(5));
wdmHelper->Connect(oxcNodes.Get(5), oxcNodes.Get(0));
wdmHelper->Connect(oxcNodes.Get(1), oxcNodes.Get(5));
wdmHelper->Connect(oxcNodes.Get(2), oxcNodes.Get(4));
94
Captulo 4. Simulao de uma rede ptica
20km
OXC-5 OXC-4
20k
m
km
20
OXC-3
20
20k
km
OXC-0
m
20k
km
m
20
20km
OXC-1 OXC-2
95
Captulo 4. Simulao de uma rede ptica
Para testar a conectividade entre cada TxRx DWDM foi instalada uma
stack de internet para simular um servio IP sobre WDM. Desta forma foi possvel
representar um servio IP usando os canais pticos implementados no cenrio em
estudo. Para isso, foi instalado um cliente e um servidor UDP (User Datagram
Protocol), um em cada extremo do canal, de modo a simular a troca de pacotes
entre os dois TxRx.
Na sequncia de comandos que se seguem, foram definidos tempos diferentes
para a simulao da conectividade IP de cada canal. Isto permite diferenciar de
forma mais simples a comunicao dentro de cada canal.
O atributo MaxPackets representa o nmero de pacotes que ser permiti-
do enviar durante a simulao. O atributo Interval indica quanto tempo tem de
esperar entre pacotes, e o atributo PacketSize diz respeito ao tamanho do pay-
load que o pacote deve ter.
//Instalar InternetStack
InternetStackHelper stack;
stack.Install(txRxNodes);
//Assignar IP addresses
Ipv4AddressHelper address;
address.SetBase("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer i0i3 = address.Assign(d0d3);
96
Captulo 4. Simulao de uma rede ptica
address.NewNetwork();
Ipv4InterfaceContainer i1i4 = address.Assign(d1d4);
address.NewNetwork();
Ipv4InterfaceContainer i2i5 = address.Assign(d2d5);
address.NewNetwork();
Ipv4InterfaceContainer i6i7 = address.Assign(d6d7);
//Application-1
UdpEchoServerHelper echoServer (9);
ApplicationContainer serverApps = echoServer.Install (txRxNodes);
serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (1.046));
97
Captulo 4. Simulao de uma rede ptica
Com base nos mtodos disponibilizados pelo mdulo WDM, foi criado o
script de simulao para testar uma rede de core ptica WDM em trs ambientes
de falha. Desta forma, foi possvel estudar o comportamento do algoritmo RWA no
reencaminhamento dos canais afectados para um caminho alternativo.
4.3.1 Boilerplate
1
Editores emacs so editores de texto customizveis e extensveis [60].
98
Captulo 4. Simulao de uma rede ptica
#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/mobility-module.h"
#include "ns3/wdm-module.h"
#include "ns3/ipv4-global-routing-helper.h"
#include "ns3/internet-module.h"
#include "ns3/applications-module.h"
#include "ns3/config-store.h"
#include "ns3/netanim-module.h"
#include "ns3/point-to-point-helper.h"
#include <ns3/log.h>
99
Captulo 4. Simulao de uma rede ptica
4.3.3.2 Topologia
A topologia do cenrio em estudo deve ser criada com base nos mtodos
disponibilizados pelo mdulo WDM, que se encontram descritos na seco 4.2.
Outros mtodos devem ser tambm usados para completar o cenrio topolgico,
nomeadamente o MobilityModel que ir definir a posio dos ns com base em
posies cartesianas.
// Instalar a mobilidade
Ptr<ListPositionAllocator> positionAlloc =
CreateObject<ListPositionAllocator>();
MobilityHelper mobility;
mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel");
mobility.SetPositionAllocator(positionAlloc);
mobility.Install(oxcNodes);
mobility.Install(txRxNodes);
mobility.Install(muxNodes);
100
Captulo 4. Simulao de uma rede ptica
com o nome animation.xml, que posteriormente ir ser usado pela aplicao NetA-
nim.
// Nome do ficheiro do output da animao
std::string animFile = "animation.xml" ;
4.3.3.4 Simulao
101
Captulo 4. Simulao de uma rede ptica
4.4 NetAnim
102
Captulo 4. Simulao de uma rede ptica
1.002s 6 UdpEchoClientApplication:Send(): [INFO ] At time 1.002s client sent 1024 bytes to 10.1.1.2 port 9
1.0023s 9 UdpEchoServerApplication:HandleRead(): [INFO ] At time 1.0023s server received 1024 bytes from 10.1.1.1 port 49153
1.0023s 9 UdpEchoServerApplication:HandleRead(): [LOGIC] Echoing packet
1.0023s 9 UdpEchoServerApplication:HandleRead(): [LOGIC] Echoing packet
1.0023s 9 UdpEchoServerApplication:HandleRead(): [INFO ] At time 1.0023s server sent 1024 bytes to 10.1.1.1 port 49153
1.0026s 6 UdpEchoClientApplication:HandleRead(): [INFO ] At time 1.0026s client received 1024 bytes from 10.1.1.2 port 9
Figura 4.7 - Fluxo de pacotes UdpEchoClient e UdpEchoServer entre o internet device instalado no
TxRx-6 e TxRx-9 recolhidos nos logs de output.
Figura 4.6 - Fluxo de pacotes UdpEchoClient e UdpEchoServer entre o internet device instalado no
TxRx-6 e TxRx-9 representados no NetAnim.
103
Captulo 4. Simulao de uma rede ptica
4.5 Resultados
104
Captulo 4. Simulao de uma rede ptica
Internet Internet
Stack IPv4 Stack IPv4
TxRx-6 TxRx-12
PortID: 0
PortID: 0 PortID: 4 PortID: 4
PortID: 2 PortID: 5
PortID: 3 PortID: 4
PortID: 7 PortID: 6
PortID: 0 PortID: 0
OXC-1 OXC-5
PortID: 2 PortID: 5
PortID: 8 PortID: 8 PortID: 8 PortID: 8
PortID: 0 PortID: 0
PortID: 1 PortID: 0
channelID=1
Internet Internet Internet
Stack IPv4 TxRx-9 Stack IPv4 Stack IPv4
Internet
Stack IPv4
105
Captulo 4. Simulao de uma rede ptica
A Figura 4.9 representa a topologia de rede sem falhas. Nas seces subja-
centes sero mostradas em detalhe o conjunto de ligaes de fibra ptica entre os
equipamentos WDM por onde encaminhado o canal DWDM ID-1. So apresen-
tados tambm os resultados do clculo do canal ptico, incluindo os pathloss, e as
tabelas de comutao de comprimentos de onda de todos os OXC da rede. Foram
realizadas medidas pticas nos links entre o OXC-1 e o OXC-2, e o OXC-5 e o
OXC-0, para confirmar a existncias dos canais.
Figura 4.10 e Figura 4.11 representam os detalhes das ligaes entre os dis-
positivos WDM por onde encaminhado o canal DWDM com o ID-1, num
ambiente sem falhas na topologia de rede.
106
Captulo 4. Simulao de uma rede ptica
Internet UdpEchoClientApplication:Send(): [INFO ] At time 1.002s client sent 1024 bytes to 10.1.1.2 port 9
Stack IPv4 UdpEchoClientApplication:HandleRead(): [INFO ] At time 1.0026s client received 1024 bytes from 10.1.1.2 port 9
NodeId: 6
Device Index: 0 Type: TxRx
TxRx-6 PortID: 0 Port Direction: IN Connected: 1 Remote Node: 14 Remote Port: 0 Remote Type: Dmux
Receiver ChannelID: 1
PortID: 1 Port Direction: OUT Connected: 1 Remote Node: 14 Remote Port: 0 Remote Type: Mux
Transmitter ChannelID: 1
PortID: 0 PortID: 1
NodeId: 14
Device Index: 0 Type: Mux
PortID: 0 Port Direction: IN Connected: 1 Remote Node: 6 Remote Port: 1 Remote Type: TxRx
PortID: 1 Port Direction: IN Connected: 0
PortID: 2 Port Direction: IN Connected: 0
PortID: 3 Port Direction: IN Connected: 0
PortID: 4 Port Direction: IN Connected: 1 Remote Node: 12 Remote Port: 1 Remote Type: TxRx
PortID: 5 Port Direction: IN Connected: 0
PortID: 0 PortID: 0
PortID: 6 Port Direction: IN Connected: 0
PortID: 7 Port Direction: IN Connected: 0
MUX/DEMUX-14
PortID: 8 Port Direction: OUT Connected: 1 Remote Node: 0 Remote Port: 1 Remote Type: OXC
Device Index: 1 Type: Dmux
PortID: 8 PortID: 8 PortID: 0 Port Direction: OUT Connected: 1 Remote Node: 6 Remote Port: 0 Remote Type: TxRx
PortID: 1 Port Direction: OUT Connected: 0
PortID: 2 Port Direction: OUT Connected: 0
PortID: 3 Port Direction: OUT Connected: 0
PortID: 4 Port Direction: OUT Connected: 1 Remote Node: 12 Remote Port: 0 Remote Type: TxRx
PortID: 5 Port Direction: OUT Connected: 0
PortID: 6 Port Direction: OUT Connected: 0
PortID: 7 Port Direction: OUT Connected: 0
PortID: 8 Port Direction: IN Connected: 1 Remote Node: 0 Remote Port: 0 Remote Type: OXC
NodeId: 0
PortID: 0 PortID: 1 Device Index: 0 Type: OXC
PortID: 0 Port Direction: INOUT Connected: 1 Remote Node: 14 Remote Port: 8 Remote Type: Dmux
PortID: 1 Port Direction: INOUT Connected: 1 Remote Node: 14 Remote Port: 8 Remote Type: Mux
OXC-0 PortID: 2 Port Direction: INOUT Connected: 1 Remote Node: 1 Remote Port: 3 Remote Type: OXC
PortID: 3 Port Direction: INOUT Connected: 1 Remote Node: 1 Remote Port: 2 Remote Type: OXC
PortID: 4 Port Direction: INOUT Connected: 1 Remote Node: 5 Remote Port: 5 Remote Type: OXC
PortID: 5 Port Direction: INOUT Connected: 1 Remote Node: 5 Remote Port: 4 Remote Type: OXC
PortID: 2 PortID: 3 PortID: 6 Port Direction: INOUT Connected: 0
PortID: 7 Port Direction: INOUT Connected: 0
NodeId: 1
PortID: 3 PortID: 2 Device Index: 0 Type: OXC
PortID: 0 Port Direction: INOUT Connected: 1 Remote Node: 15 Remote Port: 8 Remote Type: Dmux
PortID: 1 Port Direction: INOUT Connected: 1 Remote Node: 15 Remote Port: 8 Remote Type: Mux
PortID: 2 Port Direction: INOUT Connected: 1 Remote Node: 0 Remote Port: 3 Remote Type: OXC
OXC-1 PortID: 3 Port Direction: INOUT Connected: 1 Remote Node: 0 Remote Port: 2 Remote Type: OXC
PortID: 4 Port Direction: INOUT Connected: 1 Remote Node: 2 Remote Port: 3 Remote Type: OXC
PortID: 5 Port Direction: INOUT Connected: 1 Remote Node: 2 Remote Port: 2 Remote Type: OXC
PortID: 4 PortID: 5 PortID: 6 Port Direction: INOUT Connected: 1 Remote Node: 5 Remote Port: 7 Remote Type: OXC
PortID: 7 Port Direction: INOUT Connected: 1 Remote Node: 5 Remote Port: 6 Remote Type: OXC
107
Captulo 4. Simulao de uma rede ptica
NodeId: 2
PortID: 3 PortID: 2 Device Index: 0 Type: OXC
PortID: 0 Port Direction: INOUT Connected: 1 Remote Node: 16 Remote Port: 8 Remote Type: Dmux
PortID: 1 Port Direction: INOUT Connected: 1 Remote Node: 16 Remote Port: 8 Remote Type: Mux
OXC-2 PortID: 2 Port Direction: INOUT Connected: 1 Remote Node: 1 Remote Port: 5 Remote Type: OXC
PortID: 3 Port Direction: INOUT Connected: 1 Remote Node: 1 Remote Port: 4 Remote Type: OXC
PortID: 4 Port Direction: INOUT Connected: 1 Remote Node: 3 Remote Port: 3 Remote Type: OXC
PortID: 4 PortID: 5 Port Direction: INOUT Connected: 1 Remote Node: 3 Remote Port: 2 Remote Type: OXC
PortID: 5
PortID: 6 Port Direction: INOUT Connected: 1 Remote Node: 4 Remote Port: 7 Remote Type: OXC
PortID: 7 Port Direction: INOUT Connected: 1 Remote Node: 4 Remote Port: 6 Remote Type: OXC
NodeId: 3
PortID: 3 PortID: 2 Device Index: 0 Type: OXC
PortID: 0 Port Direction: INOUT Connected: 1 Remote Node: 17 Remote Port: 8 Remote Type: Dmux
PortID: 1 Port Direction: INOUT Connected: 1 Remote Node: 17 Remote Port: 8 Remote Type: Mux
PortID: 2 Port Direction: INOUT Connected: 1 Remote Node: 2 Remote Port: 5 Remote Type: OXC
OXC-3 PortID: 3 Port Direction: INOUT Connected: 1 Remote Node: 2 Remote Port: 4 Remote Type: OXC
PortID: 4 Port Direction: INOUT Connected: 1 Remote Node: 4 Remote Port: 3 Remote Type: OXC
PortID: 5 Port Direction: INOUT Connected: 1 Remote Node: 4 Remote Port: 2 Remote Type: OXC
PortID: 1 PortID: 0 PortID: 6 Port Direction: INOUT Connected: 0
PortID: 7 Port Direction: INOUT Connected: 0
NodeId: 17
Device Index: 0 Type: Mux
PortID: 0 Port Direction: IN Connected: 1 Remote Node: 9 Remote Port: 1 Remote Type: TxRx
PortID: 1 Port Direction: IN Connected: 0
PortID: 2 Port Direction: IN Connected: 0
PortID: 3 Port Direction: IN Connected: 0
PortID: 4 Port Direction: IN Connected: 0
PortID: 5 Port Direction: IN Connected: 0
PortID: 6 Port Direction: IN Connected: 0
PortID: 8 PortID: 8 PortID: 7 Port Direction: IN Connected: 0
PortID: 8 Port Direction: OUT Connected: 1 Remote Node: 3 Remote Port: 1 Remote Type: OXC
MUX/DEMUX-17 Device Index: 1 Type: Dmux
PortID: 0 Port Direction: OUT Connected: 1 Remote Node: 9 Remote Port: 0 Remote Type: TxRx
PortID: 0 PortID: 0 PortID: 1 Port Direction: OUT Connected: 0
PortID: 2 Port Direction: OUT Connected: 0
PortID: 3 Port Direction: OUT Connected: 0
PortID: 4 Port Direction: OUT Connected: 0
PortID: 5 Port Direction: OUT Connected: 0
PortID: 6 Port Direction: OUT Connected: 0
PortID: 7 Port Direction: OUT Connected: 0
PortID: 1 PortID: 0 PortID: 8 Port Direction: IN Connected: 1 Remote Node: 3 Remote Port: 0 Remote Type: OXC
NodeId: 9
Device Index: 0 Type: TxRx
TxRx-9 PortID: 0 Port Direction: IN Connected: 1 Remote Node: 17 Remote Port: 0 Remote Type: Dmux
Receiver ChannelID: 1
PortID: 1 Port Direction: OUT Connected: 1 Remote Node: 17 Remote Port: 0 Remote Type: Mux
Transmitter ChannelID: 1
Internet UdpEchoServerApplication:HandleRead(): [INFO ] At time 1.0023s server received 1024 bytes from 10.1.1.1 port 49153
Stack IPv4 UdpEchoServerApplication:HandleRead(): [INFO ] At time 1.0023s server sent 1024 bytes to 10.1.1.1 port 49153
Figura 4.11 Continuao do diagrama de fluxo para o canal DWDM com o ID-1.
108
Captulo 4. Simulao de uma rede ptica
Node Configuration:
Node: 6 DevType: TxRx Operation: TX OutPort: 1 OutChannelID: 1
Node: 14 DevType: Mux Operation: U InPort : 0 InChannelID : 1 OutPort: 8 OutChannelID: 1
Node: 0 DevType: OXC Operation: SW InPort : 1 InChannelID : 1 OutPort: 3 OutChannelID: 1
Node: 1 DevType: OXC Operation: SW InPort : 2 InChannelID : 1 OutPort: 5 OutChannelID: 1
Node: 2 DevType: OXC Operation: SW InPort : 2 InChannelID : 1 OutPort: 5 OutChannelID: 1
Node: 3 DevType: OXC Operation: SW InPort : 2 InChannelID : 1 OutPort: 0 OutChannelID: 1
Node: 17 DevType: Mux Operation: U InPort : 8 InChannelID : 1 OutPort: 0 OutChannelID: 1
Node: 9 DevType: TxRx Operation: RX InPort : 0 InChannelID : 1
Tabela 4.1 - Clculo do canal DWDM ID-1 no sentido TxRx-6 >TxRx-9 num ambiente
sem falhas.
Node Configuration:
Node: 9 DevType: TxRx Operation: TX OutPort: 1 OutChannelID: 1
Node: 17 DevType: Mux Operation: U InPort : 0 InChannelID : 1 OutPort: 8 OutChannelID: 1
Node: 3 DevType: OXC Operation: SW InPort : 1 InChannelID : 1 OutPort: 3 OutChannelID: 1
Node: 2 DevType: OXC Operation: SW InPort : 4 InChannelID : 1 OutPort: 3 OutChannelID: 1
Node: 1 DevType: OXC Operation: SW InPort : 4 InChannelID : 1 OutPort: 3 OutChannelID: 1
Node: 0 DevType: OXC Operation: SW InPort : 2 InChannelID : 1 OutPort: 0 OutChannelID: 1
Node: 14 DevType: Mux Operation: U InPort : 8 InChannelID : 1 OutPort: 0 OutChannelID: 1
Node: 6 DevType: TxRx Operation: RX InPort : 0 InChannelID : 1
Tabela 4.2 - Clculo do canal DWDM ID-1 no sentido TxRx-9 >TxRx-6 num
ambiente sem falhas.
109
Captulo 4. Simulao de uma rede ptica
110
Captulo 4. Simulao de uma rede ptica
Para confirmar a presena dos canais DWDM nos links entre os OXCs,
foram feitas duas medidas em dois pontos distintos na rede. A Figura 4.12 repre-
senta a medida feita entre o OXC-1 e OXC-2 com o OSA instalado na transmisso
do primeiro. possvel observar a existncia de trs canais pticos, o canal
DWDM ID-1, ID-2 e ID-3. Com o auxlio da Tabela 4.4, pode-se confirmar que os
trs canais so comuns aos dois OXCs. Para o caso particular do canal ID-1, a
Tabela 4.1 e Tabela 4.2 permitem ter uma percepo mais detalhada do encami-
nhamento do canal. A potncia do canal ID-2 destaca-se da potncia dos outros
dois porque o canal est instalado num transponder pertencente ao OXC-1, e os
canais ID-1 e ID-3 tm a mesma potncia porque ambos sofrem atenuao de ape-
nas um salto at chagar ao OXC-1.
Figura 4.12 - Medida de potncia ptica para o canal DWDM ID-1, ID-2 e ID-
3, entre o OXC-1 e OXC-2.
A Figura 4.13 diz res-
peito medida de potncia ptica do canal DWDM ID-5 entre o OXC-5 e OXC-0.
Da mesma forma, possvel confirmar pela tabela de comutao ptica que o nico
canal em comum entre os dois OXCs o canal ID-5.
111
Captulo 4. Simulao de uma rede ptica
Figura 4.13 - Medida de potncia ptica para o canal DWDM ID-5, entre o
OXC-5 e OXC-0.
112
Captulo 4. Simulao de uma rede ptica
A Tabela 4.5 e Tabela 4.6 sumarizam as ligaes de fibra ptica usadas pelo
canal DWDM ID-1 no sentido TxRx-6 > TxRx-9 e TxRx-9 > TxRx-6, respecti-
vamente. possvel verificar que o encaminhamento do canal sofreu alterao aps
a falha. Uma vez que o simulador no incorpora uma componente de Plano de
Controlo que permita detectar e restaurar um canal em caso de falha, para simular
este cenrio foi removido do script a ligao entre o OXC-1 e OXC-2. Neste senti-
do, como a ligao deixa de fazer parte da topologia fsica, o algoritmo RWA no a
considera para o clculo do caminho, escolhendo assim um caminho alternativo.
Tabela 4.5 - Clculo do canal DWDM ID-1 no sentido TxRx-6 >TxRx-9 com falha no link entre o
OXC-1 e OXC-2.
113
Captulo 4. Simulao de uma rede ptica
Tabela 4.6 - Clculo do canal DWDM ID-1 no sentido TxRx-9 >TxRx-6 com falha no link entre o
OXC-1 e OXC-2.
114
Captulo 4. Simulao de uma rede ptica
Tabela 4.8 - Tabela de comutao de comprimentos de onda de todos os OXCs da rede com falha
no link entre o OXC-1 e OXC-2.
115
Captulo 4. Simulao de uma rede ptica
Figura 4.15 - Medida de potncia ptica para o canal DWDM ID-1 e ID-5, entre o
OXC-5 e OXC-0.
Figura 4.16 - Medida de potncia ptica para o canal DWDM ID-1, ID-2, ID-3 e ID-5,
entre o OXC-5 e OXC-4.
116
Captulo 4. Simulao de uma rede ptica
A Figura 4.17 representa a topologia de rede com falha nos links entre o
OXC-0 e OXC-5, OXC-2 e OXC-3 e OXC-4 e OXC-5. Nas seces que se seguem
sero mostrados em detalhes o conjunto de ligaes de fibra ptica entre os equi-
pamentos WDM por onde encaminhado o canal DWDM ID-1.
So apresentados tambm os resultados do clculo do canal ptico, incluin-
do os pathloss, e tabela de comutao de comprimentos de onda de todos os OXC
da rede.
So mostradas as medidas pticas realizadas nos links entre o OXC-1 e
OXC-2, e OXC-2 e OXC-4, bem como comparar o resultado com a tabela de
comutao de comprimentos de onda dos OXC envolvidos.
Figura 4.17 - Falha nos links, entre o OXC-0 e OXC-5, OXC-2 e OXC-3 e OXC-4 e
OXC-5.
117
Captulo 4. Simulao de uma rede ptica
Tabela 4.9 - Clculo do canal DWDM ID-1 no sentido TxRx-6 >TxRx-9 com falha nos links entre
o OXC-0 e OXC-5, OXC-2 e OXC-3 e OXC-4 e OXC-5.
Tabela 4.10 - Clculo do canal DWDM ID-1 no sentido TxRx-9 >TxRx-6 com falha nos links entre
o OXC-0 e OXC-5, OXC-2 e OXC-3 e OXC-4 e OXC-5.
118
Captulo 4. Simulao de uma rede ptica
Tabela 4.12 - Tabela de comutao de comprimentos de onda de todos os OXCs da rede com
falha nos links entre o OXC-0 e OXC-5, OXC-2 e OXC-3 e OXC-4 e OXC-5.
119
Captulo 4. Simulao de uma rede ptica
Para confirmar a presena dos canais DWDM nos links entre os OXCs,
foram feitas duas medidas em dois pontos distintos na rede. A Figura 4.18 repre-
senta a medida feita entre o OXC-1 e OXC-2. possvel identificar a existncia de
quatro canais pticos, o canal DWDM ID-1, ID-2, ID-3 e ID-5. Com o auxlio da
Tabela 4.12, pode-se confirmar que os quatro canais so comuns aos dois OXCs.
A
Figura 4.18 - Medida de potncia ptica para o canal DWDM ID-1, ID-2, ID-3 e ID-5,
entre o OXC-1 e OXC-2.
120
Captulo 4. Simulao de uma rede ptica
Figura 4.19 - Medida de potncia ptica para o canal DWDM ID-1, ID-2 e ID-5, entre o
OXC-2 e OXC-4.
A Figura 4.20 representa a topologia de rede com falha no OXC-2. Nas sec-
es que se seguem sero mostrados em detalhes o conjunto de ligaes de fibra
ptica entre os equipamentos WDM por onde encaminhado o canal DWDM ID-1.
So apresentados tambm os resultados do clculo do canal ptico, incluin-
do os pathloss, e tabela de comutao de comprimentos de onda de todos os OXC
da rede.
So mostradas tambm as medidas pticas realizadas nos links entre o
OXC-5 e OXC-0, e OXC-4 e OXC-5, bem como comparar o resultado com a tabela
de comutao de comprimentos de onda dos OXC envolvidos.
121
Captulo 4. Simulao de uma rede ptica
Tabela 4.13 - Clculo do canal DWDM ID-1 no sentido TxRx-6 >TxRx-9 com falha no OXC-2.
122
Captulo 4. Simulao de uma rede ptica
Optical Path Src: 9:0--->6:0
Fibers Num: 7 Node Configuration Num: 8
Used Fibers :
NodeID: 9 Type: TxRx DevID: 0 PortID: 1 Dir: OUT --> NodeID: 17 Type: Mux DevID: 0 PortID: 0 Dir: IN Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NodeID: 17 Type: Mux DevID: 0 PortID: 8 Dir: OUT --> NodeID: 3 Type: OXC DevID: 0 PortID: 1 Dir: INOUT Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NodeID: 3 Type: OXC DevID: 0 PortID: 3 Dir: INOUT --> NodeID: 4 Type: OXC DevID: 0 PortID: 2 Dir: INOUT Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NodeID: 4 Type: OXC DevID: 0 PortID: 5 Dir: INOUT --> NodeID: 5 Type: OXC DevID: 0 PortID: 2 Dir: INOUT Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NodeID: 5 Type: OXC DevID: 0 PortID: 5 Dir: INOUT --> NodeID: 0 Type: OXC DevID: 0 PortID: 4 Dir: INOUT Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NodeID: 0 Type: OXC DevID: 0 PortID: 0 Dir: INOUT --> NodeID: 14 Type: Dmux DevID: 1 PortID: 8 Dir: IN Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NodeID: 14 Type: Dmux DevID: 1 PortID: 0 Dir: OUT --> NodeID: 6 Type: TxRx DevID: 0 PortID: 0 Dir: IN Channel usage: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Node Configuration:
Node: 9 DevType: TxRx Operation: TX OutPort: 1 OutChannelID: 1
Node: 17 DevType: Mux Operation: U InPort : 0 InChannelID : 1 OutPort: 8 OutChannelID: 1
Node: 3 DevType: OXC Operation: SW InPort : 1 InChannelID : 1 OutPort: 3 OutChannelID: 1
Node: 4 DevType: OXC Operation: SW InPort : 2 InChannelID : 1 OutPort: 5 OutChannelID: 1
Node: 5 DevType: OXC Operation: SW InPort : 2 InChannelID : 1 OutPort: 5 OutChannelID: 1
Node: 0 DevType: OXC Operation: SW InPort : 4 InChannelID : 1 OutPort: 0 OutChannelID: 1
Node: 14 DevType: Mux Operation: U InPort : 8 InChannelID : 1 OutPort: 0 OutChannelID: 1
Node: 6 DevType: TxRx Operation: RX InPort : 0 InChannelID : 1
Tabela 4.14 - Clculo do canal DWDM ID-1 no sentido TxRx-9 >TxRx-6 com falha no OXC-2.
123
Captulo 4. Simulao de uma rede ptica
RWA do simulador d erro no clculo do canal. O que natural uma vez que no
existe alternativas de ligao entre o OXC-2 e OXC-5 devido falha no OXC-2.
Tabela 4.16 - Tabela de comutao de comprimentos de onda de todos os OXCs da rede com falha
no OXC-2.
Figura 4.21 - Medida de potncia ptica para o canal DWDM ID-1 e ID-5, entre o OXC-5 e
OXC-0.
124
Captulo 4. Simulao de uma rede ptica
Figura 4.22 - Medida de potncia ptica para o canal DWDM ID-1, ID-2 e ID-5, entre o OXC-
4 e OXC-5.
125
5
Concluses e Trabalho Futuro
5.1 Concluses
127
Captulo 5. Concluses e Trabalho Futuro
128
Captulo 5. Concluses e Trabalho Futuro
129
Bibliografia
[3] J. M. Simmons, Optical Network Design and Planning, 2nd ed. New Jersey:
Springer Science & Business Media, 2014.
131
[9] I. Tomkos, B. Mukherjee, S. K. Korotky, R. S. Tucker, and L. Lunardi,
The Evolution of Optical Networking [Scanning the Issue], Proc. IEEE,
vol. 100, no. 5, pp. 10171022, May 2012.
[11] A. Stavdas, Core and Metro Networks. Chichester, UK: John Wiley & Sons,
Ltd, 2010.
132
[19] . Barradas, Quality of Service in Optical Burst Switching Networks,
Universidade do Algarve, 2009.
[20] K. H. Liu, IP over WDM. Chichester, UK: John Wiley & Sons, Ltd, 2002.
[22] G.694.1 : Spectral grids for WDM applications: DWDM frequency grid,
2012. [Online]. Available: https://www.itu.int/rec/T-REC-G.694.1/en.
[Accessed: 05-Sep-2015].
[29] D.-Z. Ruan, Lu; Du, Optical Networks Recent Advances: Recent
Advances. Published by Kluwer Academic Publishers, 2001.
133
Dispersion Constraints, Int. J. Commun. Netw. Syst. Sci., vol. 01, no. 02,
pp. 154167, Jun. 2008.
[31] A. Jajszczyk and P. Rozycki, Recovery of the control plane after failures in
ASON/GMPLS networks, IEEE Netw., vol. 20, no. 1, pp. 410, Jan. 2006.
[34] S.-C. Hwang, I-Shyan; Huang, I-Feng; Yu, Dynamic Fuzzy Controlled
RWA Algorithm for IP/GMPLS over WDM Networks, J. Comput. Sci.
Technol., 2005.
[37] J. Yates and C. Kalmanek, Control plane design for reliable optical
networks, IEEE Commun. Mag., vol. 40, no. 2, pp. 9096, 2002.
[38] J. P. Lang and J. Drake, Mesh network resiliency using GMPLS, Proc.
IEEE, vol. 90, no. 9, pp. 15591564, Sep. 2002.
[39] N. Larkin, ASON and GMPLS - The Battle of the Optical Control Plane,
Data Connect. Ltd., no. August, 2002.
134
[40] W. D. Grover, Mesh-Based Survivable Networks Options and Strategies for
Optical, MPLS, SONET and ATM Networking. New Jersey: Prentice Hall
PTR, 2004.
135
[52] D. Kachan, Integration of NS-3 with MATLAB/Simulink. Lule tekniska
universitet, 26-Oct-2010.
136