Protocolo SCTP
Stream Control Transmission Protocol

Sumário

1. Introdução
1.1. Aplicabilidade
1.2. Streams TCP e SCTP
1.3. Requisitos para tolerância a falhas
1.4. Conceito de Associação
1.5. Overview
2. Pacotes SCTP
2.1. O Header Comum
2.2. Chunks
3. Estados SCTP
3.1. Estabelecimento Normal de uma Associação
3.2. Encerramento da Associação
4. Transmissão de dados SCTP
4.1. Conceitos Gerais
4.2. Controle de Fluxo
4.3. Confirmacão seletiva de recepção
4.4. Controle de fluxo e endpoints multi-home
4.5. Controle de congestionamento
4.6. Slow Start e Prevenção de Congestionamento
4.7. Descoberta do MTU de uma rota
5. Multi-homing no SCTP
5.1. Gerenciamento de endereços na configuração das associações
5.2. Monitoramento de rotas e de peers
5.3. Seleção de rota
6. Streams SCTP
6.1. Conceitos Gerais
6.2. Entrega flexível de datagramas
7. API para SCTP
7.1. API definida na RFC 2960
7.2. A biblioteca SCTP - Resumo
8. Terminologia
8.1. Definição de termos
8.2. Abreviaturas

1. Introdução

O protocolo SCTP é um protocolo de transporte confiável que opera sobre um serviço de pacotes não confiável e sem conexão, como é o caso do IP. O SCTP oferece a transferência de datagramas (mensagens) livre de erros e de duplicações através do reconhecimento de transmissões (ACKs). A detecção de corrupção, perda e duplicação de dados é obtida através de mecanismos de checksum e números sequenciais. Um mecanismo de retransmissão seletiva é usado para corrigir a perda ou a corrupção de dados.

1.1. Aplicabilidade

Originalmente, o SCTP foi projetado como um protocolo de transporte de uso geral para aplicações orientadas a mensagens. A definição do protocolo foi feita pelo grupo de trabalho SIGTRAN do IETF, que emitiu um documento de padronização do SCTP em outubro de 2000 (RFC2960). O projeto do protocolo inclui a prevenção de congestionamento e a resistência a ataques do tipo flooding (inundação de mensagens) e mascaramento (quando um sistema assume a identidade de outro).

Notar que, apesar do desenvolvimento do SCTP ter sido motivado pelas limitações do TCP em transportar sinalização PSTN sobre redes IP, outros tipos de aplicações poderão fazer bom uso de suas características.

A RFC2960 foi atualizada e gerou a RFC3309 (setembro de 2002). Essa atualização foi decorrente da substituição do uso do checksum do tipo Adler-32 por um CRC-32c. Isso foi necessário porque a detecção de erros do Adler-32 é pouco eficiente quanto se trata de pequenos pacotes.

Notar que a migração de um mecanismo para o outro não foi feito de forma gradual. Simplesmente foi definido o novo mecanismo e as novas implementações deveriam adequar-se a ele, imediatamente. O uso do mecanismo antigo é considerado desatualizado.

Em setembro de 2007 foi publicada a RFC4960, que substitui as RFC2960 e a RFC3309. A lista das alterações está registrada na RFC4460, publicada em abril de 2006.

Adicionalmente, outras RFCs auxiliam no uso e implementação do SCTP. São elas:

1.2. Streams TCP e SCTP

Apesar do TCP ter sido bastante usado para a transferência confiável de dados sobre redes IP, um número crescente de aplicações têm implementado seus próprios mecanismos para a transferência confiável de dados sobre o UDP.

Dentre as justificativas para esse comportamento podem ser citadas:

Assim, a principal diferença entre o SCTP e o TCP tem haver com o conceito de multi-homing e a capacidade de transportar vários streams em uma única conexão.

Cabe salientar a diferença entre a definição de stream TCP e SCTP. Um stream TCP corresponde a uma seqüência de bytes enquanto que um stream SCTP corresponde a uma seqüência de mensagens enviadas em uma associação SCTP.

1.3. Requisitos para tolerância a falhas

O SCTP pode ser usado como protocolo de transporte para aplicações onde é requisito o monitoramento e a detecção de queda das sessões. Para essas aplicações, o protocolo dispõe de um mecanismo de detecção de falhas de sessão, especialmente o heartbeat, que será usado para monitorar a conectividade da sessão.

1.4. Conceito de Associação

O protocolo SCTP estabelece o conceito de associação. Levando em consideração que uma determinada conexão pode transportar vários streams, a associação corresponde ao casamento de um stream com a sua conexão. Essa forma de transportar os streams não existe no TCP, por exemplo, pois o TCP só é capaz de transportar um único stream nas suas conexões.

Uma associação SCTP, portanto, corresponde a um serviço que está no mesmo nível de um serviço TCP ou UDP. Essa idéia pode ser vista no diagrama da figura abaixo, onde aparecem a aplicação, o serviço de transporte SCTP (na posição comumente ocupada pelo UDP e pelo TCP) e o serviço IP de transporte.


Figura : Camada de uma associação SCTP

1.5. Overview

A sessão "pacotes SCTP" explicará brevemente a estrutura dos pacotes SCTP quanto a sua forma, quando são enviados por um endpoint, assim com os diferentes tipos de dados que podem ser enviados.

A sessão dos "estados SCTP" detalha a forma como as associações são estabelecidas e encerradas, alguns cenários típicos de mensagens e a explicação dos estados dos respectivos endpoints.

Na sessão de "troca de dados SCTP" serão apresentas as regras para obter-se transmissão confiável, reconhecimento (ACK) seletivo e controle de fluxo e congestionamento. Então, será analisada a característica de multi-homing. Também são apresentados os requisitos e as implicações da RFC2960 e alguns exemplos serão apresentados.

Finalmente, na última sessão, será apresentado o conceito de stream SCTP em oposição ao byte stream TCP. Será apresentada a API, conforme descrito na RFC2960 e será explicada a terminologia geral do SCTP.

2. Pacotes SCTP

As PDUs do protocolo SCTP são chamadas de "pacotes SCTP". Se o SCTP estiver rodando sobre o IP (conforme descrito na RFC2960), os pacotes SCTP formam o payload dos pacotes IP.

Um pacote SCTP é composto por um header comum e chunks. Vários chunks podem ser multiplexados dentro de um pacote IP até que seja atingido o MTU. Um chunk pode conter informações de controle ou dados de usuário.

Pacote SCTP
Figura : Uma PDU SCTP com vários chunks.

2.1. O Header Comum

O header comum do SCTP é formado por 12 bytes.

Portas: para identificar uma associação, o SCTP utiliza o mesmo conceito de portas usado pelo TCP e UDP. Assim, no header aparecem os campos "porta origem" e "porta destino".

Tag de verificação: o header comum também contém um valor de 32 bits chamado de "tag de verificação" (verification tag). Esse valor é específico da associação e é trocado entre os endpoints no estabelecimento dessas associações. Dessa forma, uma associação é formada por dois desses valores, uma para cada direção da associação (ver "estados do SCTP" para detalhes desses tags).

Checksum: para a detecção de erros de transmissão, o header dos pacotes SCTP estão protegidos por um código de verificação. Esse código é calculado por um algoritmo de CRC32c.

2.2. Chunks

Type: cada chunk inicia com o campo de tipo que é usado para distinguir os diferentes tipos de chunks.

Flags: conjunto de flags usados para várias funcionalidades. Essas funcionalidades são dependentes do typi de chunk.

Length: campo que indica o tamanho do chunk, uma vez que podem ter tamanhos variados. Esse calor corresponde ao tamanho do payload (User Data) do chunk.

User Data: é o payload do chunk. O conteúdo desse campo depende do tipo do chunk.

Até o presente momento estão padronizados 13 tipos diferentes de chunks. Esses tipos estão listados aqui, da mesma forma que na RFC2960.

Identificador Tipo do chunk
0 DATA (payload de dados)
1 INIT (Inicialização)
2 INIT-ACK (Ack de inicialização)
3 SACK (Ack seletivo)
4 HEARTBEAT (Requisição de heartbeat)
5 HEARTBEAT-ACK (Ack de heartbeat)
6 ABORT (Abort associação)
7 SHUTDOWN (Shutdown associação)
8 SHUTDOWN-ACK (Ack de shutdown)
9 ERROR (Erro de operação)
10 COOKIE-ECHO (Cookie de estado)
11 COOKIE-ACK (Ack de Cookie)
12 ECNE (Reservado para Explicit Congestion Notification Echo)
13 CCWR (Reservado para Congestion Window Reduced)
14 SHUTDOWN-COMPLETE
15 - 62 Reservado pelo IETF
63 Extensão de chunk (definido pelo IETF)
64 - 126 Reservado pelo IETF
127 Extensão de chunk (definido pelo IETF)
128 - 190 Reservado pelo IETF
191 Extensão de chunk (definido pelo IETF)
192 - 254 Reservado pelo IETF
255 Extensão de chunk (definido pelo IETF)

Adicionalmente, os dois bits mais significativos do tipo de chunk determinam a ação a ser tomada, caso o receptor não reconheça o tipo do chunk.

As ações são:

2.2.1. DATA (tipo=0)

Esse tipo de chunk é usado para transferir os dados das aplicações de usuário.

2.2.2. INIT - Inicialização (tipo=1)

Esse chunk é usado para inicializar uma associação entre dois endpoints.

2.2.3. INIT-ACK - Ack de inicialização (tipo=2)

Esse chunk é usado para reconhecer a inicialização de uma associação SCTP.

2.2.4. SACK - Ack seletivo (tipo=3)

Esse chunk é enviado para o endpoint para reconhecer chunks DATA recebidos e para informar eventuais "saltos" (gaps) na sequencia de chunks de dados recebidos, conforme representados pelos seus TSNs.

O SACK deve conter o "Ack do TSN cumulativo" e os créditos da janela de recepção (Advertised Receiver Window Credit)

Por definição, o valor do "Ack do TSN cumulativo" é o último TSN recebido antes da quebra na seqüência de TSNs recebidos. Esse parâmetro informa o recebimento de todos os chunks com TSNs menores ou iguais a esse parâmetro.

O SACK também pode conter "Blocos de salto de ack" (Gap Ack Blocks). Cada bloco desses reconhece uma subsequencia do TSNs recebidos que seguem a uma quebra dessa sequencia de TSNs recebidos. Por definição, todos os TSNs reconhecidos por esses blocos são maiores do que o valor do "Ack do TSN cumulativo"

2.2.5. HEARTBEAT - Requisição de heartbeat (tipo=4)

Um determinado endpoint envia esse chunk para outro endpoint de maneira a verificar a alcançabilidade de um destino em particular cujo endereço foi definido em uma determinada associação.

2.2.6. HEARTBEAT-ACK - Ack de heartbeat (tipo=5)

Esse chunk é enviado em resposta a um chunk HEARTBEAT. A resposta é enviada para o endpoint que originou o HEARTBEAT: o HEARTBEAT-ACK deve ser enviado para o endereço IP de origem do HEARTBEAT.

2.2.7. ABORT - Abort Associação (tipo=6)

Esse chunk é enviado para um endpoint para fechar a associação. Um dos parâmetros desse chunk é a indicação da causa do encerramento da associação.

Se um endpoint receber um ABORT com erro de formatação ou para uma associação que não existe, esse chunk deve ser descartado silenciosamente. Além disso, sob nenhuma circunstância, um endpoint que tiver recebido um ABORT deve responder a esse chunk com o envio de outro ABORT.

2.2.8. SHUTDOWN - Shutdown associação (tipo=7)

Um determinado endpoint de uma associação DEVE usar esse chunk para iniciar o processo de encerramento suave da associação.

2.2.9. SHUTDOWN-ACK - Ack de Shutdown (tipo=8)

Esse chunk DEVE ser usado para reconhecer a recepção de um chunk SHUTDOWN, ao término do processo de shutdown.

2.2.10. ERROR - Erro de operação (tipo=9)

Um determinado endpoint envia esse chunk para notificar o outro endpoint de certas condições de erro. O chunk pode conter uma ou mais causas de erro. Um "Erro de operação" não é considerado fatal por si só. Entretanto, pode-se usá-lo junto com um chunk ABORT para informar uma condição fatal.

O chunk ERROR tem como parâmetro um campo onde estão listadas todas os erros ocorridos. Cada "causa de erro" pode carregar consigo um certo númer de parâmetros. As causas de erro definidas são as seguintes:

Valor do Código de Causa Causa do Erro
1 Identificador de Stream inválido
2 Falta parâmetro obrigatório
3 Erro no estado de Cookie
4 Sem recursos (Out of Resource)
5 Endereço não resolvido
6 Tipo de chunk não reconhecido
7 Parâmetro obrigatório inválido
8 Parametro não reconhecido
9 Falta dados de usuário
10 Recebido Cookie durante o shutdown

2.2.11. COOKIE-ECHO (tipo=10)

Esse chunk é usado apenas durante a inicialização de uma associação. Esse chunk é enviado pelo iniciador da associação para completar o processo de inicialização da associação.

Esse chunk deve preceder qualquer chunk da dados (DATA) enviado em uma associação. Entretanto, pode ser agrupado no mesmo pacote com um ou mais chunks de dados.

2.2.12. COOKIE-ACK - Ack de Cookie (tipo=11)

Esse chunk é usado durane a inicialização de uma associação. Ele é usado para reconhecer a recepção de um chunk COOKIE-ECHO. Esse chunk DEVE preceder qualquer chunk DATA ou SACK enviado em uma associação. Entretanto, PODE ser agrupado em um pacote SCTP com um ou mais chunks DATA ou chunk SACK.

2.2.13. SHUTDOWN-COMPLETE (tipo=14)

Esse chunk DEVE ser usado para informar o recebimento de um chunk SHUTDOWN-ACK, ao término do processo de shutdown.

3. Estados SCTP

Essa sessão descreve os estados de uma instância do SCTP, desde o estabelecimento de uma associação até seu término. Para estabelecer uma associação os endpoints devem trocar quatro mensagens. O lado passivo (que será chamado de servidor) não aloca recursos até que a terceira dessas mensagens tenha chegado e validada. Esse mecanismo é necessário para garantir que a solicitação da criação de uma associação seja enviada de forma correta (sem a possibilidade de blind spoofing).

3.1. Estabelecimento Normal de uma Associação

Para descrever a forma como uma associação é estabelecida, será usada a nomemclatura de cliente-servidor da seguinte forma: o cliente é o endpoint que deseja iniciar a associação; o servidor é o endpoint que aguarda a solicitação de um cliente para o estabelecimento da associação.


Figura : Direção da associação Cliente/Servidor

No cliente: quando a camada superior (ULP - Upper Layer) deseja iniciar uma associação, ela preenche todas as estruturas de dados necessárias para montar um chunk INIT e usa a primitiva ASSOCIATE (ver API do SCTP) para solicitar essa associação. Então, esse chunk (INIT) é enviado para o endereço de transporte de um servidor (isso é, uma associação endereçada pela combinação de porta e endereço IP). Após o cliente ter enviado o chunk INIT ele entra no estado COOKIE-WAIT.


Figura : Inicialização de uma associação

Nesse instante o cliente inicializa um timer, que se expirar sem ter recebido resposta do servidor fará com que o cliente reenvie o chunk INIT. Caso o cliente não tenha recebido uma resposta após um número configurável de tentativas, um erro é reportado para o ULP e o endpoint destino (no caso, o servidor) é registrado como não alcançavel.


Figura : Repetição do chunk INIT

No servidor: quando o servidor recebe a solicitação da criação de uma nova associação, através de um chunk INIT. O servidor, que normalmente está no estado CLOSED, analisa os dados contidos no chunck. A partir desses dados são gerados todos os valores necessários para criar uma associação e gerar uma hash segura desses valores assim como uma chave secreta (usando os algoritmos MD5 ou SHA-1). Todos esses valores são colocados em uma estrutura de dados chamada COOKIE ao qual é atribuído um código de autenticação de mensagem (MAC - Message Authentication Code). Esse COOKIE é retornado para o cliente que solicitou a associação, em um chunk INIT-ACK. Esse COOKIE é descartado pelo servidor que permanece no estado CLOSED.


Figura : Resposta INIT-ACK do servidor

No cliente: quando o cliente, que está no estado COOKIE-WAIT, recebe um chunk INIT-ACK do servidor, ele pára o timer, monta um chunk COOKIE-ECHO, copia o COOKIE recebido no chunk INIT-ACK para o chunk COOKIE-ECHO e envia esse chunk para o servidor. O cliente inicia, então, o timer do cookie, que dispara o reenvio desse COOKIE-ECHO sempre que expirar, até que um COOKIE-ACK seja recebido do servidor. Após ter enviado o primeiro COOKIE-ECHO, a instância do protocolo no cliente entra no estado COOKIE-ECHOED. Se não for recebido o COOKIE-ACK após um número configurável de tentativas de envio de COOKIE-ECHO, o endpoint do servidor é considerado não-alcançável.

No servidor: ao receber o chunk COOKIE-ECHO (que contém uma estrutura de dados COOKIE como parâmetro), o servidor desempacota os dados nele contidos e usa, novamente, o MAC contido nele para verificar se foi o seu originador. Se o MAC indicar que esse servidor foi o construtor desse COOKIE, então os valores dos dados contidos nesse COOKIE são usados para inicializar a instância SCTP da associação. Em seguida, o servidor entra no estado ESTABLISHED e envia um COOKIE-ACK para o cliente (opcionalmente acrescentando um chunk de dados a esse chunk COOKIE-ACK). Então, o servidor está pronto para receber e enviar chunks de dados. Note que o chunk COOKIE-ECHO pode estar acompanhado por chunks de dados: o servidor é quem decide se aceita esses dados ou se os descarta.

No cliente: após ter recebido o chunk COOKIE-ACK do servidor, o cliente entre no estado ESTABLISHED.


Figura : Diagrama de estados de uma instância do protocolo SCTP

3.2. Encerramento da Associação

Ambos os endpoints envolvidos na associação podem terminá-la, praticamente, a qualquer momento.

Existe a possibilidade de shutdown suave, que garante que nenhum dado será perdido, ou encerramento forçado, que nenhum cuidado será dado ao peer.

3.2.1. Término suave de uma associação

Quando uma instância SCTP recebe a primitiva SHUTDOWN do seu processo de usuário da camada superior, ela não deve mais aceitar dados desse processo e deve iniciar a enviar o processo de shutdown: todos os chunks de dados devem ter sido reconhecidos e um chunk SHUTDOWN deve ser enviado. O processo de envio de chunks SHUTDOWN é protegido contra a perda por um timer.

Tão logo um peer receba um chunk SHUTDOWN, esse peer espera pelo reconhecimento de todos os chunks de dados enviados e, então, envia um SHUTDOWN-ACK. O processo de envio de chunks SHUTDOWN-ACK é protegido contra a perda por um timer.

Quando o primeiro peer (aquele que enviou o SHUTDOWN) receber o SHUTDOWN-ACK, ele pára o timer, envia um SHUTDOWN-COMPLETE, remove todos os dados pertencentes a essa associação e retorna para o estado CLOSED.

O peer que receber o SHUTDOWN-COMPLETE pode, então, remover todos os registros dessa associação e entrar no estado CLOSED. Se o chunk de SHUTDOWN-COMPLETE for perdido, o outro peer (o peer destino) ficará repetindo o envio de SHUTDOWN-ACK até que o contador de erros tenha sido excedido e seja sinalizado que o peer é não alcançável.

3.2.2. Abortar a associação

Um endpoint pode também decidir em abortar uma associação existente, através do envio de um chunk ABORT, mesmo que alguns chunks de dados não tenham sido reconhecidos.

O receptor do ABORT deve validar o chunk e remover a associação, se o "tag de verificação" estiver correto. O receptor não devem responder ao chunk ABORT. Em caso de encerramento da associação, o processo da camada superior é informado.

3.2.3. Casos especiais

Existem vários casos especiais que devem ser considerados. Eles ocorrem quando um endpoint é interrompido, reinicializado, etc. A sessão 5.2.4 e 5.2.9 da RFC2960 descreve o tratamento desses casos:

4. Transmissão de dados SCTP

A implementação do protocolo SCTP deve ter mecanismos de controle de fluxo e de congestionamento, de acordo com o RFC2960, que garante que o SCTP possa ser acrescentado, sem problemas, em redes onde o TCP é amplamente usado (ver, também Performance Evaluation of the Stream Control Transmission Protocol).

4.1. Conceitos Gerais

O SCTP é capaz de distinguir os diferentes streams de mensagens em uma associação SCTP. Isso possibilita um esquema de entregas de mensagens onde apenas os streams que requerem ordenação receberão esse tratamento (partial in-sequence delivery). Isso reduz o bloqueio head-of-line entre streams independentes de mensagens (ver Streams SCTP).

O SCTP opera em dois níveis:

A detecção de perda ou duplicação de chunks de dados é feita através da numeração desses chunks pelo transmissor. Esse número é chamado TSN - Transport Sequence Number. Os reconhecimentos (ACKs) enviados pelo receptor dos chunks para o transmissor são baseados nesses TSNs.

A retransmissão dos chunks é controlada por um timer cujo valor é derivado do monitoramento constante do round trip delay. Sempre que o timer expira os chunks de dados que não receberam ACK serão retransmitidos e o timer é reinicializado com o dobro do tempo anterior (da mesma forma que o TCP).

Quando o receptor detectar gaps na numeração sequencial dos chunks de dados, cada pacote SCTP será reconhecido através do envio de um chunk SACK (Ack Seletivo), onde estarão listados os gaps.

Sempre que o transmissor receber quatro SACKs consecutivos que informem a falta do mesmo chunk de dados, esse chunk será imediatamente transmitido (retransmissão rápida). A maioria dos sistemas operacionais atuais suportam extensões opcionais do TCP onde é implementado um mecanimso semelhante ao descrito (ver RFC 2018).

4.2. Controle de Fluxo

O SCTP usa um mecanismo de controle de fluxo e congestionamento baseado em janelas, semelhante ao usado pelo TCP (ver RFC 2581 - TCP Congestion Control).

O receptor dos dados pode controlar a taxa de transmissão do emissor dos dados através da especificação do tamanho da janela: é a chamada janela do receptor. Esse valor é informado em todos os chunks do tipo SACK.

O transmissor usa uma variável conhecida como janela de congestionamento (CWND - Congestion Window), que controla o número máximo de bytes de saída que podem ser enviados mesmo sem o ACK correspondente.

Todos os chunks de dados devem ter a sua recepção confirmada (ACKs) e o receptor PODE esperar por um certo tempo antes de fazê-lo (normalmente 200ms).

4.3. Confirmacão seletiva de recepção

Os chunks SACK carregam todos os TSNs dos chunks que foram recebidos. Ou seja, existe um valor cumulativos dos TSNs que indicam os chunks de ddos que foram remontados com sucesso pelo receptor e que já foram entregues para o processo da camada superior ou estão prontos para serem entregues, tão logo sejam requisitados.

Também estão presentes no SACK um blocos de gaps (Gap BLocks) que indicam que segmentos de dados chegaram mas que alguns chunks de dados foram perdidos.

Se algum(s) chunk de dados tiver sido perdido, ele será retransmitido após ter expirado o timer do transmissor ou após ter recebido quatro chunks SACK informando a falta do mesmo chunk de dados. Nesse último caso, o chunk de dados correspondente será retransmitido através do mecanismo de retransmissão rápida.

No caso da retransmissão, que indica a perda de pacotes, os parâmetros do controle de fluxo e de congestionamento devem ser adequadamente atualizados.

4.4. Controle de fluxo e endpoints multi-home

Por padrão, toda a transmissão é feita para um endereço previamente selecionado dentre um conjunto de endereços de destino. Esse endereço é chamado de Endereço Principal (Primary Address)

As retransmissões devem usar uma rota diferente de tal forma que se uma rota estiver sobrecarregada, a retransmissão não piora a situação da rota sobrecarregada (a menos que a topologia da rede seja tal que não permita essa diversidade de rotas, o que levaria o chunk retransmitido a atingir o mesmo ponto onde ocorreu o congestionamento).

Por outro lado, os reconhecimentos de recepção devem ser enviados para o endereço do originador dos dados.

No caso da rota apresentar um alto número de falhas e for excedido um determinado limite, o processo da camada superior deve ser notificada que essa rota tornou-se inativa. Então, uma nova rota deve ser escolhida pela aplicação (para mais detalhes desse mecanismo ver, mais adiante, Multi-home com SCTP)

4.5. Controle de congestionamento

De acordo com a RFC 2960, o controle de congestionamento deve impactar onde a entrega das mensagens é requerida. Isso garante um comportamento adequado do SCTP quando é introduzido em redes de pacotes de larga escala, como é o caso da Internet.

O mecanismo de controle do SCTP foi derivado da RFC 2581 (TCP Congestion Control) e adaptado para multi-homing. Assim, existe um conjunto de parâmetros de controle de fluxo e congestinamento para cada endereço de destino (isso é, cada rota possível), de tal forma que, do ponto de vista da rede, uma associação SCTP que contenha um determinado número de rotas pode comportar-se de maneira semelhante ao mesmo número de conexões TCP.

4.6. Slow Start e Prevenção de Congestionamento

Da mesma forma que o TCP, o SCTP apresenta dois modos de operação: o slow start e a prevenção de congestionamento.

O modo de operação é determinado pelo conjunto de variáveis de controle de congestionamento e, conforme já mencionado, são específicos para cada rota. Assim, por exemplo, enquanto a transmissão para o endereço principal está no modo de prevencão de congestionamento, a rota alternativa (backup path) pode estar no modo slow start.

Para que a entrega das mensagen e o reconhecimento da recepção seja bem sucedido, a variável da janela de congestionamento (CWND) é constantemente incrementada e, uma vez excedido um certo limite (chamado de Slow Start Threshold - SSTRESH), o modo de operação muda de slow start para prevenção de congestionamento.

Normalmente, quando no modo slow start, a variável CWND cresce rapidamente (aproximadamente um MTU a cada chunk SACK recebido); quando no modo de prevenção de congestionamento, ela cresce mais lentamente, a uma taxa de aproximadamente um MTU a cada RTT (Round Trip Time).

Eventos que originam a retransmissão (timeouts ou retransmissão rápida) fazem com que a variável SSTHRESH seja reduzida drasticamente e o tamanho da janela de congestionamento (representado pela variavel CWND) seja reinicializado. Essa reinicialização depende do evento causador: se for um timeout, será selecionado um novo slow start com CWND=MTU; se for uma retransmissão rápida, a janela será colocada em SSTHRESH (CWND=SSTHRESH).

4.7. Descoberta do MTU de uma rota

Uma vez que o MTU da rota é uma variável importante para, por exemplo, calibrar o controle de congestionamento, o SCTP deve manter uma estimativa do MTU atual da rota. A forma como essa descoberta é feita está descrita na RFC 1191 - Path MTU Discovery e na RFC 1981 - Path MTU Discovery for IP Version 6.

5. Multi-homing no SCTP

Uma propriedade essencial do SCTP é seu suporte a nodos multi-home, isso é, nodos que possam ser alcançados usando-se vários endereços IP.

Se os nodos SCTP e a rede IP forem configurados de tal forma que o tráfego de um nodo para outro atravesse rotas físicas diferentes quando diferentes endereços IP de destino forem usados, as associações tornam-se tolerantes até mesmo a falhas físicas da rede e quaisquer outros problemas da mesma natureza.

5.1. Gerenciamento de endereços na configuração das associações

Se um cliente opera da forma multi-home, ele deve usar os parâmetros de endereço do chunk INIT para informar ao servidor todos os seus endereços IP

De forma semelhante, o cliente precisa conhecer um único endereço IP do servidor, uma vez que ele fornecerá, para o cliente, todos os seus endereços IP, no chunk INIT-ACK de resposta.

O protocolo SCTP é capaz de usar endereços da versão 4 do IP (IPv4) assim como da versao 6 (IPv6), incluside misturando os dois. Uma instância do SCTP trata os endereços IP dos peers como se fossem uma "rota de transmissão" até o outro endpoint.

Caso não existam endereços IP nos parâmetros dos chunks INIT ou INIT-ACK, usa-se o endereço origem do pacote IP que carrega o datagrama SCTP. Esse mecanismo simplifica o uso do SCTP quando for necessário usar NATs (Network Address Translation), como é o caso nas bordas de grande redes IP privadas

Para facilitar mais ainda, a RFC 2960 teve acrescentado um mecanismo opcional que permite o uso do nome dos host além de (ou em lugar de) do endereço IP.

5.2. Monitoramento de rotas e de peers

Uma determinada instância do SCTP monitora todas as rotas de transmissão de uma determinada associação. Para isso, são enviados chunks HEARTBEAT em todas as rotas que não estão sendo usadas para transmitir chunks de dados. Os chunks HEARTBEATs devem ter seu recebimento reconhecido por chunks do tipo HEARTBEAT-ACK.

A cada rota é atribuído um estado: ativo ou inativo.

Uma rota está ativa se tiver sido usada, recentemente, para transmitir um datagrama SCTP qualquer e este tiver sido reconhecido no receptor através da transmissão de um chunk de reconhecimento. Caso a transmissão sobre certas rotas falha repetidas vezes, a rota é colocada no estado de inativo.

Um peer é considerado não alcançável quando ocorrer uma das duas situações a seguir:

Nesses casos a associação é encerrada.

5.3. Seleção de rota

Na configuração de uma associação SCTP, um dos endereços IP da lista retornada é selecionado, inicialmente, como a rota principal. Então, os chunks de dados são transmitidos, por padrão, sobre essa rota. No caso da retransmissão, entretanto, caso exista uma rota alternativa, esta PODE ser selecionada.

Para efetuar as medições do RTT, chunks SACK devem ser enviados para o endereço origem do pacote IP que transportou o chunk de dados que disparou o SACK.

Os usuários do SCTP são informados sobre o estado (na realidade, o estado e as medidas de monitoramente) de uma rota de transmissão. Isso pode ser feito sob demanda, quando o usuário solicitar, ou quando houver uma alteração de estado na rota. Então, os usuários PODEM instruir às instâncias SCTP para usarem uma nova rota como rota principal.

6. Streams SCTP

Enquanto que o TCP acopla a transferência confiável com a ordenação estrita da entrega dos dados, o SCTP separa uma da outra. Isso torna possível adaptar o protocolo às necessidades das aplicações que usam o SCTP.

Com isso, pode-se adequar o protocolo a aplicações que necessitam apenas ordenação ou que possam ficar satisfeitas com a transferência confiável, mesmo que sem a garantia da ordenação de entrega.

6.1. Conceitos Gerais

O SCTP distingue os streams de mensagens em uma associação SCTP. Isso possibilita um esquema de entregas onde deve ser garantida a ordenação das mensagens apenas na medida de garantir a ordenação em cada stream (entrega em seqüência parcial). Com isso, reduz-se os bloqueios do tipo head-of-line entre streams independentes

Adicionalmente, o SCTP fornece um mecanismo para evitar o serviço de entrega sequencial, de tal forma que as mensagens são entregues para o usuário do SCTP assim que elas sejam completamente recebidas (order-of-arrival delivery).

O contole de fluxo e de congestionamento no SCTP foi projetado de maneira a garantir que, quando na rede, o tráfego SCTP comporte-se da mesma forma que o TCP. Isso possibilita a introdução dos serviços SCTP em uma rede IP existente (ver Performance Evaluation of the Stream Control Transmission Protocol).

O SCTP opera em dois níveis:

A detecção de perda e duplicação de chunks de dados é possível graças à numeração desses chunks, pelo transmissor, com o TSN (Transport Sequence Number). As mensagens de reconhecimento da recepção enviados pelo receptor para o transmissor são baseadas nesses números sequenciais.

As retransmissões são controladas por timers. A duração da temporização é derivada do monitoramento contínuo do round trip delay. Sempre que esse timer expira, todos os chunks de dados não reconhecidos são retransmitidos e o timer é reinicializado com o dobro do valor de sua duração inicial (da mesma forma que o TCP).

Quando o receptor detecta um ou mais gaps na seqüência numérica de chunks de dados, os pacotes SCTP são reconhecidos através do envio de chunks SACK (Ack Seletivo), onde são informados esses gaps.

Sempre que o transmissor receber quatro SACKs consecutivos do mesmo chunk de dados esse chunck é retransmitido rapidamente (fast retransmit).

6.2. Entrega flexível de datagramas

O usuário de SCTP pode atribuir os datagramas a um ou vários streams de uma associação.

Quando uma associação é configurada, o número de streams disponíveis em cada direção é trocado entre as entidades peers e, para cada datagrama de usuário nesses streams, o SCTP atribui um "número sequencial do stream" independente (SSN - Stream Sequence Numbers). O receptor, por sua vez, utiliza esses SSNs para determinar a seqüência de entrega para a aplicação.

O SCTP garante que os dados de um stream (que estão marcados para entrega ordenada) sejam entregues de forma ordenada. Esse mecanismo evita o bloqueio do tipo head-of-line entre stream independentes de datagramas, de uma associação. Se fosse usado o TCP, isso só poderia ser obtido se fossem configuradas várias conexões (uma por stream), o que significa um maior overhead devido ao custo adicional de cada conexão.

O SCTP permite que os datagramas sejam marcados para entrega fora de ordem. Isso pode ser usado para a transmissão de mensagens importante e que devam podem ultrapassar as outras. Esse é o caso, por exemplo, de mensagens de encerramento de transações de uma aplicação. Se uma aplicação não requer a ordenação, pode-se transmitir essas mensagens marcando-as para não ordenação.

7. API para SCTP

Pode-se encontrar uma implementação do protocolo SCTP, escrito em C, no endereço http://www.sctp.de. A RFC2960 contém uma sessão que descreve um exemplo de interface de programação de aplicações - API - que foi usada como base para as funções dessa biblioteca.

Note que outras implementações podem ter APIs semelhantes (como a implementada por R. Stewart). As implementações em Kernel que estão, atualmente, em uso, apresentam uma API baseada na interface de sockets POSIX/Berkeley. Elas ainda estão sendo motivo de discussões.

7.1. API definida na RFC 2960

A RFC2960 considera o protocolo da camada superior (Upper Layer Protocol - ULP) que é um usuário dos serviços SCTP. Portanto, existe a comunicação entre esses dois (ULP e SCTP) em ambas as direções. O ULP pode chamar as seguintes primitivas:
  1. Initialize
  2. Associate
  3. Shutdown
  4. Abort
  5. Send
  6. Set Primary
  7. Receive
  8. Status
  9. Change Heartbeat
  10. Request HeartBeat
  11. Get SRTT Report
  12. Set Failure Threshold
  13. Set Protocol Parameters
  14. Receive unsent message
  15. Receive unacknowledged message
  16. Destroy SCTP instance
O ULP pode ser notificado pela instância de SCTP através de uma série de eventos. As seguintes notificações são mencionados na RFC 2960:
  1. DATA ARRIVE
  2. SEND FAILURE
  3. NETWORK STATUS CHANGE
  4. COMMUNICATION UP
  5. COMMUNICATION LOST
  6. COMMUNICATION ERROR
  7. RESTART
  8. SHUTDOWN COMPLETE
O significado de algumas será descrito, resumidamente, a seguir e a forma como foram implementadas na biblioteca SCTP será apresentada.

7.2. A biblioteca SCTP - Resumo

A interface completa da biblioteca SCTP está contida em um único arquivo, que deverá ser incluído em uma aplicação SCTP. É o arquivo "sctp.h".

As notificações para a aplicação são tratadas por funções do tipo "callback" que são, inicialmente, passadas para a biblioteca e que serãp chamadas após certos eventos terem ocorrido.

Junto com as declarações das funções da API, a implementação também oferece uma série de rotinas auxiliares para a execução de funções baseadas em timers e o registro de funções de callback para eventos que ocorrem no socket UDP.

A biblioteca também permite a transmissão, a recepção e o processamento de dados de sockets UDP. Entretanto, isso não será discutido aqui, uma vez que estão descritos em detalhes no manual que acompanha a implementação.

8. Terminologia

Alguns termos e abreviações usadas possuem significado especial, conforme definidos na RFC 2960, e podem ser confundidos em uma primeira leitura. Alguns desses termos serão apresentados a seguir.

8.1. Definição de termos

Active destination transport address

Endereço de transporte em um peer que um endpoint transmissor considera disponível para o recebimento de mensagens de usuário.

Bundling

Uma operação de multiplexação opcional em que mais de uma mensagem de usuário pode ser transportada no mesmo pacote SCTP. Cada mensagem de usuário ocupa seu próprio chunk de dados.

Chunk

Uma unidade de informação do pacote SCTP, formado por um header e um conteúdo específico.

Congestion Window (cwnd)

Uma variável SCTP que limita a quantidade de dados, em número de bytes, que um transmissor pode enviar para um endereço de transporte destino em particular, antes de receber a mensagem de confirmação de recebimento.

Cumulative TSN Ack Point

Corresponde ao TSN do último chunk de dados que foi reconhecido através do campo "Cumulative TSN Ack" do SACK.

Idle destination address

Um endereço para o qual não foram enviadas mensagens de usuário durante um período de tempo. Normalmente um tempo maior do que o intervalo entre dois HEARTBEATs.

Inactive destination transport address

Um endereço que é considerado inativo devido a erros ou por não estar disponível para o transporte de mensagens de usuário.

Message Authentication Code (MAC)

Um mecanismo de verificação de integridade baseado em funções hash de criptografia, usando uma chave secreta. Tipicamente, MACs são usados entre dois endpoints que compartilham uma chave secreta, a fim de validar as informações transmitidas entre esses endpoints. No SCTP eles são usados pelos endpoints para validar as informações do "estado Cookie" que são retornadas pelo peer em um chunk COOKIE-ECHO. O termo "MAC" tem diferentes significados em diferentes contextos. SCTP usa esse termo com o mesmo significado usado na RFC2104.

Ordered Message

Uma mensagem de usuário que é entregue em ordem com relação a todas as mensagens de usuário anteriormente enviadas em um determinado stream de mensagens.

Outstanding TSN (em um endpoint SCTP)

Um TSN (e o chunk de dados associado) que foi enviado por um endpoint mas para o qual não foi recebida a mensagem de confirmação de recepção.

Path (Rota)

A rota usada por um pacote SCTP que foi enviado por um endpoint SCTP para um endereço de transporte destino específico. O envio para diferentes endere'cos de destino n~ao garante que ser~ao usadas rotas diferentes.

Primary Path

A rota primária é aquela em que os pacores de dados serão colocados por padrão. Essa definição inclui o endereço de origem uma vez que a implementação PODE necessitar essa informação para obter um melhor controle da rota de retorno a ser usada pelos chunks de resposta e quais as interfaces os pacotes devem ser transmitidos quando operando com multi-home.

Receiver Window (rwnd)

Uma variável SCTP que o emissor de dados usa para armazenar a janela de recepção mais recentemente calculada para seu peer, em número de bytes. Isso fornece para o transmissor uma indicação do espaço disponível no buffer de entrada do receptor.

SCTP association

Um relacionamento entre endpoints SCTP, composto de dois endpoints SCTP, informações de estado do protocolo (incluindo Tags de Verificação), o conjunto atual de TSNs (Transmission Sequence Numbers), etc. Uma associação pode ser unicamente identificada por um endereço de transporte usado pelos endpoints da associação. Dois endpoints SCTP NÃO DEVEM ter mais do que uma associação SCTP entre eles, ao mesmo tempo.

SCTP endpoint

São os emissores/receptores lógcos de pacotes SCTP. Em um host multi-home, um endpoint SCTP é representado como uma combinação de endereços entre um conjunto de endereços de transporte de destino e um conjunto de endereços de transporte de origem. Todos os endereços de transporte usados pelos endpoints SCTP devem usar o mesmo número de porta, mas podem usar múltiplos endereços IP. Um endereço de transporte usado por um endpoint SCTP não deve ser usado por outro endpoint SCTP. Em outras palavras, um endereço de transporte é único para um determinado endpoint SCTP.

SCTP packet

É a unidade de dados que passa através da interface entre o SCTP e a rede de pacotes sem conexão (por exemplo, IP). Um pacote SCTP inclui o header comum SCTP, possíveis chunks de controle SCTP e dados de usuários encapsulados em chunks de dados (DATA) SCTP.

SCTP user application

É a entidade lógica de alto-nível de aplicação que usa os serviços do SCTP, também chamad de ULP (Upper-layer Protocol).

Slow Start Threshold (ssthresh)

É uma variável do protocolos SCTP. Corresponde ao limiar que o endpoint usará para determinar se devem operar no modo "slow start" ou no de prevenção de congestionamento, em um endereço de transporte de destino em particular. A variável SSTHRESH é o número de bytes.

Stream

Um canal lógico uni-direcional estabelecido entre dois endpoints SCTP, nos quais todas as mensagens de usuário são entregues em seqüência, exceto aquelas submetidas ao serviço de entrega não-ordenado.

Stream Sequence Number

Um número de seqüência de 16 bits usado internamente ao SCTP para garantir a entrega sequencial das mensagens de usuário, em um determinado stream. Um número sequencial de stream é anexado a cada mensagem de usuário.

Transmission Sequence Number (TSN)

Um número de seqüência de 32 bits usado internamente ao SCTP. Um TSN é anexado a cada chunk que contem dados de usuário para permitir que o endpoint de recepção possa reconhecer a sua recepção e detectar eventuais duplicações.

Transport address

É tradicionalmente definido pelo endereço de rede, protocolos de transporte e número de porta de transporte. No caso do SCTP que roda sobre IP, um endereço de transporte é definido pela cmombinação de um endereço IP em uma porta SCTP (notar que o SCTP é o protocolo de transporte).

Unacknowledged TSN (em um endpoint SCTP)

Um TSN (e o chunk DATA associado) que foi recebido pelo endpoint mas para o qual uma mensagem de reconhecimento do seu recebimento não foi ainda enviado. Ou no caso oposto, um pacote que foi enviado mas a mensagem de reconhecimento não foi recebido.

Unordered Message

Uma mensagem é dita "desordenada" quando em relação a qualquer outra mensagem. Isso inclui outras mensagens desordenadas e mensagens ordenadas. Uma mensagem desorednada pode ser entregue antes ou depois que mensagens ordenadas enviadas no mesmo stream.

Verification Tag

Um inteiro sem sinal de 32 bits que é gerado aleatoriamente. O "Verification Tag" fornece uma chave que permite, ao receptor, verificar se um determinado pacote SCTP pertence à corrente associação e não é um pacote perdido de associações antigas (e provavelmente já terminadas).

8.2. Abreviaturas

A seguinte lista de abreviaturas foi, em sua maioria, obtida da RFC 2960.

MAC
Message Authentication Code
RTO
Retransmission Time-out
RTT
Round-trip Time
RTTVAR
Round-trip Time Variation
SCTP
Stream Control Transmission Protocol
SRTT
Smoothed RTT
TCB
Transmission Control Block
TLV
Type-Length-Value Coding Format
TSN
Transmission Sequence Number
ULP
Upper-layer Protocol