Groupe de travail Réseau

Protocole d'allocation de bande passante en PPP (BAP) / Protocole de contrôle d'allocation de bande passante en PPP (BACP)

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document propose une méthode de gestion de l'allocation dynamique de bande passante des mises en œuvre qui prennent en charge le protocole multiliaison PPP [RFC1990]. Cela se fait en définissant le protocole d'allocation de bande passante (BAP, Bandwidth Allocation Protocol) ainsi que son protocole de contrôle associé, le protocole de contrôle d'allocation de bande passante (BACP, Bandwidth Allocation Control Protocol). BAP peut être utilisé pour gérer le nombre de liaisons dans un faisceau multiliaisons. BAP définit des datagrammes pour coordonner l'ajout et la suppression des liaisons individuelles dans un faisceau multi liaisons, ainsi qu'en spécifiant quel homologue est responsable des décisions concernant la gestion de la bande passante durant une connexion multi liaisons.

Table des matières

1. Introduction 1

1.1 Spécification des exigences 2

1.2 Terminologie 2

2. Nouvelle option de configuration LCP 2

2.1 Discriminant de liaison 2

3. Fonctionnement de BACP 3

4. Options de configuration de BACP 3

4.1 Homologue favori 3

5. Fonctionnement de BAP 4

5.1 Gestion des liaisons 4

5.2 Gestion de la bande passante 5

5.3 Paquets BAP 5

5.4 Conditions de concurrence 5

5.5 Format de datagramme BAP 6

6. Options de datagramme BAP 9

6.1 Type-de-liaison 9

6.2 Delta téléphone 10

6.3 Pas-besoin-de-numéro-de-téléphone 11

6.4 Raison 11

6.5 Discriminant-de-liaison 12

6.6 État d'appel 12

Appendice 13

Historique de BACP 13

Remerciements 13

Considérations pour la sécurité 13

Références 13

Comme les mises en œuvre de PPP multiliaison deviennent de plus en plus communes, il y a un besoin croissant d'une certaine conformité dans la façon de gérer la bande passante sur de telles liaisons. BACP et BAP fournissent un moyen souple mais robuste pour gérer la bande passante entre deux homologues. BAP le fait en définissant des paquets de commande d'appel et un protocole qui permet aux homologues de coordonner l'allocation et la désallocation réelles de bande passante. Les deltas de numéros de téléphone PEUVENT être passés dans les paquets de commande d'appel pour minimiser la configuration des utilisateurs finaux.

Dans le présent document, plusieurs mots sont utilisés pour signifier les exigences de la spécification. Ces mots sont souvent en majuscules.

DOIT Ce mot, ou le verbe "exiger", signifie que la définition est une exigence absolue de la spécification.

NE DOIT PAS Cette phrase signifie que la définition est une interdiction absolue de la spécification.

DEVRAIT Ce mot, ou le verbe "recommander", signifie qu'il peut exister des raisons valides dans des circonstances particulières pour ignorer cet élément, mais toutes les implications doivent en être comprises et soigneusement soupesées avant de choisir une voie différente.

PEUT Ce mot, ou l'adjectif "facultatif", signifie que cet élément fait partie d'un ensemble admis de solutions de remplacement. Une mise en œuvre qui ne comporte pas cette option DOIT être prête à interopérer avec une autre mise en œuvre qui comporte l'option.

éliminer en silence : cela signifie que la mise en œuvre élimine le paquet sans autre traitement. La mise en œuvre DEVRAIT fournir la capacité d'enregistrer l'erreur dans un journal d'événements, y compris le contenu du paquet éliminé en silence, et DEVRAIT enregistrer l'événement dans un compteur de statistiques.

BOD (bande passante à la demande) : BOD se réfère à la capacité d'un système à allouer et supprimer des liaisons dans un système multiliaisons pour changer la bande passante d'un faisceau multiliaison. Cela peut se faire en réponse à des conditions de ligne changeantes et cela peut aussi être fait en réponse à des changements de conditions de ressources. Dans l'un et l'autre cas, le changement dynamique de bande passante durant une connexion multiliaison est désigné comme BOD.

Les mises en œuvre DOIVENT utiliser le protocole de contrôle des liaisons (LCP, Link Control Protocol) comme défini dans la [RFC1661]. LCP DOIT être dans la phase de protocole de couche réseau avant que BACP puisse être négocié.

Cette option de configuration de LCP est utilisée pour déclarer un discriminant unique pour la liaison sur laquelle l'option est envoyée. Cette option DOIT être négociée par le LCP sur chaque liaison. BAP utilise le discriminant de liaison pour différencier les diverses liaisons dans un faisceau multiliaison. Chaque liaison dans un faisceau multiliaison DOIT avoir un discriminant unique. Le discriminant est indépendant pour chaque homologue, de sorte que chaque liaison PEUT avoir deux valeurs de discriminant de liaison LCP différentes, une pour chaque homologue. Lorsque le discriminant de liaison est envoyé dans un paquet BAP, l'émetteur envoie la valeur de l'option Discriminant de liaison reçue de son homologue dans le paquet Demande de configuration de LCP de l'homologue.

Un schéma du format de l'option LCP de discriminant de liaison figure ci-dessous. Les champs sont transmis de gauche à droite.

Le champ Discriminant de liaison est de deux octets, et il contient un identifiant unique utilisé pour indiquer une liaison particulière dans un faisceau multiliaison. Le discriminant de liaison pour une liaison DOIT être unique parmi les discriminants de liaison alloués par ce point d'extrémité pour ce faisceau. Le discriminant de liaison PEUT être alloué de façon séquentielle, à accroissement monotone.

BACP utilise le même mécanisme d'échange de paquets que le protocole de contrôle de liaison défini dans la [RFC1661]. Les paquets BACP sont échangés jusque à ce que PPP ait atteint la phase de protocole de couche réseau. Les paquets BACP reçus avant que cette phase soit atteinte DEVRAIENT être éliminés en silence.

BACP est négocié une fois par faisceau multiliaison. Si BACP est négocié sur une des liaisons d'un faisceau multiliaison, il est ouvert pour toutes les liaisons du faisceau.

Le protocole de contrôle d'allocation de bande passante est exactement le même que le protocole de contrôle de liaison [RFC1661] avec les exceptions suivantes :

Exactement un paquet BACP est encapsulé dans le champ Information des trames de couche Liaison de données de PPP où le champ Protocole indique le type hex c02b (protocole de contrôle d'allocation de bande passante).

Seuls les codes de 1 à 7 (Demande de configuration (Configure-Request), Acquittement de configuration (Configure-Ack), Non acquittement de configuration (Configure-Nak), Rejet de configuration (Configure-Reject), Demande de terminaison (Terminate-Request), Acquittement de terminaison (Terminate-Ack) et Code rejeté (Code-Reject)) sont utilisés. Les autres codes DEVRAIENT être traités comme non reconnus et DEVRAIENT résulter en un Code rejeté.

BACP a un ensemble distinct d'options de configuration, qui sont définies à la section suivante.

Les options de configuration de BACP permettent la négociation des paramètres BACP désirables. Ces options sont utilisées dans les paquets Demande de configuration, Accusé de réception de configuration, Non acquittement de configuration, et Rejet de configuration. BACP utilise le même format d'option de configuration que celui défini pour LCP [RFC1661], avec un ensemble d'options distinct.

Les valeurs actuelles des options de configuration de BACP sont allouées comme suit :

Cette option de configuration est utilisée pour déterminer quel homologue sera favorisé dans le cas d'une condition de concurrence dans laquelle deux homologues transmettent simultanément la même demande BAP. Chaque homologue négocie un numéro magique de quatre octets, qui est négocié avec succès lorsque les deux numéros magiques sont différents. L'homologue favori est celui qui transmet le numéro magique le plus faible dans son option de configuration Homologue favori.

BACP ne va normalement être négocié qu'après qu'une liaison d'un faisceau multiliaison a atteint la phase de protocole de couche réseau. Dans cette situation, il est acceptable pour l'homologue qui a initié la connexion d'utiliser un numéro magique de 1, et pour l'homologue qui a répondu à la connexion d'utiliser un numéro magique de 0xFFFFFFFF. Si un faisceau multiliaison a été établi avec des liaisons qui ont été générées par chaque homologue, ou si on ne sait pas trop quel homologue a initié une liaison (sur une ligne louée, par exemple) un nombre aléatoire DOIT être utilisé comme numéro magique. Se reporter à la description de l'option de configuration Numéro magique LCP dans la [RFC1661] pour une explication de la façon de créer un nombre aléatoire utile.

Lorsque une demande de configuration est reçue avec une option de configuration Homologue favori, le numéro magique reçu est comparé au numéro magique de la dernière demande de configuration envoyée à l'homologue. Si les deux numéros magiques sont différents, la négociation d'homologue favori a alors réussi, et l'option Homologue favori DEVRAIT être acquittée. Si les deux numéros magiques sont égaux, un Non acquittement de configuration DOIT être envoyé pour spécifier une valeur de numéro magique différente. Une nouvelle Demande de configuration NE DEVRAIT PAS être envoyée à l'homologue tant que le traitement normal l'amènerait à l'envoyer (c'est à dire, jusqu'à ce qu'un Non acquittement de configuration soit reçu ou que le temporisateur de redémarrage arrive à expiration).

Un schéma du format de l'option Homologue favori est montré ci-dessous. Les champs sont transmis de gauche à droite.

Le champ Numéro magique est de quatre octets, et indique un nombre qui va très vraisemblablement être unique pour une extrémité de la liaison. Un numéro magique de zéro est illégal et DOIT toujours recevoir un non accusé de réception.

BAP définit les paquets, paramètres et procédures de négociation pour permettre à deux points d'extrémité de négocier en douceur l'ajout et la suppression de liaisons d'un faisceau multiliaison. Une mise en œuvre peut :

o demander la permission d'ajouter une liaison à un faisceau (Demande d'appel, Call-Request)

o demander que l'homologue ajoute une liaison à un faisceau via un rappel (Demande de rappel, Callback-Request)

o négocier avec l'homologue l'abandon d'une liaison sur un faisceau (cela implique que l'homologue puisse refuser) (Demande-d'interrogation-d'abandon-de-liaison, Link-Drop-Query-Request)

Après que BACP a atteint l'état ouvert, l'un ou l'autre homologue PEUT demander que une autre liaison soit ajoutée au faisceau en envoyant un paquet BAP Demande d'appel ou de rappel. Un paquet Demande d'appel est envoyé si la mise en œuvre souhaite générer l'appel pour la nouvelle liaison, et un paquet Demande de rappel est envoyé si la mise en œuvre souhaite que l'homologue génère l'appel pour la nouvelle liaison. La mise en œuvre qui reçoit une Demande d'appel ou de rappel DOIT répondre par une Réponse d'appel ou de rappel avec un code de réponse valide.

Après que BACP a atteint l'état ouvert, l'un ou l'autre homologue PEUT demander qu'une liaison soit abandonnée sur le faisceau. Un paquet BAP Demande d'interrogation d'abandon de liaison est envoyé à l'homologue pour négocier l'abandon d'une liaison. L'homologue DOIT répondre par une Réponse d'interrogation d'abandon de liaison (Link-Drop-Query-Response). Si l'homologue est d'accord pour abandonner la liaison, la mise en œuvre DOIT produire une demande de terminaison (Terminate-Request) LCP pour initier l'abandon de la liaison.

Si une mise en œuvre souhaite forcer l'abandon d'une liaison sans négociation, elle DEVRAIT simplement envoyer un paquet Demande de terminaison LCP sur la liaison (sans envoyer de Demande d'interrogation d'abandon de liaison BAP).

Après l'envoi d'une Demande de terminaison LCP, une mise en œuvre DEVRAIT arrêter l'émission de paquets de données sur cette liaison, mais continuer de recevoir et traiter les paquets de données normalement jusqu'à reception d'un Acquittement de terminaison provenant de l'homologue. Le receveur d'une Demande de terminaison LCP DEVRAIT arrêter de transmettre des paquets avant de produire l'acquittement de terminaison. Cette procédure assurera qu'aucune donnée n'est perdue dans l'une et l'autre direction.

BAP permet à deux mises en œuvre homologues de gérer la bande passante disponible pour les protocoles qui utilisent le faisceau multiliaison en négociant quand ajouter et supprimer les liaisons (voir la gestion de liaison). L'utilisation des caractéristiques de négociation de BAP fait qu'il n'est pas nécessaire d'exiger un algorithme "commun" pour déterminer quand ajouter et supprimer des liaisons dans un faisceau multiliaison.

Les décisions de BOD peuvent se fonder sur l'utilisation de la liaison. Une mise en œuvre de BAP PEUT surveiller son trafic émis, le trafic émis et reçu, ou choisir de ne surveiller le trafic dans aucune des deux directions. Si un système serveur met en œuvre la surveillance bidirectionnelle, il va permettre le fonctionnement de la BOD avec un client qui ne surveille pas le trafic dans l'une ou l'autre direction, ce qui va minimiser la configuration de l'usager final. Lorsque une mise en œuvre décide qu'il est temps de supprimer une liaison du fait de la surveillance du trafic, elle DOIT transmettre une Demande-d'interrogatio-d'abandon-de-liaison pour savoir si l'homologue est d'accord avec l'abandon d'une liaison sur le faisceau multiliaison en cours. Lorsque une mise en œuvre reçoit une Demande-d'interrogatio-d'abandon-de-liaison, elle DEVRAIT fonder sa réponse sur le trafic qu'elle surveille. Elle ne fonde sa réponse que sur l'heuristique des données reçues.

Le fonctionnement des datagrammes Demande-d'interrogatio-d'abandon-de-liaison et Réponse- fait qu'une liaison dans un faisceau multiliaison est laissée en place tant que l'une ou l'autre mise en œuvre qui surveille l'utilisation de la liaison estime qu'elle est nécessaire.

Les décisions de BOD peuvent aussi se fonder sur les ressources disponibles (par exemple, accès physique, canal B, etc.) pour une mise en œuvre. Par exemple, une mise en œuvre pourrait supprimer une liaison d'un faisceau multiliaison pour satisfaire à un appel vocal entrant, ou pourrait ajouter une liaison lorsque une ligne se libère du fait de la terminaison d'un appel PPP distinct sur un autre accès. Une mise en œuvre DOIT utiliser une Demande de terminaison LCP pour supprimer une liaison suite à une condition de ressource.

Tous les paquets BAP Demande et Indication exigent un paquet Réponse en réponse avant toute action.

Une mise en œuvre DOIT établir un temporisateur lors de l'envoi d'un paquet Demande ou Indication. La valeur de ce temporisateur DEVRAIT dépendre du type et de la vitesse de la ou des liaisons utilisées. À expiration de ce temporisateur, la mise en œuvre DOIT retransmettre la demande ou l'indication, avec un numéro d'identification identique. Cette procédure va assurer que l'homologue reçoit la demande ou indication appropriée même si un paquet est perdu durant la transmission. Si un paquet de réponse est perdu, l'homologue va réaliser que ce n'est pas un paquet de nouvelle demande ou d'indication.

Si le nombre de retransmissions excède le nombre accepté par la mise en œuvre pour ce paquet, la mise en œuvre PEUT entreprendre l'action de récupération appropriée. Par exemple, si aucune réponse n'est reçue à une Demande-d'interrogatio-d'abandon-de-liaison après deux retransmissions, une mise en œuvre PEUT initier l'abandon de la liaison par l'envoi d'une Demande de terminaison LCP pour cette liaison.

Comme les paquets BAP aident à déterminer la quantité de bande passante disponible pour une mise en œuvre, PPP DEVRAIT leur donner priorité sur les autres paquets de données lors de la transmission. Cela va aider à assurer la rapidité de l'ajout et du retrait des liaisons dans un faisceau multiliaison. Ceci est particulièrement important lors de l'ajout de liaisons à un faisceau du fait de contraintes de bande passante.

Afin de résoudre les conditions de concurrence, une mise en œuvre DOIT prendre en charge l'option BACP Configuration d'homologue favori (Favored-Peer Configuration).

Une condition de concurrence peut survenir si les deux mises en œuvre envoient au même moment une Demande-d'appel, une Demande-de-rappel ou une Demande-d'interrogatio-d'abandon-de-liaison. Ces conditions de concurrence DEVRAIENT être résolues comme suit :

Si chaque mise en œuvre envoie une Demande-d'appel ou Demande-de-rappel au même moment, la mise en œuvre avec la plus faible valeur de numéro magique BACP Homologue-favori DEVRAIT avoir la priorité.

Si chaque mise en œuvre envoie en même temps une Demande-d'interrogation-d'abandon-de-liaison, le même schéma que pour Demande-d'appel DEVRAIT être utilisé.

Avant que tout paquet BAP PUISSE être communiqué, PPP DOIT atteindre la phase de protocole Couche réseau, et BACP DOIT atteindre l'état Ouvert.

Exactement un paquet BAP est encapsulé dans le champ Information des trames liaison de données de PPP où le champ Protocole indique le type hexadécimal c02d (Protocole d'allocation de bande passante).

Parce que les adaptateurs de terminal RNIS sont parfois utilisés pour faire du multi-liaison avec un client sans capacité multi-liaison, les datagrammes BAP NE DOIVENT PAS être compressés ou chiffrés. Autrement, l'adaptateur de terminal RNIS ne PEUT pas être capable d'intercepter de façon appropriée les datagrammes BAP nécessaires pour le contrôle de la connexion multi-liaison. Ceci se réfère à la compression d'un datagramme entier ; compression de champs d'adresse et de contrôle et compression de champ de protocole sont permises à condition d'une négociation appropriée.

La longueur maximum d'un paquet BAP transmis sur une liaison PPP est la même que la longueur maximum du champ Information d'une trame PPP de couche liaison des données.

Les datagrammes du protocole d'allocation de bande passante peuvent être catégorisés comme des paquets Demande, Indication ou Réponse. Chaque datagramme Demande et Indication a un paquet Réponse correspondant. Les datagrammes Demande et Indication ont un format légèrement différent du datagramme Réponse, car celui-ci comporte un octet de code Réponse.

Tous les datagrammes BAP DOIVENT être pris en charge par une mise en œuvre. Cependant, cela ne signifie pas qu'une mise en œuvre DOIVE prendre en charge toutes les actions des datagrammes BAP. Une mise en œuvre PEUT envoyer un Rejet-de-demande à une Demande qu'elle ne met pas en œuvre.

La figure ci-dessous résume le format de paquet du datagramme Demande et Indication du protocole d'allocation de bande passante. Les champs sont transmis de gauche à droite.

La figure ci-dessous résume le format de paquet du datagramme Réponse du protocole d'allocation de bande passante. Les champs sont transmis de gauche à droite.

Le champ Type fait un octet et identifie le type du paquet de datagramme BAP. Les types de datagramme sont définis comme suit. Ce champ est codé en hexadécimal codé en binaire.

Les divers types de datagrammes BAP sont expliqués dans les paragraphes qui suivent.

Le champ Identifiant fait un octet et est codé en binaire. Il aide à faire correspondre les Demandes et Indications avec les Réponses. Les paquets Indication-d'état-d'appel DOIVENT utiliser le même identifiant que celui utilisé par la Demande d'appel ou Demande de rappel originale qui a servi à initier l'appel. Tous les autres paquets Demande ou Indication DOIVENT utiliser un identifiant univoque pour chaque nouvelle Demande ou Indication. Tous les paquets Réponse DOIVENT utiliser le même identifiant que celui du paquet Demande ou Indication auquel il est répondu. Lors de la retransmission d'une demande ou d'une indication, l'identifiant DOIT être le même que celui utilisé lors de la précédente transmission de la demande ou indication.

Le champ Longueur fait deux octets et indique la longueur du paquet, y compris les champs Type, Identifiant, Longueur et Options. Il est codé en binaire. Les octets en dehors de la gamme du champ Longueur DEVRAIENT être traités comme du bourrage de couche de liaison des données et DEVRAIENT être ignorés à réception.

Le Code de réponse n'est présent que dans les datagrammes Réponse. Il est codé en binaire et peut avoir les valeurs suivantes :

Le code de réponse Accusé de réception de demande est envoyé pour indiquer que la commande Demande ou Indication est valide et a été bien reçue par une mise en œuvre. Le code de réponse Non accusé de réception de demande est envoyé pour indiquer que la commande Demande a été reçue mais qu'une mise en œuvre ne veut pas que l'action demandée soit effectuée pour le moment. Si une Réponse contenant un code de réponse Non-accusé-de-réception-de-demande est reçue, la demande d'origine PEUT être réessayée après qu'une mise en œuvre a déterminé qu'un temps suffisant s'est écoulé. Le code de réponse Rejet-de-demande est envoyé pour indiquer que la commande Demande qui a été reçue par une mise en œuvre n'est pas mise en œuvre (c'est-à-dire, si la réception d'un type de demande particulier n'est pas acceptée par l'homologue). Le code de réponse Non-accusé-demande-complète est envoyé pour indiquer que la commande Demande a été reçue mais qu'une mise en œuvre ne veut pas effectuer l'action demandée. Le Non-accusé-demande-complète est utilisé pour indiquer qu'une mise en œuvre a atteint le maximum (pour une Demande d'appel ou de rappel) ou le minimum (pour une Demande interrogation d'abandon de liaison) de bande passante configurée ou disponible pour ce faisceau multiliaison. Si une réponse contenant un code de réponse Non-accusé-demande-complète est reçue, la Demande d'origine NE DEVRAIT PAS être réessayée tant que la bande passante totale du faisceau multiliaison n'a pas changé.

Le champ Données est de longueur variable, et va normalement contenir la liste de zéro, une ou plusieurs options BAP que l'envoyeur désire transmettre. Le format des options BAP est décrit plus loin.

Avant de générer un appel pour ajouter une autre liaison à un faisceau multiliaison, une mise en œuvre DOIT transmettre un paquet Demande d'appel. Cela va informer le receveur de la demande d'ajouter une autre liaison au faisceau et donner au receveur une chance d'informer la mise en œuvre du numéro de téléphone d'un accès libre qui peut être appelé.

Le champ options DOIT inclure l'option Type-de-liaison. Le champ options PEUT inclure les options Pas-de-numéro-de-téléphone et/ou Raison.

À réception d'une Demande d'appel, un datagramme Réponse d'appel DOIT être transmis.

Une mise en œuvre DOIT transmettre un datagramme Réponse d'appel en réponse à la réception d'un datagramme Demande d'appel. Si la demande d'appel est acceptable, la réponse d'appel DOIT avoir un code de réponse de Accusé-de-réception-de-demande. L'option Delta-téléphone DOIT être incluse dans un paquet Réponse d'appel avec un code de réponse de Accusé-de-réception-de-demande sauf si la demande d'appel comportait l'option Pas-de-numéro-de-téléphone. Le champ options PEUT inclure les options Raison et/ou Type-de-liaison.

Une mise en œuvre qui veut que son homologue génère une autre liaison à ajouter au faisceau multiliaison DOIT transmettre un paquet Demande de rappel à son homologue. Cela va informer le receveur de la demande d'ajout d'une autre liaison au faisceau ainsi que du numéro à appeler.

Le champ options DOIT inclure les options Type-de-liaison et Delta-téléphone. L'option Raison PEUT aussi être incluse.

À réception d'une demande de rappel, un datagramme Réponse de rappel DOIT être émis.

Une mise en œuvre DOIT émettre un datagramme Réponse de rappel en réponse à la réception d'un datagramme Demande de rappel. Si la demande de rappel est acceptable, la réponse de rappel DOIT avoir un code de réponse de Accusé-de-réception-de-demande. Un paquet Réponse de rappel PEUT inclure l'option Type-de-liaison.

Une mise en œuvre qui détermine qu'une liaison n'est plus nécessaire et souhaite négocier son abandon (par exemple, sur la base d'une décision BOD de débit) DOIT transmettre un paquet Demande-d'interrogatio-d'abandon-de-liaison. Le champ options DOIT inclure l'option Discriminant-de-liaison (contenant le Discriminant-de-liaison du receveur) et PEUT inclure l'option Raison.

À réception d'une Demande-d'interrogatio-d'abandon-de-liaison, une mise en œuvre DOIT transmettre un datagramme Réponse-d'interrogation-d'abandon-de-liaison. Le code de réponse sera Accusé-de-réception-de-demande si il est d'accord pour abandonner la liaison ; si il n'est pas d'accord, le code de réponse sera Non-acquittement-de-demande ou Non-acquittement-demande-complète. Après la réception d'une Réponse-d'interrogation-d'abandon-de-liaison avec un code de réponse de Accusé-de-réception-de-demande, l'émetteur de la Demande-d'interrogatio-d'abandon-de-liaison DOIT initier la suppression de la liaison indiquée par l'envoi d'un paquet LCP Demande de terminaison sur la liaison désignée.

Une mise en œuvre transmet un datagramme Réponse-d'interrogation-d'abandon-de-liaison en réponse à un datagramme Demande-d'interrogation-d'abandon-de-liaison reçu. Si la mise en œuvre est d'accord (par exemple, sur la base de son algorithme BOD de débit) pour réduire la bande passante du faisceau multiliaison, le code de réponse DOIT être réglé à Accusé de réception de demande.

L'option Raison PEUT être incluse dans le paquet Réponse-d'interrogation-d'abandon-de-liaison.

Le datagramme Demande-d'interrogation-d'abandon-de-liaison DOIT être pris en charge, et la mise en œuvre sous-jacente doit aussi y répondre. Cela signifie qu'une Réponse-d'interrogation-d'abandon-de-liaison avec un code de réponse de Rejet-de-demande sera transmis en réponse à une Demande-d'interrogatio-d'abandon-de-liaison.

Après qu'une mise en œuvre a tenté d'ajouter une liaison à un faisceau par suite d'une Demande d'appel ou d'une Demande de rappel, elle DOIT envoyer un paquet Indication-d'état-d'appel à son homologue pour indiquer si la tentative d'ajout de la liaison a réussi ou échoué. Une Indication DOIT être envoyée pour chaque tentative faite. Pour chaque paquet Indication-d'état-d'appel transmis avec l'octet Action d'option d'état d'appel réglé à Réessayer, un paquet suivant Indication-d'état-d'appel DOIT être envoyé pour indiquer la réussite ou l'échec du nouvel essai. L'option État d'appel DOIT être incluse pour informer le receveur de l'état de la tentative d'ajout d'une liaison et de l'action que la mise en œuvre va prendre en cas d'échec. L'option Raison PEUT aussi être incluse dans le paquet Indication-d'état-d'appel.

À réception d'un paquet Indication-d'état-d'appel qui indique un échec, une mise en œuvre PEUT enregistrer l'échec et un code de cause dans le journal des événements. À réception de tout paquet Indication-d'état-d'appel, un datagramme Réponse-d'état-d'appel (Call-Status-Response) DOIT être transmis.

Une mise en œuvre transmet un datagramme Réponse-d'état-d'appel en réponse à la réception d'un datagramme Indication-d'état-d'appel. Le champ Code de réponse DOIT être réglé à Accusé de réception de demande dans ce paquet. L'option Raison PEUT être incluse dans ces paquet.

Les options de datagramme BAP sont utilisées dans divers paquets BAP. Leur utilisation dans les divers paquets est définie ci-dessous. Le format de ces options suit en gros les conventions de format des options de configuration de LCP. Lorsque il y a plusieurs options BAP dans un seul paquet BAP, les options PEUVENT être transmises dans n'importe quel ordre.

Un résumé du format d'option BAP est indiqué ci-dessous. Les champs sont transmis de gauche à droite.

Type : Le champ type est d'un octet, et indique le type de l'option du datagramme BAP. Ce champ est en hexadécimal codé en binaire. Les options suivantes sont actuellement définies :

Longueur : Le champ Longueur fait un octet, et indique la longueur de cette option BAP y compris les champs Type, Longueur, et Données.

Données : Le champ Données est de zéro un ou plusieurs octets, et contient des informations spécifiques de l'option BAP. Le format et la longueur du champ Données est déterminé par les champs Type et Longueur.

Cette option indique le type général de liaison indiqué pour l'opération en cours. Cette option n'indique pas un type spécifique de liaison, mais donne plutôt des caractéristiques générales du type de liaison désiré. Cette option PEUT être utilisée avec d'autres connaissances (c'est-à-dire, le type de la ou des autres liaisons dans le faisceau ou la configuration de l'usager) pour déterminer le type de liaison désiré dans l'opération. EIle DOIT être incluse dans une Demande d'appel ou de rappel, et PEUT être incluse dans une Réponse d'appel ou de rappel.

Un résumé du format de l'option BAP Type de liaison est donné ci-dessous. Les champs sont transmis de gauche à droite.

Le champ Longueur fait un octet, et indique la longueur de cette option BAP y compris les champs Type, Longueur et Type de liaison.

Le champ Vitesse de liaison fait deux octets, et indique la vitesse demandée pour la liaison désirée en kilobits par seconde. Ce champ est codé comme deux octets en hexadécimal codé en binaire, les octets de poids fort envoyés en premier.

Le champ Type de liaison est un gabarit binaire. Il est long d'un octet. Le bit 0 du champ Type de liaison correspond au bit 39 de l'option BAP Type de liaison décrit ci-dessus. Si un bit est établi (à 1), il indique la prise en charge du type de liaison correspondant. Si la liaison indiquée est différente des types de liaison pris en charge, le bit sera à zéro. Autrement, au moins un bit DOIT être établi. Si une mise en œuvre prend en charge plus d'un type de liaison, plus d'un bit PEUT être établi.

Si le champ Longueur contient plus de bits qu'il n'en est défini dans la présente spécification, tous les bits qui ne sont pas définis DEVRAIT alors être ignorés. Afin de permettre l'expansion future de ce champ, il est important de prendre correctement en charge la réception d'un champ Type de liaison plus long que ce qui est défini par la présente spécification. Si le champ Longueur est plus court que le nombre de bits défini, la mise en œuvre DEVRAIT alors régler tous les bits non reçus à 0.

L'option BAP Delta téléphone est utilisée par une mise en œuvre pour donner à son homologue les informations nécessaires pour passer un appel. Du fait de la difficulté de déterminer quels préfixes de numérotation (s'il en est) sont nécessaires pour composer une certaine combinaison de numéro de téléphone/code de destination national/code de pays, le numéro de téléphone à composer sera fondé sur un numéro connu précédent. Cela PEUT être le numéro d'origine utilisé pour établir la première liaison du faisceau multiliaison, un numéro configuré par l'utilisateur, le numéro de téléphone utilisé pour établir une connexion de rappel, ou un nombre déterminé de quelque autre façon. L'option Delta téléphone consistera en une sous option Numéro d'abonné avec une sous option Chiffres uniques qui indique combien des chiffres du numéro d'abonné sont uniques parmi les accès utilisés, précédement utilisés, et à utiliser dans le faisceau multiliaison. Il y a aussi une sous option Sous-adresse-de-numéro-de-téléphone qui est facultative.

Une mise en œuvre PEUT inclure plus d'une option Delta-téléphone dans une réponse. Cela indique qu'il y a plus d'un numéro de téléphone qui peut être utilisé pour l'opération demandée. L'option Delta-téléphone DOIT apparaître dans une Demande de rappel. Elle DOIT aussi apparaître dans une Réponse d'appel avec un code de réponse réglé à Accusé de réception de demande si la Demande d'appel ne contenait pas l'option Pas-de-numéro-de-téléphone. Elle PEUT être incluse dans le paquet Indication-d'état-d'appel.

Un résumé du format de l'option Delta-téléphone figure ci-dessous. Les champs sont transmis de gauche à droite.

Le champ Longueur fait un octet, et indique la longueur de cette option BAP y compris les champs Type, Longueur,et Sous-option.

Les types de sous-option suivants sont définis pour l'option de Delta-téléphone.

Le champ Longueur de sous-option fait un octet, et indique la longueur de cette sous-option BAP y compris les champs Type de sous-option, Longueur de sous-option, et Sous-option+++.

Le champ de sous option Chiffres-uniques consiste en un octet qui est un compte du nombre des chiffres de droite du numéro d'abonné qui sont différents de l'ensemble des numéros de téléphone des accès utilisés dans cette connexion multiliaison. (Par exemple, si le premier accès d'un faisceau multiliaison a un numéro de téléphone de 123456789, et si une mise en œuvre veut que son homologue appelle un accès avec le numéro de téléphone 123456888, l'octet Chiffres-uniques sera 3.) Si la sous option Sous-adresse-de-numéro-de-téléphone est présente, la sous option Chiffres-uniques comportera tous les chiffres de la sous-adresse dans son compte des chiffres différents sur la droite.

Ce champ est le numéro de téléphone de l'accès qui DEVRAIT être appelé par l'homologue. Tous les chiffres qui précèdent les chiffres uniques les plus à droite du numéro d'abonné sont fournis à titre de pure information, et n'ont pas besoin d'être inclus dans ce champ. Ce champ est une chaîne ASCII et DOIT ne contenir que des caractères ASCII indiquant des chiffres de numéro de téléphone valide. Ce champ est exigé.

Ce champ est la sous adresse de l'accès que l'homologue doit appeler. Cette sous option DEVRAIT n'être utilisée que pour un appel RNIS. Ce champ est une chaîne ASCII et ne contient que des chiffres d'un numéro de téléphone valide. Ce champ est facultatif.

L'option Pas-besoin-de-numéro-de-téléphone indique que la mise en œuvre appelante est déjà configurée avec le numéro de téléphone de son homologue multiliaison et que la mise en œuvre qui répond inclut l'option Numéro de téléphone dans la réponse. Cela PEUT être pour des raisons de sécurité, pour des raisons de configuration, ou pour n'importe quelle autre raison.

Un résumé du format de l'option BAP Pas-de-numéro-de-téléphone figure ci-dessous. Les champs sont transmis de gauche à droite.

Cette option est utilisée pour indiquer la raison de la Demande ou de la Réponse. Elle est destinée à être utilisée pour de simples besoins d'information. Cette option PEUT être utilisée dans tout paquet BAP.

Un résumé du format de l'option BAP Raison figure ci-dessous. Les champs sont transmis de gauche à droite.

Longueur : Le champ Longueur fait un octet, et indique la longueur de cette option BAP y compris les champs Type, Longueur et Chaîne-Raison.

C'est une chaîne ASCII. Le contenu du champ dépend de la mise en œuvre. Une mise en œuvre PEUT ignorer le champ Chaîne-Raison.

L'option Discriminant-de-liaison DOIT être utilisé dans un datagramme Demande-d'interrogation-d'abandon-de-liaison. Cette option est utilisée pour informer le receveur d'une Demande-d'interrogation-d'abandon-de-liaison de quelle liaison va être abandonnée.

Un résumé du format de l'option BAP Discriminant-de-liaison figure ci-dessous. Les champs sont transmis de gauche à droite.

Le champ Discriminant de liaison fait deux octets. Il contient le discriminant de liaison qui était contenu dans l'option de configuration LCP Discriminant-de-liaison envoyée par le receveur du paquet contenant le discriminant de liaison.

L'option État-d'appel DOIT être utilisée dans un datagramme Indication-d'état-d'appel. Cette option est utilisée pour informer le receveur du datagramme Indication-d'état-d'appel de l'état de la tentative d'appel terminée, ainsi que des actions possibles qui seront entreprises (si l'appel a échoué).

Un résumé du format de l'option BAP État-d'appel figure ci-dessous. Les champs sont transmis de gauche à droite.

Le champ État fait un octet. Si l'appel a réussi, la valeur DOIT être réglée à 0. Une valeur différente de zéro indique un échec de l'appel. Une valeur de 255 indique un échec non spécifique, et un état d'appel plus spécifique PEUT être indiqué en utilisant le même nombre que la valeur de cause Q.931 (c'est-à-dire, 1 est un numéro non alloué, 17 est l'occupation de l'usager, etc.)

L'octet Action indique l'action que la mise en œuvre appelante entreprend après un échec d'appel. Si l'appel a réussi, l'octet Action DOIT être à 0.

La première version de BACP a été écrite par Craig Richards de Shiva Corporation. Cette version a été augmentée et améliorée par le groupe de travail MPCP, fruit de la collaboration de 3Com, Ascend, Bay Networks, Cisco, Microsoft, Shiva, US Robotics et Xylogics.

À Kevin Smith de Ascend pour ses contributions fondées sur ses travaux sur la spécification MP+. À Gerry Meyer et Robert Myhill de Shiva pour leurs commentaires et améliorations des premières versions. À Andy Nicholson de Microsoft pour ses améliorations au schéma de gestion de la bande passante. À Dana Blair et Andy Valencia de Cisco, et à Cheng Chen et Dan Brennan de 3Com pour leurs bonnes idées dans le groupe de travail MPCP. À tous les membres du groupe de travail MPCP pour leurs capacité à travailler avec enthousiasme avec leurs concurrents pour produire un meilleur protocole pour l'industrie.

Groupe de travail Réseau	C. Richards, Shiva Corporation
Request for Comments : 2125	K. Smith, Ascend Communications, Inc.
Catégorie : En cours de normalisation	mars 1997
Traduction Claude Brière de L'Isle

Craig Richards	Kevin Smith
Shiva Corporation	Ascend Communications, Inc.
28 Crosby Drive	1275 Harbor Bay Parkway
Bedford, MA 01730	Alameda, CA 94501
téléphone : +1 617 270 8419	USA
fax : +1 617 270 8599	mél : kevin@ascend.com
mél : crich@us.shiva.com

Datagramme	Champs obligatoires	Options autorisées
Demande-d'appel	Type-de-liaison	Pas-de-numéro-de-téléphone
Réponse-d'appel		Delta-téléphone
		Type-de-liaison
Demande-de-rappel		Type-de-liaison
		Delta-téléphone
Réponse-de-rappel		Type-de-liaison
Demande-d'interrogation-d'abandon-de-liaison		Discriminant-de-liaison
Réponse-d'interrogation-d'abandon-de-liaison
Indication-d'état-d'appel	État-d'appel	Delta-téléphone
Réponse-d'état-d'appel