De forma bem ampla, uma conexão de transporte tem por objetivos trocar dados entre as entidades pares, prestando serviços aos seus usuários. Permite que cada usuário verifique a disponibilidade do usuário parceiro, podendo negociar parâmetros opcionais da conexão e realizar a alocação dos recursos necessários à comunicação entre tais usuários.
No modo orientado à conexão, cada conexão é vista como um par de filas interconectando dois (2) TSAP. Existe uma fila para cada direção do fluxo.
Para o estabelecimento de uma conexão de transporte, um usuário de transporte solicita o estabelecimento de uma conexão de transporte através da primitivaT-CONNECT-request, gerando uma TPDU-CR com alguns parâmetros como os que segue:
- endereço chamador (TSAP);
- proposta de classe a ser usada;
- crédito para o controle de fluxo (tamanho da janela) e
- tipo de numeracão (normal ou estendida).
Pode conter outros parâmetros que estão na parte variável da TPDU, tais como:
- throughput;
- taxa de erro residual e
- atraso de trânsito;
- utilização dos serviços de dados expressos e de reconhecimento da camada de rede (para a classe1);
- utilização de soma verificadora (para a classe 4);
- especificação de tempo máximo de reconhecimento das TPDU-DT (classe 4);
- tempo máximo para a realização de reassociação da conexão de transporte após falha da conexão de rede (para as classes 1 e 3).
No caso específico da classe 4, este mecanismo apenas de pedido e confirmação não é o suficiente, deve-se realizar a confirmação da confirmação. Essa última confirmação pode ser feita através de uma TPDU-DT como mostra o exemplo abaixo. Esse macanismo é conhecido como three-way handshake.
A TPDU-CR envia o pedido de conexão junto com os parâmetros desejados e seus valores mínimos aceitáveis, enquanto que a TPDU-CC envia a confirmação do pedido junto com os valores escolhidos (entre aqueles sugeridos anteriormente pela primeira).
Para a escolha da classe do protocolo são propostas duas classes: a preferencial e a alternativa. A tabela abaixo resume as possíveis sugestões de classes preferenciais e alternativas com as devidas possibilidades de escolha pela entidade remota - de acordo com a proposta feita.
Trocadas as TPDU e terminado os ajustes necessários a conexão esta estabelecida. Contudo, nem sempre tudo sai como o esperado. Imagine que a entidade remota não é capaz de suportar a qualidade de serviço proposta no pedido de conexão. Sendo assim, a entidade de transporte remota nem repassa o pedido de conexão para o seu usuário, ela mesma envia uma TPDU-DR (TPDU-disconect_request). A entidade local receberá a TPDU-DR e enviará para o seu usuário uma T-DISCONNECT-indication e para a entidade de transporte remota uma TPDU-DC (TPDU-disconnect_confirmation).
Pode ocorrer também a situação em que o usuário de transporte remoto não aceita a conexão, enviando uma T-DISCONECT-request, desencadeando uma seqüência de ações semelhante a anterior, como exemplificado abaixo:
