Protocole de résolution d’adresse NBMA (NARP)

Statut de ce mémoire

Le présent mémoire définit un protocole expérimental pour la communauté de l’Internet. Il ne spécifie aucune sorte de norme de l’Internet. On invite à des discussions et suggestions pour son amélioration. La dtribution du présent mémoire n’est soumise à aucune restriction.

Note de l’IESG :

Noter que le travail contenu dans le présent mémoire ne décrit pas une norme de l’Internet. Ce travail représente une étape précoce des efforts en cours pour résoudre le problème de la communication directe sur les sous-réseaux NBMA. C’est un protocole expérimental qui convient pour un premier développement. Il est prévu qu’il sera supplanté par d’autres travaux qui sont en cours de développement au sein de l’IETF.

Résumé

Le présent document décrit le protocole de résolution d’adresse NBMA (NARP, NBMA Address Resolution Protocol). NARP peut être utilisé par un terminal source (hôte ou routeur) connecté à la couche liaison d’un réseau multi accès sans diffusion (NBMA, Non-Broadcast, Multi-Access) pour trouver les adresses NBMA d’un terminal de destination pourvu que le terminal de destination soit connecté au même réseau NBMA. Bien que le présent document se concentre sur NARP dans le contexte de IP, la technique est applicable aussi aux autres protocoles de couche réseau. La présente RFC a été produite par le groupe de travail Acheminement sur les grands nuages de l’IETF.

1.   Introduction

Le protocole de résolution d’adresses NBMA (NARP) permet à un terminal source (hôte ou routeur) qui souhaite communiquer sur la couche liaison d’un réseau multi accès sans diffusion (NBMA) pour découvrir les adresses NBMA du terminal de destination si celui-ci est connecté au même réseau NBMA que la source.

Un protocole conventionnel de résolution d’adresse, tel que ARP [RFC0826], [RFC1577] pour IP, peut n’être pas suffisant pour résoudre l’adresse NBMA du terminal de destination, car il ne s’applique qu’aux terminaux qui appartiennent au même sous-réseau IP, tandis qu’un réseau NBMA peut consister en plusieurs sous-réseaux IP logiquement indépendants (LIS, [RFC1209]).

Une fois que l’adresse NBMA du terminal de destination est résolue, la source peut soit commencer à envoyer les paquets IP à la destination (dans un réseau NBMA sans connexion comme SMDS) soit établir d’abord une connexion à la destination avec les caractéristiques de bande passante et de qualité de service désirées (dans un réseau NBMA orienté connexion tel que ATM).

Un réseau NBMA peut être en non diffusion soit parce qu’il ne prend pas techniquement en charge la diffusion (par exemple, un réseau X.25) soit parce que la diffusion n’est pas faisable pour une raison ou une autre (par exemple, un groupe de diffusion SMDS ou un Ethernet étendu seraient trop grands).

2.   Vue d’ensemble du protocole

Cette section, décrit brièvement comment une source S utilise NARP pour déterminer l’adresse NBMA de la destination D ou pour trouver qu’une telle adresse n'existe pas. S vérifie d’abord si le terminal de destination appartient au même sous-réseau IP que S lui-même. Si c’est le cas, S résout l’adresse NBMA de D en utilisant les moyens conventionnels, tels que ARP [RFC0826], [RFC1577] ou des tableaux préconfigurés. Si D réside sur un autre sous-réseau, S formule une demande NARP qui contient les adresses IP de source et de destination. S transmet alors la demande à une entité appelée le "serveur ARP NBMA" (NAS, NBMA ARP Server).

Pour des raisons administratives et politiques, un réseau physique NBMA peut être partagé en plusieurs réseaux NBMA logiques disjoints. Les NAS résolvent de façon coopérative le prochein bond NBMA au sein de leur réseau logique NBMA. Dans ce qui suit, nous utiliserons toujours le terme "réseau NBMA" pour parler d’un réseau logique NBMA. Si S est connecté à plusieurs réseaux NBMA, il devrait y avoir au moins un NAS dans chacun d’eux. Pour savoir quel NAS interroger pour une adresse de destination donnée, une S multi rattachements devrait aussi être configurée de façon à recevoir des informations d’accessibilité de la part de son ou ses NAS.

Chaque NAS "dessert" un ensemble préconfiguré de terminaux et d’homologues avec un ensemble préconfiguré de NAS, qui appartiennent tous au même réseau NBMA. Un NAS peut aussi échanger du trafic avec des routeurs en dehors du NBMA desservi. Un NAS échange des informations d’accessibilité avec ses homologues (et éventuellement avec les terminaux qu’il dessert) en utilisant les protocoles d’acheminement réguliers. Cet échange est utilisé pour construire un tableau de transmission dans chaque NAS. Le tableau de transmission détermine le NAS de prochain bond vers la destination de la demande NARP ou un routeur de prochain bond en dehors du NBMA.

Après avoir reçu une demande NARP, lhe NAS vérifie si il "dessert" D. S’il en est ainsi, le NAS résout l’adresse NBMA de D, en utilisant des mécanismes qui sortent du domaine d’application du présent document (les exemples de tels mécanismes incluent ARP [RFC0826], [RFC1577] et des tableaux préconfigurés). Le NAS transmet alors la demande NARP à D ou génère une réponse NARP positive en son nom. La réponse contient l’adresse IP et NBMA de D et est renvoyée à S. Les réponses NARP traversent normalement la même séquence de NAS que la demande NARP (en ordre inverse, bien sûr).

Si le NAS ne dessert pas D, il extrait de son tableau de transmission le prochain bond vers D. Si le prochain bond est un NAS homologue, il transmet la demande NARP au prochain bond. Si le prochain bond est un routeur homologue en dehors du NBMA desservi ou si aucune entrée de prochain bond n’est trouvée, le NAS génère une réponse NARP négative.

Un NAS qui reçoit une réponse NARP peut mettre en antémémoire les informations d’adresse NBMA qui y sont contenues. Si une demande NARP ultérieure pour la même adresse cible n’exige pas une réponse d’autorité, un NAS disposant d’une antémémoire peut alors répondre avec l’adresse NBMA de l’antémémoire qui n’est pas d’autorité ou avec une information négativve d’antémémoire. Un terminal qui se comporte bien devrait toujours accepter a priori une réponse qui n’est pas d’autorité. C’est seulement si la tentative de communication fondée sur les informations qui ne sont pas d’autorité échoue que le terminal peut choisir de produire une autre demande réclamant cette fois une réponse d’autorité.

Les demandes et réponses NARP ne franchissent jamais les frontières d’un réseau NBMA. Donc, le trafic IP de et vers un réseau NBMA traverse toujours un routeur IP à sa frontière. Le filtrage de couche réseau peut alors être mis en œuvre à ces routeurs frontières.

3.   Configuration

Terminaux

Pour participer à NARP, un terminal connecté à un réseau NBMA devrait être configuré avec la ou les adresses IP de son ou ses NAS. Si le terminal est rattaché à plusieurs réseaux NBMA, il devrait aussi être configuré pour recevoir les informations d’accessibilité de la part de son ou ses NAS afin qu’il puisse déterminer quelles destinations IP sont accessibles, à travers quels réseaux NBMA.

Serveurs ARP NBMA

Un NAS est configuré avec un ensemble de préfixes d’adresses IP qui correspondent aux adresses IP des terminaux qu’il dessert. De plus, le NAS doit être configuré pour échanger les informations d’accessibilité avec ses NAS homologues (s’il en est). Le NAS peut aussi être configuré pour échanger les informations d’accessibilité avec des routeurs en-dehors du NBMA desservi. Et finalement, si un terminal desservi est rattaché à plusieurs réseaux NBMA, le NAS peut avoir besoin d’être configuré pour envoyer des informations d’accessibilité à un tel terminal.

4   Formats de paquet

Les demandes et réponses NARP sont portées dans des paquets IP sous le type de protocole 54. La présente section décrit les formats de paquet des demandes et réponses NARP :

Demande NARP

 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Version    | Compte de bond|       Somme de contrôle       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      Type     |      Code     |          Non utilisé          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                   Adresse IP de destination                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Adresse IP de source                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Longueur NBMA |                  Adresse NBMA                 |

+-+-+-+-+-+-+-+-+                                               |

|                               (longueur variable)             |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version

Numéro de version NARP. Actuellement, cette valeur est 1.

Compte de bond

Il indique le nombre maximum de NAS qu’il est permis à une demande ou réponse de traverser avant d’être éliminée.

Somme de contrôle

La somme de contrôle IP standard sur la totalité du paquet NARP (commençant à l’en-tête fixe).

Type

Type de paquet NARP. La demande NARP a un code de Type de 1.

Code

Une réponse à une demande NARP peut contenir des informations d’antémémoire. Si une réponse d’autorité est désirée, on devrait alors utiliser le code 2 (Demande NARP d’informations d’autorité). Autrement, une valeur de code de 1 (Demande NARP) devrait être utilisée.

Adresses IP de source et de destination

Respectivement, ce sont les adresses IP du demandeur NARP et du terminal cible pour lequel l’adresse NBMA est désirée.

Longueur NBMA et Adresse NBMA

Le champ Longueur NBMA est la longueur de l’adresse NBMA du terminal source en bits. L’adresse NBMA élle-même est remplie de zéros jusqu’à la prochaine limite de 32 bits.

Réponse NARP

 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Version    |Compte de bonds|       Somme de contrôle       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      Type     |      Code     |          Non utilisé          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                   Adresse IP de destination                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Adresse IP de source                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Longueur NBMA |                  Adresse NBMA                 |

+-+-+-+-+-+-+-+-+                                               |

|                      (longueur variable)                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version

Numéro de version NARP. Actuellement cette valeur esr 1.

Compte de bond

Il indique le nombre maximum de NAS qu’il est permis à une demande ou réponse de traverser avant d’être éliminée.

Somme de contrôle

Somme de contrôle IP standard sur la totalité du paquet NARP (commençant à l’en-tête fixe).

Type

Type de paquet NARP. La réponse NARP a le code de type 2.

Code

Les réponses NARP peuvent être positives ou négatives. Une réponse positive, non d’autorité, porte un code de 1, tandis que réponse positive, d’autorité, porte un code de 2. Une réponse négative, non d’autorité, porte un code de 3 et une réponse négative, d’autorite, porte un code de 4.

La règle générale est qu’un NAS ne devrait pas répondre à une demande NARP d’information d’autorité avec des informations contenues dans l’antémémoire, mais qu’elle peut le faire pour une demande NARP. Il est permis à une mise en œuvre de NAS d’assouplir cette règle et de retourner des informations non d’autorité même dans le cas où des informations d’autorité sont désirées si le NAS est lourdement chargé et si les informations de l’antémémoire ont été mises à jour très récemment.

Adresse IP de source et de destination

Respectivement, ce sont les adresses IP du demandeur NARP et du terminal cible pour lequel l’adresse NBMA est désirée.

Longueur NBMA et adresse NBMA

Le champ Longueur NBMA est la longueur de l’adresse NBMA du terminal de destination en bits. L’adresse NBMA elle-même est remplie de zéros jusqu’à la prochaine limite de 32 bits. Les réponses négatives ne portent pas de champ Longueur NBMA ou de champ Adresse NBMA.

Un NAS peut mettre les réponses NBMA en antémémoire.

5.   Fonctionnement du protocole

Le comportement externe d’un NAS peut être décrit comme deux procédures (processRequest et processReply) qui fonctionnent sur deux tableaux (forwardingTable et cacheTable). Dans une mise en œuvre réelle, le code et les structures de données peuvent être réalisées différemment.

Chaque NAS a un tableau de transmission qui consiste en entrées avec les champs :

<networkLayerAddrPrefix, type, outIf, outIfAddr>

Le champ networkLayerAddrPrefix (préfixe d’adresse de couche réseau) identifie un ensemble d’adresses IP connues du NAS. Il comporte deux sous-champs <ipAddr, mask>.

Le champ type indique le type de networkLayerAddrPrefix. Les valeurs possibles sont :

-   locallyServed : Le NAS dessert lui-même le networkLayerAddrPrefix. Le champ outIf note l’interface NBMA via laquelle les terminaux desservis peuvent être atteints et le champ outIfAddr n’a pas de signification. Une telle entrée de tableau de transmission a été créée par configuration manuelle.

-   nasLearned : Le NAS a appris le networkLayerAddrPrefix d’un autre NAS. Les champs outIf et outIfAddr notent, respectivement, l’interface NBMA et l’adresse IP de ce NAS de prochain bond. Une telle entrée de tableau de transmission résulte d’un échange d’informations de préfixe d’adresse de couche réseau avec un des NAS homologue du NAS.

-   externallyLearned : Le NAS a appris le networkLayerAddrPrefix d’un routeur homologue situé en dehors du NBMA desservi. Les champs outIf et outIfAddr notent, respectivement, l’interface NBMA et l’adresse IP de ce NAS de prochain bond. Une telle entrée de tableau de transmission résulte d’un échange d’informations de préfixe d’adresse de couche réseau avec un des routeurs homologues du NAS.

Le protocole utilisé pour échanger les informations de networkLayerAddrPrefix entre les NAS peut être tout protocole régulier d’acheminement IP intra domaine ou inter domaines.

En plus du tableau de transmission, chaque NAS a un tableau d’antémémoire NARP comportant des entrées avec les champs :

<networkLayerAddr, nbmaAddr, horodatage>

Les entrées dans le tableau d’antémémoire sont apprises des réponses NARP qur traversent le NAS. En cas d’entrée d’antémémoire négative, le champ nbmaAddr est vide. Le champ Horodatage enregistre l’heure à laquelle l’entrée du tableau d’antémémoire a été créée ou mise à jour. Il est utilisé pour déterminer si une entrée est très récente et pour périmer les vieilles entrées après une certaine période de garde.

Le pseudocode suivant définit comment les demandes et réponses NARP de NBMA sont traitées par un NAS.

procedure processRequest(request);

  let bestMatch == matchForwardingTable(request.dIPa) do

    if bestMatch then

      if bestMatch.type == locallyServed then

        let nbmaAddr == arp(request.dIPa) do

          if nbmaAddr then

            genPosAuthReply(request.sIPa, request.dIPa, nbmaAddr)

          else

            genNegAuthReply(request.sIPa, request.dIPa)

          end

        end

      elseif bestMatch.type == nasLearned then

        if not requestForAuthInfo?(request) or

          realBusyRightNow?() then

        let cacheMatch == matchCacheTable(request.dIPa) do

          if cacheMatch and

            (not requestForAuthInfo?(request) or

              realRecentCacheEntry?(cacheMatch)) then

          if cacheMatch.nbmaAddr == EMPTY then

            genNegNonAuthReply(request.sIPa, request.dIPa)

          else

            genPosNonAuthReply(request.sIPa, request.dIPa,

              cacheMatch.nbmaAddr)

          end

        else /* pas de correspondance dans l’antémémoire */

          forwardRequest(request, bestMatch.OutIf,

            bestMatch.OutIfAddr)

        end

      end

    else /* demande des information d’autorité */

      forwardRequest(request, bestMatch.OutIf,

        bestMatch.OutIfAddr)

    end

  else /* bestMatch.type == externallyLearned */

    genNegAuthReply(request.sIPa, request.dIPa)

  end

 else /* pas de correspondance dans le tableau de transmission */

   genNegAuthReply(request.sIPa, request.dIPa)

  end

 end

end

procedure processReply(reply);

  addCacheTableEntry(reply.dIPa, reply.nbmaAddr, currentTime);

  if reply.sIPa == selfIpAddr then /* la réponse est au NAS lui-même */

  else

    let bestMatch == matchForwardingTable(reply.sIPa) do

      if bestMatch then

        forwardReply(reply, bestMatch.outIf, bestMatch.outIfAddr)

      end

    end

  end

end

La sémantique de la procédure utilisée dans le pseudocode est expliquée ci-dessous.

matchForwardingTable(ipAddress) retourne l’entrée du tableau de transmission dont le champ networkLayerAddrPrefix a la plus longue correspondance pour ipAddress ou FAUX si aucune correspondance n’est trouvée.

arp(ipAddress) résout l’adresse NBMA qui correspondant à ipAddress. Il retourne FAUX si la résolution échoue.

genPosAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) et genPosNonAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) génèrent une réponse positive, d’autorité et non d’autorité avec sourceIpAddr, destIpAddr, et destNbmaAddr dans les champs Adresse IP de source, Adresse IP de destination, et Adresse NBMA, respectivement. genNegAuthReply(sourceIpAddr, destIpAddr) et genNegNonAuthReply(sourceIpAddr, destIpAddr) génèrent respectivement une réponse négative, d’autorité et non d’autorité avec sourceIpAddr et destIpAddr respectivement dans les champs Adresse IP de source et Adresse IP de destination.

requestForAuthInfo?(request) vérifie si request est une demande d’informations d’autorité.

realBusyRightNow?() retourne VRAI si le NAS est très chargé et FAUX autrement.

realRecentCacheEntry?(cacheTableEntry) retourne VRAI si l’entrée du tableau d’antémémoire a été très récemment mise à jour et FAUX autrement.

matchCacheTable(ipAddr) retourne une entrée du tableau d’antémémoire dont le champ networkLayerAddr est égal à ipAddr ou FAUX si aucune correspondance n’est trouvée.

forwardRequest(request, interface, ipAddr) décrémente le champ Compte de bond de la demande, recalcule le champ Somme de contrôle NARP, et transmet la demande à ipAddr de l’interface pourvu que la valeur du champ Compte de bond reste positive.

addCacheTableEntry(ipAddr, nbmaAddr, time) ajoute une nouvelle entrée au tableau d’antémémoire ou subroge une entrée existante dont le champ networkLayerAddr est égal à ipAddr.

forwardReply(reply, interface, ipAddr) décrémente le champ Compte de bond de la demande, recalcule le champ Somme de contrôle NARP, et transmet la réponse à ipAddr de l’interface pourvu que la valeur du champ Compte de bond reste positive.

Comme les NAS, chaque terminal NBMA a un tableau de transmission et un tableau d’antémémoire. Le tableau de transmission est configuré manuellement ou rempli via l’échange d’informations d’accessibilité avec le NAS du terminal ou les routeurs homologues.

Lorsque le terminal souhaite trouver l’adresse NBMA d’un terminal de destination particulier, il vérifie d’abord si une entrée correspondante se trouve dans le tableau de transmission. Si il n’y en a pas, la destination est injoignable et le terminal abandonne. Si il trouve une entrée du tableau de transmission, et si le prochain bond appartient à un des NAS du terminal, le terminal consulte ensuite son tableau d’antémémoire pour obtenir l’adresse NBMA. Si il ne trouve aucune entrée d’antémémoire, le terminal génère une demande NARP au NAS du prochain bond. Si la réponse à la demande NARP est positive, le terminal acquiert l’adresse NBMA et met à jour son tableau d’antémémoire avec les nouvelles informations.

6.   Discussion

La sémantique de NARP ressemble étroitement à la sémantique de ATMARP décrite dans la [RFC1577]. Les seules différences réelles sont :

-   Les demandes et réponses NARP comportent un compte de bonds pour les empêcher de faire des boucles sans fin dans le cas d’une mauvaise configuration de NAS.

-   Les demandes et réponses NARP font la distinction entre les informations d’autorité et non d’autorité.

Afin que les terminaux NBMA restent aussi simples que possible, il serait souhaitable d’étendre un peu le protocole ATMARP de façon qu’il puisse être aussi utilisé comme protocole de terminal-NAS. Cela pourrait facilement se faire en ajoutant juste trois nouveaux codes d’opération à ATMARP pour couvrir les différentes sortes d’interrogations et de réponses. NARP deviendait alors le protocole NAS-NAS. Finalement, si les NAS sonte co-localisés avec les serveurs ARP ATM "classiques", les terminaux n’auraient besoin de faire aucune distinction entre sous-réseau IP local et étranger.

Les NAS peuvent aussi agir comme des "serveurs sans connexion" pour les terminaux en leur annonçant toutes les destinations sans distinguer si elles sont à l’intérieur ou à l’extérieur du NBMA desservi. Le terminal pourrait ensuite choisir d’essayer de résoudre l’adresse NBMA de la destination ou juste d’envoyer les paquets IP au NAS. Cette dernière option peut être désirable si la communication avec la destination est de courte durée et n’exige pas beaucoup de ressources du réseau.

NARP prend en charge la portabilité des terminaux NBMA. Un terminal peut être déplacé en tout endroit du réseau NBMA et toujours conserver son adresse IP d’origine tant que son ou ses NAS restent les mêmes. Les demandes d’informations d’autorité vont toujours retourner l’adresse NBMA correcte.

Références

[RFC0826]   D. Plummer, "Protocole de résolution d’adresses Ethernet : conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur un matériel Ethernet", STD 37, novembre 1982.

[RFC1577]   M. Laubach, "IP classique et ARP sur ATM", janvier 1994.

[RFC1209]   D. Piscitello et J. Lawrence, "Transmission de datagrammes IP sur le service SMDS", STD 52, mars 1991.

Remerciements

Nous tenons à remercier John Burnett de Adaptive, Dennis Ferguson de ANS, Joel Halpern de Network Systems, et Paul Francis de Bellcore de leurs apports et commentaires précieux aux précédentes versions de ce projet.

Security Considerations

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

Adresse des auteurs