QoS - Présentation de la Signalisation ccnp_cch ccnp_cch

Sommaire • Introduction • Precedence IP • RSVP (Resource Reservation Protocol) - Comment cela fonctionne-t-il? - Support de RSVP pour LLQ (low latency Queueing) - Support de RSVP pour Frame Relay • Inter-fonctionnement RSVP-QoS ATM - Comment cela fonctionne-t-il? • COPS pour RSVP - Comment cela fonctionne-t-il? - Vue détaillée du fonctionnement COPS pour RSVP • Gestionnaire de bande passante de sous-réseau ccnp_cch

Introduction ccnp_cch De manière générale, la signalisation de QoS est une forme de communication en réseau qui permet à des stations terminales ou à des nœuds de réseau de communiquer ou à signaler à des voisins une requête pour la gestion d'un certain trafic. La signalisation de QoS est très utile pour coordonner les techniques de gestion de trafic fournies par d'au- tres fonctionnalités de QoS. Elle joue un rôle clé dans la configuration réussie du servi- ce de QoS global de bout en bout à travers votre réseau. Une véritable QoS de bout en bout requiert que chaque élément du réseau dans le che- min (commutateur, routeur, pare-feu, host, client, etc..) délivre sa part de QoS et que toutes ces entités soient coordonnées par la signalisation de QoS. Plusieurs solutions de QoS viables fournissent de la QoS à certains points de l'infra- structure; cependant elles ont souvent une portée limitée à travers le réseau. Pour réa- liser une QoS de bout en bout, la signalisation doit recouvrir tout le réseau. La QoS de l'IOS Cisco tire partie d'IP pour réussir le challenge qui est de trouver une solution de signalisation de QoS qui peut opérer sur des infrastructures de réseaux hétérogènes. Elle recouvre des solutions de signalisation de QoS de couche 2 spécifiques à la techno- logie avec des méthodes de signalisation de QoS de couche 3 IP, des fonctionnalités de RSVP (Resource Reservation Protocol) et de Precedence IP. Un réseau IP peut réaliser de la QoS de bout en bout, par exemple en utilisant une partie de l'en-tête du paquet IP pour demander une gestion spéciale de priorité de trafic ou de trafic sensible au délai. Grâce à l'ubiquité d'IP , la signalisation de QoS qui s'ap- puie sur IP fournit une puissante signalisation de bout en bout. La precedence IP et RSVP entrent dans cette catégorie. On utilise la signalisation dans la bande (Precedence IP, 802.1p) ou de la signalisation hors-bande (RSVP) pour indiquer qu'une QoS particulière est souhaitée pour une clas- sification de trafic particulier. La Precedence IP sert de signalisation pour de la QoS différenciée (DSCP - Differentiated Service Code Point) et RSVP pour de la bande pas- sante garantie. Precedence IP Comme cela est montré dans la figure suivante, la fonctionnalité Precedence IP utilise les bits de precedence dans le champ ToS (Type of Service) de l'en-tête paquet IPv4 pour spécifier la classe de service de chaque paquet. Vous pouvez partitionner le trafic en six classes de service en utilisant la Precedence IP. Les techniques de gestion de file d'atten- te à travers le réseau peuvent ensuite utiliser ce "signal" pour fournir la gestion appro- priée pour l'expédition. 8 15 16 31 Vers IHL Tos Longueur totale Precedence IP (3bits) ccnp_cch

Vous pouvez utiliser des fonctionnalités telles que le routage basé sur des politiques (Policy-Based Routing) et CAR ( Committed Access Rate) pour fixer la precedence basée sur la classification par des listes d'accès étendues. L'utilisation de ces fonctionnalités permet une grande flexibilité de l'affectation de la precedence comprenant l'application par utilisateur, par réseau source ou destination. de manière typique, vous déployez ces fonctionnalités aussi près que possible de la périphérie de réseau ou du domaine admi- nistré pour que chaque élément du réseau suivant puisse fournir un service basé sur la politique déterminée. La Precedence IP peut être fixée sur le host ou le client réseau. Cependant la Precedence IP peut être supplantée par la politique dans le réseau. La Precedence IP permet aux classes de service d'être établies en utilisant des mécanis- mes de files d'attentes existants tels que WFQ (Weighted Fair Queueing) et WRED ( Weighted Radom Early Discard) sans aucun changement au niveau des applications et sans demandes compliquées pour le réseau. RSVP (Resource Reservation Protocol) RSVP est le premier protocole de signalisation standardisé pour paramétrer dynamique- ment la QoS de bout en bout à travers un réseau hétérogène. RSVP qui opère au-dessus de IP permet à une application de réserver dynamiquement de la bande passante. En utilisant RSVP, les applications peuvent demander un certain niveau de QoS pour un flux de données à travers un réseau. L'implémentation de la QOS de l'IOS Cisco autorise RSVP à être initié à l'intérieur du ré- seau en utilisant un mandataire RSVP (Proxy). En utilisant cette capacité, vous tirez pro- fit dans le réseau même pour les applications et le host non prévues pour RSVP. RSVP fonctionne en conjonction avec, pas à la place de, les mécanismes de gestion de files d'attente courants. RSVP demande une QoS particulière mais il est à la charge du mécanisme de gestion de file d'attente sur l'interface, tels que WFQ ou WRED, d'implé- menter la réservation. Vous pouvez utiliser RSVP pour faire deux types de réservation dynamiques : charge contrôlée et service à débit garanti. Une caractéristique principale de RSVP est son évolutivité. RSVP évolue bien en utilisant l'évolutivité inhérente au multicast. RSVP peut évoluer vers de grands groupes multicast car il utilise des requêtes de réservation orientées receveur qui fusionnent lors de leur progression vers le haut de l'arbre multicast. Bien que RSVP ait été conçu de manière particulière pour des applications multicast, il peut également faire des réservations uni- cast. RSVP est une fonctionnalité de QoS très importante mais il ne résoud pas tous les pro- blèmes engendrés par la QoS et il y a toujours quelques obstacles comme le temps re- quis pour établir des réservations de bout en bout. ccnp_cch

ccnp_cch Comment cela fonctionne-t-il ? Les hosts et les routeurs utilisent RSVP pour délivrer des requêtes de QoS routeurs le long du chemin de flux de données et pour maintenir l'état du host et du routeur afin de fournir le service requis, usuellement de la bande passante et du délai garantis. RSVP utilise un débit moyen - le plus grand nombre de données que le routeur gardera dans sa file d'attente - de la QoS minimum ( qui est la garantie de la bande passante spécifiée quand la réservation a été faite) pour déterminer la réservation de bande pas- sante. Un host utilise RSVP pour demander un service de QoS spécifique au réseau à la de- mande d'une application de flux de données. RSVP demande la QoS particulière, mais c'est au mécanisme de gestion de file d'attente de l'interface d'implémenter la réserva- tion. RSVP transporte la requête à travers le réseau, passant par chaque nœud que le réseau utilise pour transporter le flux. A chaque nœud, RSVP tente de faire une réser- vation de ressource pour le flux en utilisant son propre module de contrôle d'admission, propre à RSVP, lequel détermine si le nœud a suffisamment de ressources disponibles pour fournir la QoS requise. Note : Pour RSVP, une application peut transmettre du trafic à un débit supérieur à la QoS requise mais l'application est garantie pour le débit minimum requis. Si la bande passante est disponible, le trafic dépassant le débit requis passera s'il est transmis; si la bande passante n'est pas disponible, le trafic en excès sera éliminé. Si les ressources requises sont disponibles et l'utilisateur a le droit d'accès, le démon RSVP fixe les paramètres dans le "classifieur" de paquets et l'ordonnanceur de paquets pour obtenir la QoS désirée. Le classifieur détermine la classe de QoS pour chaque pa- quet et l'ordonnanceur gère la priorité de transmission des paquets pour réaliser la QoS requise pour chaque flux. Si la ressource n'est pas disponible ou si l'utilisateur n'a pas les droits, le programme RSVP retourne une notification d'erreur au processus applica- tif à l'origine de la requête. WFQ ou WRED réalisent la classification et l'ordonnancement de paquets requis par les flux réservés. En utilisant WFQ, RSVP délivre des services à débit garanti. En utilisant WRED, RSVP délivre un service "Charge contrôlée". Support RSVP pour LLQ (Low Latency Queueing) RSVP est un protocole de contrôle réseau qui fournit un moyen de réservation de res- sources réseau - initialement de la bande passante - pour garantir que les applications qui transmettent de bout en bout à travers le réseau aient la QoS désirée. Le trafic voix a des exigences strictes de délai et de gigue. Il doit avoir un faible délai et une gigue minimale pour éviter une dégradation de la QoS de bout en bout. Ces exigen- ces demandent une implémentation efficace de la gestion de files d'attente, telle que LLQ (Low Latency Queueing) qui peut servir le trafic voix avec une priorité stricte dans le but de minimiser le délai et la gigue. RSVP utilise WFQ pour fournir l'équité parmi les flux et affecter un faible poids à un pa- quet pour obtenir une priorité. Cependant le traitement préférentiel fourni par RSVP ne suffit pas pour minimiser la gigue à cause la nature de l'algorithme de gestion de file ccnp_cch

d'attente lui-même. Par conséquent, les exigences de faible délai et de gigue pourraient ne pas être satisfaites dans l'implémentation précédente de RSVP et WFQ. RSVP fournit un contrôle d'admission. Toutefois pour fournir les garanties de bande passante et de délai pour le trafic voix et avoir un contrôle d'admission, RSVP doit tra- vailler avec LLQ. La fonctionnalité support RSVP pour LLQ permet à RSVP de classifier les flux voix et de les placer dans la file prioritaire dans le système LLQ tandis tout en fournissant les réservations pour les flux de données en obtenant une file réservée. La figure suivante montre comment RSVP opère avec d'autres fonctionnalités VoIP telle que ip rtp priority en utilisant le même mécanisme LLQ de gestion de file d'attente. RSVP File Prioritaire IP RTP priority Classe prioritaire Classification Classe 1 Classe 2 Classe par défaut Flux voix Flux Data Files réservées File non réservée Sortie Trafic destiné à l'interface ccnp_cch

RSVP est le seul protocole qui fournit un contrôle d'admission basé sur la disponibilité des ressources réseau comme la bande passante. LLQ fournit un moyen pour achemi- ner le trafic voix avec une priorité stricte sur les autres trafics de données. Quand ils sont combinés, le support RSVP pour LLQ fournit un contrôle d'admission et achemine les flux voix avec la latence et la gigue les plus petites possibles. Le trafic non voix de priorité élevée pour des applications temps-critique peut continuer à être transmis sans être défavorablement affecté par le trafic voix. Le reste du trafic a un traitement de type "best-effort" évitant ainsi toute dégradation qui autrement pourrait affecter tout le trafic. La fonctionnalité support RSVP pour LLQ supporte les RFC suivants : • RFC 2205, Resource Reservation Protocol • RFC 2210, RSVP with IETF Integrated Services • RFC 2211, Controlled-Load Network Element Service • RFC 2212, Specification of Guaranteed Quality of Service • RFC 2215, General Characterization Parameters for Integrated Service Network Elements La figure suivante montre un exemple de topologie de réseau avec LLQ actif sur chaque interface. cette configuration garantit la QoS pour le trafic voix. Note: si la source ne supporte pas RSVP, le routeur peut servir de proxy RSVP à la de- mande de la source. Routeur RLB-w Routeur RLB-1 Routeur RLB-2 Routeur R12-e Réseau IP 128 kb/s 64 kb/s Dial peer 2 POTS Dial peer 1 Voice port 1/0/0 Serial port 0/0 1/0 1/0 1/3 1/3 1/0 ccnp_cch

Support RSVP pour Frame Relay Restrictions Les restrictions suivantes s'appliquent à la fonctionnalité Support RSVP pour LLQ. ● LLQ n'est supporté sur aucun tunnel ● Le support RSVP pour LLQ dépend de la file d'attente prioritaire. Si LLQ n'est pas disponible sur n'importe quelle interface ou sur une plateforme alors le support RSVP pour LLQ n'est pas disponible. ● Le support RSVP pour LLQ sur des circuits virtuels permanents Frame Relay ou des PVC ATM n'est pas encore disponible. Prérequis Le réseau doit supporter les fonctionnalités suivantes de l'IOS Cisco avant que le sup- port RSVP pour LLQ soit validé. ● RSVP ● WFQ ou LLQ (WFQ avec file d'attente prioritaire) Support RSVP pour Frame Relay Les administrateurs réseaux utilisent les files d'attente pour gérer la congestion sur une interface de routeur ou un circuit virtuel (VC). Dans un environnement Frame Relay le point de congestion n'est peut-être pas l'interface elle-même mais le VC à cause du CIR (Committed Information Rate). Pour du trafic temps-réel (flux voix) devant être transmis avec un délai fixe, le débit ne doit pas excéder le CIR sinon les paquets seront éliminés ce qui affectera la qualité de la voix. FRTS (Frame Relay Traffic Shaping) est configuré sur les interfaces pour contrôler le débit du trafic sortant avant d'éviter au routeur de dépasser le CIR. Ce type de configuration signifie que des mécanismes de files d'attente tels que CBWFQ (Class-Based Weighted Fair Queueing), LLQ ou WFQ peuvent opérer sur le VC pour fournir de la QoS garantie pour le trafic. Auparavant les réservations RSVP n'avaient pas la contrainte du CIR du VC pour le flux sortant. Le résultat est que de la sur-allocation pouvait se produire quand la somme du trafic RSVP et d'autre trafic excédait le CIR. La fonctionnalité Support RSVP pour Frame Relay permet à RSVP de fonctionner avec une gestion de file d'attente par VC (DLCI - Data Link Control Identifier) pour des flux type voix. le lissage de trafic doit être validé dans un environnement Frame Relay pour un contrôle d'admission aux ressources précis (bande passante et files d'attente) au point de congestion qui est le VC lui-même. Spécifiquement RSVP peut fonctionner avec des VC définis au niveaux interface et sous-interface. Il n'y a pas de limite au nombre de VC qui peuvent être configurés par interface ou sous-interface. ccnp_cch

QoS modulaire ccnp_cch Allocation de bande passante RSVP et Interface ligne de commande QoS modulaire RSVP peut utiliser un algorithme de gestion de file d'attente d'interface (ou de PVC) tel que WFQ pour assurer la QoS pour un flux de données. Contrôle d'admission Quand WFQ est opérationnel, RSVP peut co-exister avec d'autres fonctionnalités de QoS sur une interface (ou PVC) qui réserve aussi de la bande passante et respecte la QoS. Quand vous configurez plusieurs fonctionnalités avec des réservations multiples de bande passante (telles que RSVP, LLQ, CB-WFQ et ip rtp priority) les parties de la bande passante disponible peuvent être affectées à chacune de ces fonctionnalités pour les utiliser avec les flux qu'elles classifient. Un gestionnaire interne de bande passante basé interface (ou PVC) évite que le volume de trafic réservé par ces fonctionnalités dépasse la capacité de l'interface (ou PVC). Vous pouvez voir ce pool de bande passante disponible en utilisant la commande show queue et si cela est configuré (comme un pourcentage de la capacité de l'interface ou du PVC) via la commande max-reserved-bandwidth. Quand vous configurez les fonctionnalités telles que LLQ et CB-WFQ, toutes les classes qui ont une bande passante affectée réservent leur bande passante au moment de la configuration et déduisent cette bande passante du gestionnaire de bande passante. Si la bande passante configurée excède la capacité de l'interface, la configuration est rejetée. Quand RSVP est configuré, aucune bande passante n'est réservée (le montant de bande passante spécifié dans ip rsvp bandwidth agit comme une limite haute stricte et ne garantit pas l'admission de tous les flux. C'est uniquement lorsqu'une réservation arri- ve que RSVP tente de réserver de la bande passante dans le pool de bande passante restant disponible (ce qui signifie: bande passante qui n'a pas été dédiée au trafic géré par d'autres fonctionnalités). Classification des paquets de données Par défaut, RSVP réalise une classification efficace de paquets de données basée sur le flux pour assurer la QoS pour son trafic réservé. La classification est faite avant la ges- tion des files d'attente, par ip rtp priority ou CB-WFQ. Aussi, l'utilisation d'une classe CB-WFQ ou de la commande ip rtp priority n'est pas requise pour que les flux data RSVP obtiennent la QoS. Aucune configuration ip rtp priority ou CB-WFQ ne corres- pondra à des flux RSVP mais elles réserveront de la bande passante supplémentaire pour tout les flux non-RSVP qui correspondront à leurs identificateurs de classes. ccnp_cch

Avantages Les avantages de cette fonctionnalité sont les suivants: ● RSVP fournit maintenant du contrôle d'admission basé sur la valeur maximum acceptable pour le VC sortant ( min CIR), si elle est définie, au lieu du montant de bande passante disponible sur l'interface. ● RSVP fournit des garanties de QoS pour du trafic de priorité élevée en réservant des ressources au point de congestion qui est le VC Frame Relay. ● RSVP fournit le support des configurations pour des interfaces point à point et point à multipoint, permettant ainsi le déploiement des services tels que VoIP sur Frame Relay avec des garanties de QoS. ● RSVP, CB-WFQ et la commande ip rtp priority n'excèdent pas le montant de bande passante disponible sur l'interface ou le VC même si elles opèrent simultanément. Avant d'admettre une réservation, ces fonctionnalités ( ainsi que la commande ip rtp priority) consultent un gestionnaire interne de bande passante pour éviter tout dé- passement de capacité. ● Les fonctionnalités de QoS peuvent être maintenant intégrées sans discontinuté depuis IP dans des environnements Frame Relay avec RSVP fournissant du contrôle d'admission sur la base du VC (DLCI). La fonctionnalité support RSVP pour Frame Relay supporte les MIB et RFC suivants: ● RFC 2206, RSVP Management Information Base using SMIv2 ● RFC 220, Resource Reservation Protocol ● RFC 2210, RSVP with IETF Integrated Services ● RFC 221, Controlled-Load Network Element Service ● RFC 2212, Specification of Guaranteed Quality of Service ● RFC 2215, General Characterization Parameters for Integrated Service Network Elements Restrictions Les restrictions suivantes s'appliquent à la fonctionnalité Support RSVP pour Frame Relay. ● Le GTS (Generic Traffic Shaping) par interface n'est pas supporté. ● La gestion de file d'attente au niveau VC et la gestion de file d'attente au niveau interface ne sont pas supportées sur la même interface. ● Les flux RSVP non-voix ne sont pas supportés ● Les flux multicast ne sont pas supportés. ccnp_cch

Interfonctionnement RSVP - QoS ATM Prérequis Le réseau doit supporter les fonctionnalités suivantes de l'IOS cisco avant de valider le support RSVP pour Frame Relay: ● RSVP ● WFQ sur le VC ● LLQ ● FRF.12 (Frame Relay Forum) sur l'interface. Interfonctionnement RSVP - QoS ATM La fonctionnalité d'interfonctionnement RSVP - QoS ATM fournit un support pour un "Controlled Load Service" utilisant RSVP sur un cœur de réseau ATM. Cette fonction- nalité requiert la capacité de signaler l'établissement de circuits virtuels commutés (SVC) à travers un réseau ATM en réponse au messages de requête de réservation RSVP. Pour satisfaire ces exigences, RSVP sur ATM supporte la correspondance des sessions RSVP avec des SVCs ATM. La fonctionnalité d'interfonctionnement RSVP - QoS ATM vous permet de réaliser les tâches suivantes: ● Configurer une interface ou une sous-interface pour créer dynamiquement des SVCs en réponse aux messages de requête de réservation RSVP. Pour assurer la Qos défi- nie, ces SVCs sont établis en ayant des profils de QoS cohérents avec les spécifica- tions de flux RSVP correspondants. ● Attache les définitions de groupe DWRED (Distributed Weighted Radom Early Détec- tion) à une interface avancée ATM port Adaptor (PA-A3) pour supporter la politique d'élimination de paquets DWRED par VC. L'utilisation de DWRED par VC assure que si des paquets doivent éliminés alors les paquets "best-effort" seront éliminés en premier et non ceux qui sont conformes à la QoS appropriée déterminée par le "Token Bucket" de RSVP. ● Configure les valeurs de Precedence IP et du ToS devant être utilisés pour les paquets qui sont conformes ou sortent des profils de QoS. Comme partie du traitement en en- trée, RSVP utilise les valeurs que vous spécifiez pour fixer le ToS et la Precedence IP sur les paquets entrants. Si DWERD par VC est configuré il utilise la configuration des bits ToS et Precedence IP sur l'interface de sortie du même routeur pour déter- miner quels paquets éliminer. Les interfaces sur les routeurs aval utilisent ces para- mètres pour le traitement des paquets. Cette fonctionnalité est supportée sur les routeurs Cisco série 7500 avec VIP2-50 et Enhanced ATM Port Adapter (PA-A3). Le matériel fournit le lissage de trafic requis par la fonctionnalité et satisfait les exigences de débit de OC-3. ccnp_cch

Comment cela fonctionne-t-il? Traditionnellement RSVP a été couplé avec WFQ. WFQ fournit la garantie de bande pas- sante à RSVP et donne la visibilité à RSVP pour tous les paquets qu'il voit. Cette visibi- lité permet à RSVP d'identifier et de marquer les paquets qui ont un rapport avec lui. L'interfonctionnement RSVP - QoS ATM vous permet de découpler RSVP et WFQ et à la place de l'associer à des SVC ATM pour gérer les messages de requête de réservation ( et fournit des garanties de bande passante) et Netflow pour rendre les paquets visibles pour RSVP. Pour configurer une interface ou une sous-interface pour qu'elle utilise la fonctionnalité d'interfonctionnement RSVP - QoS ATM, utilisez la commande ip rsvp svc-required. Ensuite chaque fois qu'une nouvelle réservation est requise, le logiciel du routeur établit un nouveau SVC ATM pour servir la réservation. Pour assurer la correspondance entre les valeurs TSVP et ATM SVC, le logiciel mappe avec un algorithme les paramètres de débit et de taille de burst dans la spécification de flux RSVP au débit de cellule ATM soutenu ( Sustained Cell Rate) et à la taille maxi- mum de burst (Maximum Burst Size). Pour le débit crête de cellules (Peak Cell Rate), il utilise la valeur que vous configurez ou la valeur par défaut du débit de la liaison. L'interfonctionnement RSVP - QoS ATM requiert un adaptateur de port ATM amélioré (PA-A3) avec un débit OC-3. Quand un paquet appartenant à un flux réservé arrive sur l'interface ou la sous-inter- face, le logiciel "Interfonctionnement RSVP - QoS ATM" utilise un "Token Bucket" pour gérer les garanties de bande passante. Il mesure les débits de trafic actuels comparés aux spécifications de flux réservés pour déterminer si le paquet est conforme ou non à la spécification de flux. En utilisant les valeurs que vous configurez pour le trafic conforme ou non-conforme, il fixe les bits de ToS et de la Precedence IP dans l'octet ToS de l'en-tête du paquet et délivre le paquet au circuit virtuel (VC) approprié pour la transmission. Pour le fonctionnalité "Interfonctionnement RSVP -QoS ATM", le trafic est lissé avant d'être transmis sur le SVC ATM. Le lissage crée en retour une pression sur le VIP (Versatile Interface Processor) quand la charge offerte dépasse le débit. Le logiciel "Interfonctionnement RSVP - QoS ATM" utilise DWRED par VC pour éliminer les paquets quand le lissage entraine la création d'une file d'atteinte sur le VIP. L'utili- sation de SWRD par SVC permet à RSVP de délivrer une classe de service "Charge Con- trôlée" qui requiert que les paquets réservés bénéficient d'une performance équivalente à celle d'un réseau non chargé (un réseau avec un taux de perte très faible et un délai très faible). Pour avoir plus de détails sur comment travaille la fonctionnalité "Interfonc- tionnement RSVP - QoS ATM", voyons l'exemple de scénario ci-après. Exemple de scénario Pour comprendre le comportement de la fonctionnalité "Interfonctionnement RSVP - QoS ATM", considérez l'exemple suivant qui utilise un routeur Cisco 7500 avec des interfaces VIP en entrée et en sortie et la fonctionnalité RSVP en entrée implémentée sur les RSP (Route Switch Processor). La figure page suivante illustre cet exemple; elle montre une paire de routeurs qui communiquent à travers un réseau ATM. Dans cet exemple, un seul PVC est utilisé pour les messages de requête RSVP et un SVC ATM est établi pour gérer chaque message de nouvelle requête de réservation. ccnp_cch

Réseau ATM Host X Host Y Routeur A Routeur B Requête RSVP SVC avec la QoS requise Le Host X, qui en amont est en amont du routeur A, est directement connecté à celui-ci en utilisant FDDI. Le Host Y, qui est en aval du routeur A est directement connecté au routeur B en utilisant FDDI. Dans une configuration alternative, ces deux connexions host-routeur pourraient utiliser des PVC ATM. Pour la fonctionnalité Interfonctionnement RSVP-QoS ATM, les réservations sont néces- saires principalement entre les routeurs à travers le backbone ATM. Pour limiter le nom- bre d'emplacements où les réservations sont faites, vous pouvez valider RSVP de mani- ère sélective uniquement aux sous-interfaces qui correspondent aux connexions routeur à routeur à travers le réseau backbone ATM. Eviter que les réservations soient faites entre le host et le routeur limite l'utilisation de VC et réduit la charge sur le routeur. Les messages RSVP RESV vont du host receveur vers le host émetteur. Dans cet exem- ple le host Y est le host receveur et le host X le host transmetteur (le host Y transmet des messages RESV vers le host X). Le routeur B qui est à la périphérie du réseau ATM reçoit les messages RESV et les transmet en amont vers le routeur A sur le PVC utilisé pour les messages de contrôle. L'exemple de la figure précédente montre qu'un PVC est utilisé; celui-ci transporte la requête RSVP. L'interface d'entrée du routeur A est configurée pour RSVP-ATM ce qui lui permet d'éta- blir pour chaque requête un SVC pour servir toutes les nouvelles réservations RSVP- RESV faites sur cette interface. Quand elle reçoit une requête de réservation, l'interface sur le routeur A crée un SVC nRTVBR (non-Real Time Variable Bit Rate) avec les carac- téristiques de QoS utilisées pour établir le SVC résultent d'un algorithme de correspon- dance de flowspec dans le message RSVP-RESV avec un ensemble de paramètres de signalisation ATM. Dans cet exemple, "Controlled Load Service" est utilisée comme classe de QoS. Le para- mètre ATM PCR est fixé au débit de la liaison. Si la commande ip rsvp atm-peak-rate- limit est utilisée sur l'interface pour configurer un limiteur de débit, le PCR est fixé au débit crête du limiteur. Le paramètre ATM SCR est fixé au débit du flowspec RSVP et le paramètre ATM MBS est fixé à la taille de burst du flowspec RSVP. Les paquets sont lissés avant transmis sur le SVC ATM. Le lissage crée une pression en retour sur le VIP quand le trafic offert excède le débit. Quand un nouveau SVC est établi pour gérer une requête de réservation, un autre état est établi incluant un état de classification qui utilise les adresses source et destination, les numéros de ports pour déterminer, s'il y en a, à quelle réservation le paquet appar- tient. ccnp_cch

COPS pour RSVP ccnp_cch Un "token bucket" est également établi pour assurer que si une source transmet plus de données que le débit et les paramètres MBS de son flowspec spécifié, le trafic en excès n'interfère pas avec les autres réservations. Les sections suivantes décrivent plus spécifiquement comment les données suivent le chemin. Quand un paquet de données destiné au routeur B arrive sur le routeur A, avant de tra- verser le réseau ATM, les adresses source et destination et les numéros de ports du pa- quet sont vérifiés par rapport aux spécifications du filtre RSVP (filterspec) pour détermi- ner si le paquet correspond à la réservation. Si le paquet ne correspond pas à une réservation, il est transmis sur le PVC "Best-effort" vers le routeur B. Si un paquet correspond à une réservation, il est traité par RSVP. Le paquet est vérifié par rapport au "token bucket" de la réservation pour déterminer s'il est conforme à ou excède les paramètres du "token bucket" (tous les paquets correspon- dant à une réservation sont transmis sur le SVC de la réservation pour éviter un désé- quencement des paquets). Pour introduire une différenciation entre paquets conformes au "flowspec" et ceux excé- dant le "flowspec", vous pouvez spécifier les valeurs que RSVP-ATM utilise pour fixer les bits de precedence IP et ToS des paquets. Pour spécifier ces valeurs, vous utilisez les commandes ip rsvp precedence et ip rsvp tos. Quand vous fixez des valeurs de prece- dence pour les paquets conformes ou en excédant et que vous utilisez une politique d'élimination de paquet préférentielle telle que DWRED, RSVP-ATM assure que les pa- quets excédant le "flowspec" seront éliminés avant les paquets conformes au "flowspec" quand le SVC est congestionné. COPS pour RSVP COPS (Common Open Policy Service) est un protocole utilisé pour communiquer des informations de politique de trafic réseau à des équipements réseau. RSVP est un moyen de de réservation de ressources réseau, principalement de la bande passante , pour garantir que des applications transmettant de bout en bout à travers Internet fonctionnent bien avec le débit et la qualité voulus. Combiner COPS avec RSVP donne aux administrateurs réseaux une gestion et un con- trôle centralisés de RSVP incluant les facilités suivantes : ● Assurer une bande passante adéquate et les limites de délai et variation de délai pour le trafic sensible à ces paramètres telle que la transmission de la voix. ● Assurer une bande passante adéquate pour les applications multimédia telles que la vidéoconférence et la formation à distance. ● Eviter que des applications consommatrices de bande passante retardent des flux de priorité élevée ou pénalisent les performances d'autres applications fonctionnant tra- ditionnellement sur le même réseau. En faisant cela, COPS pour RSVP supporte les fonctionnalités cruciales suivantes: ● ● ccnp_cch

En faisant cela, COPS pour RSVP supporte les fonctionnalités cruciales suivantes: ● Contrôle d'admission. La réservation RSVP est acceptée ou rejetée sur la base de ressources réseau disponibles de bout en bout. ● Bande passante. La réservation RSVP, si elle est acceptée, garantira que ces ressources réservées seront toujours disponibles tant que la réservation restera établie. ● Réservation indépendante du média. Une réservation RSVP de bout en bout peut re- couvrir plusieurs types de média de couches basses. ● Classification des données. Quand une réservation est faite, les paquets de données appartenant à ce flux RSVP sont séparés des autres paquets et acheminés comme partie du flux réservé. ● Politique sur les données. Les paquets de données appartenant à un flux RSVP et qui excèdent la bande passante réservée sont marqués avec une priorité plus faible. Note : Pour utiliser la fonctionnalité COPS pour RSVP, votre réseau doit opérer avec l'IOS 12.1(1)T ou suivants. En plus de cela un serveur de politique tel que Cisco QoS Policy Manager doit être connecté au réseau. Note : L'IOS Cisco release 12.1(2)T pour RSVP ne supporte pas RSVP+. COPS pour RSVP fonctionne sur les interfaces suivantes : ● Ethernet ● FastEthernet ● High-Speed Serial Interface (HSSI): V35, EIA/TIA-232 ● E1/T1 La fonctionnalité COPS pour RSVP supporte les RFCs suivantes : ● RFC 2749, COPS Usage for RSVP ● RFC 2205, Resource ReSerVation Protocol (RSVP) ● RFC 2748, The COPS (Common Open Policy Service) Protocol ccnp_cch

Comment cela fonctionne-t-il ? Cette section fournit une vue assez détaillée de comment COPS pour RSVP fonctionne dans votre réseau et fournit les grandes étapes pour configurer la fonctionnalité COPS pour RSVP. Policy Decision Point (PDP) Serveur opérant avec Qos Policy manager COPS decision COPS request RSVP sender RSVP receiver RSVP path RSVP path RSVP reservation RSVP reservation Policy Enforcement Point (PEP) Routeur Cisco (client) Pour configurer un routeur afin qu'il traite tous les messages RSVP entrant sur celui-ci selon les politiques stockées sur un serveur de politiques particulier (appelé PDP ou Policy Decision Point), exécutez les étapes suivantes : 1. Sur le serveur PDP entrez les politiques en utilisant Cisco Qos Policy Manager ou une application de gestion de politique compatible. 2. Configurer le routeur (avec la CLI) pour faire des requêtes de décision concernant les messages RSVP à partir du serveur. Après cette configuration , les flux réseau sont traités par le routeur désigné comme PEP (Policy Enforcement Point) comme suit : a) Quand un message de signalisation RSVP arrive au routeur, le routeur demande au serveur PDP comment traiter le message, soit l'accepter, le rejeter, l'acheminer ou l'installer. b) Le serveur PDP transmet sa décision au routeur qui ensuite traite le message com- me cela lui est signifié. 3. Autrement vous pouvez configurer le routeur pour qu'il prenne ces décisions par lui-même (localement) sans qu'il ait besoin de consulter un serveur PDP. (La fonctionnalité locale n'est pas supportée dans cette version). ccnp_cch

ccnp_cch Vue détaillée du fonctionnement COPS pour RSVP La figure suivante illustre les options disponibles dans la politique de gestion des flux de messages RSVP. pour chaque option, un exemple de commande de configuration utilisée pour cette option est donné entre crochets et en caractères gras. Les zones grisées couvrent les fonctions de politique locale; le reste de la figure illustre le fonctionnement de politique distante. Politique locale Message RSVP entrant Est-ce qu'il correspond à une ACL de politique locale? [ip rsvp policy local 40 55] Est-il rejeté par un opérateur local ? Message éliminé (a) (a-1) (b-1) Oui Oui (a-2) Non (b-2) Non Est-ce qu'une politique locale par défaut est configurée? [ip rsvp policy local] Est-ce que le flag local override est fixé pour cette entrée ? [ip rsvp policy local local-override] (d-1) (c-1) Message traité Oui Oui (d-2) Non (c-2) Non Est-ce qu'il correspond à une ACL de politique distante? [ip rsvp policy cops 40 165 servers] (e-1) Transmettre une requête au PDP distant Oui (e-2) Non Est-ce qu'une politique distante par défaut est configurée? [ip rsvp policy cops servers] (g-1) Oui (g-2) Non Message éliminé Est-ce que la décision locale par défaut est le rejet? [ip rsvp policy default-reject] (h-1) Oui Est-ce que le PDP a retourné une décision de rejet? Message éliminé (h-2) Non (f-1) Oui Message traité (f-2) Non Message traité ccnp_cch

Les informations suivantes sont les points clés dans la figure: a Les informations suivantes sont les points clés dans la figure: a. Le routeur reçoit un message PATH ou RESV et tente d'abord de l'analyser localement (c'est-à-dire sans faire référence au serveur de politique). Si le routeur a été configuré analyser avec une liste de contrôle d'accès (ACL) localement et que le message corres- pond à une de ces listes d'accès (a-1), le module de politique du routeur applique les opérateurs avec lesquels il a été configuré sinon le traitement de la politique continue. b. Pour chaque message rejeté par les opérateurs, le routeur transmet un message d'er- reur à l'émetteur et retire le message PATH ou RESV de sa base de données (b-1). Si le message n'est pas rejeté le traitement de politique continue (b-2). c. Si le flag 'local override" est positionné pour cette entrée, le message est immédiate- ment accepté avec les opérateurs de politique spécifiés (c-1). dans tous les autres cas le traitement de politique continue. d. Si le message ne correspond à aucune ACL configurée pour la politique locale (a-2), le routeur applique la politique locale par défaut (d-1). Cependant si aucune politique par défaut n'a été configurée, le message est dirigé vers un traitement de politique distant (d-2). e. Si le routeur a été configuré avec des ACLs spécifiques pour des serveurs de politique (PDP) et que les messages correspondant à une de ces ACLs, le routeur transmet ce message vers un PDP spécifique pour jugement (e-1). Dans les autres cas, le traite- ment de politique continue. f. Si le PDP spécifie une décision de rejet (f-1) le message est éliminé et un message d'er- reur est transmis en retour vers l'émetteur indiquant la cause du rejet. Si le PDP spé- cifie une acceptation (f-1) alors le message est accepté et traité selon les règles de traitement normales de RSVP. g. Si le message ne correspond à aucune ACL configurée pour des PDP spécifiques (d-2) le routeur applique la configuration PDP par défaut. Si une configuration COPS par défaut a été entrée, le traitement de politique continue (g-1) sinon le message est con- sidéré sans correspondance (g-2). Si la politique de décision par défaut pour les messages sans correspondance est de rejeter (h-1) le message alors le message est immédiatement éliminé et un message ERROR est transmis à l'émetteur en indiquant la condition d'erreur. Autrement le mes- sage est accepté et traité selon les règles de traitement normales de RSVP (h-2). Voici quelques détails supplémentaires au sujet de la communication PDP-PEP et du traitement. ● Policy request timer . Chaque fois q'une requête pour adjudication (ou de toute sorte) est transmise au PDP, un timer de 30 secondes associé aux messages PATH et RESV est demandé. Si le timer expire avant que le PDP réponde à la requête, le PDP est présumé indisponible et la requête est passée à la politique par défaut. ccnp_cch

● Traçage des réservations PEP par le PDP ● Traçage des réservations PEP par le PDP . Quand le PDP spécifie qu'une réservation peut être installée, cette réservation doit être ensuite installée sur le routeur. Une fois que la bande passante a été allouée et que la réservation est installée, le module de politique du PEP transmet un message COMMIT vers le PDP. Mais si la réserva- tion ne peut pas être installée pour cause de ressources insuffisantes, la réservation est marquée à l'état non-installée et un message NO-COMMIT est transmis vers le PDP. Si la réservation était nouvelle (pas d'état précédent) alors le message DELETE REQUEST est transmis vers le PDP. De cette manière le PDP peut garder la trace des réservations sur le PEP. ● Resynchronisation . Si le PDP transmet un message SYNCHRONIZE-REQUEST vers le PEP, le module de politique du PEP scrute sa base de données pour tous les che- mins et réservations qui ont précédemment adjugés par le PDP et retransmet des requêtes pour celles-ci. L'information de politique précédemment adjugée est retenue jusqu'à ce qu'une nouvelle décision soit reçue. Quand tous les états PATH ou RESV ont été rapportés au PDP, un message SYNCHRONIZE-COMPLETE est transmis par le module de politique vers le PDP. Le PEP transmet également les requêtes concer- nant tous les flux qui ont été adjugés localement pendant que le PDP était indispo- nible. ● Réadjudication : - Aussi longtemps que les flux gérés par la session RSVP continuent de passer par à travers du routeur PEP, le PDP peut décider de manière unilatérale de réadjuger n'importe laquelle des décisions COPS pour cette session. Par exemple, le PDP pourrait décider qu'un flux particulier qui avait eu l'acceptation doit maintenant être rejeté ( à cause d'une préemption ou d'un timeout)? Dans de tels cas, le PDP transmet un nouveau message de décision vers le PEP qui ensuite ajustera son comportement en conséquence. - Si le routeur PEP reçoit un message RESV dans lequel un objet a changé, la politi- que de décision doit être réadjugée. Par exemple si l'émetteur veut augmenter ou diminuer la bande passante de réservation, une nouvelle politique de décision doit être faite. Dans de tels cas, les flags de politique appliqués précédemment à cette session sont retenus et la session est réadjugée. ● Fermeture . Le module de politique du PEP est responsable de la fermeture d'une réservation ou d'un chemin qui avait été précédemment établi par la politique quel- qu'en soit la raison. Le PEP notifie au PDP en transmettant un message DELETE REQUEST ● Gestion de connexion : - Si la connexion avec le PDP est fermée( soit parce que le PDP a fermé la connexion , un erreur TCP/IP est survenue ou les "keepalives" ont échoué), le PEP transmet un message CLIENT-CLOSE et tente de se reconnecter au même PDP. Si le PEP reçoit un message CLIENT-CLOSE contenant une adresse de redirection PDP, le PEP tente de se reconnecter avec le nouveau PDP. ccnp_cch

- Si cette tentative échoue, le PEP tente de se connecter aux PDP préalablement spé- cifiés dans la configuration ip rsvp policy cops servers, en respectant la séquence des donnée dans la configuration en commençant par le premier de la liste. - Si le PEP atteint la fin de la liste des serveurs sans se connecter, il attend un cer- tain temps (appelé "délai de reconnexion") avant de tenter de se connecter à nou- veau au premier serveur de la liste. Ce délai de reconnexion est initialement de 30 secondes et double chaque fois que le PEP attend la fin de la liste sans se con- necter jusqu'à ce que le délai de reconnexion atteigne le maximum de 30 minutes. Dès qu'une connexion est effectuée, le délai repasse à 30 secondes. ● Remplacement d'objet - Le tableau suivant identifie les objets que le PDP peut rem- placer dans les messages RSVP passant à travers le PEP. Un x dans la colonne in- dique que le PDP peut remplacer cet objet dans les messages RSVP. Contexte de message Objets Items affectés Politique TSpec Flowspec Errorspec Path In x -- ● Etat de chemin installé. ● Tous les messages PATH sortants pour ce PATH Path Out Ceci rafraîchit le PATH (mais pas l'état de PATH installé). Resv In ● Etat RESV installé ( ins- tallation du contrôle du trafic entrant et sortant) ● Tous les messages RESV sortants pour cette RESV Resv Alloc Ressources installées pour cette session. Resv Out Ce rafraîchissement parti- culier de message RESV (mais pas l'état RESV ins- tallé ni le contrôle d'alloca- tion de trafic). PathError In Message PATHERROR acheminé. PathError Out ResvError In Tous les messages RESVERROR acheminés par ce routeur. ResvError Out Ce message RESVERROR acheminé par ce routeur. ccnp_cch

Gestionnaire de bande passante de sous-réseau Si un message RSVP dont un objet a été remplacé est rafraîchi plus tard par l'amont, le PEP garde trace de l'ancienne et de la nouvelle version de l'objet et n'interprète pas à tort le rafraîchissement comme un changement de l'état PATH ou RESV. Gestionnaire de bande passante de sous-réseau RSVP et ses définitions de classe de service sont largement indépendants des technolo- gies de réseau sous-jacentes. cette indépendance requiert qu'un utilisateur définisse la correspondance de RSVP avec les technologies de sous-réseau. La fonctionnalité SBM (Subnetwork Bandwidth Manager) répond aux exigences de RSVP en relation avec les réseaux basés sur IEEE 802. SBM spécifie une méthode de signali- sation et un protocole pour un contrôle d'admission pour des flux RSVP. SBM permet aux routeurs RSVP et aux équipements couche 2 et couche 3 de supporter la réserva- tion de ressources LAN pour des flux de données RSVP. La méthode de signalisation SBM est similaire à celle de RSVP. Les entités du protocole SBM ont les caractéristiques suivantes: ● Réside dans des équipements couche 2 ou couche 3. ● Peut gérer les ressources sur un segment. Un segment est un segment physique couche 2, partagé par un ou plusieurs émetteurs, tel que Ethernet partagé ou Token Ring. ● Peuvent devenir candidats dans un processus d'élection dynamique qui désigne un SBM comme gestionnaire de segment. Le candidat élu est appelé DSBM (Designated Subnetwork Bandwidth Manager). Le DSBM élu est responsable de l'exercice du con- trole d'admission sur les requêtes de réservation de ressources sur un segment géré. Un segment géré inclut les parties interconnectées d'un segment LAN partagé qui ne sont pas séparées par des DSBMs. La présence d'un DSBM en fait un segment géré mais il ne peut y avoir qu'un seul DSBM par segment géré. Vous pouvez configurer une interface sur les routeurs connectés au segment pour qu'elle participe au processus d'élection du DSBM. Le candidat configuré avec la priorité la plus élevée devient le DSBM pour le segment géré. Si vous ne configurez pas un routeur comme candidat DSBM et que RSVP est validé alors le système interagit avec le DSBM si un DSBM est présent sur le segment. En fait, si un DSBM, s'identifiant en tant que tel, existe sur le segment, le segment est considé- ré comme segment géré et l'acheminement de tous les messages RSVP sera basé sur les règles d'acheminement du SBM. Ce comportement existe pour permettre les cas dans lesquels vous ne voudriez pas qu'une interface avec RSVP validé sur un routeur connecté à un segment géré devienne un DSBM mais vous voulez qu'il interagisse avec le DSBM s'il y a en un de présent et gérant le segment. Note: SBM n'est pas supporté sur les LANs Token Ring. ccnp_cch

La figure suivante montre un segment géré dans un domaine couche 2 qui interconnec- te un ensemble de hosts et de routeurs. Routeur R2 Host C DSBM Host B Routeur R3 Host A Routeur R1 Quand un client DSBM transmet ou achemine un message RSVP PATH sur une interfa- ce attachée à un segment géré, il transmet le message PATH au DSBM du segment au lieu de l'adresse de la session RSVP de destination comme cela se fait dans le traite- ment conventionnel de RSVP. En tant que partie du traitement du message, le DSBM construit et maintient un état PATH pour la session et note le saut précédent de couche 2 ou de couche 3 duquel il a reçu le message PATH. Après avoir traité le message PATH le DSBM achemine le message vers son adresse destination. Le DSBM reçoit le message RSVP RESV et le traite de manière similaire à celle avec la- quelle RSVP traite les requêtes de réservation en se basant sur la bande passante dis- ponible. La procédure est la suivante: ● S'il ne peut pas satisfaire la requête à cause d'un manque de ressources, le DSBM retourne le message RESVERROR vers l'origine de la requête. ● Si des ressources suffisantes sont disponibles et que le DSBM peut satisfaire la re- quête de réservation, il achemine le message RESV vers les sauts précédents en uti- lisant l'état PATH local pour cette session. ccnp_cch