3. Spécification fonctionnelle de RSVP
3.11 Interfaces RSVP
RSVP sur un routeur a des interfaces pour acheminer et pour contrôler le trafic. RSVP sur un hôte a une interface avec les applications (c'est-à-dire, une API) et aussi une interface avec le contrôle de trafic (si il existe sur l'hôte).
3.11.1 Interface application/RSVP
Ce paragraphe décrit une interface générique entre une application et un processus de contrôle RSVP. Les détails d'une interface réelle peuvent dépendre du système d'exploitation ; ce qui suit suggère seulement les fonctions de base à effectuer.
Certains de ces appels causent un retour asynchrone des informations.
o Enregistrer une session
Appel : SESSION( DestAddress , ProtocolId, DstPort [ , SESSION_object ] [ , Upcall_Proc_addr ] ) -> Session-id Cet appel initie un traitement RSVP pour une session, définie par une DestAddress ainsi qu'un ProtocolId et éventuellement un numéro d'accès DstPort. S'il réussit, l'appel SESSION retourne immédiatement avec un identifiant de session locale Session-id, qui peut être utilisé dans les appels ultérieurs.
Le paramètre Upcall_Proc_addr définit l'adresse d'un rappel de procédure pour recevoir une notification asynchrone d'erreur ou d'événement ; voir ci-dessous. Le paramètre SESSION_object est inclus comme mécanisme d'échappement pour la prise en charge d'une définition plus générale de la session ("accès de destination généralisé") si cela devait devenir nécessaire à l'avenir. Normalement, SESSION_object sera omis.
o Définir l'envoyeur
Appel : SENDER( Session-id [ , Source_Address ] [ , Source_Port ] [ , Sender_Template ] [ , Sender_Tspec ] [ , Adspec ] [ , Data_TTL ] [ , Policy_data ] )
Un envoyeur utilise cet appel pour définir, ou modifier la définition des attributs d'un flux de données. Le premier appel SENDER pour la session enregistré comme "Session-id" va causer l'envoi de messages Path par RSVP pour cette session ; les appels ultérieurs vont modifier les informations de chemin.
Les paramètres SENDER sont interprétés comme suit : - Source_Address
C'est l'adresse de l'interface d'où les données seront envoyées. Si il est omis, on utilisera une interface par défaut. Ce paramètre est nécessaire seulement sur un hôte envoyeur à rattachements multiples.
- Source_Port
C'est l'accès UDP/TCP à partir duquel les données sont envoyées.
- Sender_Template
Ce paramètre est inclus dans un mécanisme d'échappement pour prendre en charge une définition plus générale de l'envoyeur ("accès de source généralisé"). Normalement, ce paramètre peut être omis.
- Sender_Tspec
Ce paramètre décrit le flux de trafic à envoyer, voir la [RFC2210].
- Adspec
Ce paramètre peut être spécifié pour initialiser le calcul des propriétés de QS le long du chemin ; voir [RFC2210].
- Data_TTL
C'est le paramètre Durée de vie IP (pas par défaut) qui est fourni sur les paquets de données. Il est nécessaire pour s'assurer que les messages Path n'ont pas une portée plus grande que celle des paquets de données en diffusion groupée.
- Policy_data
Ce paramètre facultatif passe les données de politique pour l'envoyeur. Ces données peuvent être fournies par un service système, l'application le traitant comme opaque.
o Réservé
Appel : RESERVE( session-id, [ receveur_adress , ] [ CONF_flag, ] [ Policy_data, ] style, style-dependent-parms ) Un receveur utilise cet appel pour faire ou modifier une réservation de ressource pour la session enregistrée comme
"session-id". Le premier appel RESERVE va initier la transmission périodique de messages Resv. Un appel RESERVE ultérieur peut être fait pour modifier les paramètres de l'appel antérieur (mais noter que changer les réservations existantes peut résulter en des défaillances du contrôle d'admission).
Le paramètre facultatif "receveur_adresse" peut être utilisé par un receveur sur un hôte (ou routeur) multi rattachement ; c'est l'adresse IP de l'une des interfaces du nœud. Le fanion CONF_flag devrait être établi si une confirmation de réservation est désirée, et à zéro autrement. Le paramètre "Policy_data" spécifie les données de politique pour le receveur, alors que le paramètre "style" indique le style de la réservation. Le reste des paramètres dépend du style ; ce seront généralement les flowspec et spec de filtre appropriées.
L'appel RESERVE est retourné immédiatement. À la suite d'un appel RESERVE, une invocation asynchrone ERROR/EVENT peut survenir à tout moment.
o Libération
Appel : RELEASE( session-id )
Cet appel supprime l'état RSVP pour la session spécifiée par session-id. Le nœud envoie alors les messages de suppression appropriés et cesse d'envoyer des messages de rafraîchissement pour ce session-id.
o Rappels d'erreur/événement
La forme générale d'un rappel est la suivante :
Rappel : <Upcall_Proc>( ) -> session-id, Info_type, information_parameters
Ici, "Upcall_Proc" représente la procédure de rappel dont l'adresse a été fournie dans l'appel SESSION. Ce rappel peut survenir en asynchrone à tout moment après un appel SESSION et avant un appel RELEASE, pour indiquer une erreur ou un événement.
Actuellement, il y a cinq types de rappel, distingués par le paramètre Info_type. Le choix des paramètres d'information dépend du type.
1. Info_type = PATH_EVENT
Un rappel d'événement de chemin résulte de la réception du premier message Path pour cette session, indiquant à une application receveuse qu'il y a au moins un envoyeur actif, ou si l'état du chemin change.
Rappel : <Upcall_Proc>( ) -> session-id, Info_type=PATH_EVENT, Sender_Tspec, Sender_Template [ , Adspec ] [ , Policy_data ]
Ce rappel présente le Sender_Tspec, le Sender_Template, le Adspec, et toutes données de politique d'un message Path.
2. Info_type = RESV_EVENT
Un rappel d'événement de réservation est déclenché par la réception du premier message RESV, ou par la modification d'un état de réservation précédent, pour cette session.
Rappel : <Upcall_Proc>( ) -> session-id, Info_type=RESV_EVENT, Style, Flowspec, Filter_Spec_list [ , Policy_data ]
Ici, "Flowspec" va être la QS effective qui a été reçue. Noter qu'un message Resv de style FF peut résulter en plusieurs rappels RESV_EVENT, un pour chaque descripteur de flux.
3. Info_type = PATH_ERROR
Un événement Erreur de chemin indique une erreur dans les informations d'envoyeur qui étaient spécifiées dans un appel SENDER.
Rappel : <Upcall_Proc>( ) -> session-id, Info_type=PATH_ERROR, Error_code , Error_value , Error_Node , Sender_Template [ , Policy_data_list ]
Le paramètre Error_code va définir l'erreur, et Error_value peut fournir des données supplémentaires (peut-être spécifiques du système) sur l'erreur. Le paramètre Error_Node va spécifier l'adresse IP du nœud qui a détecté l'erreur. Le paramètre Policy_data_list, s'il est présent, contiendra tous les objets POLICY_DATA du message Path en échec.
4. Info_type = RESV_ERR
Un événement Erreur de réservation indique une erreur dans un message de réservation auquel cette application a contribué.
Rappel : <Upcall_Proc>( ) -> session-id, Info_type=RESV_ERROR, Error_code , Error_value , Error_Node , Error_flags , Flowspec, Filter_spec_list [ , Policy_data_list ]
Le paramètre Error_code va définir l'erreur et Error_value peut fournir des données supplémentaires (peut-être spécifiques du système). Le paramètre Error_Node va spécifier l'adresse IP du nœud qui a détecté l'événement rapporté.
Il y a deux Error_flags : - InPlace
Ce fanion peut être mis pour une défaillance de contrôle d'admission, pour indiquer qu'il y avait, et qu'il y a toujours, une réservation en place au nœud défaillant. Ce fanion est mis au point de défaillance et transmis dans les messages ResvErr.
- NotGuilty
Ce fanion peut être mis pour une défaillance de contrôle d'admission, pour indiquer que la flowspec demandée par ce receveur était strictement inférieure à la flowspec qui a eu l'erreur. Ce fanion est mis à l'API receveuse.
Filter_spec_list et Flowspec contiennent les objets correspondants du descripteur de flux erroné (voir au paragraphe 3.1.8). List_count spécifie le nombre de FILTER_SPECS dans Filter_spec_list. Le paramètre Policy_data_list contient tous les objets POLICY_DATA du message ResvErr.
5. Info_type = RESV_CONFIRM
Un événement Confirmation indique qu'un message ResvConf a été reçu.
Rappel : <Upcall_Proc>( ) -> session-id, Info_type=RESV_CONFIRM, Style, List_count, Flowspec, Filter_spec_list [ , Policy_data ]
Les paramètres sont interprété comme le rappel Erreur de réservation.
Bien que les messages RSVP indiquant des événements de chemin ou de réservation puissent être reçus périodiquement, l'API ne devrait faire le rappel asynchrone correspondant pour l'application que sur la première occurrence ou lorsque les informations à rapporter changent. Tous les événements d'erreur et de confirmation devraient être rapportés à l'application.
3.11.2 Interface de contrôle RSVP/trafic
Il est difficile de présenter une interface générique au contrôle de trafic, parce que les détails de l'établissement d'une réservation dépendent fortement de la technologie particulière de la couche liaison utilisée sur une telle interface.
La fusion des réservations RSVP est nécessaire à cause de la livraison des données en diffusion groupée, qui duplique les paquets de données pour leur livraison sur les différents nœuds de prochain bond. À chacun de ces points de réplication, RSVP doit fusionner les demandes de réservation provenant des prochains bonds correspondants en calculant le
"maximum" de leur flowspec. Chez un routeur ou hôte donné, une ou plusieurs des trois localisations de réplication suivantes peuvent être utilisées.
1. Couche IP
La transmission IP en diffusion groupée effectue la réplication dans la couche IP. Dans ce cas, RSVP doit fusionner les réservations qui sont en place sur les interfaces sortantes correspondantes dans l'ordre pour transmettre une demande vers l'amont.
2. "Le réseau"
La réplication peut avoir lieu en aval du nœud, par exemple, dans un LAN de diffusion, dans des commutateurs de couche liaison, ou dans un maillage de routeurs sans capacité RSVP (voir au paragraphe 2.8). Dans ces cas, RSVP doit fusionner les réservations provenant des différents prochains bonds afin de faire la réservation sur la seule interface sortante. Il doit aussi fusionner les demandes de réservations provenant de toutes les interfaces sortantes afin de transmettre une demande vers l'amont.
3. Pilote de couche liaison
Pour une technologie multi accès, la réplication peut survenir dans le pilote de couche liaison ou la carte d'interface. Par exemple, ce cas peut se produire lorsqu'il y a un circuit virtuel ATM point à point distinct vers chaque prochain bond.
RSVP peut avoir besoin d'appliquer le contrôle de trafic indépendamment à chaque circuit virtuel, sans fusionner les demandes des différents prochains bonds.
En général, ces situations complexes n'ont pas d'impact sur le traitement du protocole qui est exigé par RSVP, excepté pour déterminer exactement quelles demandes de réservation doivent être fusionnées. Il peut être souhaitable d'organiser une mise en œuvre RSVP en deux parties : un cœur qui effectue le traitement indépendant de la couche de liaison, et une couche d'adaptation dépendante de la couche de liaison. Cependant, nous présentons ici une interface générique qui suppose que la réplication ne peut survenir qu'à la couche IP ou dans "le réseau".
o Faire une réservation
Appel : TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec, TC_Adspec, Police_Flags ) -> RHandle [, Fwd_Flowspec]
Le paramètre TC_Flowspec définit la QS désirée effective pour le contrôle d'admission ; sa valeur est calculée comme le maximum sur la flowspecs des différents prochains bonds (voir l'appel Compare_Flowspecs ci-dessous). Le paramètre TC_Tspec définit le Path_Te de Tspec effective d'envoyeur (voir au paragraphe 2.2). Le paramètre TC_Adspec définit l'Adspec effective. Le paramètre Police_Flags porte les trois fanions E_Police_Flag, M_Police_Flag, et B_Police_Flag ; voir au paragraphe 3.8.
Si cet appel est réussi, il établit un nouveau canal de réservation correspondant à RHandle ; autrement, il retourne un code d'erreur. Le nombre opaque RHandle est utilisé par l'appelant pour les références ultérieures à cette réservation. Si le service de contrôle de trafic met à jour la flowspec, l'appel va aussi retourner l'objet mis à jour comme Fwd_Flowspec.
o Modifier une réservation
Appel : TC_ModFlowspec( Interface, RHandle, TC_Flowspec, TC_Tspec, TC_Adspec, Police_flags ) [ ->
Fwd_Flowspec ]
Cet appel est utilisé pour modifier une réservation existante. La TC_Flowspec est passée au contrôle d'admission ; si elle est rejetée, la flowspec actuelle reste en vigueur. Les spec de filtre correspondantes, s'il en est, ne sont pas affectées.
Les autres paramètres sont définis comme dans TC_AddFlowspec. Si le service met à jour la flowspec, l'appel va aussi retourner l'objet mis à jour comme Fwd_Flowspec.
o Supprimer une Flowspec
Appel : TC_DelFlowspec( Interface, RHandle )
Cet appel va supprimer une réservation existante, y compris la flowspec et toutes les spec de filtre associées.
o Ajouter une spec de filtre
Appel : TC_AddFilter( Interface, RHandle, Session , FilterSpec ) -> FHandle
Cet appel est utilisé pour associer une spec de filtre supplémentaire à la réservation spécifiée par le RHandle donné, suite à un appel TC_AddFlowspec réussi. Cet appel retourne un traitement de filtre FHandle.
o Supprimer une spec de filtre
Appel : TC_DelFilter( Interface, FHandle )
Cet appel est utilisé pour retirer un filtre spécifique, spécifié par FHandle.
o Mise à jour d'OPWA
Appel : TC_Advertise( Interface, Adspec, Non_RSVP_Hop_flag ) -> New_Adspec
Cet appel est utilisé pour que l'OPWA calcule l'annonce sortante New_Adspec pour une interface spécifiée. Le bit de fanion Non_RSVP_Hop_flag devrait être établi chaque fois que le démon RSVP détecte que le précédent bond RSVP comporte un ou plusieurs routeurs sans capacité RSVP. TC_Advertise va insérer cette information dans New_Adspec pour indiquer qu'il a été trouvé un bond sans intégration de service ; voir au paragraphe 3.8.
o Rappel de préemption
Rappel : TC_Preempt() -> RHandle, Reason_code
Afin d'accorder une nouvelle demande de réservation, les modules de contrôle d'admission et/ou de contrôle de politique peuvent préempter une ou plusieurs réservations existantes. Cela va déclencher un rappel TC_Preempt() à RSVP pour chaque réservation préemptée, qui passe le RHandle de la réservation et un sous code qui en indique la raison.
3.11.3 Interface RSVP/contrôle de politique
Cette interface sera spécifiée dans un document à paraître.
3.11.4 Interface RSVP/acheminement
Une mise en œuvre RSVP doit avoir le soutien des mécanismes d'acheminement du nœud suivants.
o Interrogation de chemin
Pour transmettre les messages Path et PathTear, un processus RSVP doit être capable d'interroger le ou les processus d'acheminement sur les chemins.
Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) -> OutInterface Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) -> [ IncInterface, ] OutInterface_list
Selon le protocole d'acheminement, l'interrogation peut ne pas dépendre de SrcAddress, c'est-à-dire, de l'adresse IP de l'hôte envoyeur, qui est aussi l'adresse IP de source du message. Ici, IncInterface est l'interface à travers laquelle le paquet est supposé arriver ; certains protocoles d'acheminement de diffusion groupée peuvent ne pas le fournir. Si le Notify_flag est Vrai, l'acheminement va conserver l'état nécessaire pour produire des rappels non sollicités de notification de changement de chemin (voir ci-dessous) chaque fois que le chemin spécifié change.
Une interrogation de chemin de diffusion groupée peut retourner une OutInterface_list vide si il n'y a pas de receveur en aval d'un routeur particulier. Une interrogation de chemin peut aussi retourner une erreur "Pas de tel chemin", probablement par suite d'une incohérence transitoire de l'acheminement (parce qu'un message Path ou PathTear est arrivé à ce nœud pour le chemin demandé). Dans l'un et l'autre cas, l'état local devrait être mis à jour comme demandé par le message, qui ne peut pas être transmis plus loin. La mise à jour de l'état local va rendre l'état de chemin immédiatement disponible pour un nouveau receveur local, ou il va supprimer immédiatement l'état de chemin.
o Notification de changement de chemin
Si c'est demandé par une interrogation de chemin avec le fanion Notify_flag Vrai, le processus d'acheminement peut fournir un rappel asynchrone au processus RSVP qui indique qu'un chemin spécifié a changé.
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress, OutInterface Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, [ IncInterface, ] OutInterface_list
o Découverte de liste d'interfaces
RSVP doit être capable d'apprendre quelles interfaces réelles et virtuelles sont actives, avec leur adresse IP.
Il devrait être possible de désactiver logiquement une interface pour RSVP. Lorsque une interface est désactivée pour RSVP, un message Path ne devrait jamais être transmis de cette interface, et si un message RSVP est reçu sur cette interface, le message devrait être éliminé en silence (peut être avec un enregistrement de journalisation local).
3.11.5 Interface d'entrée/sortie RSVP/paquet
Une mise en œuvre RSVP a besoin du soutien des mécanismes d'entrée/sortie de paquets et de transmission du nœud suivants.
o Mode de réception de proximité pour les messages RSVP
Les paquets reçus pour le protocole IP 46 mais non adressés au nœud doivent être déviés sur le programme RSVP pour traitement, sans être transmis. Les messages RSVP à dévier de cette manière incluront les messages Path, PathTear, et ResvConf. Ces types de message portent l'option IP Alerte de routeur qui peut être utilisée pour les extraire d'un chemin de transmission à grande vitesse. Autrement, le nœud peut intercepter tous les paquets du protocole 46.
Sur un routeur ou hôte multi rattachement, l'identité de l'interface (réelle ou virtuelle) sur laquelle un message dévié est reçu, ainsi que l'adresse IP de source et le TTL IP avec lesquels il est arrivé, doivent aussi être disponibles au processus RSVP.
o Spécification de liaison sortante
RSVP doit être capable de forcer l'envoi d'un datagramme (de diffusion groupée) sur une liaison sortante réelle ou virtuelle spécifique, en outrepassant le mécanisme d'acheminement normal. Une liaison virtuelle peut être un tunnel de diffusion groupée, par exemple. La spécification de la liaison sortante est nécessaire pour envoyer des versions différentes d'un message Path sortant sur des interfaces différentes, et pour éviter des boucles d'acheminement dans certains cas.
o Spécification d'adresse de source et TTL
RSVP doit être capable de spécifier l'adresse IP de source et la TTL IP à utiliser lors de l'envoi de messages Path.
o Alerte de routeur
RSVP doit être capable de causer l'envoi de messages Path, PathTear, et ResvConf avec l'option IP Alerte de routeur.
3.11.6 Manipulations dépendantes du service
Les Flowspec, Tspec et Adspec sont des objets opaques pour RSVP ; leur contenu est défini dans des documents de spécification de service. Pour manipuler ces objets, le processus RSVP doit avoir les programmes dépendant du service suivant à sa disposition.
o Comparer les Flowspec
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code
Les result_code possibles indiquent : les flowspec sont égales, la Flowspec_1 est supérieure, la Flowspec_2 est supérieure, les flowspec sont incomparables mais le LUB peut être calculé, ou les flowspec sont incompatibles
Noter que comparer deux flowspec compare implicitement les Tspec qui sont contenues. Bien que le processus RSVP ne puisse pas par lui-même analyser une flowspec pour extraire la Tspec, il peut utiliser l'invocation Compare_Flowspecs pour calculer implicitement Resv_Te (voir au paragraphe 2.2).
o Calculer le LUB des Flowspec
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> Flowspec_LUB o Calculer le GLB des Flowspec
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> Flowspec_GLB o Comparer les Tspec
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
Les result_codes possibles indiquent : les Tspec sont égales, ou les Tspec sont inégales.
o Faire la somme des Tspec
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
Cette invocation est utilisée pour calculer Path_Te (voir au paragraphe 2.2).