É o mais lento acesso a Renpac, pois prevê a ligação do usuário aos nos de rede via telex, cuja velocidade de transmissão e de apenas 50 bauds por segundo - também com o protocolo X.28. Apesar da lentidão na transmissão dos dados, esse tipo de acesso não deve ser desprezado, pois o parque da rede nacional de telex e o segundo maior do pais, com aproximadamente 130 mil terminais: só perde para a planta telefônica básica, com seus 10 milhões de terminais.

4 Protocolo X.25

Para comunicação de dados, Protocolo é um conjunto de regras que tem como propósito assegurar o completo e correto entendimento entre todos os dispositivos e sistemas envolvido na comunicação. Essas regras cobrem uma larga faixa de requisitos de comunicação, desde os sinais elétricos transmitidos e procedimentos de detecção e correção de erros, até a aplicação em si. No campo de protocolos, o ITU-T adotou como padrão modelo OSI-OPEN SYSTEM INTERCONECT, em que o protocolo X.25 é aderente como protocolo de Rede Pública de Comutação de Pacotes.

O protocolo X.25 está aderente as três primeiras camadas do modelo OSI, definindo um conjunto de regras para comunicação entre terminais e Rede Pública, estabelecimento de chamada, transmissão de dados, desconexão de chamada e controle de transmissão e do fluxo de dados.

O protocolo X.25 é um protocolo síncrono, full-duplex, especificado em três níveis distintos e independentes de controle. Esses níveis são: Nível Físico, Nível de Quadros e Nível de Pacotes.

4.1 Nível Físico

O nível físico define as características elétricas da interface do Terminal e Rede. O padrão adotado é a interface serial RS-232C, conforme definido pela EIA e adotado internacionalmente pelo ITU-T como V.24. Para velocidade de acesso iguais ou superiores a 64 Kbps, a interface utilizada é a V.36.

4.2 Nível de Quadros

O nível de Quadros define o protocolo de linha usado para inicializar, verificar e controlar a transmissão dos dados na ligação física entre o Terminal e a Rede. Este nível é o responsável pela troca eficiente de dados entre Terminal e Rede, pelo sincronismo da ligação, detecção e correção de erros através de retransmissões, identificação e informação de procedimentos de erro para o nível superior de pacotes para recuperação.

4.3 Nível de Pacotes

O nível de pacotes define como as chamadas são estabelecidas, mantidas e terminadas, e como os dados e informações de controle são formatadas em pacotes. Não existe limite de comprimento de mensagens na RENPAC, porém o tamanho máximo de pacote é de 512 bytes, sendo que o tamanho default é de 128 bytes. As mensagens são portanto divididas em tantos pacotes quantos necessários na transmissão. O conteúdo dos pacotes é transparente para a Rede, sendo que cada pacote possui um cabeçalho com informações de controle e endereçamento para seu correto encaminhamento na Rede.

Este nível é o responsável pelo estabelecimento dos canais lógicos sobre um único acesso físico. O número de canais lógicos correspondem ao número de ligações simultâneas que podem ser realizadas em um acesso físico a Rede. O número máximo de canais lógicos por acesso a RENPAC é de 250. Quando uma chamada é estabelecida entre dois terminais, a combinação de seus canais lógicos e os recursos de Rede associados, é denominada de circuito virtual.

Existem dois tipos de circuitos virtuais na RENPAC: Circuito Virtual Comutado(CVC) e Circuito Virtual Permanente (CVP). O CVC é uma associação temporária entre dois terminais ligados a Rede, e tem início com um deles enviando um pacote de "Call Request" indicando o endereço de destino, sendo utilizado um canal lógico disponível em cada acesso. O CVP é uma associação permanente entre dois terminais ligados a Rede. Cada um deles possui um canal lógico pré-definido para o circuito permanente e as informações para a conexão residem na Rede. Um CVP é estabelecido assim que o usuário liga seus equipamentos , eliminando os procedimentos de chamada e desconexão pelo usuário.

4.4 Benefícios do X.25

Sendo o X.25 um padrão internacional, está aderente às tendências e requisitos do mercado de comunicação de dados com constantes aperfeiçoamentos em novas versões. O X.25 tem aceitação internacional demonstrada pelo número de Redes com as quais a RENPAC encontra-se interligada através do serviço INTERDATA. Investimentos a nível mundial desse porte tem assegurada uma longevidade tecnológica.

5 Comunicação em X.25

5.1 Sincronismo:

Para transmissão de dados através de uma ligação, é necessário que haja sincronismo entre os pontos interligados. Isto é feito através de cabeçalhos, constituídos por um conjunto padronizado de bits (01111110) denominados "flags", que delimitam o início e fim de cada quadro.

5.2 Tipos de Quadros

Existem três tipos de quadros no protocolo X.25:

5.3 Controle da Ligação

Para controle da ligação são utilizados, pelo Terminal e pela Rede, dois octetos (16 bits) denominados "Endereço do Nível de Quadros" e "Campo de Controle", que identificam o tipo de quadro, seu número seqüencial e endereço. Esses dados asseguram uma ligação sem erros.

5.4 Detecção de Erro e Procedimentos de Recuperação:

Existem três mecanismos de proteção para detecção de erros de transmissão ocorridos nas linhas de acesso e na Rede. O primeiro ocorre entre o Terminal e a Rede para assegurar que a Rede recebeu corretamente os dados transmitidos pelo Terminal. Nesse caso, utiliza-se o Cyclic Redundacy Check – CRC, calculado para cada quadro e anexado a eles como bytes de verificação de seqüência de quadro (Frame Check Sequence). O CRC é recalculado pela outra extremidade e comparado com os bytes de FCS enviados. Se o resultado for igual, o quadro é aceito como sem erro; caso contrário, o quadro será descartado e ocorrerá uma retransmissão.

Para proteção contra erros internos da Rede, um byte de redundância longitudinal (Longitudinal Redundacy – LRC) é acrescentado em cada pacote que está sendo processado e é verificado pelo nó da Rede gerador e por cada um dos nós intermediários até chegar ao destino.

Entre quaisquer dois elementos de comutação da Rede, dois bytes de CRC são gerados e verificados para detecção de erros de transmissão. Se ocorrerem erros de CRC, será requerida a retransmissão. Uma numeração seqüencial fim a fim permite que os pacotes fora de ordem ou perdidos sejam detectados.

5.5 Tipos de Pacotes

Vários tipos de pacotes são usados para estabelecer chamadas, controle de fluxo de dados e término de chamadas.

- Pacotes de "Call Request" e "Incoming Call"

Utilizados para estabelecer um circuito virtual. O Terminal envia um pacote de "Call Request" e o destinatário recebe um pacote de "Incoming Call". Não há diferença no formato desses pacotes, mas a Rede pode acrescentar informações sobre a chamada no "Incoming Call".

- Pacotes de "Call Accept" e "Call Connect"

Utilizados para especificar a aceitação de um "Call Request". O receptor envia um "Call Accept" e o emissor recebe um "Call Connect". Novamente, não há diferença entre os pacotes, mas a Rede pode adicionar informações sobre a chamada no pacote de "Call Connect". Esses pacotes também podem conter códigos de facilidades indicando valores de facilidades opcionais requeridas pelo Terminal emissor e/ou Rede.

- Pacotes de "Clear Request" e "Clear Indication"

Utilizados para se desconectar um circuito virtual. Podem ser usados para recusar uma chamada em resposta a um "Call Request". O "Clear Request" é enviado pelo Terminal que deseja a desconexão e o "Clear Indication" é recebido pelo outro.

- Pacote de "Clear Confirmation"

Utilizado para confirmar a recepção do pacote de "Clear Indication".

- Pacotes de Dados

Contêm os dados do usuário e levam o "número de seqüência de envio", usado para assegurar que os pacotes estão sendo enviados e recebidos na ordem certa.

- Pacote de "Receive Ready"

Usado pelo Terminal ou pela Rede para indicar a disponibilidade de receber mais pacotes de dados, ele contém o número de seqüência do próximo pacote de dados esperado.

- Pacote de "Receive Not Ready"

Usado pelo Terminal ou pela Rede para indicar a indisponibilidade temporária para receber mais pacotes de dados

- Pacotes de "Reset", "Reset Indication" e "Reset Confirmation"

Os pacotes de "Reset" e "Reset Indication" zeram o número de seqüência para um canal lógico específico e são usados para indicar que pacotes de dados devem ser retransmitidos. Tanto a Rede como o Terminal pode enviar estes pacotes. O "Reset" é enviado pelo emissor e o "Reset Indication" é recebido pelo destinatário. O "Reset Confirmation" é a confirmação do recebimento de um "Reset Indication", até que este pacote seja enviado, todos os pacotes de dados enviados serão descartados.

- Pacotes de "Restart", "Restart Indication" e "Restart Confirmation"

Os pacotes de "Restart" e "Restart Indication" são utilizados para inicializar ou reinicializar o nível de pacotes. Todos os circuitos virtuais serão desconectados. Tanto a Rede quanto o Terminal podem enviar esses pacotes. O "Restart" é enviado pelo emissor e o "Restart Indication" transmitido para o receptor. O "Restart Confirmation" é enviado como uma confirmação de recebimento de "Restart Indication".

- Pacote de "Interrupção"

Utilizados para permitir ao Terminal local enviar dados ao Terminal Remoto sem procedimentos de controle de fluxo.

- Pacote de "Diagnóstico"

Usado pela Rede para indicar um erro no nível de pacotes não associado com um canal lógico particular

5.6 Estabelecendo um Circuito Virtual Comutado

- Tempo de Estabelecimento da Chamada

É o intervalo de tempo entre a solicitação e completação de uma chamada, incluindo os retardos da linha de acesso da origem e do destino, o tempo de resposta do Terminal chamado e o retardo interno da Rede. O retardo interno máximo da Renpac é de 250 milisegundos.

- Estabelecendo uma Chamada

Um Terminal inicia um circuito virtual comutado enviando um "Call Request" para a Rede. O pacote contém o endereço da Rede do Terminal chamado, um campo de facilidades e o número do canal lógico escolhido pelo Terminal, que será usado para identificar todos os pacotes associados a essa chamada.

O Terminal selecionará o canal lógico disponível de número mais alto para realizar a chamada, enquanto a Rede selecionará o canal lógico disponível de número mais baixo para uma chamada entrante para o Terminal. Esse procedimento reduz a possibilidade de colisão de chamadas entrantes e saintes no mesmo canal lógico. Na hipótese de ocorrência de uma eventual colisão, a chamada sainte terá prioridade e a chamada entrante será desconectada.

O campo de facilidades estará presente apenas quando o Terminal deseja utilizar uma facilidade opcional de usuário, devendo indicar nesse campo os seus códigos. Tarifação Reversa, Classe de Tráfego e Grupo Fechado são algumas facilidades opcionais que podem ser especificadas nesse campo.

O Terminal chamado recebe um pacote de "Incoming Call" da Rede. Se o Terminal chamado quiser aceitar a chamada, ele enviará um pacote de "Call Accept" para a Rede que por sua vez enviará um pacote de "Call Connect" para o Terminal chamador. Alternativamente, o Terminal chamado poderá retornar um pacote de "Clear Request" para recusar a chamada.

- Desconectando uma Chamada

Caso a chamada não possa ser estabelecida, o Terminal emissor receberá um pacote de "Clear Indication" indicando a causa. Um pacote de "Clear Confirmation" é enviado pelo Terminal emissor para confirmar a não conexão daquela tentativa de chamada. A Rede também poderá enviar um pacote de "Clear Request" se a chamada está sendo estabelecida com facilidades ou valores de facilidades inválidas, formato incorreto ou por tentativa de violação de alguma opção de bloqueio de chamada existente. Se o Terminal chamado deseja recusar a chamada ou se deseja desconectar após troca de dados, um pacote de "Clear Request" deverá ser enviado.

- Transferência de Dados

A transferência de dados só pode ocorrer após o circuito virtual ter sido estabelecido. Cada pacote recebido ou transferido por um terminal em um circuito virtual é numerado seqüencialmente de zero a sete. O número de seqüência associado a cada pacote de dados é um recurso usado para manter a integridade da transferência de pacotes de dados em um circuito virtual. Esse procedimento permite tanto à Rede quanto ao Terminal detectar a perda de pacotes de dados bem como controlar o fluxo desses pacotes entre dados e Terminal. Podem ser usados pacotes com 64, 128, 256 e 512 octetos. Se um terminal deseja autorizar a transmissão de um ou mais pacotes de dados, mas não existe fluxo de dados no sentido contrário para mandar essa informação, ele pode transmitir um pacote de "Receive Ready". Um Terminal pode também indicar que recebeu um ou mais pacotes mas não deseja receber mais nada em um canal lógico, transmitindo um pacote "Receive Not Ready".

Quando um Terminal deseja transmitir um bloco grande de dados que não pode ser enviado num único pacote, ele indica a continuação lógica dos dados em pacotes adicionais de dados em um circuito virtual, ligando um bit especial chamado BIT M (More Data Bit) em todos os pacotes exceto no último da seqüência. Normalmente o BIT M só é ligado quando o pacote de dados está cheio.

5.7 Estabelecendo um Circuito Virtual Permanente

- Definindo a chamada

Para definir a chamada, o usuário deverá fornecer informações a respeito de cada terminação da chamada. Essas informações são configuradas na Rede para permitir a associação lógica entre os dois Terminais. As informações mínimas necessárias para cada CVP são:

Parâmetros de controle de fluxo, tamanho de pacote, tamanho de janela e classe de vazão também podem ser definidos na chamada de um Circuito Virtual Permanente.

- Estabelecimento da Chamada

Quando qualquer um dos Terminais é ligado, a interface Terminal/Rede no nível de quadros se torna operacional e a Rede enviará um pacote de "Reset Indication" para sinalizar ao Terminal que a Rede está operacional. O mesmo procedimento ocorrerá quando o Terminal remoto for ligado. Assim que a rede identificar que ambas as terminações do CVP estão ligadas, enviará para os dois um pacote de "Reset Indication" com diagnóstico de "Terminal Remoto Operacional" ou "Rede Operacional". Cada Terminal então envia um pacote de "Reset Confirmation" e podem a partir daí iniciar a transmissão de dados.

5.8 Controle de Fluxo

Controle de Fluxo significa regular a quantidade de informação que pode ser enviada para a Rede ou recebida dela pelo Terminal. Tanto a Rede quanto o Terminal devem assegurar que o lado transmissor não envie mais dados do que o receptor possa receber. É exercido tanto pela Rede quanto pelo Terminal e diz a quem está transmitindo para parar até que receba uma mensagem para continuar a transmissão.

5.9 Procedimentos de Recuperação de Erros

Os dois mecanismos principais de recuperação de erros no nível de pacote do X.25 são os procedimento de "Reset" e procedimento de "Restart".

5.9.1 Procedimentos de "Reset"

5.9.2 Procedimentos de "Restart"

Este procedimento proporciona uma forma da Rede recuperar falhas maiores, como desconexão do nível de quadros devido a falhas no Terminal, meio de transmissão ou Rede.

Um Terminal inicia um "Restart" enviando para a Rede um pacote de "Restart Request". O envio desse pacote é equivalente a enviar um "Clear Request" em todos os circuitos virtuais comutados e um "Reset Request" em todos os circuitos virtuais permanentes. Dessa forma o procedimento de "Restart" levará a interface Rede/Terminal para o estado de quando foi inicializado o nível de quadros. A rede também enviará um pacote de "Restart Indication" se o Terminal apresentar falha na seqüência correta do procedimento de "Restart".

5.10 Subendereçamento na Renpac

O endereço de Rede de um Terminal é usado para identificação de um acesso para efeito de encaminhamento de chamadas na rede. Normalmente os usuários possuem mais de um dispositivo associados a um único acesso a rede, como impressoras, redes locais, concentradores de Terminais, etc. Se o usuário desejar especificar um determinado dispositivo que esteja ligado a um acesso Renpac, poderá utilizar o chamado Subendereçamento. Outro uso do subendereçamento é na especificação de uma aplicação em particular residente em um Host do usuário, onde residem diversas aplicações. Em qualquer das duas utilizações, o que se deseja é passar alguma informação adicional além do endereço da Rede, ao Terminal de destino. Para isso, há duas possibilidades, através de subendereçamento e uma outra se utilizando de um campo de dados de usuário do pacote de "Call Request".

- Endereço Extendido (X.25 versão 84)

A versão 84 do protocolo X.25 possui duas facilidades que possibilitam o subendereçamento. Essas facilidades são chamadas de "Extensão de Endereço Chamado" e "Extensão de Endereço do Chamador". Cada uma delas possibilita a utilização de 40 dígitos para especificar um endereço. Com um total de 10 elevado a 40 endereços, essa facilidade é uma poderosa ferramenta na customização de um plano de numeração de rede de usuário. Essas facilidades são disponíveis nos pacotes "Call Request" e "Call Accept" dependendo do suporte do fornecedor do equipamento do usuário.

- 9º, 10º e 11º Dígitos de Endereço de Rede Nacional (Subendereço)

A Renpac oferece a possibilidade de transportar endereços de Rede com 11 dígitos. Apenas 8 dígitos são utilizados para encaminhamento na rede, enquanto que o 9º, o 10º e 11º são passados transparentemente pela rede para o Terminal. Isso possibilita especificar até 1000 subendereços. Esses dígitos podem ser especificados nos campos de endereço do chamado e do chamador para chamadas entrantes e saintes. O Terminal de destino (versão 80 ou 84 do X.25) pode acrescentar ou alterar os dígitos de subendereço no campo de "Endereço Chamado" nos pacotes de "Call Accept" ou "Call Request".

- Campo de Dados do Usuário

O Campo de Dados do Usuário, é um dos campos de facilidades do pacote de chamadas e possibilita ao usuário enviar até 16 octetos que podem ser usados para subendereçamento. A desvantagem dessa forma de subendereçamento é a posição desse campo após as facilidades do pacote de "Call Request", tornando menos eficiente para implementação pelos usuários. É aplicável apenas no pacote de "Call Request" não estando presente no "Call Accept/ Call Connect" para verificação pelo Terminal chamador. Pode também ser utilizado para passagem de uma senha de sistema para o Host.

6 Facilidades

6.1 Introdução

Na contratação do serviço Renpac-3025 devem ser definidas pelo usuário as características do serviço, tais como velocidade e facilidades, além dos parâmetros específicos de configuração de uma ligação X.25 .

Para auxílio na seleção das facilidades do serviço que melhor atendam as necessidades do usuário, as facilidades foram agrupadas de acordo com suas aplicações mais conhecidas. Quando uma facilidade se destinar a mais de uma aplicação, ela aparecerá repetida nos diversos grupos a que pertença.

6.2 Capacidade de Chamada

Algumas facilidades podem ser utilizadas para restringir a capacidade de chamada do acesso Renpac, encaminhar chamadas diretamente a aplicações ou periféricos do usuário ou para simplificar o estabelecimento da chamada para o usuário.

6.2.1 Circuito Virtual Comutado (CVC)

São canais lógicos que podem ser utilizados para estabelecer chamadas comutadas com qualquer outro Terminal de Rede, não existindo uma associação permanente entre origem e destino. São disponíveis três tipos de CVC:

- Circuito Virtual Unidirecional Entrante (CVE)

São canais lógicos reservados exclusivamente para chamadas entrantes no Terminal do usuário. Isto assegura que o canal lógico nunca estará ocupado com chamadas saintes. Este tipo de canal lógico pode ser apropriado para um periférico apenas receptor, como uma impressora, por exemplo. Se o usuário solicitar um mix de canais lógicos unidirecionais e bidirecionais, ele pode reservar grupos de canais lógicos para diferentes aplicações solicitadas pelo seu Host. Possuir CVE´s equivale a ter chamadas saintes bloqueadas para um número específico de canais lógicos.

- Circuito Virtual Unidirecional Sainte (CVS)

São canais lógicos reservados exclusivamente para chamadas saintes do DTE. Isto assegura que o canal lógico nunca estará ocupado com chamadas entrantes, aumentando a possibilidades de um circuito estar disponível para uma chamada sainte. Esta facilidade pode ser utilizada para atender a equipamentos como concentradores, onde todos os usuários estão fazendo digitação para um arquivo central residente num Host. Possuir CVS´s equivale a ter chamadas entrantes bloqueadas para um número específico de canais lógicos.

- Circuito Virtual Bidirecional (CVC)

São canais lógicos bidirecionais, o que significa que podem ser usados tanto para chamadas entrantes quanto saintes. Para evitar colisões de chamadas, as chamadas entrantes da rede iniciam no mais baixo canal lógico disponível, enquanto as chamadas saintes do DTE começam no mais alto canal lógico disponível até que todos os canais lógicos estejam em uso. Esse tipo de circuito virtual é o mais versátil para múltiplas aplicações.

6.2.2 Circuito Virtual Permanente (CVP)

São canais lógicos bidirecionais, no entanto a destinação de cada um deles deve ser designada antecipadamente e tem caráter permanente, ou seja, o canal lógico só pode ser utilizado para comunicação com a destinação designada. O CVP é o tipo de circuito virtual mais limitado para o usuário, pois permite comunicação apenas com um destino. Basta ao usuário ligar seu equipamento que a conexão é estabelecida automaticamente pela rede, como se fosse uma linha privativa.

6.2.3 Estabelecimento de Faixas de Canal Lógico

6.2.4 Chamada Direta

Essa facilidade possibilita programar previamente na rede, um endereço de destino e facilidades a serem utilizadas na chamada (quando não forem fornecidos pelo DTE no pacote de chamada) e esta se realizar num canal lógico pré-determinado. Isto significa para o usuário o procedimento de chamada e, diferentemente do CVP, o canal lógico pode ser utilizado normalmente para realizar chamadas para outros destinos e não exige que o terminal de destino tenha um canal lógico pré-determinado para essa comunicação. Para ser utilizada, a Chamada Direta deve ser solicitada para utilização em CVS´s. Estes são mais indicados que os CVC´s para evitar que o canal lógico seja utilizado por uma chamada entrante tornando-o indisponível para a Chamada Direta.

6.2.5 Fast Select

Consiste na realização de uma chamada onde todos os dados que se deseja transferir estão no próprio pacote de "Call Request" e no de "Clear Indication". Existem duas modalidades de "Fast Select":

- Fast Select sem restrição:

Nessa modalidade, o terminal que solicitou a facilidade envia até 128 octetos no pacote de "Call Request". Como resposta, pode receber um "Call Connect" ou "Clear Indication" com 128 octetos.

- Fast Select com restrição

Nessa modalidade, o terminal que solicitou a facilidade envia até 128 octetos no pacote de "Call Request". Como resposta só poderá receber um pacote de "Clear Indication" com até 128 octetos

A facilidade "Fast Select" se aplica somente a transações curtas e normalmente padronizadas que não necessitam obrigatoriamente de estabelecimento da chamada, transferindo todos os dados nos pacotes de chamada e desconexão.

6.3 Facilidades de Operação

6.3.1 Detecção de Falha

Esta facilidade oferece ao usuário a possibilidade da Rede monitorar determinados terminais para detectar uma falha o mais cedo possível. A detecção é feita pela Rede enviando ao terminal um pacote de "Clear Indication" e o terminal respondendo com "Clear Confirmation" a cada período de tempo especificado na negociação da facilidade. Se o terminal não responder com "Clear Confirmation", então o nível de enlace será desconectado e reinicializado seguindo-se de solicitação de reinicialização do nível de pacote. Isto resulta em chamadas a serem desconectadas e CVP´s a receber "Reset" com o código da causa do problema.

Um exemplo de aplicação seria o caso de um terminal após o estabelecimento de uma chamada para um Host e iniciar uma transação, apresentar uma falha. O Host não tem nenhuma indicação da falha. Com a facilidade de Detecção de Falha, o acesso do terminal seria desconectado quando detectada a falha pela Rede e o Host seria alertado na tentativa de estabelecimento da chamada ou pela desconexão dela. Para o caso de CVP´s, o alerta seria através de um "Reset" com o código do problema.

Para a utilização da facilidade, é preciso que o terminal que esteja sendo monitorado possua sempre um canal lógico disponível para a troca de pacotes "Clear Indication" e "Clear Confirmation".

6.3.2 Pacote de Diagnóstico

O pacote de Diagnóstico pode ser usado como uma ferramenta de gerência de rede, nas situações em que problemas são identificados, mas não são sérios o suficiente para justificar a desconexão da chamada ou o "Reset" do circuito virtual. O terminal do usuário poderá se utilizar dessa informação para análise do problema e iniciar procedimentos de recuperação.

Um exemplo do tipo de problema que pode ocorrer que se enquadre nesse caso seria o esgotamento da temporização de pacotes. Se o terminal deixa de responder certos pacotes (Call, Clear, Reset, Restart) dentro de um período de tempo pré-determinado, a Rede enviará um pacote de Diagnóstico avisando ao terminal que ocorreu um fim de temporização de pacotes.

O pacote de Diagnóstico também é utilizado para notificar ao terminal que ele enviou um pacote com um número de canal lógico não contratado. Isto pode significar que o terminal esgotou todos os seus canais lógicos e, portanto, canais lógicos adicionais deverão ser contratados caso isso venha a ocorrer com freqüência.

O pacote de diagnóstico tem apenas significado local. Ele é transmitido da rede para o terminal no canal lógico zero, podendo transportar informação de erro de qualquer dos canais lógicos do acesso. Este pacote é considerado irrecuperável e por isso não existe confirmação de recebimento.

6.3.3 Tamanho de Pacote

É definido na contratação do serviço. Os tamanhos de pacotes suportados pela Renpac são: 64, 128, 256 e 512 bytes, sendo que 128 é o tamanho default. O tamanho de pacote pode ser alterado para atender limitação de algum equipamento ou para se adequar à aplicação. Por exemplo, transações curtas requerem pacotes menores, enquanto que uma transferência de arquivo torna-se mais eficiente com tamanhos de pacotes maiores.

Obs.: Tamanhos de pacotes iguais a 512 bytes, só poderão ser utilizados em acessos com velocidade de 9600 BPS ou maiores, e o terminal do usuário deve estar apto a negociar para tamanho de pacotes menores, tamanho de janela e classe de vazão baseado nos valores dos pacotes de "Incoming Call" ou "Call Connect".

6.3.4 Negociação de Tamanho de Pacote

O protocolo X.25 permite que o tamanho de pacote e classe de tráfego sejam determinados para cada circuito virtual comutado do acesso, devendo o terminal indicar o código da facilidade e o valor do parâmetro no estabelecimento da chamada. Se o usuário desejar estabelecer o tamanho do pacote e a classe de tráfego a cada chamada, deverá indicar ,na contratação do serviço Renpac-3025, que o terminal utilizará negociação de tamanho de pacote. Na contratação da facilidade, deverá ser informado qual o tamanho de pacote default do terminal. Quando houver negociação na chamada, poderão ser estabelecidos tamanhos de pacotes maiores ou menores que o default.

Para terminais com versão 84 do protocolo X.25, espera-se que tratem negociação do tamanho de pacote e a Renpac assumirá como default a facilidade que está sendo utilizada. Para os circuitos virtuais permanentes do acesso, essa facilidade não se aplica, devendo ambas as terminações do CVP possuir o mesmo tamanho de pacote especificado na contratação do serviço.

6.3.5 Classe de Vazão (Throughput)

6.3.6 Negociação de Classe de Vazão

A classe de vazão default do acesso será utilizada pela rede em todas as chamadas virtuais entrantes ou saintes, a menos que o terminal negocie um valor no estabelecimento da chamada, através de circuitos virtuais comutados. Terminais que na subscrição tenham definido que a versão de protocolo X.25 utilizada é a 80, podem ou não ter a capacidade de fazer negociação e será assumido como condição default a não negociação. Caso o terminal tenha capacidade de negociação, deverá ser explicitado na subscrição do serviço.

Para o caso de terminais que operem com versão 84 do protocolo X.25, é esperado que façam negociação e, portanto será assumida como condição default a negociação. Na contratação do serviço deverá ser especificada a classe de vazão default a ser utilizada pelo terminal. Quando houver negociação na chamada, poderão ser estabelecidos valores maiores ou menores que o default.

Para os circuitos virtuais permanentes do acesso, essa facilidade não se aplica, devendo ambas as terminações do CVP ter o mesmo valor para classe de vazão, especificada na contratação do serviço.

6.3.7 Tamanho de Janela

Define a quantidade de pacote que podem ser transmitidos sem a espera de confirmação entre terminal do usuário e rede. O tamanho da janela default na Renpac é dois. Isto significa que o terminal pode enviar dois pacotes para a rede e depois deverá parar aguardando confirmação de recebimento da rede. A confirmação de recebimento permite ao terminal o envio de mais dois pacotes. O mesmo processo se aplica no sentido inverso. Caso o terminal envie mais dois pacotes sem aguardar confirmação, a rede enviará um Reset com o código da causa do problema. Tamanhos de janela maiores poderão ser adotados, sendo necessário explicitar na subscrição do serviço.

6.3.8 Negociação do Tamanho de Janela

Permite determinar o tamanho de janela no estabelecimentos da chamada, através de circuitos virtuais comutados, da mesma forma que a classe de vazão, permitindo a adoção de um valor diferente da subscrição. Na contratação do serviço, deverá ser especificado o tamanho da janela default a ser utilizado pelo terminal. Quando houver negociação na chamada, poderão ser estabelecidos valores maiores ou menores que o default. Terminais que tenham definido na subscrição que a versão de protocolo X.25 utilizada é a 80, podem ou não ter a capacidade de negociação e será assumido como default a condição de negociação. Terminais que operem com a versão 84 do protocolo X.25, é esperado que façam negociação e portanto será assumida como default essa condição. Para os circuitos virtuais permanentes do acesso, essa facilidade não se aplica, devendo ambas as terminações de CVP ter o mesmo tamanho de janela especificado na contratação do serviço.

6.3.9 Relação Classe de Vazão e Tamanho de Janela

Classe de Vazão e Tamanho de Janela devem ser considerados conjuntamente para o estabelecimento de um controle de fluxo fim a fim. Não será possível adotar tamanhos de janela superiores aos internos da rede, que são definidos dependendo da classe de vazão e tamanho de pacote adotados, conforme tabela a seguir:

A negociação de classe de vazão e tamanho de janela são particularmente úteis na alocação de recursos da rede e do equipamento do usuário. Todos os acessos do usuário a rede são compartilhados por diversos circuitos virtuais e dependendo da aplicação cursada por cada um desses circuitos, pode se desejar atribuir diferentes classes de vazão e tamanho de janela para privilegiar algumas aplicações mais críticas em termos de tempo de resposta, alocando maiores recursos para elas através de valores lasse de vazão mais altos e por conseguinte possibilitando o aumento do tamanho de janela.

Para contratação do serviço em altas velocidades ou com tamanho de pacote igual a 512 bytes (só disponível para velocidades de acesso a partir de 9600 BPS), é obrigatória a subscrição das facilidades de negociação de classe de vazão e tamanho de janela, permitindo que a rede estabeleça valores menores durante o estabelecimento da chamada, caso contrário o terminal receberá um "Reset".

6.3 Facilidade de Tarifação

6.3.1 Aceitação de Tarifação Reversa

Essa facilidade permite que o terminal seja responsável pela tarifação da chamada, quando a chamada a ela destinada contiver pedido de tarifação reversa.

6.4 Facilidade de Segurança

6.4.1 Grupo Fechado de Assinantes

É a facilidade de segurança que permite ao usuário definir um grupo de terminais que se comunica exclusivamente entre si, negando acesso de/para os terminais da Rede. Esta facilidade oferece alto nível de segurança para aquelas redes que lidam com informações de caráter restrito, ou redes de uma comunidade de interesse comum. Uma vez o usuário tendo contratado a facilidade de Grupo Fechado de Assinantes (GFA), este recebe um único número para o seu GFAA. Esse número é relacionado a cada terminal que se deseja que faça parte do Grupo. O número do GFA é configurado na Rede cm as opções que definem a acessibilidade de/para toda a Rede e os outros acessos pertencentes ao GFA. Assim a Rede vai permitir o estabelecimento ou bloquear chamadas baseadas nestas opções.

6.4.2 Múltiplos GFA'S

Um único terminal de Rede pode pertencer a diferentes GFA's , até um máximo de 10. Esta facilidade é útil nos casos em que o terminal atende a mais de um Departamento, ou Filial de uma empresa com diferentes grupos de interesse de tráfego de dados. Para se obter acesso a um GFA, é necessário uma carta de autorização do contratante do GFA, concedendo permissão de inclusão e definindo as características do acesso. Qualquer alteração nas características do acesso também precisará ser autorizada pelo contratante do GFA. No caso de múltiplos GFA'S, precisa ser definido tanto para a rede como para o Terminal a seqüência dos GFA'S . Os GFA'S possuem números índices que possibilitam o cruzamento com o número do GFA através de uma tabela de referência existente na rede. Quando um terminal faz uma chamada, ele identifica o GFA desejado utilizando o número índice. A Rede traduz o número índice no número do GFA e encaminha a chamada para o terminal de destino com o número índice por ele definido. Desta forma os números do GFA são transparentes aos usuários finais.

7 Interconexão com Outros Serviços: Utilização do Serviço Renpac 3025

Utilizado usualmente para a ligação de Host´s a Renpac nas redes de usuários. O lado do terminal, dependendo do protocolo utilizado pelos terminais, é normalmente atendido via Renpac 3028, Renpac 2028 ou através de PAD´s externos, se os terminais forem assíncronos tipo TTY. Caso os terminais sejam microcomputadores, tanto são utilizados os serviços acima como também o próprio Renpac 3025 ou o Renpac 2032. Se forem terminais que se utilizem dos protocolos BSC3 ou SDLC, são utilizados os PAD´s BSC e SDLC da Renpac.

7.1 Interconexão com o Renpac 3028

O ITU-T tem três recomendações para o serviço assíncrono, que são a X.3, X.28 e X.29. O PAD assíncrono desempenha três principais funções além de empacotar e desempacotar informações:

7.2 Comandos e Mensagens X.29

O Host pode gerar os seguintes comandos:

O PAD pode gerar as seguintes mensagens:

Por que o controle pelo Host?

Se o Host está suportando múltiplas aplicações assíncronas, pode ser desejável que o Host envie um comando de configuração X.29 (SET) para assegurar que os parâmetros do PAD remoto estarão configurados corretamente. Por exemplo, se um terminal deseja fazer uma transferência de arquivos, o Host poderá se certificar que os parâmetros do PAD remoto estão configurados corretamente para essa aplicação enquanto que uma aplicação interativa deverá ter outro tipo de configuração. O Host assumindo a função de configurar corretamente os parâmetros do PAD remoto garante o controle da comunicação, principalmente quando não se tem gerência sobre todos os terminais com os quais haverá comunicação.

7.3 Interconexão com o Renpac 3030

O serviço Renpac 3030 suporta o protocolo SDLC de terminais IBM 3270 Full Screen. Para um Host IBM se ligar ao Renpac 3025, o Front End requer um software para permitir as translações apropriadas entre a saída de um terminal normal do Host IBM e o formato dos pacotes X.25 da Renpac, Esse software pode ser proprietário IBM-Network Control Program (NCP) e Network Packet Switching Interface (NPSI) ou de outro fornecedor com produto similar.

Para interconexão de um Host IBM ligado no Renpac 3025 ou 2032 e terminais ligados no PADSDLC, é necessário que o Host suporte também o protocolo QLLC (Qualified Logical Link Control). Para interconexão com terminais ligados no PAD SDLC, é necessário que o Host suporte também o protocolo DSP (Display System Protocol).

Se o Host estiver usando NPSI e os terminais estiverem utilizando o serviço Renpac 303 PAD SDLC, o tamanho de janela e de pacote podem ser os mesmos na transmissão e na recepção, A classe de vazão máxima do PAD SDLC é baseada na velocidade de linha, conforme descrito para o Renpac 3025 no capítulo de facilidades.

No acesso X.25 do Host, é recomendado que janelas e classe de vazão sejam configuradas com os valores 4 e 9 respectivamente, para minimizar retardos. Considerando que uma sessão SDLC típica consiste na entrada, pelo terminal, de 40 caracteres de dados e saída do Host de 800 a 1000 caracteres, o aumento do tamanho da janela e classe de vazão ajudam a prevenir problemas de apresentação de tela. Uma explicação simplificada disso seria dividir 1000 caracteres em 4 pacotes de 256 bytes, possibilitando a transmissão dos 4 pacotes sem confirmação de recebimento evitando retardo na apresentação da tela, o que ocorreria caso o tamanho de janela fosse menor e exigisse confirmação do recebimento dos dados antes da transmissão completa da tela.

Caso todos os canais lógicos sejam configuradas para o mesmo tamanho de janela e classe de vazão, efetivamente será dada uniformidade no tempo de resposta para todas as ligações. Contudo, se for desejado priorizar com mais recursos determinadas ligações, poderá ser feita negociação dos parâmetros tamanho de janela e classe de vazão, aumentando ou diminuindo seus valores para alocar mais ou menos recursos.

O NCP também pode ser configurado para otimizar o tamanho de pacote para controlar o número de pacotes necessários numa transmissão. Uma forma de se fazer isso é configurando o tamanho do buffer do NCP para 122. O default do fabricante é 128. O quadro SDLC/QLLC, requer 6 ou 9 caracteres que devem ser incluídos dentro do pacote. Considerando a utilização de 6 caracteres, somados com o buffer, teríamos 134 bytes a serem empacotados. Isso significa que serão necessários dois pacotes para enviar um quadro SDLC/QLLC. Contudo, se o buffer do BCP for configurado com 122 bytes, teríamos 128 bytes que cabem em um único pacote. Com esse ajuste, o número de pacotes transmitidos pode ser reduzido em até 50%.

8 Acesso Comutado X.32

O acesso comutado que a Renpac via Rede Pública de Telefonia para terminais que implementam o protocolo X.25 é denominado de Renpac 2032, estando aderente à recomendação X.32 do ITU-T versão 84. O serviço Renpac 2032 é prestado nas modalidades "Entrante" e "Sainte".

9 Conclusão
A RENPAC é a Rede Pública de Comunicação de Dados por Comutação de Pacotes operada pela EMBRATEL. É um serviço que provê comunicação de dados entre equipamentos de diferentes tipos, protocolos e velocidades (de 2.400 bits/s a 2 Mbits/s), possuindo cobertura nacional (1.500 localidades) e internacional (170 Redes em 70 países).
Permite a configuração de soluções corporativas em uma mesma Rede ou soluções que exijam comunicação entre Redes diferentes. A Rede segue a filosofia de estabelecimento de chamadas através da criação de circuitos virtuais entre os terminais assinantes. Esses circuitos virtuais possibilitam a comunicação de dados entre ambientes situados em qualquer ponto do país ou do mundo.
As características e facilidades dos serviços RENPAC-3025 e RENPAC-2032 foram mostradas com maior ênfase. O serviço RENPAC-3025 consiste em um acesso dedicado a RENPAC para equipamentos terminais que implementam o protocolo de comunicação X.25. O serviço RENPAC-2032 consiste no acesso comutado a RENPAC para equipamentos terminais que implementam o protocolo de comunicação X.25
Computadores em geral, controladoras de comunicação/terminais, terminais inteligentes e microcomputadores podem utilizar-se dos serviços RENPAC-3025 e RENPAC-2032 através de implementação interna do protocolo de comunicação X.25, ou através de conversores externos.
A ligação com a RENPAC através dos serviços 3025 e 2032 proporciona diversos benefícios aos usuários, destacando-se:
· Confiabilidade pela utilização do protocolo X.25, com controle e correção de erros no acesso a Rede;
· Otimização do acesso físico a Rede através de circuitos virtuais, possibilitando várias chamadas simultâneas num único acesso;
· Economia de interfaces de comunicação do equipamento do usuário pelo compartilhamento de vários circuitos virtuais
· Flexibilidade na comunicação com outros terminais ligados a Rede em diferentes velocidades e diferentes protocolos.

10 BIBLIOGRAFIA

· Comunicação de Dados - Descrição Funcional Renpac 3025 e 2032
Embratel,1999

· Kee, Eddie, Redes de Computadores Ilustrada
Rio de Janeiro, Axcel Books, 1995.

· Embratel
http://www.embratel.net.br,1999

· Zeve, Carlos, RENPAC
http://penta2.ufrgs.br/CarlosZeve/zeve.html,1999

· Tipos de Redes
http://penta.ufrgs.br/hometipo.html, 1999

· Bezerra, Eduardo Augusto, Renpac - Protocolo X.25
http://penta.ufrgs.br/Eduardo/renpac.html, 1999

· Cyclades
http://www.cyclades.com.br/suporte/pr3.html, 1999