Professional Documents
Culture Documents
INTRODUO
PROTOCOLOS PPP
2.1
Formato de tramas PPP
2.2
Encapsulamento de dados PPP
2.2.1
HDLC sncrono ao bit
2.2.2
HDLC assncrono (AHDLC)
2.2.3
HDLC sncrono ao octeto
2.3
Diagrama de estados de PPP
2.3.1
Estado Inactivo
2.3.2
Estado de Estabelecimento
2.3.3
Estado de Autenticao
2.3.4
Estado de Rede
2.3.5
Estado de Aberto
2.3.6
Estado de Terminao
2.4
Protocolo LCP
2.4.1
Formato de pacotes LCP
2.4.2
Opes de configurao de pacotes LCP
2.5
Protocolos de autenticao
2.5.1
PAP (Password Authentication Protocol)
2.5.2
CHAP (Challenge Handshake Authentication Protocol)
2.6
Protocolo IPCP
2.6.1
Descrio das opes de configurao IPCP
2.6.2
Envio de Pacotes IP
2.7
Diagrama de opes LCP
2.8
O protocolo PPP Multilink
2.9
Extenso Multi-Classe para PPP Multilink
2.10 PPP sobre RDIS
2.10.1 Encapsulamento de PPP em X.25
2.10.2 Encapsulamento de PPP em Frame Relay
2.11 PPP sobre ATM
2.11.1 PPP sobre AAL5
2.11.2 PPP sobre AAL2
2.12 PPP sobre Ethernet
3
3.1
3.2
PROTOCOLO RADIUS
Arquitectura AAA
Protocolo RADIUS
4.1
Equipamento terminal de acesso Internet via RDIS
4.1.1
PC com carta RDIS interna activa
4.1.2
PC com carta RDIS interna passiva
4.1.3
TA RDIS externo
4.1.4
TA RDIS externo com V.120
4.2
Diagramas de mensagens de acesso a redes IP
4.3
Always On Dynamic ISDN (AODI)
REFERNCIAS
ACRNIMOS
2
3
4
5
5
6
6
6
6
7
7
7
7
8
8
8
9
11
11
12
13
14
15
15
17
18
18
18
19
19
19
20
20
22
22
22
24
24
24
24
25
25
25
27
29
30
1 Introduo
Os acessos Internet tm vindo a crescer a forte ritmo, quer em nmero de utilizadores quer em trfego
gerado. As redes mais utilizadas para esses acessos so ainda a rede telefnica comutada (PSTN) e a RDIS,
tendo contudo nos ltimos anos sido desenvolvidas vrias tecnologias ditas de banda larga, com maiores
dbitos, de que se destacam nomeadamente em Portugal a ADSL e o HFC (Hybrid Fibre Coax).
Na Figura 1 apresenta-se um diagrama de acesso Internet usando diferentes tecnologias e redes,
nomeadamente atravs de PSTN, RDIS e ADSL.
Analgica
PSTN
Modem
ISP POP
Internet
RDIS S0
ISDN
TA
ISP POP
ADSL
ATM
Modem ADSL
ISP POP
DSLAM
TCP/UDP
IP
PPP
V.24
Fsico
PC
Modem
IP
PPP
FR/ATM
V.24
SDH
POP/Router
IP
IP
PPP
V.24
V.24
I.430
PPP
FR/ATM
I.430
SDH
PC
POP/Router
TA
Figura 3 Diagrama de protocolos de dados de acesso Internet atravs de RDIS, canal B
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
Como o protocolo PPP baseado no protocolo HDLC (High-level Data Link Control), oportuno listar os
protocolos de ligao de dados baseados em HDLC actualmente definidos. Como se observa na tabela, os
protocolos derivados de HDLC esto presentes em todas as modernas redes de comunicaes, pblicas e
privadas, fixas e mveis.
Tabela 1 Famlia de protocolos de ligao de dados baseados em HDLC
Nome
Rede/norma
Descrio
SDLC
SNA (IBM)
HDLC
Linha Srie
LLC
LAN
LAPB
X.25
LAPD
ISDN
LAPDm
GSM
LAPM
V.42
LAPF
FR
V.120
TA ISDN
MTP-2
SS7
PPP
Internet
Point-to-Point Protocol
2 Protocolos PPP
O protocolo PPP foi especificado pelo IETF inicialmente no RFC 1331 e posteriormente actualizado no RFC
1548 e no RFC 1661. Este protocolo providencia um mtodo normalizado de transporte de datagramas
multi-protocolo sobre circuitos ponto a ponto. O PPP suporta deteco de erros, mltiplos protocolos e
negociao para atribuio de endereos IP na fase de conexo e autenticao.
O PPP um protocolo que se situa na camada 2 do modelo de referncia OSI, estruturado em tramas,
apropriado para funcionar sobre Modems, linhas sries HDLC orientadas a octeto ou a bit, SONET/SDH e
outras camadas fsicas. Pode ser usado no s para ligaes do tipo marcao em linhas telefnicas (DialUp) mas tambm para ligao entre Routers em linhas dedicadas.
O protocolo PPP constitudo por um conjunto de protocolos, sendo caracterizado por vrias componentes:
1.
Mtodo de encapsulamento de dados em forma de trama que permite determinar o incio e o fim de
cada trama. Este formato tambm apresenta a vantagem de permitir a deteco de erros.
2.
Um protocolo de ligao de dados LCP (Link Control Protocol), que permite iniciar a ligao,
testar a qualidade da linha, negociar opes de configurao, como por exemplo o tipo de protocolo
a ser usado nas fases seguintes, e finalmente interromper a ligao quando esta j no for
necessria.
3.
Um protocolo NCP (Network Control Protocol), que faz a multiplexagem de diferentes protocolos
de nvel superior (camada de rede), como por exemplo IP, IPX, AppleTalk, sobre a forma de
negociao de opes de configurao.
4.
Protocolos de autenticao (por exemplo CHAP ou PAP) para validao dos acessos dos
utilizadores.
De acordo com a funcionalidade descrita, o protocolo PPP pode ser organizado em duas subcamadas, como
se indica na Figura 4.
LCP
NCP (IPCP)
CHAP
HDLC
Para compreender como as vrias componentes do PPP interagem, exemplifica-se uma situao real em que
um utilizador em sua casa pretende contactar um Internet Service Provider (ISP) para se ligar
temporariamente Internet.
A primeira aco do PC cliente fazer uma chamada ou um pedido de ligao atravs do Modem (Fase 1).
Depois do Modem do lado do ISP responder e estabelecer a ligao fsica (Fase 2) e lgica (Fase 3) do canal,
o PC cliente e o Router trocam pacotes do tipo LCP para a configurao da ligao (Fase 4). Terminado este
estado os dados de autenticao opcionais so analisados pelo ISP (Fases 5) e em caso de sucesso trocada
uma srie de pacotes NCP (IPCP no caso de se usar IP) (Fase 6) para configurao de parmetros da camada
de rede. Aps este estado podem ser enviados dados (Fase 7).
Na Figura 5 exemplificam-se simplificadamente as diferentes fases de operao do PPP no acesso Internet
atravs da rede telefnica com Modem.
PC Cliente
Router/NAS
Marcao nmero ISP
Atendimento
Fase 1
Fase 2
LAPM SABM
LAPM UA
Fase 3
PPP LCP
PPP LCP
Fase 4
PPP CHAP
PPP CHAP
Fase 5
Fase 6
Dados Utilizador
Dados Utilizador
Fase 7
2.1
A formatao dos pacotes PPP em HDLC definida na RFC 1662, PPP in HDLC-like Framing. Como se
pode verificar na figura 6, o formato das tramas PPP em HDLC comea com um campo FLAG (7Eh), a que
se seguem os campos Address, Control, Protocol, Information, FCS e FLAG.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
PROTOCOL
INFORMATION
2
FLAG
(7Eh)
ADDRESS
(FFh)
0 a N-2
CONTROL
(O3h)
FCS
2aN
FLAG
(7Eh)
2 ou 4
octetos
Protocolos
C021
C023
PAP - Password-Authentication-Protocol
C025
C223
8021
80FD
0800
Dados IP
O campo Information constitudo por zero ou mais octetos, sendo constitudo por dados correspondentes
ao protocolo especificado no campo Protocol, onde o seu tamanho mximo determinado pela negociao
de opes do pacote LCP, por omisso 1500 Octetos.
O campo FCS (Frame Check Sequence) tem 16 bits por omisso mas por negociao poder ocupar 32 bits.
Trata-se de um campo de controlo calculado com base em todos campos da trama PPP excepto nos campos
Flag e FCS.
2.2
Na RFC 1662 so definidos trs tipos de formatos de encapsulamento de dados PPP em HDLC:
- HDLC Sncrono ao Bit
- HDLC Assncrono (AHDLC)
- HDLC Sncrono ao Octeto
2.2.1
O formato HDLC sncrono ao bit o formato mais comum, sendo usado na maioria dos casos, em particular
para dbitos elevados.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
Este formato corresponde ao HDLC padro. Os pacotes PPP comeam e terminam com um campo FLAG,
que consiste numa sequncia binria 01111110, 7Eh em hexadecimal. Este campo um separador de
tramas, portanto no deve existir uma sequncia idntica ao campo FLAG no interior da trama. por isso
usado bit stuffing (insero de um bit zero aps a ocorrncia de 5 uns sucessivos) para manter a
transparncia da informao no interior das tramas.
2.2.2
O HDLC assncrono usado em interfaces srie de baixo dbito, nomeadamente em Modems assncronos e
interfaces sries assncronas, por exemplo portas srie de PC. Neste formato so usados caracteres especiais
para identificar funes, nomeadamente o carcter 7Eh para delimitao de trama e o carcter 7Dh para
Escape. O carcter 7Eh marca o incio e fim da trama HDLC, sendo tambm enviado entre tramas
sucessivas. O carcter 7Dh permite usar os caracteres 00h-1Fh e 7Eh, os quais so antecedidos de 7Dh,
sendo este mecanismo denominado octet stuffing.
Para manter a transparncia, cada carcter de dados com cdigo igual Flag (7Eh), ao Escape (7Dh) ou a
um carcter de controlo definido no mapa ACCM (Async Control Character Map) substitudo por dois
caracteres, o primeiro dos quais um Escape e o segundo um octeto que obtido atravs da operao ou
exclusivo do octeto original com 20h, isto , o octeto original com o 6 bit mais significativo
complementado.
Na tabela 3 mostram-se alguns exemplos de codificao com octet stuffing.
Tabela 3 Exemplos de codificao com octet stuffing
Caracter
Valor (Hex)
Flag
Escape
ETX
XON
XOFF
7e
7d
03
11
13
7d
7d
7d
7d
7d
5e
5d
23
31
33
Mostra-se em seguida uma sequncia de incio de pacote PPP sem e com octet stuffing, em que se
considera que os caracteres FF e 03 no so permitidos e em que o carcter inicial 7E a flag de incio da
trama HDLC:
2.2.3
7E FF 03 C0 21 ...
7E 7D DF 7D 23 C0 21 ...
O HDLC Sncrono ao octeto usado em canais sncronos. semelhante ao AHDLC excepto no facto de os
caracteres de controlo no necessitarem de usar Escape ou octet stuffing. Na RFC 1618, PPP over ISDN
esta formatao uma das opes consideradas no transporte de PPP em canais B de RDIS.
2.3
As diferentes fases de processamento do protocolo podem ser descritas com base num diagrama de estados
simplificado apresentado na Figura 7.
2.3.1
Estado Inactivo
A ligao comea e termina nesta fase. Quando h um evento externo (tal como a deteco de uma portadora
no nvel fsico) indicando que a camada fsica est disponvel para ser usada, o PPP prossegue para o estado
de Estabelecimento da ligao.
Durante este estado a mquina de estados do LCP (descrito adiante), estar nos estados inicial ou Starting.
Retorna-se ao estado Inactivo aps a desconexo do Modem. Este estado torna-se muito curto nos casos de
ligaes Hard-Wired (por exemplo Modem Interno).
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
Portadora
Detectada
Opes LCP
Acordadas
Inactiva
Autenticao
Estabelecimento
Autenticao
com Sucesso
Falha
Falha
Rede
Portadora
Perdida
Opes NCP
Acordadas
Terminao
Encerrar Ligao
Opened/Aberto
2.3.2
Estado de Estabelecimento
O protocolo de controlo da ligao (LCP) usado para estabelecer a conexo mediante a troca de pacotes de
configurao. O estado Aberto (Opened) atingido depois da recepo e envio de pacotes Configure-Ack
(descrito adiante). Opened o ltimo estado da mquina de estados da fase de estabelecimento.
Neste estado so negociadas as opes de configurao independentes do tipo de protocolos de rede a serem
usados nas fases posteriores. A configurao de protocolos da camada de rede feita por protocolos
independentes (NCPs).
A recepo neste estado de pacotes que no sejam do tipo LCP devem ser descartados silenciosamente. A
recepo de um pacote Configure-Request LCP nas fases seguintes resulta no retorno reconfigurao da
ligao.
2.3.3
Estado de Autenticao
Em algumas ligaes a camada homloga pode desejar que o utilizador se autentique antes de prosseguir
com a configurao dos protocolos de rede (fase NCP). Neste estado so negociadas opes atravs de
pacotes LCP com base num protocolo de autenticao especfico, da que a autenticao no seja
obrigatria.
Este estado s pode ser activado quando recebido um sinal explcito de indicao do trmino do estado de
estabelecimento. Se a autenticao for obtida com sucesso a linha passa para o estado de Rede, no caso de
insucesso a ligao retorna para o estado de terminao.
Os protocolos permitidos neste estado so o LCP, os protocolos de monitorizao de linha e os protocolos de
autenticao.
2.3.4
Estado de Rede
Uma vez terminado o estado precedente, cada protocolo de rede (tais como o IP, IPX e AppleTalk) deve ser
configurado separadamente pelo protocolo NCP correspondente, que no caso do IP o IPCP.
Quando o estado de Rede termina o protocolo de rede negociado o assumido no estado de Aberto.
Qualquer outro protocolo de rede diferente do configurado ao ser recebido dever ser imediatamente
descartado. Neste estado qualquer combinao de pacotes como LCP, NCP ou outros protocolos de rede
podem surgir.
2.3.5
Estado de Aberto
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
2.3.6
Estado de Terminao
O PPP pode terminar a ligao em qualquer altura. Isto pode acontecer devido a perda da portadora, falha na
autenticao, fraca qualidade de ligao, um temporizador expirado por causa de um perodo longo de
inactividade e ainda o encerramento por parte do operador.
O LCP faz a troca de pacotes de terminao da ligao. Quando a troca de pacotes de terminao da conexo
chega ao fim necessrio forar a camada fsica desconexo, particularmente quando h falha de
autenticao.
O remetente do pacote Terminate-Request deve desligar aps receber um pacote Terminate-Ack ou depois do
temporizador expirar. Finalmente o PPP prossegue para o estado inactivo. Caso os pacotes do tipo LCP
sejam recebidos devem ser imediatamente descartados.
2.4
Protocolo LCP
O protocolo de controlo de ligao LCP permite iniciar a ligao, testar a qualidade da linha, negociar
opes de configurao, como por exemplo o tipo de protocolo a ser usado nas fases seguintes, e finalmente
interromper a ligao quando esta j no seja necessria.
Existem trs classes de pacotes LCP a saber:
1.
2.
3.
2.4.1
FLAG
(7Eh)
ADDRESS
(FFh)
CODE
IDENT
LENGTH
CONTROL
(03h)
PROTOCOL
(C021h)
DATA
LCP
0 a N-2
INFORMATION
2aN
FCS
2/4
FLAG
(7Eh)
PPP
Nome
Sentido
Descrio
ConfigureRequest
T-->R
Configure-Ack
TR
Configure-Nak
TR
Configure-Reject
TR
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
TerminateRequest
TR
Terminate-Ack
TR
Code-Reject
TR
Protocol-Reject
TR
Echo-Request
TR
Este pedido enviado para que T saiba que no est a comunicar com
ele prprio, envia a opo magic-number no pacote echo-request.
10
Echo-Reply
TR
11
Discard-Request
TR
12
Identification
TR
13
Time-Remaining
TR
O terminal T inicia a ligao propondo certas opes de configurao do tipo LCP ao terminal R, e
consoante o tipo de opo este envia respostas adequadas proposta recebida. Existem tambm pacotes para
terminar a ligao que podem ser enviados por qualquer um dos terminais.
O campo Identifier relaciona a sequncia das mensagens transmitidas com as mensagens recebidas. O
campo Length tem dois octetos, indicando o tamanho total do pacote LCP incluindo o cabealho. O campo
Data tem tamanho varivel, dependente do cdigo do pacote.
2.4.2
Como foi referido os pacotes LCP contm uma srie de opes a serem negociadas. Pretende-se que as
opes de configurao do protocolo PPP sejam fceis de negociar, devendo as opes configuradas ser
mantidas aps a negociao. Consideram-se tambm as opes de configurao com a interveno do
operador que de outra forma seriam impossveis de realizar, como por exemplo os dados para a autenticao
do utilizador ou a atribuio dinmica de endereos IP. A configurao automtica conseguida graas a um
mecanismo extensivo de negociao de opes, baseada numa mquina de estados.
Exemplifica-se em seguida a sequncia de mensagens entre dois terminais, considerando um terminal cliente
a que chamamos Cliente e um servidor de Internet designado por ISP.
Quando se d o incio das negociaes para a configurao da ligao, o Cliente envia um pacote configurerequest com uma lista de opes que suporta, propondo ao ISP que as suporte tambm, e quase
simultaneamente o ISP envia um pacote configure-request com a respectiva lista de opes definidas por
omisso. Este comportamento justifica-se pelo facto das mquinas de estado de ambos serem iguais e se
iniciarem a partir do instante em que o meio fsico se torna disponvel.
As negociaes prosseguem at que ambos recebam pacotes configure-ack , confirmando a chegada a um
acordo. Este acordo pode demorar se pelo meio houver opes que no so aceites por qualquer um dos
terminais, o que mais frequente. Em resposta so enviados pacotes configure-reject ou configure-nak de
acordo com a descrio da Tabela 4.
A Figura 9 mostra a estrutura de dados do pacote de configurao de opes de LCP.
TYPE
LENGTH
CODE
IDENT
LENGTH
OPES
0 a N-2
DATA
LCP
2aN
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
O campo Type ocupa um octeto e admite valores especificados no IANA, o campo Length ocupa um octeto
e contm o tamanho em bytes da opo incluindo Type, Length e Data, o campo Data ocupa um espao
varivel dependendo do valor da opo como mostra a Tabela 5.
Tabela 5 - Opes de Configurao de LCP
Type
Descrio
Async-Control-Character-Map
Authentication-Protocol
Quality Protocol
Magic-Number
FCS-Alternatives [RFC1570]
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
10
2.5
Protocolos de autenticao
O PAP um mtodo simples de autenticao em que a identificao feita num sentido e no sentido de
retorno aguarda-se uma nica resposta de aceitao ou rejeio, e feita apenas no incio do estabelecimento
de uma ligao PPP.
O processo de autenticao PAP tem incio depois de terminado o estado de estabelecimento descrita
anteriormente, onde o utilizador envia uma combinao nome_do_utilizador / palavra_chave para a entidade
autenticadora, e espera que uma resposta seja devolvida, caso contrrio a ligao termina.
Este um protocolo em que os dados so enviados em texto puro e o utilizador tem um controlo total
relativamente frequncia e ao nmero de tentativas de autenticao.
O protocolo PAP encapsulado na trama PPP do mesmo modo que o protocolo LCP mas com a diferena
de no ter campos extensivos de opes de configurao no campo Data. No campo Protocol usado o
valor C023hex que identifica o protocolo PAP.
A Figura 10 mostra a estrutura de dados do pacote authenticate-request. Trata-se do pacote mais importante
do protocolo PAP, por conter os elementos de identificao do utilizador.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
11
>=0
CODE
IDENT
LENGTH
PASSWD
>=0
DATA
PAP
2aN
Nome
Sentido
Descrio
Authenticaterequest
T->R
Authenticate-ack
T<-R
Authenticate-nak
T<-R
Rejeio da combinao
Authenticate-Request
username/password
recebido
do
Peer_ID : tem zero ou mais octetos e preenchido pelo nome do utilizador a ser autenticado.
Passwd : ocupa zero ou mais octetos e preenchido pela palavra chave do utilizador a ser autenticada.
O pacote authenticate-ack e authenticate-nak tm o campo Data vazio, a entidade autenticadora
encarrega-se apenas de dar a indicao de ter aceite ou rejeitado respectivamente o pacote authenticaterequest.
2.5.2
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
12
Nome
Sentido
Descrio
Challenge
T<-R
Response
T->R
Success
T<-R
Failure
T<-R
O mtodo 3-way handshake consiste no envio de uma mensagem challenge pelo equipamento
autenticador ao equipamento remoto, e este responde com uma mensagem calculada na base de uma funo
one-way hash. A resposta analisada e, se os valores coincidirem, uma resposta de confirmao enviada,
caso contrrio a ligao termina. Os valores so nicos e secretos, e so apenas do conhecimento da entidade
autenticadora e do equipamento remoto.
O valor do desafio uma sequncia varivel de octetos. O valor do desafio deve ser mudado cada vez que
um desafio emitido. O comprimento do valor do desafio depende do mtodo usado gerar os octetos, e
independente do algoritmo de hash usado.
O valor da resposta o hash calculado sobre uma sequncia de octetos que consistem no identificador,
concatenado com o "segredo", concatenado com o valor do desafio. O comprimento do valor da resposta
depende do algoritmo hash usado (16 octetos para MD5).
Na figura Figura 11 apresenta-se um diagrama de mensagens exemplificativo do funcionamento do
protocolo CHAP.
PC Cliente
Router/NAS
CHAP Challenge
CHAP Response
CHAP Success/Failure
2.6
Protocolo IPCP
Na presente implementao o NCP configura protocolos do tipo IP especialmente para permitir o acesso a
Internet. A negociao do protocolo IP denominada Internet Protocol Control Protocol (IPCP) [RFC1332].
O IPCP responsvel em ambos os extremos da ligao pela capacidade de utilizao ou no do uso de
pacotes do tipo IP. O IPCP usa o mesmo mecanismo de troca de pacotes de controle de ligao (LCP)
descrito anteriormente. Pacotes IPCP no podem ser trocados at que o estado de configurao de protocolos
de rede (NCP/IPCP) seja alcanada. Os pacotes IPCP recebidos antes deste nvel ser atingido devem ser
silenciosamente descartados.
Os pacotes IPCP tm a mesma constituio que os pacotes LCP na sua estrutura de dados e funcionamento,
com algumas excepes a considerar:
- Ao nvel de ligao de dados o pacote IPCP encapsulado no campo Information da trama PPP, onde
o campo Protocol preenchido pelo 8021hex [IANA].
- O campo Code admite sete pacotes IPCP: configure-request, configure-ack, configure-nak, configurereject, terminate-request, terminate-ack e code-reject. Qualquer outro cdigo deve ser rejeitado.
- S podero ser trocados pacotes IPCP aps terminadas as fases de estabelecimento de linha e de
autenticao.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
13
2.6.1
Descrio
Comprimento
Valor
(bytes)
(Hex)
>=4
002d
IP Address
Varivel
129
Varivel
130
Varivel
131
Varivel
132
Varivel
IP Compression Protocol
uma opo que ocupa dois octetos e indica o tipo de compresso do protocolo desejado. Por opo a
compresso no est activada.
A compresso de cabealho TCP/IP Van Jacobson (RFC 1144) permite reduzir o tamanho dos cabealhos
TCP/IP de 40 octetos para 3 octetos, o que um aumento significativo da eficincia e reduo do tempo de
transmisso dos pacotes, em especial para pacotes com campo de informao baixo e canais de baixo dbito.
possvel definir vrias opes na transmisso de pacotes IP, identificadas atravs do campo Protocol do
PPP que se indicam na Tabela 9.
Tabela 9 Valores do campo Protocolo de PPP para transmisso de pacotes IP
Valores (hex)
Protocolos
0021
002d
002f
IP Address
uma opo que ocupa quatro octetos e possui uma forma de negociao de endereos IP a ser usado pelo
utilizador remoto ao longo da ligao. Permite que o remetente especifique que endereo IP deseja utilizar.
O peer pode responder com um pacote Configure-Nak com o valor IP vlido a ser usado. O requerente
remoto pode sugerir um endereo IP ou pode enviar um endereo a zero, para que o peer atribua um
endereo IP.
Primary DNS (Domain Name Server)
Esta opo do tipo 129. Define o mtodo de negociao do endereo Primary DNS com o peer remoto a
ser usado no terminal.
Se o peer local enviar um endereo ao servidor com valor falso (que normalmente feito intencionalmente),
o servidor retorna um pacote Nak que contm o valor Primary DNS correcto.
Secundary DNS (Domain Name Server)
Esta opo define o mtodo de negociao do endereo Secondary DNS com o peer remoto a ser usado no
terminal.
Se o peer local enviar um endereo ao servidor com valor falso (que normalmente feito intencionalmente),
o servidor retorna um pacote Nak que contm o valor Secondary DNS correcto.
Primary NBNS (Netbios Name Server)
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
14
Esta opo define o mtodo de negociao do endereo Primary NBNS com o peer remoto a ser usado no
terminal.
Se o peer local enviar um endereo ao servidor com valor falso (que normalmente feito intencionalmente),
o servidor retorna um pacote Nak que contm o valor Primary NBNS correcto.
Secundary NBNS (Netbios Name Server)
Esta opo define o mtodo de negociao do endereo Secondary NBNS com o peer remoto a ser usado no
terminal.
Se o peer local enviar um endereo ao servidor com valor falso (que normalmente feito intencionalmente),
o servidor retorna um pacote Nak que contm o valor Secondary NBNS correcto.
2.6.2
Envio de Pacotes IP
Antes de qualquer pacote IP ser transmitido, o IPCP deve alcanar o estado Opened na fase de configurao
de protocolos de rede (NCP).
Um pacote do tipo IP encapsulado exactamente numa trama PPP, com a indicao 0021hex no campo
Protocolo.
O comprimento mximo de um pacote IP deve ser o mesmo que o tamanho mximo do campo Information
da trama PPP. Os datagramas maiores devem ser fragmentados quando necessrio.
Se o sistema desejar evitar a fragmentao e a reagrupamento de pacotes, dever usar a opo do tamanho
mximo do TCP e da MTU.
2.7
O diagrama seguinte mostra a maioria dos parmetros LCP que podem ser negociados durante a fase de
estabelecimento. Este diagrama pode ajudar a localizar os parmetros LCP que a mquina local no est a
negociar com a mquina LCP remota.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
15
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
16
2.8
As interfaces bsica e primria de RDIS oferecem a possibilidade de abrir mltiplos canais simultneos entre
equipamentos terminais, dando aos utilizadores largura de banda a pedido, obviamente com custos
adicionais.
H vrias propostas que proporcionam sincronizao entre mltiplos fluxos ao nvel de bit, de que se destaca
a proposta BONDING, mas que tm o inconveniente de requererem hardware adicional.
A soluo definida na RFC 1990, The PPP Multilink Protocol (MP), pode ser implementada inteiramente
em software, sendo baseada num cabealho de 4 octetos e em regras simples de re-sincronizao.
Na Figura 13 apresenta-se um diagrama esquemtico do funcionamento do PPP Multilink.
Aplicao
TCP/UDP
IP
PPP
Mux / Demux
MLPPP
MLPPP
Canal 1
Canal 2
SEQ. NUM.
1
FLAG
(7Fh)
ADDRESS
(FFh)
CONTROL
(O3h)
PID=003d
MP
DATA FRAGMENT
0aM
FCS
4aN
FLAG
(7Fh)
2 ou 4
PPP
octetos
FLAG
(7Fh)
ADDRESS
(FFh)
CONTROL
(O3h)
BE 00
SEQ. NUM.
0,5
1,5
0aM
PID=003d
MP
DATA FRAGMENT
FCS
2aN
FLAG
(7Fh)
2 ou 4
PPP
octetos
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
17
FLAG
(7Eh)
FLAG
(7Eh)
ADD CNT
(FFh) (O3h)
PID
003d
BE
10
ADD CNT
(FFh) (O3h)
SN
PACOTE IP
PID
FCS
FRAGMENTO 1
FLAG
(7Eh)
ADD CNT
(FFh) (O3h)
SN
BE
01
PID
003d
FCS
FLAG
(7Eh)
PPP
FLAG
(7Eh)
MP
FCS
FRAGMENTO 2
FLAG
(7Eh)
2.9
Na RFC 2686 foi definida uma extenso de PPP Multilink para suportar servios integrados sobre linhas de
baixo dbito. Para tal definido um formato de encapsulamento para tempo real, baseado no mecanismo de
fragmentao do PPP Multilink, a que se adiciona o campo CLS (Classe) que permite definir pacotes com
diferentes prioridades e diferentes disciplinas de servio.
Na Figura 17 apresenta-se a estrutura dos pacotes MP com Classes com Nmero de Sequncia Longo, em
que o campo CLS tem a dimenso de 4 bits.
BE CLS 00
SEQ. NUM.
1
FLAG
(7Eh)
ADDRESS
(FFh)
CONTROL
(O3h)
PID=003d
MP
DATA FRAGMENT
0aM
FCS
4aN
2 ou 4
FLAG
(7Eh)
PPP
octetos
Figura 17 Formato PPP Multilink com Classes com Nmero de Sequncia Longo
Na Figura 18 apresenta-se a estrutura dos pacotes MP com Classes com Nmero de Sequncia Curto, em
que o campo CLS tem a dimenso de 2 bits.
FLAG
(7Eh)
ADDRESS
(FFh)
CONTROL
(O3h)
PID=003d
BE CLS
SEQ. NUM.
0,5
1,5
MP
DATA FRAGMENT
0aM
FCS
2aN
2 ou 4
FLAG
(7Eh)
PPP
octetos
Figura 18 Formato PPP Multilink com Classes com Nmero de Sequncia Curto
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
18
PROTOCOL
INFORMATION
2
FLAG
(7Eh)
SVClow
0aM
p(r) M p(s) 0
FLAG
(7Eh)
FCS
2aN
2 ou 4
octetos
INFORMATION
2
FLAG
(7Eh)
ADDRESS CONTROL
LAPF
(O3h)
1a3
0aM
NLPID
(CFh)
FLAG
(7Eh)
FCS
2aN
2 ou 4
octetos
SSAP
(FE)
Information
CNT= NLPID =
UI (03) PPP (CF)
1
PPP
0aN
SSCS-PDU
Pad
U C Len CRC32
0-47
1 1
CPCS-PDU
Nx48 octetos
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
19
Na cauda utiliza-se a cauda usual da subcamada CPCS de AAL5, constituda pelo Pad de tamanho varivel e
pelos campos UU (User-User Information), CPI (Common Part Indicator), Len (Length) e CRC32.
2.11.2 PPP sobre AAL2
O RFC 3336 "PPP over AAL2", define a utilizao de PPP sobre ATM usando o AAL2, nomeadamente os
mecanismos de encapsulamento de PPP em PDUs AAL2.
O encapsulamento do PPP usando SSSAR (Service Specific Segmentation and Reassembly) e AAL2 CPS
(Common Part Sublayer) mais eficiente que o AAL5. Utilizando um CRC de 2 octetos e considerando que
o cabealho do CPS de AAL2 de 3 octetos e o campo Offset de 1 octeto, obtemos um "overhead" de
encapsulamento de 6 octetos, o que inferior aos 8 octetos da cauda do AAL5.
A funo de multiplexagem de subcamada CPS de AAL2 permite ainda uma maior eficincia de transporte
de pacotes, multiplexando mltiplos pacotes em uma ou mais clulas, eliminando o "overhead" do Pad de
AAL5, o que particularmente importante no transporte de pacotes pequenos.
O formato de encapsulamento de pacotes PPP em AAL2 apresentado na Figura 22.
PROTOCOL
2
8
CID
LI
OSF
0aM
PPP
UUI HEC
3 octetos
6
CRC16
INFORMATION
Payload
CPS Packet
1 a 45 / 1 a 64
1 1 bit
S
P
N
CPS Packet
CPS Packet
CPS Packet
PAD
CPS PDU
CPS-PDU
header
(1 octeto)
Header
Payload
5 octetos
48 octetos
ATM
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
20
endereo MAC da Ethernet do par e estabelecer um identificador de sesso PPPoE. Enquanto que o PPP
define uma relao entre pares, a Descoberta define uma relao cliente-servidor. No processo de
Descoberta, um terminal (cliente) pode descobrir um ou mais concentrador do acesso (servidores),
seleccionando um de entre eles. Quando a Descoberta termina com sucesso, o terminal e o concentrador de
acesso seleccionado tm a informao que usaro para construir a sua conexo ponto a ponto sobre a
Ethernet.
A fase de Descoberta permanece sem estado at que uma sesso do PPP esteja estabelecida. Uma vez
estabelecida uma sesso PPP, o terminal e o concentrador do acesso devem atribuir os recursos para uma
interface virtual PPP.
Na Figura 23 mostra-se o formato de uma trama PPPoE, a qual ocupa o campo de informao de uma trama
Ethernet.
VER
TYPE
CODE
1/2
1/2
SESSION_ID
LENGTH
PAYLOAD
N
octetos
O terminal transmite em broadcast um pacote de iniciao (PPPoE Active Discovery Initiation, PADI);
2.
Um ou mais concentradores de acesso (AC) emitem pacotes de oferta (PPPoE Active Discovery Offer,
PADO);
3.
4.
AC
Discovery Initiation (PADI)
Discovery Offer (PADO)
Discovery Request ( PADR)
Fase 1
Fase 2
Fase 3
Fase 4
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
21
3 Protocolo RADIUS
3.1
Arquitectura AAA
3.2
A autorizao refere-se aos mecanismos que permitem ao prestadores de servio controlar o acesso
dos seus utilizadores aos servios disponibilizados. Actualmente estes mecanismos permitem a
coabitao simultnea de vrios tipos de servios, o que possibilita a implementao de polticas
diferenciadas, normalmente associadas a diferentes custos.
Por fim, os mecanismos de AAA definem a forma como efectuada a contabilizao dos dados
transferidos que permitem aos prestadores de servio a cobrana pelos recursos usados pelos
respectivos clientes. Nas redes IP tradicionais a informao essencial para a cobrana o tempo e o
volume de trfego usado pelos clientes. No entanto, a introduo de acessos do tipo always on e a
possibilidade de mobilidade, obriga a um refinar das formas de contabilizao existentes.
Protocolo RADIUS
O protocolo RADIUS o protocolo de AAA mais usado nas actuais redes IP. Foi inicialmente desenvolvido
a pensar nas ligaes de utiliza dores atravs de acessos telefnicos, vulgo dial up, via PPP.
O RADIUS implementa mecanismos de autenticao dos utilizadores, autorizao de acesso a servios e
contabilizao de informao que permita a facturao do servio e dos recursos usados pelo cliente. Tem
uma arquitectura de cliente - servidor onde as perguntas (requests, na terminologia) so sempre iniciadas
pelo cliente, o que limita a sua flexibilidade na implementao de servios. transportado sobre UDP, pelo
que no dispe de mecanismos de retransmisso em caso de perda de informao, caracterstica que o torna
vulnervel em ligaes onde a perda de pacotes possa ser significativa.
O mecanismo de funcionamento do RADIUS est representado na Figura 25. As suas entidades principais
so o cliente, o ponto de entrada na rede que no caso do dial-up o Network Access Server (NAS) e o
servidor RADIUS. O servidor RADIUS contm ainda uma base de dados Lightweight Directory Access
Protocol (LDAP) onde so aguardados todos as informaes relativas aos clientes. O utilizador no participa
directamente no mecanismo RADIUS.
1. Access Request
3. Access Request
5. Accounting Req.
Nome e
palavra chave
Network
Access Server
(NAS)
Terminal
Autorizao
Consulta
Base de Dados
Servidor
RADIUS
2. Access Challenge
4. Access Accepted
6. Accounting Ack.
Base de
Dados
(LDAP)
Resposta da
Base de Dados
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
22
Os procedimentos do mecanismo RADIUS podem ser descritos sumariamente na Figura 52, onde est
representado o caso de um cliente que se tenta ligar rede acedendo atravs do NAS, indicando-lhe o seu
nome de utilizador e palavra chave, via PAP ou CHAP.
Com essa informao, o cliente constri uma mensagem (#1) Access Request que enviada para o servidor.
Aps a sua chegada, o servidor consulta a informao referente ao utilizador na sua base de dados. Com base
nesta informao o servidor poder efectuar um desafio ao Cliente em que lhe pede dados adicionais (#2). A
resposta ao desafio dada num novo Access Request (#3). Se por fim toda a informao for validada pelo
servidor, dada a autorizao para o acesso atravs de uma mensagem de Access Accepted (#4).
Para alm dos procedimentos de autenticao, o RADIUS implementa tambm mecanismos de colecta de
dados para tarifao. A colecta de dados iniciada pelo servidor a pedido do cliente via mensagem de
Accounting Request. A sua confirmao dada atravs de um Accounting Accepted. A partir desse momento
o servidor RADIUS comea a contagem do tempo de sesso e do volume de dados transferidos. Devido
mais uma vez arquitectura cliente - servidor, os dados de contabilizao apenas so enviados do cliente
para o servidor aps terminada a sesso.
O RADIUS, parte do seu relevante papel nas actuais redes IP sofre de algumas limitaes que fortaleceram
o aparecimento de uma nova arquitectura, o DIAMETER. A cabea das limitaes do RADIUS vem a sua
reduzida flexibilidade na implementao de servios. Exemplos destas limitaes so a dificuldade de o
servidor desligar uma sesso que esteja a decorrer, a impossibilidade de implementao de servios de
contabilizao em tempo real dos recursos utilizados (trfego enviado e recebido) e ainda a no definio de
mecanismos de negociao que permitam que os clientes e servidores conheam as suas capacidades
mtuas.
No aspecto da segurana o RADIUS implementa apenas de forma opcional o uso de IPSec (IP Security), o
que torna difcil a implementao de associaes de segurana entre servidores RADIUS localizados em
domnios diferentes, com consequncias negativas em situaes de roaming.
Na Figura 26 apresenta-se um diagrama de mensagens exemplificativo do funcionamento do protocolo
RADIUS juntamente com o protocolo CHAP.
Terminal
Servidor
RADIUS
NAS
Base de
Dados
CHAP Challenge
CHAP Response
Access Request
Access Challenge
Consulta B. Dados
Resposta da B. Dados
Access Request
CHAP Success
Access Accepted
Accounting Request
Accounting Ack.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
23
4.1
Os protocolos mais usados actualmente para acesso Internet via RDIS so o PPP, ML-PPP e V.120, sobre
o qual utilizado o protocolo IP e camadas superiores, TCP ou UDP e aplicaes.
No acesso Internet atravs de computador pessoal (PC) podemos considerar 4 diferentes arquitecturas, em
funo do equipamento usado e da localizao dos diferentes protocolos.
4.1.1
Nesta arquitectura usada um PC com uma carta de adaptao RDIS activa, isto , que possui um
processador autnomo e firmware de implementao de protocolos, nomeadamente PPP ou ML-PPP e
sinalizao RDIS.
Aplicao
TCP/UDP
PC
CAPI
IP
DSS1
DSS1
LAPD
LAPD
(ML)-PPP
(ML)-PPP
Carta
RDIS
IP
I.430
I.430
(U)
FR/ATM
(C)
RDIS
SDH
(U)
(C)
PC com Carta
RDIS activa
POP
Nesta arquitectura usada uma carta de adaptao RDIS passiva, sem processador. Neste caso
todos os protocolos acima do nvel 1(ou parte do nvel 2) so implementados pelo PC.
Aplicao
TCP/UDP
PC
CAPI
IP
(ML)-PPP
IP
DSS1
DSS1
LAPD
LAPD
(ML)-PPP
I.430
I.430
Carta RDIS
(U)
PC com Carta
RDIS activa
FR/ATM
(C)
RDIS
(C)
SDH
(U)
POP
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
24
4.1.3
TA RDIS externo
Nesta arquitectura usado um TA RDIS externo, sendo a interface com o PC feita atravs de interface RS232 e Comandos AT. de salientar neste caso a converso de PPP ou ML-PPP assncrono para sncrono no
sentido do PC para TA e a converso inversa no sentido TA para PC.
Aplicao
TCP/UDP
IP
IP
(ML)-PPP
(ML)-PPP
(ML)-PPP
Assnc.
Assinc.
Snc.
V.24
V.24
DSS1
DSS1
LAPD
LAPD
(ML)-PPP
Snc
I.430
(U)
RDIS
(C)
I.430
SDH
(U)
(C)
TA
PC
FR/ATM
POP
4.1.4
Nesta arquitectura tambm usado um TA RDIS externo, sendo a interface com o PC feita atravs de
interface RS-232 e Comandos AT. A diferena em relao arquitectura anterior consiste na utilizao do
protocolo V.120 para transporte de dados entre o TA e o POP.
Aplicao
TCP/UDP
IP
IP
(ML)-PPP
(ML)-PPP
Assnc.
Assinc.
V.24
V.24
(ML)-PPP
DSS1
DSS1
(ML)-PPP
V.120
LAPD
LAPD
V.120
I.430
(U)
PC
RDIS
(C)
I.430
(C)
FR/ATM
SDH
(U)
TA
POP
4.2
Analisam-se em seguida alguns cenrios de utilizao da RDIS para acesso a RDIS IP, nomeadamente para
acesso Internet, acesso a LAN e interligao de LANs
Na Figura 31 apresenta-se um exemplo de diagrama de mensagens para o estabelecimento de chamada de
acesso RDIS usando o canal B (Dial-In RDIS)
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
25
PC
V.24
Ds
Ds
Controlo
E
E
B T
T B
TA
RDIS
S
Comutador RDIS
RDIS
DTE
Rede
e
TA
Internet
POP
ISP
RDIS
Rede
POP
Internet
SABME(x,s)
UA(x,s)
Canal D
RDIS
I(x,s)[S IP]
I(x,s)[S IP]
I(x,s)[CP]
I(x,s)[C]
I(x,s)[C]
PPP LCP
PPP LCP
PPP LCP
Canal B
extremoa
extremo
PPP LCP
PPP IPCP
PPP IPCP
PPP IPCP
PPP IPCP
Pacote IP
Pacote IP
Pacote IP
Pacote IP
Pacote IP
Pacote IP
Eth.
B/R
RDIS
Ds
Ds
Controlo
E
E
B T
T B
S
RDIS
LAN
S
Comutador RDIS
Rede
e
B/R
B/R
RDIS
Eth.
RDIS
Rede
LAN
B/R
SABME(x,s)
UA(x,s)
Canal D
RDIS
I(x,s)[S IP]
I(x,s)[CP]
I(x,s)[S IP]
I(x,s)[C]
I(x,s)[C]
Pacote IP
Canal B
extremoa
extremo
Pacote IP
Pacote IP
Pacote IP
Pacote IP
Pacote IP
Figura 32 - Estabelecimento de chamada para interligao de LAN com protocolo IP com canal B
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
26
4.3
Always On Dynamic ISDN (AODI) um servio de rede que proporciona uma conexo sempre disponvel,
atravs de uma interface RDIS.
AO/DI baseado na infraestrutura de centrais digitais RDIS equipadas com comutadores de pacotes X.25 e
usando o protocolo BACP (Bandwidth Allocation Control Protocol) definido na RFC 2025. O servio
AO/DI basedo numa conexo X.25 estabelecida sobre o canal D de RDIS entre o utilizador e o ISP.
O protocolo PPP Multilink e os protocolos TCP/IP so encapsulados no canal lgico transportado no canal
D. Os canais B so invocados medida que necessria mais largura de banda. Os canais B usam o PPPML sem encapsulamento X.25 nem LAPD, isto usando o canal B transparente at ao POP, sobre o qual
so enviados pacotes IP encapsulados em ML-PPP. Na Figura 33 apresenta-se o diagrama de protocolos no
acesso Internet com AO/DI.
Aplicao
TCP/UDP
IP
IP
ML-PPP
ML-PPP
X.25
X.25
LAPD
LAPD
SDH
I.430
I.430
(D)
FR/ATM
(B)
S0 (2B+D)
(D)
PC
(B)
POP/Router
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
27
- Se o tempo para esvaziar a fila menor que 5 s use o canal D X.25 sem invocar o canal B.
- Se o tempo para esvaziar a fila maior que 5 s use o canal D X.25 para enviar um pedido BAP
para invocar um canal B.
- Se um canal B estiver disponvel use o protocolo PPP-ML para aumentar o dbito do servio,
- Se um canal B no estiver disponvel fica espera que um canal B fique disponvel
- Se o tempo para esvaziar a fila maior que 10 seg, pede 2 canais B.
Aps terminar a transferncia de dados que requereu a invocao dos canais B adicionais, estes precisam de
ser desligados atravs de pedidos BACP.
Apresenta-se em seguida um exemplo de heurstica para reduzir a largura de banda:
- Se no for detectada actividade durante 5 seg, os canais devero ser desligados.
- Se for detectada uma chamada de entrada atravs de mensagens DSS1, um canal B deve ser
desligado.
- Se for detectada uma chamada de sada atravs de mensagens DSS1, um canal B deve ser
desligado.
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
28
Referncias
RFC 1661, The Point-to-Point Protocol (PPP), July 1994.
RFC 1570. PPP LCP Extensions, January 1994.
RFC 1662, PPP in HDLC-like Framing, July 1994.
RFC 1618, PPP over ISDN, May 1994.
RFC 1962, CCP - Compression Control Protocol, June 1996.
RFC 1332, The PPP Internet Protocol Control Protocol (IPCP), May 1992.
RFC 1144, "Compressing TCP/IP Headers for Low-Speed Serial Links", Feb 1990.
RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), August 1996.
RFC 1990, The PPP Multilink Protocol (MP), August 1996.
RFC 2125, The PPP Bandwidth Allocation Protocol (BAP). The PPP Bandwidth Allocation Control
Protocol (BACP), March 1997.
RFC 1598, "PPP in X.25", March 1994.
RFC 1973, "PPP in Frame Relay", June 1996.
RFC 2364, "PPP over AAL5", July 1998.
RFC 3336, "PPP over AAL2", December 2000.
RFC 2516, "PPP over Ethernet", December 2000.
RFC 1483, "Multiprotocol Interconnect over AAL5", July 1993.
RFC 3153, PPP Multiplexed, August 2001.
RFC 1963, PPP Serial Data Transport Protocol (SDTP), August 1996.
RFC 1989, PPP Link Quality Monitoring, August 1996.
RFC 2509, IP Header Compression over PPP, February 1999.
RFC 2615, PPP over SONET/SDH, June 1999.
RFC 2661, Layer Two Tunneling Protocol 'L2TP' , August 1999.
RFC 2701, Multi-link Multi-node PPP Bundle Discovery Protocol, September 1999.
RFC 2823, PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing, May 2002.
RFC 2687, PPP in a Real-time Oriented HDLC-like Framing, September 1999.
RFC 2138, Remote Authentication Dial In User Service (RADIUS), April 1997
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
29
Acrnimos
AAL
ATM Adaptation Layer
AC
Access Concentrator
ACCM Async Control Character Map
ACFC Address and Control Field Compression
ADSL Asymmetric Digital Subscriber Line
AHDLC Asynchronous HDLC
AO/DI Always On Dynamic ISDN
ATM Asynchronous Transfer Mode
BACP Bandwidth Allocation Control Protocol
BAP
Bandwidth Allocation Protocol
CHAP Challenge-Handshake-Authentication-Protocol
CID
Channel Identifier
CLS
Class
CPI
Common Part Indicator
CPS
Common Part Sublayer
CRC
Cyclic Redundancy Check
DCE
Data Circuit-terminating Equipment
DNS
Domain Name Server
DSS1 Digital Signalling System number 1
FCS
Frame Check Sequence
FR
Frame Relay
GSM Global System for Mobile
HFC
Hybrid Fibre Coax
HDLC High-level Data Link Control
HEC
Header Error Control
IANA Internet Assigned Number Authority
IETF Internet Engineering Task Force
IP
Internet Protocol
IPCP IP Control Protocol
IPX
Internetwork Packet Exchange
ISDN Integrated Services Digital Network
ISP
Internet service provider
L2TP Layer Two Tunneling Protocol
LAN
Local area Network
LAPB Link Access Procedure, Balanced
LAPD Link Access Procedure for D Channel
LAPDm LAPD for Mobile Links
LAPM Link Access Procedure for Modems
LAPF LAP for Frame Relay
LCP
Link Control Protocol
LI
Length Indicator
LLC
Logical Link Control
LQR
Link Quality Report
ML
Multi Link
MTP
Message Transfer Part
MTU Maximum Transmission Unit.
MRU Maximum Receive Unit
NBNS Netbios Name Server
NCP
Network Control Protocol
NLPID Network Layer Protocol Identifier
OSI
Open Systems Interconnection
PADI PPPoE Active Discovery Initiation
PADO PPPoE Active Discovery Offer
PADR PPPoE Active Discovery Request
PADS PPPoE Active Discovery Session-confirmation
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
30
PAP
Password-Authentication-Protocol
PC
Personal Computer
PDU
Protocol Data Unit
PID
Protocol Identifier
POP
Point of Presence
PPP
Point-to-Point Protocol
PSTN Public Switched Telephone Network
RADIUS Remote Authentication Dial In User Service
RDIS Rede Digital com Integrao de Servios
RFC
Request for Comments
SSSAR Service Specific Segmentation and Reassembly
SDH
Synchronous Digital Hierarchy
SDL
Simple Data Link
SDLC Synchronous Data Link Control
SONET Synchronous Optical Network
SDTP Serial Data Transport Protocol
SNA
Systems Network Architecture
SS7
Signalling System number 7
TA
Terminal Adaptor
TCP
Transfer Control Protocol
UDP
User Datagram Protocol
UU
User-User Information
UUI
User-to-User Indication
Redes de Acesso: Parte B Protocolos de acesso, Mrio Serafim Nunes, IST, Maro 2006
31