UNIVERSIDADE FEDERAL DO PARANÁ
MESTRADO EM TELECOMUNICAÇÕES
Comutação Multi-protocolar de Rótulo Generalizado (GMPLS)
Descrição Funcional de Sinalização
(RFC3471)
Curitiba
2003
Moises Fernandes de Souza
Trabalho da disciplina Comunicação de Dados do Curso de Pós-Graduação em Telecomunicações, Setor de Tecnologia, Universidade Federal do Paraná.
Prof.º Eduardo Parente Ribeiro
CURITIBA
2003
(RFC3471) Comutação Multi-protocolar de Rótulo Generalizado (GMPLS)
Descrição Funcional de sinalização
Resumo
Este documento descreve extensões para a Comutação Multi-protocolar de Rótulo Generalizado (MPLS) sinalizando exigências de suporte ao MPLS Generalizado. O MPLS Generalizado estende o controle MPLS a fim de atender a divisão no tempo (por exemplo, Rede Óptica síncrona e Hierarquia Digital Síncrona, SONET/SDH), comprimento de onda (lambdas óptico) e chaveamento espacial (por exemplo, uma conexão entrante ou fibra para uma conexão de partida ou fibra). Este documento apresenta uma descrição funcional das extensões. Protocolos e formatos específicos, mecanismos, tecnologias de detalhes específicos são especificados em documentos separados.
Índice
1.Introdução............................................... 2
2.Avaliação.................................................. 3
3.Formatos de Rótulo Relacionados..................................... 6
3.1 Pedido de Rótulo generalizado............................... 6
3.2 Rótulo generalizado....................................... 11
3.3 Waveband Switching...................................... 12
3.4 Rótulo sugerido......................................... 13
3.5 Conjunto de Rótulos............................................... 14
4. Bidirectional LSPs......................................... 16
4.1 Informações exigidas.................................... 17
4.2 Resolução de contenção................................... 17
5.Notificação em Erro de Rótulo................................ 20
6.Controle Explícito de Rótulo..................................... 20
6.1 Informações exigidas.................................... 21
7.Informação de proteção..................................... 21
7.1 Informações exigidas.................................... 22
8.Estado de Informação administrativa.......................... 23
8.1 Informações exigidas.................................... 24
9.Controle de Separação de Canal................................. 25
9.1 Identificação de interface................................ 25
9.2 tratamento de falha.......................................... 27
10. Referências............................................ 27
11. Considerações de segurança.................................... 28
12. Considerações de IANA........................................ 28
13. Considerações de Propriedade intelectuais....................... 29
14. Referências................................................. 29
14.1 Referências normativas................................... 29
14.2 Referências informativas................................. 30
15. Contribuintes............................................... 31
16. O Endereço de editor........................................... 33
17. Completa Declaração de Proteção dos direitos autorais ............. 34
1. Introdução
A Arquitetura da Comutação Multi-protocolar de Rótulo Generalizado (MPLS) [RFC3031] foi definida para suportar o encaminhamento de dados baseados em rótulos. Nesta arquitetura, os Roteadores de Chaveamento de Rótulo (LSRs) foram definidos como tendo um plano de remetendo que é capaz de: (a) reconhecer qualquer pacote ou limites de célula, (b) processar qualquer um dos cabeçalhos de pacote (para LSRs capazes de reconhecer limites de pacote) ou cabeçalhos de célula (para LSRs capazes de reconhecer limites de célula).
A arquitetura original foi recentemente estendida para incluir LSRs que não reconhecem nenhum pacote de planos de remetendos, nem células limites, e então, não podem remeter informação baseado nos dados levados nos pacotes ou cabeçalhos da célula. Especificamente, tais LSRs incluem dispositivos onde a decisão de remeter é baseada em um tempo de abertura definido “time-slot”, comprimentos de onda, ou conexões físicas.
Visto isto, LSRs, ou mais precisamente interfaces em LSRs, pode ser subdividida nas seguintes classes:
1. Interfaces que reconhecem limites de pacotes/células e podem remeter dados baseados no conteúdo do cabeçalho. Exemplos interfaces dentro de roteadores que passam adiante dados baseados no conteúdo do cabeçalho de “shim” calço, interfaces em (Modo de Transferência Assíncrona) ATM-LSRs que remetem dados baseados em ATM VPI/VCI. Tais interfaces são chamadas de chaveador de Pacote Capaz (PSC) “Packet-Switch Capable”.
2. Interfaces que remetem dados baseados na abertura de tempo dos dados em um ciclo repetido. Um exemplo de tal uma interface é uma interface em uma SONET/SDH Cross-Connect. Tais interfaces são chamadas de Divisão no Tempo Multiplexada (TDM).
3. Interfaces que remetem dados baseados no comprimento de onda em que os dados são recebidos. Um exemplo de tal uma interface é uma interface em uma conexão Óptica Cross que pode operar ao nível de comprimento de onda individual. Tais interfaces estão chamadas de Chasveador Lambda Capaz (LSC).
4. Interfaces que remetem dados baseados na posição dos dados nos espaços físicos no mundo real. Um exemplo de tal interface é uma interface Óptica Cross-connect que pode operar ao nível de uma única (ou múltipla) fibra. Tais interfaces são chamadas Chaveador Fibra Capaz (FSC).
Usando o conceito alojado no Rótulo de Caminhos Chaveados (LSPs) que permitem a um sistema a construção de uma hierarquia de escala do remetendo. O topo desta hierarquia são interfaces FSC, seguidas de interfaces de LSC, seguidas por interfaces de TDM, seguidas por interfaces de PSC. Deste modo, um LSP que começa e termina em uma interface de PSC pode ser alojado (junto com outro LSPs) em um LSP que começa e termina em uma interface de TDM. Este LSP, em troca, pode ser alojado (junto com outro LSPs) em um LSP que começa e termina em uma interface de LSC que em troca pode ser alojada (junto com outro LSPs) em um LSP que começa e termina em uma interface de FSC. Veja [HIERARQUIA-MPLS] para mais informação sobre hierarquias LSP.
O estabelecimento de LSPs do que cobrem só a primeira classe de interfaces estão definidas dentro [RFC3036, RFC3212, RFC3209]. Este documento apresenta uma descrição funcional das extensões necessárias ao plano de controle do MPLS generalizado para suportar cada uma das quatro classes de interfaces. Somente o formato do protocolo de sinalização independente é definido neste documento.
Formatos de protocolos específicos estão definidos dentro [RFC3473] e [RFC3472]. Detalhes específicos de tecnologia estão fora da extensão deste documento e serão especificadas dentro de documentos específicos, como [GMPLS-SONET].
2. Visão Geral
O MPLS generalizado difere do MPLS tradicional no suporte à múltiplos tipos de chaveamento ,ex, a adição de apoio para TDM, lambda, e chaveamento de fibra (conexão). O suporte para tipos adicionais de chaveamento é conduzido pelo MPLS generalizado para estender certas funções base do MPLS tradicional e, em alguns casos, somar funcionalidade. Estas mudanças e adições impactam nas propriedades do básicas do LSP, como rótulos são pedidos e comunicados, a natureza de unidirecional dos LSPs, como são propagados erros, e informações necessárias para sincronizar o ingresso e egresso.
Na engenharia de Tráfico MPLS tradicional, ligações atravessadas por um LSP podem incluir uma mescla de ligações com codificações de rótulo heterogêneas. Por exemplo, um LSP pode transpassar ligações entre roteadores, ligações entre rotedores e ATM-LSRs, e ligações entre ATM-LSRs. O MPLS generalizado estende estas ligações incluindo onde o rótulo é codificado um tempo abertura, ou um comprimento de onda, ou uma posição no espaço físico do mundo real. Como MPLS TE tradicional onde nem todos o LSRs são capazes de reconhecimento dos limites dos pacotes (IP) (por exemplo, ATM-LSR) em planos de remessa, MPLS generalizados incluem suporte para LSRs que não podem reconhecer limites de pacotes de (IP) nos planos do remetendo. Em MPLS TE tradicionais um LSP que leva IP tem que começar e terminar em um roteador. MPLS generalizados estendem isto requerendo um LSP para começar e terminar em tipo semelhante de LSRs. Também, em MPLS generalizados o tipo de uma carga útil que pode ser levada por um LSP está estendido para permitir cargas úteis como SONET/SDH, ou 1 ou 10Gb Ethernet. Estas mudanças do MPLS tradicional são refletidas em como rótulos são pedidos e comunicados em MPLS generalizados, veja Seções 3.1 e 3.2. Um caso especial de chaveamento Lambda , chamado de chaveamento Waveband, também é descrito na Seção 3.3.
Outra diferença básica entre tipos tradicionais e não-PSC de LSPs MPLS generalizados, é que a distribuição de bandwidth para um LSP pode ser só executada em unidades discretas, veja Seção 3.1.3. Também é provável ter (muito) menos rótulos em ligações não-PSC que em ligações de PSC.
Note que o uso de Remeter Adjacências (FA), veja [HIERARQUIA-MPLS], provê um mecanismo que pode melhorar a utilização da bandwidth, quando a distribuição de bandwidth só pode ser executada dentro unidades discretas, como também um mecanismo para se agregar o estado do remetendo, permitindo reduzir assim o número de rótulos exigidos.
MPLS generalizado permite um rótulo a ser sugerido por nó de “upstream” fluxo contrário, veja Seção 3.4. Esta sugestão pode ser anulada por um nó de “downstream” mesmo fluxo, em alguns casos, às custas de um maior tempo de configuração do LSP. O rótulo sugerido é valioso ao estabelecer LSPs por certos tipos de equipamento óptico onde pode haver uma prolongada (em condições elétricas) demora na configuração de fabrica do chaveamento. Por exemplo micro espelhos podem ter que ser elevados ou podem mover, e seu tempo para movimento físico e subsequente esvaziamento. Se os rótulos e por conseguinte os chaveamentos fabricados estão configurados na direção inversa (a norma) a mensagem de MAPEAMENTO/Resv pode precisar ser atrasada por 10’s até milissegundos por pulo para estabelecer um caminho remetendo utilizável. O rótulo sugerido também é valioso ao recuperar de falhas nodais.
MPLS generalizados estendem na noção de restringir a gama de rótulos que podem ser selecionados a um nó de “downstream” mesmo fluxo, veja Seção 3.5. Em MPLS generalizados, um ingresso ou outro nó de “upstream” fluxo contrário pode restringir os rótulos que podem ser usados por um LSP ao longo de um único pulo ou ao longo do caminho de LSP inteiro. Esta característica é dirigida do domínio óptico onde há casos onde comprimentos de onda usados pelo caminho tiveram que ser restringidos a um subconjunto pequeno de possíveis comprimentos de onda, para um comprimento de onda específico. Esta exigência acontece porque alguns equipamentos só pode poder gerar um conjunto pequeno de comprimentos de onda que equipamentos intermediários podem poder trocar, ou porque equipamentos intermediários podem não poder trocar um comprimento de onda, só podendo redirecionar a uma fibra diferente.
Enquanto o tráfico tradicional criou MPLS (e pares de LDP ) unidirecionais, o MPLS generalizado suporta o estabelecimento de LSPs bidirecionais, veja Seção 4. A necessidade de LSPs bidirecionais vem de aplicações non-PSC. Há múltiplas razões para a necessidade de LSPs, particularmente a possível contenção de recursos quando na alocação de LSPs recíprocos por sessões sinalizadas separadas, e procedimentos de restauração de falhas simplificando no caso de non-PSC.
LSPs bidirecionais também têm o benefício de mais baixo latência de configuração e mais baixo número de mensagens necessárias durante a configuração.
MPLS generalizado suporta a comunicação de um rótulo específico para uso em uma interface específica, veja Seção 6. [RFC3473] também suporta um mecanismo RSVP específico para notificação de falha rápida.
MPLS generalizado formaliza a possível separação de controle e canais de dados, veja Seção 9. Tal suporte é particularmente importante para suportar tecnologias onde controle de tráfico não pode ser enviado in-band com o tráfico de dados.
MPLS generalizado também permite a inclusão de tecnologia específica e parâmetros sinalização. A intenção é para todos os parâmetros de uma tecnologia específica ser levada, ao usar RSVP, no SENDER_TSPEC e outros objetos relacionados, e ao usar CR-LDP, no Tráfico, Parâmetros TLV. Formatos específicos de Tecnologia serão definidos com base na necessidade. Para uma definição de exemplo, veja [GMPLS-SONET].
3. Formatos de Rótulo Relacionados
Lidar com a extensão alargada de MPLS no domínio óptico e tempo, são necessárias várias formas novas de " rótulo". Estas formas novas de rótulo estão coletivamente chamado um "rótulo" generalizado. Um rótulo generalizado contém bastante informação para permitir a recepção em um nó para programar sua cross-connect, embora o tipo da conexão cross, tal que o ingresso segmentado do caminho é corretamente unido. Esta seção define um pedido de rótulo generalizado, um rótulo generalizado, suporte a “waveband switching”, rótulo sugerido e conjuntos de rótulo.
Note que desde que os nós enviam e recebem a novas formas de rótulo saiba que tipos de ligação eles estão usando, o rótulo generalizado faz com que não contenha um campo de tipo, ao invés é esperada que os nós saibam o contexto do tipo de rótulo a esperar.
3.1. Pedido de Rótulo generalizado
O Pedido de Rótulo generalizado suporta comunicação de características necessárias ao suporte ao LSP que é pedido. Estas características incluem codificação do LSP a e carga útil do LSP. Note que estas características podem ser usadas através de nós em trânsito, por exemplo, suportar o penúltimo pulo estourado.
O Pedido de Rótulo Generalizado leva um parâmetro que codifica o LSP, chamado LSP Encoding Type. Este parâmetro indica o tipo de codificação, por exemplo, SONET/SDH/GigE etc., isso será usada com os dados associados com o LSP. O LSP Encoding Type representa a natureza do LSP, e não a natureza das ligações atravessam os LSPs. Uma ligação pode suportar um conjunto de formatos codificados onde suportam meios que uma ligação pode levar e chavear um sinal de um ou mais formatos codificados dependendo da disponibilidade de recurso e capacidade da ligação. Por exemplo, considere um LSP que sinalizou com a codificação lambda. Espera-se que um LSP fosse suportado sem conversão elétrica e nenhum conhecimento da modulação e rapidez de ajuste dos nós de trânsito. Outros formatos normalmente necessitam de conhecimento e ajuste, e parâmetros de campo estão quebrados no tipo de ajuste e rapidez como mostrada abaixo.
O Pedido de Rótulo Generalizado também indica o tipo de chaveamento que está sendo pedido em uma ligação. Este campo regularmente é consistente por todas as ligações de um LSP.
3.1.1. Informação exigida
A informação levada em um Pedido de Rótulo Generalizado é:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ENC. type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type: 8 bits
Indica a codificação do LSP que é pedido. Os seguintes valores permitem mostrar o seu significado:
Tipo de valor
---------
1 pacote
2 Ethernet
3 ANSI/ETSI PDH
4 reservado
5 SDH ITU-T G.707 / SONET ANSI T1.105
6 reservado
7 Envoltura digital
8 Lambda (photonic)
9 fibra
10 reservado
11 FiberChannel
Os tipos ANSI PDH e ETSI PDH designam estas respectivas
tecnologias transmitindo em rede. DS1 e DS3 são exemplos de ANSI PDH
LSPs. Um E1 LSP seria ETSI PDH. O Lambda que codifica tipo
recorre a um LSP que cerca alguns comprimentos de onda inteiros. O
tipo de codificação Fibra recorre a um LSP que cerca completamente a
interface de fibra.
Switching Type: 8 bits
Indica o tipo de chaveamento que deveria ser executado em um
ligação particular. Este campo é necessário para ligações que anunciam
mais de um tipo de capacidade de chaveamento. Este campo deve
mapear a um dos valores anunciados para a ligação correspondente
a ligação no routing switching Capability Descriptor, veja [GMPLS -
RTG].
A seguir valores definidos correntemente:
Tipo de valor
---------
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 camada-2 Interruptor Capaz (L2SC)
100 tempo-divisão-Multiplex Capaz (TDM)
150 Lambda-interruptor Capaz (LSC)
200 fibra-interruptor Capaz (FSC)
PID generalizado (G-PID): 16 bits
Um identificador da carga útil levado por um LSP, ex., um
identificador da camada de cliente daquele LSP. Isto é usado pelos
nós aos endpoints do LSP, e em alguns casos pelo
penúltimo salto. Valores padrão Ethertype são usados para pacote
e Ethernet LSPs; outros valores são:
Tecnologia de Tipo de valor
-------------------
0 desconhecido Tudo
1 reservado
2 reservado
3 reservado
4 reservado
5 mapeamento assíncrona de E4 SDH
6 mapeamento assíncrona de DS3/T3 SDH
7 mapeamento assíncrona de E3 SDH
8 bit mapeamento síncrona de E3 SDH
9 byte mapeamento síncrona de E3 SDH
10 mapeamento assíncrona de DS2/T2 SDH
11 bit mapeamento síncrona de DS2/T2 SDH
12 reservado
13 mapeamento assíncrona de E1 SDH
14 byte mapeamento síncrona de E1 SDH
15 byte mapeamento síncrona de 31 * DS0 SDH
16 mapeamento assíncrona de DS1/T1 SDH
17 bit mapeamento síncrona de DS1/T1 SDH
18 byte mapeamento síncrona de DS1/T1 SDH
19 VC-11 em VC-12 SDH
20 reservado
21 reservado
22 DS1 SF SONET Assíncrono
23 DS1 ESF SONET Assíncrono
24 DS3 M23 SONET Assíncrono
25 DS3 C-Bit Paridade SONET Assíncrono
26 VT/LOVC SDH
27 STS SPE/HOVC SDH
28 POS - Nenhum Subindo, 16 bit CRC SDH,
29 POS - Nenhum Subindo, 32 bit CRC SDH,
30 POS - Subindo, 16 bit CRC SDH,
31 POS - Subindo, 32 bit CRC SDH,
32 ATM que traça SDH
33 Ethernet SDH, Lambda, Fibra,
34 SONET/SDH Lambda, Fibra,
35 reservado (SONET implorou) Lambda, Fibra,
36 Envoltura digital Lambda, Fibra,
37 Fibra de Lambda
38 ANSI/ETSI PDH SDH
39 SDH reservado
40 Protocolo de Acesso de ligação SDH SDH
(COLOS - X.85 e X.86)
41 FDDI SDH, Lambda, Fibra,
42 DQDB (ETSI ETS 300 216) SDH
43 FiberChannel-3 (Serviços) FiberChannel
44 HDLC SDH
45 Ethernet V2/DIX (só) SDH, Lambda, Fibra,
46 Ethernet 802.3 (só) SDH, Lambda, Fibra,
3.1.2. Codificação de Bandwidth
São levadas codificações de Bandwidth em 32 bit no formato de ponto flutuante IEEE (a unidade é bytes por segundo). Para non-pacote de LSPs,isto é útil para definir valores discretos para identificar o bandwidth do LSP. Alguns valores típicos pedidos para o bandwidth são enumerados abaixo. (Estes valores são diretrizes.) Valores adicionais serão definida se necessário. Valores de codificação de Bandwidth são levados por um protocolo maneira específica, veja [RFC3473] e [RFC3472].
Signal Type (bit-rate) Valor (Bytes/Sec)
(IEEE ponto Flutuante)
-------------------------------- -----------------------
DS0 (0.064 MBPS) 0X45FA0000
DS1 (1.544 MBPS) 0X483C7A00
E1 (2.048 MBPS) 0X487A0000
DS2 (6.312 MBPS) 0X4940A080
E2 (8.448 MBPS) 0X4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 MBPS) 0X4A831A80
DS3 (44.736 MBPS) 0X4AAAA780
STS-1 (51.84 MBPS) 0X4AC5C100
Ethernet rápido (100.00 Mbps) 0x4B3EBC20
E4 (139.264 MBPS) 0X4B84D000
FC-0 133M 0X4B7DAD68
OC-3/STM-1 (155.52 MBPS) 0X4B9450C0
FC-0 266M 0X4BFDAD68
FC-0 531M 0X4C7D3356
OC-12/STM-4 (622.08 MBPS) 0X4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
FC-0 1062M 0X4CFD3356
OC-48/STM-16 (2488.32 MBPS) 0X4D9450C0
OC-192/STM-64 (9953.28 MBPS) 0X4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
OC-768/STM-256 (39813.12 MBPS) 0X4F9450C0
3.2. Rótulo generalizado
O Rótulo Generalizado estende o rótulo tradicional permitindo a representação de não só rótulos com os quais viajam in-band associados a pacotes , mas também rótulos que identificam o “time-slots” tempo-aberturas, comprimentos de onda, ou posições espaciais de divisão multiplexada. Por exemplo, o Rótulo Generalizado pode levar um rótulo que representa (a) um único pacote em fibra, (b) um único waveband dentro de fibra, (c) um único comprimento de onda dentro de um waveband (ou fibra), ou (d) um conjunto de aberturas no tempo “time-slot” dentro de um comprimento de onda (ou fibra). Também pode levar um rótulo que representa uma etiqueta MPLS genérica, um rótulo de Revezamento de Armação,ou um rótulo de ATM (VCI/VPI).
Um Rótulo Generalizado não identifica a "classe" para qual o rótulo pertence. Isto está implícito nas capacidades de multiplexação do link em que o rótulo é usado.
Um Rótulo Generalizado só leva um único nível de rótulo, ex., é não-hierárquico. Quando níveis múltiplos de rótulo (LSPs dentro de LSPs)são requeridos, cada LSP deve ser estabelecido separadamente, veja [MPLS - HIERARQUIA].
Cada Rótulo Generalizado object/TLV leva um rótulo de comprimento de parâmetro variável.
3.2.1. Informação exigida
A informação levada em um Rótulo Generalizado é:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rótulo |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rótulo: Comprimento variável
Leva informação de rótulo. A interpretação deste campo
depende do tipo da ligação em cima da qual o rótulo é usado.
3.2.1.1. Interface e Rótulos de Comprimento de onda
Algumas configurações de chaveamento de fibra (FSC) e chaveamento lambda (LSC) usam dados múltiplos de channels/links controlados por um único canal de controle. Em tais casos o rótulo indica o channel/link de dados para seja usada para o LSP. Note que neste caso não é o mesmo quando [MPLS-BUNDLE] está sendo usado.
As informações levaram em uma Interface e rótulo de Comprimento de onda é:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rótulo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rótulo: 32 bits
Indica interface/fibra ou lambda a ser usada, da perspectiva do remetente de um object/TLV. Valores só usados neste campo têm significado entre dois vizinhos, e o receptor pode precisar converter o valor recebido em um valor que tenha significado local. Podem ser configurados valores ou determinados dinamicamente usando um protocolo como [LMP].
3.2.1.2. Outros Rótulos
Etiquetas “Labels” MPLS genéricos e rótulos de “Frames Relays” são corretamente codificados e alinhados em 32 bits (4 octetos). Rótulos de ATM são correamente codificados com VPI justificado em bits 0-15 e o VCI corretamente justificado dentro bits 16-31.
3.3. chaveamento de Waveband
Um caso especial de chaveamento lambda é o chaveamento waveband. Um waveband representa um conjunto de comprimentos de onda contíguos que podem ser trocados para um novo conjunto de waveband. Por razões de otimização pode ser desejável para uma conexão cross óptica que conecta-se opticamente com uma unidade de chaveamento múltiplo de comprimentos de onda. Isto pode reduzir a distorção nos comprimentos de onda individuais e pode permitir separação mais apertada dos comprimentos de onda individuais. O Rótulo de Waveband é definido para suportar este caso especial.
O Chaveamento de Waveband naturalmente introduz outro nivel de hierarquia de rótulo e como tal o waveband é tratado do mesmo modo que todos os outros rótulos de camadas superiores.
Até onde os protocolos de MPLS estão relacionados há pequena diferença entre um rótulo de waveband e um rótulo de comprimento de onda a não ser semanticamente o waveband pode ser subdividido em comprimentos de onda considerando que o comprimento de onda só pode ser subdividido em tempo ou estatisticamente multiplexado e rotulado.
3.3.1. Informação exigida
O Chaveamento de Waveband usa o mesmo formato do rótulo generalizado, veja
seção 3.2.1.
No contexto do chaveamento de waveband, o rótulo generalizado tem o
formato seguinte:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id de Waveband |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rótulo de começo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rótulo de fim |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Id de Waveband: 32 bits
Um identificador de waveband. O valor é selecionado pelo remetente e
usado de novo em todas mensagens relacionadas subseqüentes.
Rótulo de começo: 32 bits
Indica o identificador de canal de valor do mais baixo comprimento de onda compondo o waveband, da perspecitiva do remetente de object/TLV.
Rótulo de fim: 32 bits
Indica o identificador de canal do valor mais alto de comprimento de onda que compõe o waveband, da pespectiva do remetente de object/TLV.
Identificadores de canal ou são estabelecidos através de configuração ou por
meios de um protocolo como LMP [LMP]. Eles normalmente são usados dentro da
etiqueta de parâmetro do Rótulo Generalizado em um PSC e LSC.
3.4. Rótulo sugerido
O Rótulo Sugerido é usado para prover a um nó “downstream” o qual o “upstream” é a preferência de rótulo de nó. Isto permite o nó de “upstream”
começar a configurar seu hardware com o rótulo proposto antes do rótulo comunicado pelo nó de “downstream”. A configuração é valiosa a sistemas que levam um tempo não trivial para estabelecer um rótulo em hardware. Tal configuração pode reduzir a latência de configuração, e pode ser importante para propósitos de restauração onde LSPs alternados podem precisar estabelecer rapidamente a transmissão de falhas na network.
O uso de Rótulo Sugerido é só uma otimização. Se um nó “downstream” passa um rótulo diferente “upstream”, um “upstream” reconfigura um LSR de forma a usar o rótulo especificado pelo nó de “downstream”, mantendo assim o “upstream” no controle de um rótulo. Note, que a transmissão de um rótulo sugerido não insinua que os rótulos estão disponíveis para uso. Em particular, um nó de ingresso deve não transmitir dados de trafico em um rótulo sugerido até o nó de “downstream” passar um rótulo de “upstream”.
A informação levada em um rótulo sugerido é idêntica para um rótulo generalizado. Note, valores usados no campo de um rótulo sugeridos são da perspectiva do remetente de object/TLV.
3.5. Conjunto de rótulos
O Conjunto de Rótulos é usado para limitar as escolhas de rótulo de um nó de “downstream” para um conjunto de rótulos aceitáveis. Esta limitação base se aplica em um por pulo.
Nós descrevemos quatro casos em onde um Conjunto de Rótulo é útil no domínio óptico. O primeiro caso é onde o equipamento de fim só é capaz de transmitir em um conjunto específico pequeno de wavelengths/bands. O segundo caso é onde há uma sucessão de interfaces que não podem suportar a conversão de comprimento de onda (CI-incapaz) e requer o mesmo comprimento de onda seja usado fim-para-fim em cima de uma sucessão de pulos, ou até mesmo um caminho inteiro. O terceiro caso é onde é desejável limitar o a quantia de conversão de comprimento de onda que é executada para reduzir a distorção nos sinais ópticos. O último caso é onde dois fins de um conjunto diferente de comprimentos de onda suporte.
Conjunto de rótulo é usado para restringir gamas de rótulo para as que podem ser usadas em um LSP particular e entre dois semelhantes. O receptor de um Conjunto de Rótulo deve restringir sua escolha de rótulos a um que está no Conjunto de Rótulo. Muito como um rótulo, um Conjunto de Rótulo pode estar presente do outro lado de pulos de múltiplos. Neste caso cada nó gera seu próprio Rótulo de partida Fixado, possivelmente, baseado no Rótulo entrante Fixado e nas capacidades de hardware do nó. É esperada que este caso seja a norma para nós com conversão incapaz (CI-incapaz) interfaces.
O uso de Conjunto de Rótulo é opcional, se não estiver presente, todos os rótulos da gama de rótulos válida pode ser usada. Conceitualmente a ausência de um conjunto de Rótulos insinua um Conjunto de Rótulos cujo valor é {U}, o conjunto de todos rótulos válidos.
3.5.1. Informação exigida
Um conjunto de rótulos está composto de um ou mais objects/TLVs de um conjunto de rótulos. Cada object/TLV contém um ou mais elementos do Conjunto de Rótulos. Cada elemento está relacionado a um identificador de subcanal e tem o mesmo formato de um rótulo generalizado.
A informação levada em um Label_Set é:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ação | Reservado | Tipo de Rótulo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBCHANNEL N |
|... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ação: 8 bits
0 - Lista inclusiva
Indica que o object/TLV contém um ou mais elementos subcanais
que são incluídos no Conjunto de Rótulo.
1 - Lista exclusiva
Indica que o object/TLV contém um ou mais elementos subcanais
que são excluídos do Conjunto de Rótulo.
2 - Gama inclusiva
Indica que o object/TLV contém uma gama de rótulos. O object/TLV contém dois elementos de subcanal. O primeiro elemento indica o começo da gama. O segundo elemento indica o fim da gama. Um valor de zero indica que não há nenhuma amarra na porção correspondente da gama.
3 - Gama exclusiva
Indica que o object/TLV contém uma gama de rótulos que é excluída do Conjunto de Rótulo. O object/TLV contém dois elementos de subcanal. O primeiro elemento indica o começo da gama. O segundo elemento indica o fim da gama. Um valor de zero indica que não há nenhuma amarra na porção correspondente da gama.
Reservada: 10 bits
Este campo está reservado. Deve ser fixado para zerar em transmissão e deve ser ignorada na recepção.
Tipo de rótulo: 14 bits
Indica o tipo e formato dos rótulos levados dentro do object/TLV. Valores estão sinalizando protocolo específico.
Subcanal:
O subcanal representa o rótulo (comprimento de onda, fibra... ) o qual
é elegível para distribuição. Este campo tem o mesmo formato descrita para rótulos debaixo da seção 3.2.
Note que o subcanal para identificadores de canal locais (por exemplo, comprimento de onda) mapeamentos são uma questão local.
4. LSPs Bidirectionais
Esta seção define suporte direto bidirectional a LSPs. O suporte está definido para LSPs que tem a mesma exigência de engenharia de tráfico inclusive destino compartilhado, proteção e restauração, LSRs, e exigências de recurso (por exemplo, latência e se agita) em cada direção. No resto desta seção, está o termo " iniciador " recorra a um nó que começa no estabelecimento de um LSP e o termo " terminator " é usado para recorrer ao nó que é o objetivo do LSP. Note que para o LSPs bidirectional, há um único iniciador " e um " terminator ".
Normalmente para estabelecer um LSP bidirectional ao usar [RFC3209] ou [RFC3212] devem ser estabelecidos dois caminhos unidirectionais independentemente.
Esta aproximação tem as seguintes desvantagens:
* A latência para estabelecer o LSP bidirectional é igual a uma viagem de ida-e-volta que sinaliza tempo mais iniciador-terminator sinalizando demora de trânsito. Isto não só estende a latência de configuração para estabelecimento de LSP próspero, mas estende o pior caso de latência por descobrir um LSP malsucedido a até dois tempos o iniciador-terminator demora de trânsito. Estas demoras são particularmente significantes para LSPs para os propósitos estabelecidos de restauração.
* O controle é em cima duas vezes as de um LSP unidirectional. Isto é porque mensagens de controle separadas (por exemplo, Caminho e Resv) deve ser geradas para ambos os segmentos do LSP bidirectional.
* Porque os recursos são estabelecidos em segmentos separados, rota, seleção são complicados. Também há uma potencial corrida adicional para condições em tarefa de recursos e diminuições da probabilidade global de estabelecer a conexão bidirectional prosperamente.
* É mais difícil de prover uma interface limpa para equipamentos SONET/SDH que pode se confiar em caminhos de pulo-por-pulo de chaveamento protegido bidirecional.
* LSPs óptico bidirecionais (ou lightpaths) são vistos como uma exigência para muitos provedores de serviço de gestão de redes ópticas.
Com LSPs bidirecionais ambos os cominhos de dados “downstream” e ”upstream”, ex., do iniciador para terminator e terminator para iniciador, eles são usados para estabelecer um único conjunto de sinalização de mensagens. Isto reduz a latência de configuração essencialmente um iniciador-terminator tem um tempo de viagem de ida-e-volta mais tempo de processo, e limites o controle em cima para o mesmo número de mensagens como um unidirectional LSP.
4.1. Informação exigida
Para LSPs bidireconais, devem ser alocados dois rótulos. A configuração bidirecional de LSP é indicada pela presença de um Rótulo de “upstream” object/TLV sinalizando na mensagem apropriada. Um rótulo “upstream” tem o mesmo formato do rótulo generalizado, veja Seção 3.2.
4.2. Resolução de contenção
A Contenção para rótulos pode acontecer entre dois pedidos de configurações bidirecionais de LSP que viajam em direções opostas. Esta contenção acontece quando ambos os lados alocam os mesmos recursos (rótulos) a efetivamente o mesmo tempo. Se não há nenhuma restrição nos rótulos que podem ser usados para LSPs bidirecionais e se há recursos alternados, então ambos os nós passarão rótulos diferentes “upstream” e nenhuma contenção. Porém, se há uma restrição nos rótulos que pode ser usada para o LSPs bidirecional (por exemplo, se eles devem ser fisicamente juntados em um único cartão de I/O), ou se não há mais nenhum recursos disponível, então a contenção deve ser solucionada por outros meios. Para solucionar a contenção, o nó com ID mais alto vai ganhar a contenção e emitirá uma mensagem de PathErr/NOTIFICATION com uma " Falha de Roteamento de Rótulos" indicação de falha. No recebimento de tal erro, o nó deveria tentar alocar um diferente rótulo “upstream”(e um Rótulo Sugerido diferente do usado) para o caminho bidirecional. Porém, se nenhum outro recurso está disponível,o nó tem que proceder com manipulação de erro padrão.
Para reduzir a probabilidade de contenção, a imposição de uma política que o nó com o mais baixo ID nunca sugestione um rótulo na direção “downstream” e sempre aceita um Rótulo Sugerido de um nó de “upstream” com um ID mais alto. Além disso, desde que os rótulos podem ser trocados usando LMP, uma política local alternativa poderia ser imposta mais adiante que (com respeito ao rótulo do nó numerado mais alto fixado) o nó numerado mais alto poderia alocar rótulos do fim alto da gama de rótulo enquanto o mais baixo nó numerado aloca rótulos de baixo do fim da gama de rótulo. Este mecanismo aumentaria qualquer fim de algoritmos empacotando os que podem ser usados para otimização do bandwidth (ou comprimento de onda). Um caso especial que deveria ser notado ao usar RSVP e apoiando esta aproximação é que o nó do vizinho que o ID não pode seja conhecido ao enviar uma mensagem de Caminho inicial. Quando este caso acontece, um nó deveria sugestionar um rótulo escolhido ao acaso do espaço de rótulo disponível.
Um exemplo de contenção entre dois nodos (PXC 1 e PXC 2) é mostrado na Figura 1. Neste exemplo PXC 1 nomeia um Rótulo “upstream” para o canal que corresponde a BCId=2 local (BCId=7 local em PXC 2) e envia um Rótulo Sugerido para o canal que corresponde a BCId=1 local (BCId=6 local em PXC 2). Simultaneamente, PXC 2 nomeia um rótulo “upstream” para o canal que corresponde a seu BCId=6 local (BCId=1 local em PXC 1) e envia um Rótulo Sugerido pelo canal correspondido para seu BCId=7 local (BCId=2 local em PXC 1). Se não há nenhuma restrição nos rótulos que podem ser usados para LSPs bidirecionais e se há recursos alternados disponíveis, então PXC 1 e PXC 2, passam rótulos diferentes “upstream” e a contenção está resolvida naturalmente (veja Figo. 2). Porém, se há uma restrição nos rótulos que pode ser usado para LSPs bidirecinais (por exemplo, se eles deve ser juntados fisicamente em um único cartão de I/O), então a contenção deve ser solucionada usando o nodo ID (veja Figo. 3).
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + SL1,UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1, SL2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + + +
+ 3 +------------------------>+ 8 +
+ + + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figura 1. Rótulo de Contenção
Neste exemplo, PXC 1 nomeia um Rótulo “upstream” que usa BCId=2 (BCId=7
em PXC 2) e um Rótulo Sugerido que usa BCId=1 (BCId=6 em PXC 2).
Simultaneamente, PXC 2 nomeia um Rótulo “upstream” que usa BCId=6 (BCId=1
em PXC 1) e um Rótulo Sugerido que usa BCId=7 (BCId=2 em PXC 1).
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + L2 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figura 2. Rótulo de Resolução de Contenção sem restrições de recurso
Neste exemplo, não há nenhuma restrição nos rótulos que podem ser
usada pela conexão de bidirecional e não há nenhuma contenção.
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + L2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + UL1 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 3. Rótulo de Resolução de Contenção com restrições de recurso
Neste exemplo, etiquetas 1,2 e 3,4 em PXC 1 (etiquetas 6,7 e 8,9 em PXC 2, respectivamente) devem ser usadas pela mesma conexão bidirecional. Considerando que PXC 2 tem um nó de ID mais alto, ganha a contenção e PXC 1 tem que usar um conjunto diferente de rótulos.
5. Notificação em Erro de Rótulo
Há casos em MPLS tradicionais e em GMPLS no que resulta uma mensagem de erro que contém uma " indicação de valor de rótulo Inaceitável”, veja [RFC3209], [RFC3472] e [RFC3473]. Quando estes casos acontecem, isto pode ser útil para o nó que gera a mensagem de erro para indicar quais rótulos seriam aceitáveis. Cobrir este caso, GMPLS, introduz a habilidade para carregar tal informação pelo " Conjunto Aceitável" de rótulo. Um Conjunto de Rótulo Aceitável é levado dentro do apropriado protocolo de mensagens de erro específicas, veja [RFC3472] e RFC3473].
O formato de um Conjunto de Rótulo Aceitável é idêntico a um Conjunto de Rótulo, veja seção 3.5.1.
6. Controle de Rótulo explícito
Em MPLS tradicionais, podem ser controladas as interfaces usadas por um LSP
por uma rota explícita, ex., ERO ou ER-Hop. Isto habilita a inclusão de um node/interface particular, e a terminação de um LSP em uma interface de partida particular do egresso LSR. Onde a interface pode ser numerada ou desnumerada, veja [MPLS-UNNUM].
Há casos onde a semântica de rota explícita existente não provém bastante informação para controlar o LSP ao grau desejado.
Isto acontece no caso quando o iniciador de LSP desejar selecionar um rótulo usado em uma ligação. Especificamente, o problema é aquele ERO e ER-Hop não suporta objetos substitutos de rótulo explícitos. Um caso de exemplo onde um tal mecanismo é desejável é onde há dois LSPs para serem " entrançados " juntos, ex., onde o rabo do primeiro LSP seria " entrançada " na cabeça do segundo LSP. Este último caso é mais provável ser usada nas classes de non-PSC de ligações.
Para cobrir este caso, um Rótulo subobjeto de ERO/Hop de ER é introduzido.
6.1. Informação exigida
O Rótulo Explícito e Rotas de Registro contêm:
L: 1 bit
Este bit deve ser fixado a 0.
U: 1 bit
Este bit indica a direção do rótulo. É 0 para o
Rótulo “downstream”. É fixado a 1 para rótulo de “upstream” e é
só usada em LSPs bidirecionais.
Rótulo: Variável
Este campo identifica o rótulo a ser usado. O formato deste
campo é idêntico ao usada pelo campo de Rótulo dentro
Rótulo generalizado, veja Seção 3.2.1.
A Colocação e ordenação destes parâmetros estão sinalizados no protocolo
específico.
7. Informação de proteção
É levada Informação de proteção em um novo object/TLV . É usada uma indicação de ligação relacionada a atributos de proteção de um LSP pedido. O uso de Informação de Proteção para um LSP particular é opcional. Informação de proteção indica o tipo de proteção de ligação atualmente desejada para o LSP. Se um tipo de proteção particular, ex., 1+1, ou 1:N, é pedida, então um pedido de conexão só é processado se o tipo de proteção desejado pode ser honrado. Note que as proteções podem ser anunciadas e capacidades de uma ligação, veja [GMPLS-RTG].
Algoritmos de computação de caminho podem levar em conta esta informação ao computar caminhos para montar LSPs.
Informação de proteção também indica se o LSP for um primário ou LSP secundário. Um LSP secundário é um auxilio a um LSP primário. O recursos de um LSP secundário não são usados até o LSP primário falhar. Os recursos alocados para um LSP secundário podem ser usados por outro LSPs até que o LSP primário falhar em cima de para o LSP secundário. Naquele ponto, qualquer LSP que está usando os recursos para o LSP secundário, deve ser adquirido por preempção.
7.1. Informação exigida
A informação seguinte é levada na Informação de Proteção:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reservado | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secundário (S): 1 bit
Quando habilitado, indica que o LSP pedido é um LSP secundário.
Reservado: 25 bits
Este campo está reservado. Deve ser habilitado em zero na transmissão
e deve ser ignorado na recepção. Estes bits devem se manter
inalterados passando através de nodos de trânsito.
Flags de ligação: 6 bits
Indica tipo de proteção de ligação desejado. Como previamente
mencionada, podem ser anunciadas capacidades de proteção de uma ligação
derrotando. Um valor de 0 inplica que qualquer, incluindo nenhum,
ligação, proteção pode ser usada. Mais de um bit pode ser habilitado
indica quando tipos de proteção múltiplos forem aceitáveis. Quando
bits múltiplos são tipos de proteção fixos e múltiplos são
disponíveis, a escolha de tipo de proteção é um habitante (política)
decisão.
As bandeiras seguintes estão definidas:
0x20 Avançado
Indica que um esquema de proteção que é mais seguro que
Dedicada deveriam ser usadas 1+1, por exemplo, 4 BLSR/MS-FONTE de fibra.
0x10 Dedicado 1+1
Indica que um ligação camada proteção esquema dedicado,
i.e., 1+1 proteção, deveria ser usada para apoiar o LSP.
0x08 Dedicado 1:1
Indica que um ligação camada proteção esquema dedicado,
i.e., 1:1 proteção, deveria ser usada para apoiar o LSP.
0x04 Compartilhado
Indica que um ligação camada proteção esquema compartilhado, tal,
como 1:N proteção, deveria ser usada para apoiar o LSP.
0x02 Desprotegido
Indica que o LSP não deveria usar nenhuma camada de ligação
proteção.
0x01 Tráfico Extra
Indica que o LSP deveria usar ligações que estão protegendo
outro (primário) tráfico. Tal LSPs pode ser adquirido por
preempção quando as ligações que levam o (primário) tráfico que é protegido falhar.
8. Informação de Estado administrativa
A Informação de Estado administrativa é levada em um object/TLV novo. Informação de Estado administrativa é atualmente usada de dois modos. Em primeiramente, a informação indica estado administrativo com respeito a um LSP particular. Neste uso, o Estado Administrativo da Informação indica o estado do LSP. Indicações estatais incluem " para cima " ou " abaixo ", ou se está em um " modo de prova ", e se uma deleção está em andamento. As ações levadas por um nó baseados em um estado de decisão local. Uma em ação de exemplo que pode ser entrada é inibir alarme informando quando um LSP está “down” dentro " ou " testando " estados, ou informar alarmes associados com a conexão a uma prioridade igual ou para menos que " Non Service affecting ".
No segundo uso de Informação de Estado Administrativa, a informação indica um pedido para habilitar o estado administrativo de um LSP. Esta informação sempre é retransmitida ao nó de ingresso no qual age o pedido.
Os usos diferentes são distintos de um protocolo específico da moda. Veja [RFC3473] e [RFC3472] para detalhes. O uso de Informação de Estado Aministrativa para um LSP particular é opcional.
8.1. Informação exigida
A informação seguinte é levada no Estado Administrativo
Informação:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reservado |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit
Quando habilitado, indica que o nó de extremidade deveria refletir o object/TLV atrás na mensagem apropriada. Este bit não DEVE ser habilitado em pedido de mudança de estado, ex., Notificação, mensagens.
Reservada: 28 bits
Este campo está reservado. Deve ser habilitado para zerar na transmissão e deve ser ignorada na recepção. Estes bits deveriam se passar por inalterados através de nós de trânsito.
Testando (T): 1 bit
Quando habilitados, indicam que as ações locais relacionaram o modo
" testando " deveriam ser levadas.
Administrativamente abaixo (UM): 1 bit
Quando habilitado, indica que as ações locais relacionaram o
" administrativamente abaixo " estado deveria ser levada.
Apagamento em desenvolvimento (D): 1 bit
Quando habilitado, indica que que as ações locais relacionaram um LSP
e deveriam ser levados teardown. Nós de extremidade podem usar esta
bandeira para controle teardown de conexão.
9. Controle de Separação de Canal
O conceito de ser um controle de canal difere que um canal de dados sendo sinalizado foi apresentada a MPLS com relação a ligação de empacotando, veja [MPLS-PACOTE]. Em GMPLS, a separação de controle e canal de dados pode ser devido a qualquer número de fatores. (Incluindo empacotando e outros casos como canais de dados nos que não podem levar - informação de controle de faixa).
Esta seção cobrirá os dois críticos assuntos relacionados: a identificação de canais de dados sinalizados e controle de falhas de canal de controle que não impactam nos canais de dados.
9.1. Identificação de Interface
Em MPLS tradicional há uma associação implícita um-para-uma de um controle de canal a um canal de dados. Quando uma associação é presente, nenhuma informação adicional ou especial é requerida associada a uma configuração de LSP em uma transação particular com um canal de dados particular. (Está implícito no canal de controle em cima de qual são enviadas mensagens sinalizadas)
Em casos onde não hão uma associação explícita um-para-uma de canais de controle para canais de dados é necessário carregar informação adicional sinalizando para identificar os dados particulares do canal controlado. O GMPLS suporta a identificação de canal de dados explícito provendo informação de identificação de interface. GMPLS permite o uso de vários esquemas de identificação de interface incluindo o IPv4 ou IPv6 se dirige, índices de interface (veja [MPLS - UNNUM]) e o componente conecta-se (estabelecido por configuração ou um protocole como [LMP]). Em todos os casos a escolha dos dados interface é indicada pelo nó de “upstream” que usa endereços e identificadores usados pelo nó de “upstream”.
9.1.1. Informação exigida
A informação seguinte é levada em um Interface_ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Onde cada TLV tem o formato seguinte:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tipo | Comprimento |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Valor ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Comprimento: 16 bits
Indica o comprimento total do TLV, ex., 4 + o comprimento do valor do campo em octetos. Um campo de valor cujo comprimento não é um múltiplo de quatro deve ser zero-padded de forma que o TLV é quatro - octetos alinhados.
Tipo: 16 bits
Indica tipo de interface que é identificada. Valores definidos
são:
Types Lenght Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 veja abaixo IF_INDEX (Índice de Interface)
4 12 veja abaixo COMPONENT_IF_DOWNSTREAM (interface de Componente)
5 12 veja abaixo COMPONENT_IF_UPSTREAM (interface de Componente)
Para Types 3, 4 e 5 o campo de Valor tem o formato:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
O campo do IP pode levar um endereço de IP de uma ligação ou um endereço de IP associado com o roteador onde associou o endereço e o valor levado em um endereço do roteador TLV.
Interface ID: 32 bits
Para uso no tipo 3, a Interface ID leva uma interface identificadora.
Para tipos 4 e 5, a Interface ID indica um empacotamento da ligação de componente. O valor especial 0xFFFFFFFF pode ser usado para indicar o mesmo rótulo e para validar através de todas as ligações componentes.
9.2. Manipulação de falha
Há duas falhas novas que devem ser controladas quando o controle
canal é independente do canal de dados. No primeiro, há uma ligação ou outro tipo de falha que limita a habilidade de nós vizinhos para passar controle de mensagens. Nesta situação, nós vizinhos não podem trocar controle mensagens por um período de tempo. Uma vez que é restabelecida a comunicação a sinalização e estando por baixo do protocolo deve indicar que os nós mantiveram o estado pela falha. O protocolo de sinalização também tem que assegurar que qualquer estado de mudanças que eram instanciados durante a falha sejam sincronizadas entre os nós.
Em segundo, o plano de controle de falhas em um nó é então reiniciado e perdas a maioria de informação de seu estado. Neste caso, ambos “upstream” e os nós “downstream” têm que sincronizar a informação de seus estados com o nó reiniciado. Para que qualquer re-sincronização aconteça o nó que sofreu o reinicio precisará preservar um pouco de informação, como seus mapeamentos de entrante a rótulos de partida.
10. Reconhecimentos
Este documento é o trabalho de numerosos autores e consiste de um composição de vários documentos prévios nesta área.
Foram recebidas valiosos comentários e contribuição de várias pessoas, Igor Bryskin incluindo, Adrian Farrel, Ben Mack-Crane, Dimitri, Papadimitriou, Fong Liaw e Juergen Heiles. Algumas seções deste documento estão baseado em texto proposto por Fong Liaw.
11. Considerações de segurança
Este documento não introduz nenhuma consideração de segurança nova para [RFC3212] ou [RFC3209]. As considerações de segurança mencionaram dentro [RFC3212] ou [RFC3209] aplique ao protocolo respectivo específico formas de GMPLS, veja [RFC3473] e [RFC3472].
12. Considerações de IANA
O IANA administrará tarefa de valores novos para namespaces definida neste documento. Esta seção usa a terminologia de BCP 26 " diretrizes por Escrever uma IANA Considerações Seção em RFCs " [BCP26].
Este documento define o namespaces seguinte:
o LSP Encoding Tipo: 8 bits
o Switching Tipo: 8 bits
o Generalized PID (G-PID): 16 bits
Ação do: 8 bits
o Interface_ID Tipo: 16 bits
Todas as tarefas futuras deveriam ser alocadas por Consensos de IETF
ação ou documentou em uma Especificação.
13. Considerações de Propriedade intelectuais
Esta seção é levada de Seção 10.4 de [RFC2026].
O IETF não leva nenhuma posição relativo à validez ou extensão de qualquer propriedade intelectual ou outra propriedade para as que poderiam ser reivindicadas pertença à implementação ou uso da tecnologia descritos dentro este documento ou até que ponto qualquer licença debaixo de tal corrige possa ou possa não estar disponível; nem que isto fez qualquer esforço para identificar qualquer tal direito. Informação no Os procedimentos de IETF com respeito a direitos em padrão-rasto e documentação padrão-relacionada pode ser achada em BCP-11. Cópias de reivindicações de direitos fizeram disponível para publicação e qualquer garantia de licenças ser feita disponível, ou o resultado de uma tentativa fez obtenha uma licença geral ou permissão para o uso de tal propriedades proprietário por implementors ou usuários desta especificação podem seja obtida da Secretaria de IETF.
O IETF convida qualquer festa interessada a trazer a sua atenção qualquer direito autorais, patentes ou aplicações patentes, ou outro proprietário direitos que podem cobrir tecnologia que pode ser exigida praticar este padrão.
Por favor envie a informação ao Executivo de IETF Diretor.
14. Referências
14.1. Referências normativas
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J.,Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002. [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 14.2. Referencias Informativas [GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress. [GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH Specifics", Work in Progress. [LMP] Lang, et al., "Link Management Protocol", Work in Progress. [MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress. [MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC3031, January 2001.