TP309 – Redes de Transporte Parte 3

Apresentação em tema: "TP309 – Redes de Transporte Parte 3"— Transcrição da apresentação:

1 TP309 – Redes de Transporte Parte 3
INATEL Competence Center Av. João de Camargo, 510 Santa Rita do Sapucai - MG Tel: (35)

2 Situação Atual das Redes...
SDH – É a tecnologia predominante nos backbones e onde foram feitos enormes investimentos em capacidade! Ethernet – É a tecnologia predominante nas LANs e a mais conhecida entre as empresas no mundo todo! Tráfego de Dados – Está crescendo moderadamente... As propostas para uma rede puramente IP foram adiadas para um futuro um pouco mais distante. O Futuro Hoje: Utilizar a rede SDH para transporte de Ethernet !

3 Ethernet vs. SDH Ethernet SDH Redes Locais Redes de Transmissão Assíncrono Síncrono Banda Dinâmica Banda Fixa Não Orientado a Conexão Orientado a Conexão Serviço “Best Effort” Serviço de Alta Qualidade

4 Redes Ópticas Ethernet

5 Redes Ópticas Ethernet
Preâmbulo 8 bytes Endereço Destino 6 bytes Origem Compr/ Tipo 2 bytes Dados (Payload) bytes 4 bytes FCS Preâmbulo/SFD: Campo que permite o receptor sincronizar-se com o fluxo de transmissão entrante e localização do início do pacote Ethernet Endereço Origem: (MAC-) Address do elemento de rede que está originando o pacote Compr/Tipo: Comprimento do pacote. Para pacotes tipo DIX, o tipo de protocolo de camada 3 presente no campo de Dados (Payload) Dados (Payload): Campo que contém informação de cliente/útil (todos outros campos são considerados parte do cabeçalho) FCS: Frame Check Sequence. O valor é calculado no elemento de rede de origem e inserido no pacote. O elemento de rede receptor realiza o mesmo cálculo e compara seu FCS com o FCS recebido no pacote. Switches Ethernet irão descartar o pacote que tiver erro de FCS. Quadro de linha Ethernet IEEE 802.3 Endereço Destino: (MAC-) Address do elemento de rede ao qual o pacote está sendo encaminhado O frame ethernet pode variar o comprimento do frame de 64 até 1518 bytes (excluindo o preâmbulo). A figura acima ilustra a estrutura do frame ethernet. Os campos de overhead tem seu comprimento fixados e a área do payload pode variar de 46 bytes até 1500 bytes. Preâmbulo/SFD: Campo que permite o receptor sincronizar-se com o fluxo de transmissão entrante e a localização do início do pacote Ethernet. Endereço Destino: (MAC-Media Access Control) Endereço do elemento de rede ao qual o pacote está sendo encaminhado. Endereço Origem:(MAC-Media Access Control) Endereço do elemento de rede que está originando os pacotes. Compr/Tipo:Comprimento do pacote. Para pacotes tipo DIX ( Digital Intel Xerox- (Ethernet type II)), o tipo de protocolo de camada 3 presente no campo de Dados (Payload). Dados (Payload): Campo que contém informação de cliente/útil (todos outros campos são considerados parte do cabeçalho) FCS:Frame Check Sequence. O valor é calculado no elemento de rede de origem e inserido no pacote. O elemento de rede receptor realiza o mesmo cálculo e compara seu FCS com o FCS recebido no pacote. Switches Ethernet irão descartar o pacote que tiver erro de FCS.

6 Redes Ópticas Ethernet
Topologia: Etherner over Fiber (EoF) IEEE 802.3 É simplesmente a transmissão de pacotes Ethernet em fibras ópticas. Pode-se ter conexões ponto-a-ponto ou em malha: Ethernet Ethernet Ethernet LOCAL A LOCAL B Conexão Ponto-a-ponto

7 Redes Ópticas Ethernet
Topologia: Ethernet over SDH (EoS) É o mapeamento de Ethernet sobre um Container Virtual (VC-n) SDH Anel SDH STM-n Ethernet Ethernet 100Mbps 100Mbps VC-4 VC-4 LOCAL A VC-n LOCAL B

8 3) Ethernet over GFP (ITU-T G.7041)
Opções de Mapeamento 3) Ethernet over GFP (ITU-T G.7041) GFP Frame Ethernet Frame SDH GFP (Generic Frame Procedure) O GFP (Generic Frame Procedure ) é padronizado pela ITU-T G.7041, trata-se de um mecanismo “genérico” desenvolvido para adaptar diversos tipos de serviços em um canal de transmissão bit-síncrono (WDM) ou octeto- síncrono (SDH,OTN). O GFP tem a capacidade de adaptar tráfego de camadas 1 (Fibre Channel, Gigabit Ethernet, ESCON, FICON) e camada 2 (PPP/IP/MPLS, Ethernet , RPR), utilizando um algoritmo simples e estável, com correção de cabeçalho. Trata-se de uma tecnologia que é compatível com qualquer serviço de nível superior e com qualquer tecnologia de rede além de proporcionar fácil expansão sendo eficiente desde 10M até 40G não necessitando de novos equipamentos no backbone somente nos equipamentos terminais, pois a rede SDH atua como uma rede de transporte transparente ao fluxo ethernet, mapeado em GFP(Generic Frame Procedure), sendo possível a formação de estruturas adequadas ao transporte de cada aplicação independente de sua taxa como Ethernet, Fast Ethernet , Gigabit Ethernet e outras, adaptando à uma quantidade satisfatória de Virtual Container utilizando VCAT (Concatenação Virtual) além de utilizar LCAS (Link Capacity Adjustment Scheme) para realizar o ajuste dinâmico da banda sem interrupção do serviço. Dessa forma cria-se novas oportunidades tecnológicas e econômicas. Ethernet sobre GFP Cabeçalho de transporte determinístico Não interfere na gerência de QoS/Largura de Banda Delineação simples e eficiente quando em altas velocidades Pode ser usado com SDH e Vcat, OTN, etc.

9 New Generation SDH Cliente A Cliente B Storage Servers SDH SDH SDH
Ethernet Cliente B Ethernet SDH SDH Optical Core Network Storage Servers SDH SDH/DWDM Remote Servers

10 Elemento de Rede de Nova Geração SDH
New Generation SDH Elemento de Rede de Nova Geração SDH Cliente Rede Ethernet GFP Generic Frame Procedure VC Virtual Concatenation LCAS Link Capacity Adjustment Scheme ? SDH Interfaces Nativas SDH MUX/DEMUX

11 Generic Frame Procedure
GFP

12 GFP – Generic Frame Procedure
Padronizado pela ITU-T G.7041 É um mecanismo “genérico” criado para adaptar múltiplos tipos de serviços em um canal de trasmissão bit-síncrono (WDM) ou octeto-síncrono (SDH, OTN). É possível adaptar tráfego de camadas 1 (Fibre Channel, GE) e 2 (PPP/IP/MPLS, Ethernet, RPR) Algoritmo simples e estável, com correção de cabeçalho Compatível com qualquer serviço de nível superior e com qualquer tecnologia de rede Cria novas oportunidades tecnologicas e econômicas Fácil expansão (eficiente desde 10M até 10G e já está aprovado para 40G). Não requer novos equipamentos no backbone (somente os das pontas)

13 GFP – Generic Frame Procedure
Core Header Payload Type Extension Field Area Headers O frame GFP é composto de duas partes Core header e Payload Area. O Core header tem comprimento de 4 bytes e contém (comprimento do payload área, início do quadro de informação, detecção e correção de erro utilizando CRC-16). O payload área esta subdividido em payload headers e payload área, e no payload headers será subdividido em payload type e Extension Header Field e o Payload área será subdividido em Client Payload Information e Optional Payload FCS ,

14 GFP – Generic Frame Procedure
Payload Headers informa tipo de cliente e suporta procedimentos específicos de gerência  Inclui detecção e correção por CRC  Comprimento= 4 a 64 byte Payload Headers Core Header contém o comprimento da área de payload,  e início do quadro de info  e deteção & correção de erro com CRC-16  Comprimento = 4 bytes 8 bit Payload Area Core Header Client Payload Field contêm  client frames (GFP-F) ou  client characters (GFP-T) Client Payload Information GFP Payload Area transporta info de camadas superiores Comprimento = 4 a bytes Optional Payload FCS protege o campo de “client payload information” CRC-32 Comprim = 4 byte Optional Payload FCS

15 GFP – Generic Frame Procedure
Core Header Core Header Core Header CID Spare eHEC PTI PFI EXI UPI tHEC PLI cHEC 4 Payload Area Payload Headers Payload Type 4 Extension Header Field 4 Core Header: PLI = Payload Length Inidcator cHEC = Core Header Error Check (CRC-16) - Protects PLI Payload Area Payload Headers: Payload Type: PTI=Payload Type Identifier PFI= Payload Frame Check Sequence Identifier EXI=Extension Header Identifier UPI=User Payload Identifier tHEC = Type Header Error Check (CRC-16) - protects Payload Type Extension Header Field: CID= Channel ID eHEC = Extension Header Error Check (CRC-16) - Protects CID Client Payload Information: Optional Payload FCS: FCS = Frame Check Sequence Payload Area Payload Area Client Payload Information Optional Payload FCS 4 8 bits

16 GFP – Generic Frame Procedure – Core Header
PLI cHEC 1 PLI - PDU Length Indicator Campo de 16 bits contendo um número binário que representa o comprimento da área da payload area: mín.: 4 bytes (PLI = 00 04hex) max.: byte (PLI = FF FFhex) PLI = 0hex a 3hex reservado para frames de controle Payload Area Core Header Core Header O Core Header tem a função de enviar o comprimento da área de payload PDU e contém bits destinados ao controle de erro para proteger a integridade do Core Header. PLI ( PDU Lenght Indicator) Indicação do comprimento da PDU, um campo de 16 bits que contêm de forma binária a representação do comprimento do payload área, a mesma podendo ser de no mínimo 4 bytes que será representada por (PLI = hex) e no máximo que será representada por (PLI = FF FF hex). O valor de PLI de 0 hex até 3 hex é reservado para frames de controle. Quando o valor do PLI é de 0 hex até 3 hex é reservado para frames de controle que serão usados na gerência da conexão GFP, portanto existem 4 tipos de frames de controle PLI = hex até hex , mas somente um está atualmente especificado que é o PLI = hex que é o menor frame possível com comprimento da área de payload 00 portanto o tamanho do frame GFP é de apenas 4 bytes chamado de “GFP IDLE Frame”. cHEC - Core Header Error Control Contém um código de controle de erro CRC-16 para proteger a integridade do “Core Header”. Possibilita: Correção de 1 bit errado Deteção de múltiplos bits errados

17 GFP – Generic Frame Procedure – Control Frames
GFP Control Frames são usados na gerência da conexão GFP. Existem quatro tipos de Control Frames: PLI= 00 00hex to PLI = 00 03hex Mas somente um Control frame está atualmente especificado: “Control Frames (GFP idle frames)” para PLI menor ou igual à 03 hex, esse frame é usado para o gerenciar a conecção GFP, e consiste somente o campo de cabeçalho sem área de payload. Esse frame é usado para compensar o espaço entre o sinal do cliente aonde o transporte médio tem alta capacidade. O GFP idle frame é inserido se não existir frames GFP pronto para transmissão, o mesmo no caso fornece uma contínua rajada de frames para o mapeamento. No caso também de Client Signal Fail (CSF) que significa a perda de um frame GFP, o GFP dá início a geração de um frame de gerenciamento do cliente a cada 100ms, essa condição só é eliminada após um recebimento de um GFP válido, ou quando a indicação de CSF não é recebida por 1000ms, durante essa condição de CSF, os GFP idle frames são enviados. GFP Control Frames GFP control frames é usado no gerenciamento da conecção GFP. O único control frame especifico até agora é o GFP Idle Frame. GFP Idle Frame O GFP Idle Frame é um especial GFP control frame de quatro octetos consistindo de somente um GFP Core Header com campos de PLI e cHEC setados para 0 (veja no 6.1.1), e sem Payload Area. O Idle Frame é destinado no uso como um frame de preenchimento pelo processo de adaptação de origem para facilitar a adaptação das rajadas de octetos GFP para algum determinado transporte médio aonde o canal de transporte médio tem uma alta capacidade que é solicitado pelo client signal. Os “GFP IDLE Frame” são necessários no processo de adaptação de taxa e para garantir o processo de sincronização de frames. Outros Control Frames Control frames com PLI = 1, 2 ou 3 estão em estudos. GFP IDLE Frames O menor frame GFP possível, com somente 4 bytes de comprimento PLI = 00 00hex IDLE frames são necessários para processo de adaptação de taxa garantir processo de sincronização de frames IDLE Frame PLI =00 PLI= 00 cHEC = 00

18 GFP – Generic Frame Procedure – Payload Header
Area Core Header Client Information Headers Optional Payload FCS Payload Type Field É obrigatório para GFP client frames (PLI 4) Fornece informação sobre: conteúdo e formato da informação do Client Payload indica diferentes tipos de GFP frame distingue diferentes serviços em um ambiente multi-serviço Payload Type Extension Header Field O campo do payload type é obrigatório para o “GFP client frames” que são representados com o valor de PLI maior ou igual a 04 hex, e contém informações sobre o conteúdo e formato da informação do “Client Payload”, indica diferentes tipos de GFP frame e distingue diferentes tipos de serviços em um ambiente multi-serviço.

19 GFP – Generic Frame Procedure – Payload Header
Type Extension Header Field PTI PFI EXI UPI tHEC 1 PTI - Payload Type Identifier Campo de 3 bits que indica o tipo de GFP client frame Atualmente definidos: PTI = 000  Client Data PTI = 100  Client Management PTI = Outros  Reserved PFI - Payload FCS Indicator Campo de 1 bit que indica PFI = 1  Presença PFI = 0  Ausência do campo opcional de Frame Check Sequence (pFCS) do payload PTI (Payload Type Identifier)  representado por um campo de 3 bits que indica o tipo de GFP client frame. Definido como: PTI = 000  Client Data PTI = 100  Client Management PTI = outros  Reservado Portanto um Client Frame pode ser dividido em um “Client Data Frame” ou um “Client Management Frame” dependendo do valor do PTI (Payload Type Identifier). PFI – (Payload FCS Indicator)  Campo de apenas 1 bit usado para indicar ausência ou presença do campo opcional de Frame Check Sequence (pFCS) do payload. PFI=1  Presença PFI=0  Ausência EXI (Extension Header Identifier)  Campo de 4 bits destinado a indicar o formato do “Extension Header Field”, o EXI será setado consistentemente com a multiplexação de frames e indicando a topologia requisitada pela conecção GFP. EXI =  Null Extension Header EXI =  Linear Frame EXI =  Ring Frame EXI = Others  Reservado UPI (User Payload Identifier)  Campo de 8 bits que identifica o tipo de cliente /serviço encapsulado no “Client Payload Information” do GFP , sendo a interpretação do UPI diferente para: PTI = 000  Client Data Frames ; PTI = 100  Client Management Frames; EXI - Extension Header Identifier Campo de 4 bits que indica o formato do campo Extension Header Atualmente definidos: EXI =  Null Extension Header (só 1 usuário plugado) EXI =  Linear Frame (vários usuários plugados) EXI =  Ring Frame EXI = Others  Reserved

20 GFP – Generic Frame Procedure – Payload Header
Type Extension Header Field PTI PFI EXI UPI tHEC 1 UPI - User Payload Identifier Campo de 8 bits que identifica o tipo de cliente/serviço encapsulado no Client Payload Field do GFP A interpretação dos valores do UPI é diferente para: Client data frames (PTI=000) ou Client management frames (PTI=100) Mais detalhes nos próximos slides UPI (User Payload Identifier)  Campo de 8 bits que identifica o tipo de cliente /serviço encapsulado no “Client Payload Information” do GFP , sendo a interpretação do UPI diferente para: PTI = 000  Client Data Frames ; PTI = 100  Client Management Frames; tHEC (Type Header Error Control) é um código de 16 bits no payload type para controle de erro, que protege a integridade do conteúdo do campo Type, realiza a correção de 1 bit errado e detecta múltiplos erros de bit no campo do “Payload Type”. O Type header consiste do campo Type e o tHEC. O conteúdo do campo tHEC é gerado usando os passos: - O M(x) é formado apartir de todos os octetos do campo Type, excluindo o próprio campo tHEC. - M(x) é multiplicado por e dividido por G(x) , produzindo um resto R(x) de grau 15 ou menos. - O coeficiente de R(x) é considerado ser uma sequência de 16 bits, aonde é o bit mais significativo. - Essa sequência de 16 bits é o CRC-16 onde o primeiro bit do CRC-16 a ser transmitido é o de coeficiente de e o último bit transmitido é o de coeficiente . tHEC - Type Header Error Control código de 16 bits para controle de erros para correção de 1 bit errado ou para detetar múltiplos erros de bit no campo de Payload Type

21 GFP – Generic Frame Procedure – Client Data Frames
PTI PFI EXI UPI tHEC Info de clientes/serviços são transportadas sobre Client Data Frames GFP Indicação no campo Type PTI = 000 Client Data Frames atualmente definidos - User Payload Identifier (UPI) UPI = 00 & FF  Reserved and not available UPI = 01hex  Ethernet (frame-mapped) UPI = 02hex  PPP (frame-mapped) UPI = 03hex  Fibre Channel (transparent-mapped) UPI = 04hex  FICON (transparent-mapped) UPI = 05hex  ESCON (transparent-mapped) UPI = 06hex  Gigabit Ethernet (transparent-mapped) UPI = 07hex  Reserved for future use UPI = 08hex  Multiple-Access Protocol over SDH (frame-mapped) UPI = 09 to EF  Reserved for future use UPI = F0 to FE  Reserved for proprietary use

22 Client Management Frames
GFP – Generic Frame Procedure Client Management Frames PTI PFI EXI UPI tHEC Esta funcionalidade provê um mecanismo para enviar informação de gerência desde a origem do GFP até o destino. Indicação no campo Type PTI = 100 E para os valores de UPI para o “Client Management Frames” indicado no campo de PTI = 100, para esse frame o UPI tem a funcionalidade de provê um mecanismo para enviar informação de gerência desde a origem do GFP até o destino. Management Frames atualmente definidos UPI = 00 & FFhex  Reserved and not available UPI = 01hex  Loss of Client Signal (Client Signal Fail) UPI = 02hex  Loss of Character Synchronization UPI = 03 to FEhex For future use

23 GFP – Generic Frame Procedure – Extension Header
Extension Header Field Suporta cabeçalhos de nível 2 (data link) especificos da tecnologia, ex: virtual link identifier Endereço Origem/Destino Classe de Serviço Possui de 0 a 60 bytes de comprimento e é indicado no campo Type (EXI) Três variantes do Extension Header estão atualmente definidas, para configurações ponto-a-ponto ou anel (ring) EXI =  Null Extension Header EXI =  Linear Frame EXI =  Ring Frame EXI = Others  Reserved Payload Area Core Header Client Information Headers Optional Payload FCS Payload Type Extension Header Field O campo de Extension Header suporta cabeçalho de nível 2 expecíficos da tecnologia, por exemplo identificação do link virtual, endereço de origem e destino e classe de serviço. Possui um comprimento de 0 à 60 bytes e é indicado no campo Type EXI no Payload Type. Atualmente 3 variantes estão atualmente definidas, para configuração ponto-a-ponto ou anel (ring). EXI =  Null Extension Header EXI =  Linear Frame EXI =  Ring Frame EXI = Others  Reservado

24 GFP – Generic Frame Procedure – Null Extension Header
tHEC Type 1 Null Extension Header (EXI = 0000 (0hex)) Aplica-se configurações lógicas ponto-a-ponto, onde a via de transporte é dedicada a somente um cliente ou serviço Extension Header Field  Para EXI = 0000 No caso do Null Extension Header onde o valor de EXI é 0000 ( 0 hex ), aplica-se configurações lógicas ponto a ponto, onde a via de transporte é dedicada a somente um cliente ou serviço. Desta forma o campo de “Extension Header” não estará presente. O campo Extension Header não estará presente

25 Extension Header para Ring Frame  em estudo
GFP – Generic Frame Procedure – Linear Extension Header Linear Frame Extension Header (EXI = 0001) Aplica-se a configurações lineares (ponto-a-ponto), onde vários clientes independentes ou serviços são agregados a uma única via de transporte eHEC CID Spare 1 tHEC Type Extension Header Field CID - Channel ID Campo de 8 bits para identificar até 256 canais GFP independentes em um mesmo link  Para EXI = 0001 No caso do Linear Frame onde o valor de EXI é 0001 ( 01 hex ), aplica-se a configuração Linear (ponto a ponto), quando vários clientes independentes ou serviços são agregados a uma única via de transporte. Neste caso o valor do byte CID ( Channel ID), um campo de 8 bits usado para identificar até 256 canais GFP independentes em um mesmo link. O fluxo de GFP de múltiplas portas ou clientes são multiplexados quadro a quadro, e no caso de não haver sinal de cliente ou serviço células GFP Idle são transmitidas. Pode ser identificado até 256 sinais independentes.  Para EXI = 0010 No caso do Extension Header para Ring Frame ainda encontra-se em estudo. Spare Campo de 8 bits para uso futuro eHEC - Extension Header Correction Código de 16 bits para controle de errors corrige um bit errado deteta multiplos erros de bit no campo Extension Header Extension Header para Ring Frame  em estudo

26 GFP – Generic Frame Procedure Linear Extension Header – Multiplexação
Fluxos GFP de múltiplas portas ou clientes são multiplexados quadro a quadro Células GFP IDLE são transmitidas no caso de não haver sinal de cliente eHEC CID Spare Linear Extension Header 1..256 signals GFP Mux Fluxos GFP com clientes distintos IDLE Insertion CID=0 CID=2 CID=1 Spare  O byte Spare, um campo de 8 bits destinado para usos futuros. eHEC (Extension Header Correction)  é um código de 16 bits para controle de erro, corrigindo apenas 1 bit errado mas detecta múltiplos erros de bit no campo de “Extension Header”. O M(x) é formado apartir de todos os octetos do Extension Header, excluindo o próprio campo eHEC. M(x) é multiplicado por e dividido por G(x) , produzindo um resto R(x) de grau 15 ou menos. O coeficiente de R(x) é considerado ser uma sequência de 16 bits, aonde é o bit mais significativo. Essa sequência de 16 bits é o CRC-16 onde o primeiro bit do CRC-16 a ser transmitido é o de coeficiente de e o último bit transmitido é o de coeficiente .

27 GFP – Generic Frame Procedure – Client Payload Area
CPI - Client Payload Information Field Campo de comprimento variável o qual contém informação útil de cliente/serviço GFP-F (frame mapped) CPI transporta frames de cliente GFP-T (transparent mapped) CPI transporta caracteres de cliente (unframed) máx. comprimento: bytes - payload header - pFCS Payload Area Core Header Client Information (CPI) Headers Optional Payload FCS Client Payload Information Transporta informações de camadas superiores, campo de comprimento variável pode ir de 0 à X bytes, onde X é o tamanho do Payload Header, o qual contém informações úteis de cliente/serviço.Pode conter GFP-F (frame mapped) onde transporta frames de cliente ou seja a PDUs (Protocol data unit), nesse modo o frame é utilizado para a transmissão de quadros (PPP/IP ou MAC) com divisão em bytes de 8 bits, o client sinal PDU é sempre transferido para dentro do campo de informações do payload do GFP como um octeto alinhado na rajada de pacote. GFP-T (Transparent mapped) onde transporta caracteres de cliente (unframed). O modo transparente é usado para transmissão de informação codificada em blocos, como ocorre nas redes Gigabit Ethernet. Nesse tipo de codificação cada código, em geral, tem um tamanho diferente de 8 bits. O Payload Área pode conter um campo chamado de “Optional Payload FCS” pFCS (payload Frame Check Sequence) que é um código de controle opcional. Esse contém uma sequência CRC-32 destinado a proteger o conteúdo do campo client payload information. O mesmo estará presente, se no campo PFI do Type do Payload Header estiver como PFI = 1. O pFCS pode somente detectar bits errados. pFCS - Payload Frame Check Sequence Código de controle opcional de 32 bits para proteger o campo client payload information Estará presente se PFI=1 no campo Type (Payload Header) pFCS pode somente detetar bits errados

28 GFP Header ou IDLE frames
GFP – Generic Frame Procedure – Client Payload Area variável Ethernet Frame GFP GFP GFP Eth. Frame GFP GFP Eth GFP GFP-F Frame a Frame 1GigE LE Ethernet Frame IDLE Eth. Frame IDLE Eth Bloco a Bloco Transparent GFP Transparent GFP Transparent GFP GFP GFP-T fixo GFP GFP GFP Header ou IDLE frames

29 GFP – Generic Frame Procedure Framed Mapeamento Ethernet
Bytes tHEC Type PLI cHEC GFP Extension Header GFP Payload 2 0-60 As Client Source Address Destination Address Preamble Start of Frame Delimeter Length/Type MAC Client Pad Frame Check Sequence Bytes 7 1 2 6 4 46- 1500 Source Address Destination Address Length/Type MAC Client Pad Frame Check Sequence Encapsulamento do Ethernet MAC No caso do encapsulamento do ethernet MAC dentro do GFP, o campo de endereço de destino ao Frame Check Sequence (FCS) é colocado dentro da área de payload do GFP. No processo de adaptação na origem o GFP apaga os espaços vazios entre os pacotes, conhecido como Inter Packet Gaps (IPGs). Ethernet MAC é então passada adiante promovendo o encapsulamento dentro do frame GFP. Do outro lado, o processo de adaptação restaura o IPGs, e ethernet MAC é então enviado para a camada client para facilitar o processamento. Ethernet MAC Frame GFP-F Frame

30 GFP – Generic Frame Procedure
t 1 2 3 4 2.5M Ethernet Quadros Ethernet Tráfego Variável GFP Idle Frames Rajada Constante Quadro GFP mapeados com Ethernet

31 Concatenação VC Concatenação
Para o transporte de payloads que não se adaptam eficientemente dentro do padrão dos virtuais containers (VC-3/4/2/12/11) o VC concatenado pode ser usado. VC concatenado é definido por: VC-3/4 – para prover transporte de payloads que requerem grandes capacidades em comparação a um VC-3/4; VC-2 – Provê transporte de payloads que requerem grandes capacidade em comparação a um container –2; VC-1n – Provê transporte de payloads que requerem grandes capacidades em comparação a um container-1.

32 VC-n-Xc VC-n-Xv Concatenação Concatenação Contígua
Dois métodos de concatenação são definidos: Contígua e concatenação Virtual. Ambos métodos provê largura de banda concatenada de X vezes container –N no caminho final. A diferença é o transporte no caminho final. Concatenação contígua mantêm a largura de banda contígua por todo o transporte, enquanto a concatenação virtual quebra a largura de banda contígua dentro de VCs individuais , o transporte do VCs individuais é recombinado nesses VCs para uma largura de banda contígua no ponto final da transmissão. Virtua concatenação requer concatenação funcional somente no equipamento de caminho terminal, enquanto a concatenação contígua requer concatenação funcional em cada elemento da rede. Isso é possível executar uma conversão entre dois tipos de concatenação. A conversão entre concatenação virtual e contígua VC-4 é definida no ITU-T Rec. G.783. A conversão entre concatenação virtual e contígua VC-2 está em estudos futuros. VC-n-Xv Concatenação Virtual

33 Concatenação Contígua de X VC-4s
K3 F3 H4 F2 G1 C2 B3 J1 C- 4 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 4 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 4 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 4 VC- 4 260 bytes 261 bytes VC-4-Xc, sendo X = 4, 16, 64, 256 J1 Bit stuffing Concatenação contígua de X VC-4s (VC-4-Xc, X=4,16,64,256) – SÓ EXISTE PARA ALTA ORDEM (VC-4-Xc) Um VC-4-Xc provê uma área de payload de X containers –4 como apresentado na figura acima. Um grupo comum de POH, localizado na primeira coluna é usado por todo VC-4-Xc (o BIP-8 cobre todo 261 x X colunas do VC-4-Xc). Coluna 2 para X é fixado para bit stuff (preenchimento). O VC-4-Xc é transportado em X AU-4 contíguos no sinal do STM-N. A primeira coluna do VC-4-Xc é sempre localizada no primeiro AU-4. O ponteiro desse primeiro AU-4 indica a posição do byte J1 do VC-4-Xc. O ponteiro do AU-4 #2 para X está fixo para indicação de concatenação para indicar o payload concatenado contíguamente. Justificação de ponteiro é executada em comum por X AU-4s concatenados e X x 3 bytes de stuffing são usados. B3 C2 G1 C- 4 -4c VC- 4-4c F2 H4 F3 K3 N1 4 x 260 bytes 4 x 261 bytes

34 Concatenação Contígua
Problema: Como transportar 100Mbps Ethernet sobre SDH? 100 Mbps Tamanhos dos VCs do SDH C Mbit/s C Mbit/s C Mbit/s C-4 é desperdício! C-4-4c Mbit/s C-4-16c 2,396 Gbit/s C-4-64c 9,584 Gbit/s C-4-256c ,338 Gbit/s Concatenação Contígua > 150 Mbps

35 Concatenação Contígua de X VC-4s
Virtual Container Capacidade VC-4 VC-4-4c VC-4-16c VC-4-64c VC-4-256c 149,76 Kbps 599,04 Kbps 2.396,160 Kbps 9.584,640 Kbps 38.338,560 Kbps X=1 X=4 X=16 X=64 X=256 Um VC-4-Xc provê uma capacidade de payload de kbit/s por X= 4, kbit/s por X=16, kbit/s por X=64 e kbit/s por X=256. Nota – Alta taxa VC-4-Xc poderá ser usada sem qualquer força na conecção ponto a ponto. Rede SDH pode ser limitada para uma certa taxa de bit de VC-4-Xc (e.g.X  64), e.g. devido a anel com MSSPRING que tem reserva de 50% de largura de banda de proteção no STM-N.

36 VC-n-Xv Concatenação Virtual VC ou VCat – Virtual Concatenation
A Concatenação Virtual está padronizada pela ITU-T G.707 para containers SDH e pela ANSI T.105 para containers SONET; É uma forma de se montar uma estrutura de containers que seja eficiente para transportar cada tipo de sinal; Oferece a granularidade do VC-n; Pode-se concaternar VCs de Baixa Ordem (64x) e Alta Ordem (256x); VC-n-Xv

37 Concatenação Virtual Taxa de Tx Eficiencia sem VCat Utilizando VCat
Tamanhos dos VCs do SDH C Mbit/s C Mbit/s C Mbit/s Ethernet (10M) VC3 20% VC-12-5v  92% Taxa de Tx Eficiencia sem VCat Utilizando VCat Fast Ethernet (100M) VC-4 67% VC-12-47v  100% Gigabit Ethernet (1G) VC-4-16c 42% VC-4-7v  85%

38 VC-2-Xv / VC-11-Xv /VC-12-Xv
New Generation SDH VC ou Vcat – Virtual Concatenation High Order VC Low Order VC Informação no Byte H4 16 frame Multi-Frame Transmitido por um bit do Byte K4 32 frame Multi-Frame RS-ACK F2 H4 F3 K3 B3 C2 G1 J1 N1 VC-3 / VC-4 out of VC-3-Xv / VC-4-Xv J2 N2 K4 V5 VC-2 / VC-11/VC-12 out of VC-2-Xv / VC-11-Xv /VC-12-Xv

39 Concatenação Virtual de X VCs
VC-X-Nv, com X = 3, 4 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 4 C- 3 VC- 3- 4v 84 bytes 85 bytes N x VCs Independentes H4 Concatenação contígua de X VC-4s (VC-4-Xc, X=4,16,64,256) Um VC-4-Xc provê uma área de payload de X containers –4 como apresentado na figura acima. Um grupo comum de POH, localizado na primeira coluna é usado por todo VC-4-Xc (o BIP-8 cobre todo 261 x X colunas do VC-4-Xc). Coluna 2 para X é fixado para bit stuff (preenchimento). O VC-4-Xc é transportado em X AU-4 contíguos no sinal do STM-N. A primeira coluna do VC-4-Xc é sempre localizada no primeiro AU-4. O ponteiro desse primeiro AU-4 indica a posição do byte J1 do VC-4-Xc. O ponteiro do AU-4 #2 para X está fixo para indicação de concatenação para indicar o payload concatenado contíguamente. Justificação de ponteiro é executada em comum por X AU-4s concatenados e X x 3 bytes de stuffing são usados.

40 VC & LCAS Control Packet
New Generation SDH VC ou Vcat – Virtual Concatenation VC & LCAS Control Packet Frame Counter MFI VCG Sequence Indicator SQ RS-ACK Virtual Concatenation Information Reservado para LCAS

41 New Generation SDH Multi-Frame Indicator é um contador
Direção da Informação Origem  Destino Multi-Frame Indicator é um contador para distinguir vários VCGs* uns dos outros necessário para compensar o Delay Diferencial MFI SQ Sequence Indicator é um contador para diferenciar cada container VC-n dentro do VCG* para re-ordenar os containers VC-n no ponto de chegada em caso de ocorrencia de delay diferencial

42 Concatenação Virtual 1 2 255 1 2 255 1 2 255 VC-3-1v VC-3-2v VC-3-3v
MFI2 MFI1 . 15 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 3 VC-3-1v 1 . 15 2 . 15 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 3 VC-3-2v MFI2 MFI1 1 2 255 SQ=1 255 . 15 SQ=0 N1 K3 F3 H4 F2 G1 C2 B3 J1 C- 3 VC-3-3v MFI2 MFI1 1 2 255 SQ=2

43 Concatenação Virtual de X VC-12
VC v N x VCs Independentes K4 N2 J2 V5 VC- 12 C- 12 34 bytes µs 1 VC-12 capacidade de 2,176 Mbps VC-12-5v capacidade de 10,880 Mbps K4 byte 2º bit Concatenação contígua de X VC-4s (VC-4-Xc, X=4,16,64,256) Um VC-4-Xc provê uma área de payload de X containers –4 como apresentado na figura acima. Um grupo comum de POH, localizado na primeira coluna é usado por todo VC-4-Xc (o BIP-8 cobre todo 261 x X colunas do VC-4-Xc). Coluna 2 para X é fixado para bit stuff (preenchimento). O VC-4-Xc é transportado em X AU-4 contíguos no sinal do STM-N. A primeira coluna do VC-4-Xc é sempre localizada no primeiro AU-4. O ponteiro desse primeiro AU-4 indica a posição do byte J1 do VC-4-Xc. O ponteiro do AU-4 #2 para X está fixo para indicação de concatenação para indicar o payload concatenado contíguamente. Justificação de ponteiro é executada em comum por X AU-4s concatenados e X x 3 bytes de stuffing são usados.

44 Concatenação Virtual de X VC-12
MFI 1 SQ 0 MFI 2 SQ 0 VC-12-1v K4 N2 J2 V5 MFI 3 SQ 0 MFI 32 SQ 0 VC-12-2v K4 N2 J2 V5 MFI 1 SQ 0 MFI 2 MFI 3 MFI 32 SQ 1 VC-12-3v K4 N2 J2 V5 MFI 1 SQ 0 MFI 2 MFI 3 MFI 32 SQ 2

45 Next Generation SDH Quadros Ethernet Tráfego Variável GFP Idle Frames
Tráfego Constante 5M 7.5M 10M t 1 2 3 4 2.5M 5M 7.5M 10M t 1 2 3 4 2.5M Ethernet Quadros Ethernet Tráfego Variável Quadro GFP mapeados com Ethernet

46 Next Generation SDH Quadro GFP mapeados com Ethernet Rajada Constante
1 2 3 4 2.5M VC-12-5v K4 N2 J2 V5

47 Concatenação Contígua
New Generation SDH Concatenação Contígua Um Caminho C-4 C-4 C-4 NE NE VC-4-4c Core Network Concatenação Virtual Na Concatenação Virtual a informação pode ir por mais de 1 caminho VC-4 #1 Caminho 2 Caminho 1 #2 Differential Delay VC-4 #2 #1 VC-4 #1 VC-4 #2 #1 VC-4 #2 VC-4-2v

48 Novos Serviços: Largura de Banda sob Demanda
Gerência da Rede VC-12-3v NG NG LCAS ISP +VC-12 LAN no cliente Rede de Transporte Cliente  Aluga uma conexão de 6M para Internet (VC-12-3v)  Telefona para operadora e solicita 2M adicionais! Operadora  provisionará um novo VC-12 à via ..e o adicionará a conexão existente via LCAS! sem interromper o serviço!

49 Link Capacity Adjustment Scheme
LCAS Link Capacity Adjustment Scheme

50 Comunicação Fonte a Destino Comunicação Destino a Fonte
New Generation SDH LCAS – Link Capacity Adjustment Scheme - Padronizado pela ITU-T G.7042 - É uma forma de se ajustar a capacidade / largura de banda dinamicamente e sem interromper o serviço - Extensão para “Virtual Concatenation”, transmitido pelos bytes H4 e K4 (POH). Transparente no “Core” da rede. - Protocolo LCAS atua nos NE das pontas (edge NEs) em uma forma de “handshaking” ponta-a-ponta e em tempo real Comunicação Fonte a Destino MFI SQ CTRL GID CRC Fonte Destino Comunicação Destino a Fonte MST RS-Ack

51 VC & LCAS Control Packet
New Generation SDH LCAS – Link Capacity Adjustment Scheme VC & LCAS Control Packet Frame Counter MFI VCG Sequence Indicator SQ LCAS Control Commands CTRL LCAS Source Identifier GID LCAS Resequence Acknow-ledgement RS-Ack LCAS Member Status MST LCAS Error Protection CRC RS-ACK Virtual Concatenation Information LCAS Information Pacotes de Informação trocados pelos NEs das pontas para o ajuste de largura de banda

52 Multi-Frame Indicator é um contador
Direção da Informação Origem  Destino Multi-Frame Indicator é um contador para distinguir vários VCGs* uns dos outros necessário para compensar o Delay Diferencial MFI SQ Sequence Indicator é um contador para diferenciar cada container VC-n dentro do VCG* para re-ordenar os containers VC-n no ponto de chegada em caso de ocorrencia de delay diferencial RS-ACK CTRL LCAS “Control” são: palavras/comandos que mostram o status atual dos containers dentro de um VCG* e iniciam alterações de banda FIXED – container no modo NON-LCAS ADD - container que será adicionado ao um VCG REMOVE - container que será removido de um VCG NORM - container é parte de um VCG ativo EOS – último container de um VCG ativo DNU - container com falha (“do not use”)

53 LCAS – Link Capacity Adjustment Scheme
Direção da Informação Origem  Destino GID Group Identification Bit é um mecanismo adicional de verificação para assegurar que todos membros de um VCG fazem parte do mesmo grupo RS-Ack Re-sequence acknowledgement é um mecanismo no qual o destino reporta à origem a deteção de qualquer adição/remoção a/de um VCG RS-ACK MST Member Status Field é um mecanismo, no qual o destino reporta à origem quais membros de um VCG estão sendo recebidos corretamente CRC Cyclic Redundancy Check é um mecanismo de proteção para deteção de erros de bit nos pacotes de controle.

54 Link Capacity Adjustment Scheme
1 2 3 4 2.5M VC-12-5v 5M 7.5M 10M t 1 2 3 4 2.5M Ethernet 5M 7.5M 10M t 1 2 3 4 2.5M Ethernet VC-12-5v VC-12-4v VC-12-2v Alocação Automática de Banda: Automaticamente, VCs pré-provisionados serão ativados Cliente não paga pela capacidade não utilizada do link

55 Agradecimentos Prof. MSc. Bruno de Oliveira Monteiro bruno@inatel.br
cel.: (35) (35) INATEL Competence Center Av. João de Camargo, 510 Santa Rita do Sapucai - MG Tel: (35)

56 INATEL Competence Center Santa Rita do Sapucai - MG
Tecnologia NG-SDH INATEL Competence Center Av. João de Camargo, 510 Santa Rita do Sapucai - MG Tel: (35)