Network Working Group                                          B. Parker
Solicitud de Comentarios: 1378                            Cayman Systems
Traducci—n al castellano: Mayo de 2003                       
Traductor: Ing. Lucas E. Alberione                        Noviembre de 1992

 
El Protocolo de Control PPP AppleTalk (AppleTalk Control Protocol - ATCP)

Estado de este Memorandum

Este RFC especifica un seguimiento de est‡ndares de protocolo de IAB para la 
comunidad Internet y solicita su discusi—n y sugerencias para mejoras. 
RefiŽrase a la edici—n actual de los "Est‡ndares Oficiales de Protocolos IAB" 
para consultas sobre el estado de este protocolo y su fase de estandarizaci—n. 
La distribuci—n de este memorandum es ilimitada.

Resumen 

El Protocolo Punto A Punto (PPP - Point-to-Point Protocol) provee de un mŽtodo 
est‡ndar para el transporte de datagramas multiprotocolos a travŽs de enlaces 
punto a punto. Adem‡s, PPP define un Protocolo de Control de Enlace y propone 
una serie de Protocolos de Control de Red (Network Control Protocols - NCPs) 
para el establecimiento y configuraci—n de diferentes protocolos de capa de 
red.

Este documento define el NCP para el establecimento y la configuraci—n del 
protocolo AppleTalk [3] sobre PPP.

Este memorandum es producto del esfuerzo conjunto del Grupo de Trabajo Apple-
IP y del Grupo de Trabajo del Protocolo Punto-a-Punto de la Internet Engineering 
Task Force (IETF). Comentarios sobre este documento deben ser enviados a la 
lista de correo ietf-ppp@ucdavis.edu .


Tabla de Contenidos

1	Introducci—n
2	Un Protocolo PPP de Control de Red (NCP) para AppleTalk
2.1	Enviando Datagramas AppleTalk
2.2	Medios-Ruteadores
3	Opciones de Configuraci—n ATCP
3.1	Direcci—n-AppleTalk
3.2	Protocolo-Ruteo
3.3	Supresi—n-Difusi—n
3.4	Protocolo-Compresi—n-AT
3.5	Informaci—n-Servidor
3.6	Informaci—n-Zona
3.7	Direcci—n-Ruteador-Por-Defecto
APƒNDICES
A 	Opciones Recomendadas para ATCP
REFERENCIAS

1. Introducci—n

PPP consiste de tres componentes principales:

1. Un mŽtodo de encapsulamiento de datagramas multiprotocolos.

2. Un protocolo de control de enlace (LCP - Link Control Protocol) para el 
establecimiento, configuraci—n y prueba de la conexi—n de enlace de datos.

3. Una familia de Protocolos de Capa de Red (NCP - Network Control Protocols) 
para el establecimiento y la configuraci—n de diferentes protocolos de capa de 
red.

Para el establecimiento de comunicaciones a travŽs de un enlace punto-a-punto, 
primero, cada extremo del enlace PPP debe enviar paquetes LCP para configurar 
y probar el enlace de datos. Luego de que el enlace ha sido establecido y 
recursos opcionales han sido negociados por el LCP, PPP debe enviar paquetes 
NCP para elegir y configurar uno o m‡s protocolos de capa de red. Una vez que 
cada protocolo de capa de red ha sido configurado, datagramas provenientes de 
cada extremo del enlace pueden ser transmitidos a travŽs del enlace.

El enlace permanecer‡ configurado para comunicaciones hasta que paquetes LCP o 
NCP arriven indicando la finalizaci—n del enlace, o hasta que ocurra algœn 
evento externo (expiraci—n de un temporizador de inactividad o intervenci—n 
del administrador de la red).


2. Un Protocolo PPP de Control de Red (NCP) para AppleTalk

El Protocolo de Control AppleTalk (ATCP) es el responsable de la 
configuraci—n, activaci—n y desactivaci—n de los m—dulos de protocolo 
AppleTalk, en ambos extremos del enlace punto-a-punto. ATCP utiliza el mismo 
mŽtodo de intercambio de paquetes que el Protocolo de Control de Enlace (Link 
Control Protocol - LCP). Paquetes ATCP no deber’an ser intercambiados hasta 
que PPP haya alcanzado la fase de Protocolo de Capa de Red. Paquetes ATCP 
recibidos antes de dicha fase deber’an ser descartados silenciosamente.

El Protocolo de Control AppleTalk (ATCP) es similar al Protocolo de Control de 
Enlace [1], salvo en las siguiente excepciones:

Modificaciones de Marco

El paquete puede presentar ciertas modificaciones con respecto al formato 
b‡sico de marco que ha sido negociado durante la fase de Establecimiento de 
Enlace.

Campo de Protocolo de Capa de Enlace de Datos

Exactamente s—lo un paquete ATCP es encapsulado en el campo de Informaci—n de 
un marco PPP de Capa de Enlace de Datos, donde dicho campo contiene el valor 
hexadecimal 8029 (Protocolo de Control AppleTalk).

Campo C—digo

S—lo C—digos de 1 a 7 (paquetes Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
y Code-Reject) son utilizados. Otros C—digos deber’an ser tratados como no 
reconocidos y deber’an resultar en la emisi—n de paquetes de Rechazo de C—digo 
(Code-Reject).

Expiraci—n de Temporizadores

Paquetes ATCP no deber’an ser intercambiados hasta que PPP haya alcanzado la 
fase de Protocolo de Capa de Red. Una implementaci—n deber’a estar preparada 
para esperar a que finalicen la Autenticaci—n y la Determinaci—n de la Calidad 
del Enlace, antes de la expiraci—n del temporizador en espera un paquete 
Configure-Ack o de otra respuesta. Se sugiere que una implementaci—n finalice 
luego de la intervenci—n del usuario o despuŽs de una cantidad de tiempo 
configurable.

Tipos de Opciones de Configuraci—n

ATCP tiene una colecci—n diferente de Opciones de Configuraci—n, que se definir‡n m‡s 
adelante.


2.1 Enviando Datagramas AppleTalk

Antes de que cualquier paquete AppleTalk sea enviado, PPP debe alcanzar la 
fase de Protocolo de Capa de Red, y el Protocolo de Control AppleTalk, el 
estado Abierto (Opened).

A menos que sea negociado de manera diferente (a travŽs de la opci—n 4), 
exactamente un paquete AppleTalk es encapsulado en el campo Informaci—n del 
marco PPP de Enlace de Datos, donde el campo Protocolo indica el valor 
hexadecimal 0029 (AppleTalk).

N—tese que la negociaci—n de compresi—n puede implicar la utilizaci—n de un formato de encapsulamiento diferente y, de esta manera, de diferentes campos de protocolo. Dichos campos de protocolo implican tipos de paquetes pertenecientes a sub-
protocolos del NCP AppleTalk b‡sico.

Un paquete AppleTalk encapsulado comienza con un encabezado DDP (Datagram 
Delivery Protocol - Protocolo de Entrega de Datagramas) extendido - conocido 
tambiŽn como encabezado DDP Largo. La longitud m‡xima de un datagrama DDP es 
de 599 octetos.

Dado que no existe un mŽtodo est‡ndar para la fragmentaci—n y reensamblado de 
datagramas AppleTalk, se requiere que los enlaces PPP implementando AppleTalk 
permitan al menos 599 octetos en el campo Informaaci—n de un marco de enlace 
de datos.


2.2 Medios-Ruteadores

Un modelo para ruteadores utilizado en [3] se compone de dos ruteadores 
AppleTalk remotos enlazados como "medios-ruteadores" (half-routers), sin ID de 
Nodo (Node ID) y sin nœmeros de Red asignados a cada extremo del enlace. 
Cuando actuan como medios-reuteadores, el œnico efecto en los paquetes 
transportados es que el conteo de saltos es incrementado cuando dichos paquetes son recibidos a travŽs del enlace. Valores actualizados de ruteo recibidos a travŽs de un enlace con un medio-ruteador, tambiŽn, deber’an incrementar el conteo de saltos, durante las actualizaciones a la tabla de ruteo.

Como parte de su operaci—n normal, AppleTalk enviar‡ actualizaciones de ruteo 
RTMP cada 10 segundos.


3. Opciones de Configuraci—n ATCP

Las Opciones de Configuraci—n ATCP permiten la negociaci—n de par‡metros de 
AppleTalk. ATCP utiliza el mismo formato para las Opciones de Configuraci—n 
que el definido para LCP [1], con un grupo diferente de Opciones.

Valores actualizados para el campo Tipo de Opci—n ATCP est‡n se encuntran
especificados en la versi—n m‡s reciente del RFC "Assigned Numbers" [2]. Se 
definen los siguientes valores: 

1	Direcci—n-AppleTalk (AppleTalk-Address)
2 	Protocolo-Ruteo (Routing-Protocol)
3 	Supresi—n-Difusi—n (Suppress-Broadcasts)
4 	Protocolo-Compresi—n-AT (AT-Compression-Protocol)
5 	RESERVADO
6 	Informaci—n-Servidor (Server-Information)
7 	Informaci—n-Zona (Zone-Information)
8 	Direcci—n-Ruteador-Por-Defecto (Default-Router-Address)


3.1 Direcci—n-AppleTalk

Descripci—n

Esta Opci—n de Configuraci—n establece una manera de negociar la red AppleTalk 
y el nœmero de nodo a ser utilizado en el extremo local del enlace. Permite al 
emisor del paquete Configure-Request decidir quŽ direcci—n AppleTalk desea 
utilizar, o permite solicitar al par la provisi—n de tal informaci—n. El 
par puede realizar esto acusando negativamente la opci—n y retornando una 
Direcci—n-AppleTalk v‡lida.

Si se requiere la negociaci—n remota de una Direcci—n-AppleTalk y el par no 
incluye dicha opci—n en su paquete Configure-Request, la opci—n DEBERêA ser 
insertada en un paquete Configure-Nak. El valor Direcci—n-AppleTalk provisto 
debe ser un valor aceptable, as’ como la Direcci—n-AppleTalk remota. En caso contrario indicar una solicitud en la que el par provea esa informaci—n.

Por defecto, ninguna direcci—n AppleTalk es asignada. Un nœmero de red o de 
nodo con valor cero en un paquete Configure-Request deber’a ser interpretado 
como si se solicitara al extremo remoto que especifique un valor a travŽs de 
un paquete Configure-Nak. Un nœmero de red o de nodo con valor cero en un 
paquete Configure-Request deber’a ser interpretado como un acerdo de la 
inexistencia de tal valor.

Una implementaci—n que requiera que ninguna direcci—n AppleTalk sea asignada 
(tal como de un sistema intermedio a otro sistema intermedio el tipo "ruteador-
medio") DEBE rechazar, a travŽs de paquetes Configure-Reject, todas las 
Opciones de Configuraci—n del tipo Direcci—n-AppleTalk.

Una implementaci—n que requiera que las direcciones AppleTalk sean asignadas a 
ella (tal como un sistema final) DEBE fallar ante la configuraci—n si el 
extremo remoto responde con paquetes Configure-Reject a todas las solicitudes 
Direcci—n-AppleTalk, o fallar en la provisi—n de un valor v‡lido.

Si esta opci—n es negociada, ambos extremos DEBEN negociar un nœmero de red 
AppleTalk comœn y dos nœmeros de nodo AppleTalk œnicos. El nœmero de red 
DEBERêA ser cero, pero los nœmeros de nodo AppleTalk DEBEN ser distintos de 
cero. Los nœmeros de red y de nodos seleccionados deben respetar los rangos 
definidos en [3].

El protocolo AppleTalk fase 2 define el concepto de redes "extendidas" y "no 
extendidas". Las redes extendidas pueden soportar un gran nœmero (cientos) de 
nodos y requieren mœltiples nœmeros de red  y mœltiples nombres de zonas para 
que puedan ser administradas de manera eficiente. Las redes no extendidas s—lo 
pueden soportar un s—lo nœmero de red y una zona œnica para que puedan ser 
administradas de manera eficiente.

Si a un enlace PPP transportando AppleTalk se le asigna una direcci—n 
AppleTalk, Žste debe tener caracter’sticas de redes "no extendidas" como se 
define en [3].

El formato de las direcciones de red y de nodo son definidas de la misma 
manera que las "direcciones AppleTalk" como se especifica en [3], cap’tulo 3 
del documento "AppleTalk AARP packet formats on Ethernet and token ring". 

Un resumen del formato de la Opci—n de Configuraci—n Direcci—n-AppleTalk se 
muestra debajo. Los campos son transmitidos de izquierda a derecha.


 0                   1                       2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Tipo      |    Longitud   |   Reservado   |    AT-Red     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    AT-Red     |    AT-Nodo    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Tipo

1

Longitud

6

Reservado

Este octeto est‡ reservado y DEBE contener ceros duruante la transmisi—n, y ser 
ignorado durante la recepci—n.

AT-Red

Este campo es de dos octetos y denota el nœmero de red AppleTalk del emisor 
del paquete Configure-Request. Estos dos octetos representan un nœmero de 16 
bits sin signo, en donde el octeto m‡s significativo es enviado primero.

AT-Nodo

Este campo es de un octeto y denota el nœmero de nodo AppleTalk del emisor del 
paquete Configure-Request.


3.2 Protocolo-Ruteo

Descripci—n

Esta Opci—n de Configuraci—n provee de un mecanismo para negociaciar la 
utilizaci—n de un protocolo de ruteo espec’fico. En particular, "medios-
ruteadores" pueden tener la intenci—n de intercambiar informaci—n de ruteo 
utilizando un protocolo optimizado para la conexi—n PPP. Por defecto, la 
informaci—n de ruteo AppleTalk RTMP (Protocolo de Mantenimiento de Tablas de 
Ruteo - Routing Table Maintenance Protocol) es enviada a travŽs de la conexi—n 
PPP.

Un resumen del formato de la Opci—n de Configuraci—n Protocolo-Ruteo se 
muestra debajo. Los campos son transmitidos de izquierda a derecha.
 0                   1                       2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Tipo     |   Longitud    | Protocolo-Ruteo              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datos ...
+-+-+-+-+


Tipo

2

Longitud

>=4

Protocolo-Ruteo

Este campo es de dos octetos e indica el tipo de Protocolo de Ruteo deseado. 
Estos dos octetos representan un nœmero de 16 bits sin signo, en donde el 
octeto m‡s significativo es enviado primero.

La negociaci—n de algunos protocolos de ruteo implica que se recibir‡n tipos 
de paquetes que transportan dichos protocolos.

Por ejemplo, en le negociaci—n de AppleTalk AURP para el intercambio de 
informaci—n de ruteo impica que ambos extremos aceptar‡n paquetes de tipo 
EDDP, dado que este es el tipo de transporte utilizado por AURP.

Valores iniciales son asignados de la siguiente manera:

Valor		Protocolo

0 		No hay intercambio de informaci—n de ruteo
1 		AppleTalk RTMP se usa el intercambio de informaci—n de ruteo
2 		AppleTalk AURP se usa el intercambio de informaci—n de ruteo
3		AppleTalk ABGP se usa el intercambio de informaci—n de ruteo


Datos

Este  campo es de cero o m‡s octetos y contiene informaci—n adicional 
determinada por el protocolo de ruteo indicado en el campo Protocolo-Ruteo.

Ninguna de las opciones Protocolo-Ruteo definidas en este documento requieren 
informaci—n adicional.

3.3. Supresi—n-Difusi—n

Descripci—n

Esta Opci—n de Configuraci—n provee una manera de negociar la supresi—n de 
datagramas AppleTalk de difusi—n que podr’an congestionar al enlace PPP, de 
ancho de banda limitado. Esta Opci—n de Configuraci—n es utilizada para 
indicar a un extremo remoto que datagramas AppleTalk de difusi—n de un tipo 
DDP dado no deber’an ser enviados.

Esta opci—n es œtil cuando es negociada por un s—lo sistema final. Permite al 
sistema final local solicitar que paquetes de difusi—n no sean enviados a 
travŽs del enlace PPP. En el caso de un sistema final conectado a una gran 
red, esto puede ser utilizado para suprimir operaciones de bœsqueda NBP 
generadas por otros sistemas finales de la red remota. Esto significa que 
protocolos tales como NBP ya no pueden ser utilizados para encontrar entidades 
de red en el sistema local pero, dado que la configuraci—n es asimŽtrica, no 
impide que el sistema localice entidades en la red remota.

Por defecto, los datagramas AppleTalk de difusi—n no son suprimidos. N—tese 
que esta opci—n podr’a entrar en conflicto con otras opciones (tales como 
Protocolo-Ruteo). Si as’ sucediera, la opci—n Supresi—n-Difusi—n tendr’a 
precedencia.

Un resumen del formato de la Opci—n de Configuraci—n Supresi—n-Difusi—n se 
muestra debajo. Los campos son transmitidos de izquierda a derecha.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tipo        |     Longitud    |   DDP-Tipo 1  |  DDP-Tipo 2  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| etc...
+-+-+-+-+


Tipo

3

Longitud

2

DDP-Tipo 1 y DDP-Tipo 2

Un vector de uno o m‡s octetos de valores de tipo DDP, cada uno de los cuales 
ser‡n suprimidos si son enviados a la direcci—n de difusi—n.

Si no hay datos presentes (longitud = 2), todos los paquetes de difusi—n ser‡n 
suprimidos, sin importar el tipo DDP.


3.4 Protocolo-Compresi—n-AT

Descripci—n

Esta Opci—n de Configuraci—n provee de un mŽtodo para negociar la utilizaci—n 
de un protocolo de compresi—n espec’fico. Por defecto, la compresi—n no est‡ 
activa.

Un resumen del formato de la Opci—n de Configuraci—n Protocolo-Compresi—n-AT 
se muestra debajo. Los campos son transmitidos de izquierda a derecha.

 0                   1                       2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Tipo     |   Longitud    |    Protocolo-Compresi—n-AT   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datos ...
+-+-+-+-+

Tipo

4

Longitud

>= 4

Protocolo-Compresi—n-AT

Este campo es de dos octetos e indica el protocolo de compresi—n a utilizar. 
Los valoers para este campo son siempre los mismos que los del campo Protocolo 
de Capa de Enlace de Datos de PPP para el mismo protocolo de compresi—n.

Los valores m‡s actualizados para este campo se encuentran definidos en la 
versi—n m‡s reciente del RFC "Assigned Numbers" [2].
Valores actuales son definidos a continuaci—n:

Valor (en hex.)		Protocolo

					ninguno definido


Datos

Este campo es de cero o m‡s octetos y contiene informaci—n adicional requerida 
por el protocolo de compresi—n a utilizar.


3.5. Informaci—n-Servidor

Descripci—n

Esta Opci—n de Configuraci—n provee un mŽtodo para la obtenci—n de informaci—n 
acerca del servidor de comunicaciones, en el extremo remoto del enlace PPP.

La naturaleza de esta opci—n es solamente de car‡cter consultivo. Es provista a efectos de mejorar la capacidad de un sistema final de proveer una interfaz de usuario simple.

Un resumen del formato de la Opci—n de Configuraci—n Id-Implementaci—n-Servidor
se muestra debajo. Los campos son transmitidos de izquierda a derecha.


 0                   1                   2                     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Tipo      |   Longitud    |        Clase-Servidor         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Id-Implementaci—n-Servidor                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nombre-Servidor ...
+-+-+-+-+-+-+-+-+-+-+-+-+


Tipo

6

Longitud

>= 8

Clase-Servidor

Este campo es de dos octetos e indica la clase de servidor de comunicaciones que provee el extremo remoto de la conexi—n PPP.

Los valores asignados son los siguientes:

Valor		Clase

1			Servidor PPP AppleTalk de Discado.
			
			El campo Id-Implementaci—n-Servidor es un identificador de 4 				bytes, cuyo primer byte es definido como el nœmero de versi—n 				principal (1-255) y el segundo byte como el nœmero de versi—n de 			menor importancia.

			El tercer y cuarto byte no est‡n definidos deber’an tener valor 				cero.

2			Implementaci—n PPP AppleTalk genŽrica.
			
			El campo Id-Implementaci—n-Servidor no est‡ definido y es 					espec’fico para cada fabricante.

3			Servidor de discado y ruteador.


Id-Implementaci—n-Servidor

Este campo es de cuatro octetos e indica la versi—n del servidor de comunicaciones que provee el extremo remoto de la conexi—n PPP.

Nombre-Servidor

Este campo opcional contiene el nombre "AppleTalk ASCII" del servidor. Los c—digos de caracter utilizados en "AppleTalk ASCII" est‡n definidos en [3], appendix D, "Character codes". La longitud del nombre est‡ limitado por la opci—n de longitud.

3.6 Informaci—n-Zona

Descripci—n

Esta Opci—n de Configuraci—n provee de un mŽtodo para la obtenci—n de informaci—n acerca de la zona AppleTalk utilizada en la conexi—n PPP.

La naturaleza de esta opci—n es solamente de car‡cter consultivo. Es provista a efectos de mejorar la capacidad de un sistema final de proveer una interfaz de usuario simple.

Un resumen del formato de la Opci—n de Configuraci—n Informaci—n-Zona
se muestra debajo. Los campos son transmitidos de izquierda a derecha.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Tipo      |   Longitud    | Nombre-Zona ...                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Tipo

7

Longitud

>= 3

Nombre-Zona

Este campo contiene el nombre "AppleTalk ASCII" de la zona. Los c—digos de caracter utilizados en "AppleTalk ASCII" est‡n definidos en [3], appendix D, "Character codes". La longitud del nombre est‡ limitado por la opci—n de longitud.


3.7. Direcci—n-Ruteador-Por-Defecto

Descripci—n

Cualquier paquete AppleTalk RTMP recibido deber’a XXX suceder a la informaci—n negociada en esta opci—n.

Por defecto, no hay un ruteador por defecto.

Un resumen del formato de la Opci—n de Configuraci—n Direcci—n-Ruteador-Por-Defecto se muestra debajo. Los campos son transmitidos de izquierda a derecha.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Tipo      |    Longitud   |   Reservado   |     AT-Red    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    AT-Red     |     AT-Nodo   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tipo

8

Longitud

6

Reservado

Este octeto est‡ reservado y DEBE tener valor cero durante la transmisi—n y ser ignorado durante la recepci—n.

AT-Red

Este campo de dos octetos denota el nœmero de red AppleTalk del ruteador por defecto. Este nœmero representa un valor de 16 bits sin signo, en donde el bit m‡s significativo es enviado en primer lugar.

AT-Nodo

Este campo de un octeto indica el ID de nodo AppleTalk del ruteador por defecto.



A. Opciones Recomendadas para ATCP

El protocolo ATCP est‡ designado para soportar tres modos de operaci—n diferentes. Cada modo tiene  limitaciones en lo referente a las opciones de configuraci—n a utilizar y en los valores a negociar.

Las opciones relacionadas a la informaci—n de servidores, de zonas y de ruteadores por defecto son opciones "informativas" provistas por un extremo del enlace y no est‡n pensadas para ser negociadas. Estas opciones est‡n pensadas para soportar un servicio de alto nivel a sistemas finales de discado.

Las opciones que DEBERêAN ser negociadas en cada caso se indican m‡s abajo. Cualquier opci—n no listada puede ser rechazada.

Sistema Final a Sistema Intermedio - Discado

Este modo de operaci—n esta pensado para soportar el discado en sistemas finales.

1. Direcci—n AppleTalk (requerida)
2. Protocolo-Ruteo (requerida, no hay protocolo de ruteo)
3. Supresi—n-Difusi—n (opcional)
4. Protocolo-Compresi—n-AT (opcional)
5. Informaci—n-Servidor (opcional, solicitud desde sistema final)

Sistema Intermedio a Sistema Intermedio - con nœmero de red

Este modo de operaci—n est‡ pensado para soportar conexiones WAN-a-WAN, por ejemplo, ruteador a ruteador, en donde el enlace est‡ configurado con un nœmero de red.

1. Direcci—n AppleTalk (requerida)
2. Protocolo-Ruteo (requerida, nros. de red con valor cero o iguales)
3. Supresi—n-Difusi—n (opcional)

Sistema Intermedio a Sistema Intermedio - sin nœmero de red

Este modo de operaci—n est‡ pensado para soportar conexiones WAN-a-WAN, por ejemplo, ruteador a ruteador, en donde el enlace no est‡ configurado con un nœmero de red. Los ruteadores en este modo son llamados "medios-ruteadores" en [3].

1. Direcci—n AppleTalk (requerida)
2. Protocolo-Ruteo (requerida, nros. de red y de nodo DEBEN tener valor cero)
3. Supresi—n-Difusi—n (opcional, suprime todas las difusiones)


Referencias

[1]	Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331, Daydreamer, 		Mayo de 1992.

[2] 	Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, 	USC/Information Sciences Institute, Julio de 1992.

[3] 	Sidhu G., Andrews, R., y A. Oppenheimer, "Inside AppleTalk, Second 	Edition", Addison-Wesley Publishing Company, Inc., Mayo de 1990.



Reconocimientos

Cierta parte de este texto fue tomada de documentos previos, producidos por el Grupo de Trabajo del Protcolo Punto-a-Punto de la Internet Engineering Task Force (IETF).

Este documento se deriva de bosquejos escritos por las siguientes personas. Muchas gracias por sus trabajos y por tomar la iniciativa en este protocolo:

Steve Senum (sjs@network.com), Network Systems Corporation
Jim Muchow (muchow@anubis.network.com), Network Systems Corporation
Frank Slaughter (fgs@Shiva.COM), Shiva Corporation


Consideraciones de Seguridad

No se discuten Consideraciones de Seguridad en este memorandum.

Direcci—n del Jefe

Los grupos de trabajo pueden ser contactados a travŽs de sus actuales jefes:

Brian Lloyd

Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
TelŽfono: (916) 676-1147
EMail: brian@lloyd.com


John Veizades

Apple Computer, Inc.
20525 Mariani Avenue
Cupertino, CA 95014
TelŽfono: (408) 996-1010
EMail: veizades@apple.com


Direcci—n del Autor

Las preguntas acerca de este memorandum tambiŽn pueden ser enviadas a:

Brad Parker

Cayman Systems, Inc.
26 Landsdowne Street
Cambridge, Ma 02139
EMail: brad@cayman.com


Datos del Traductor

Ing. Lucas E. Alberione

Email: alberione@myrealbox.com