Policy-Based Networks & COPS Protocol. DEA MISI Samir Tohmé Mars 2004

Transcription

1 Policy-Based Networks & COPS Protocol DEA MISI Samir Tohmé Mars 2004

2 La situation présente du monde de l Internet Le contrôle est principalement effectué dans les machines terminales Il y a peu d intelligence au niveau des nœuds D où une réelle difficulté pour introduire de la QoS dans les réseaux IP actuels : besoin de disposer d une signalisation appropriée Problème de complexité des routeurs

3 Internet Télécom Concept de Policy-Based Network La réservation est effectuée grâce à un paquet de supervision (ex : RSVP) : introduction de la signalisation Traitement centralisé de la requête dans un centre de contrôle : introduction de l intelligence dans le réseau

4 Les réseaux à base de politiques Politique : Ensemble de règles capables de gérer et de contrôler l accès aux ressources du réseau Quels utilisateurs pour quelles ressources du réseau? Applications prioritaires? Délivrer des services différenciés en fonction des besoins etc. introduction de la QoS. mobilité. sécurité. etc...

5 PBN ( Internet Télécom ) Point de décision Plan contrôle rminal 1 Plan utilisateur Terminal

6 Architecture détaillée Serveur d annuaires rminal PEP Policy Enforcement Point PDP Policy Decision Point PIB Local PDP Protocole de transaction : DIAMETER et... Autres bases, sondes

7 Modèles de politiques Outsourcing : le PDP reçoit une requête d un PEP. RSVP, MPLS, etc. Provisionning : le PDP envoie des directives de configuration sans avoir été sollicité.

8 Vue conceptuelle d un contrôle par politique Niveau business (SLA, SLS.) Niveau réseau (Règles, objectifs de la QoS) Niveau physique (Classification, gestion des mémoires)

9 Exemple

10 Protocoles (1) LDAP (Lightweight Directory Access Protocol) : un protocole utilisé pour accéder à des annuaires. LDAP est une version simplifiée du protocole DAP qui est utilisé pour accéder à des annuaires X.500.

11 Le protocole COPS

12 COPS : overview Le protocole COPS permet principalement : la gestion active des équipements du réseau. l introduction de la QoS. la communication entre domaines. la mobilité. de faire la sécurité. Le protocole COPS dispose de plusieurs extensions. COPS est officiellement reconnu par l IETF (RFC2748).

13 Le modèle de base du protocole COPS COPS a été proposé par le groupe RAP de IETF Protocole du type requête/réponse fondé sur le protocole TCP COPS définit des messages entre le PDP et le PEP COPS est un protocole flexible

14 Le modèle de base du protocole COPS (cont.) Le PEP doit d abord ouvrir une connexion TCP (3288) vers le PDP responsable Le PEP peut alors envoyer une requête au PDP La tolérance aux pannes est une des préoccupations des concepteurs de COPS LPDP peut remplacer le PDP (perte de connexion, décision trop longue)

15 La structure des messages COPS Encapsule une série d objets On ajoute une en-tête comprenant les champs suivants: Version Flags Op.code Client-type Message Length

16 La structure des messages COPS (cont.) Version Flags Op Code Client-type Message Length OBJET COPS OBJET COPS

17 La structure des messages de COPS : Op.code Request(REQ) Decision(DEC) Report State(RPT) Delete Request state (DRQ) Synchronize State Req (SSQ) Client-Open(OPN) Client-Accept(CAT) Client-Close(CC) Keep-Alive(KA) Synchronize Complete (SSC)

18 La structure des message de COPS : Client-type Nécessaire pour Interpréter les objets encapsulés Il peut prendre les valeurs: RSVP PR

19 Les objets COPS Length(octets) C-Num C-Type Contenue de l objet

20 Les objets COPS (cont.) Ils sont constitués: Une en-tête Length (octets) C-Num C-Type Contenu de l objet Un ou plusieurs mots de 32 bits

21 Les objets COPS : Classes d information(c-num) 1. Handle 2. Context 3. In interface 4. Out interface 5. Reason code 6. Decision 7. LPDP decision 8. Error 9. Client Specific Info 10. Keep-Alive Timer 11. PEP identification 12. Report Type 13. PDP Redirect Address 14. Last PDP Address 15. Accounting Timer 16. Message Integrity

22 Exemple d échange de messages TPEP OPN : (Client-type = COPS-MU) CAT : KA Timer TFPDP REQ : Handle, context = MU registration DEC : Handle, context, command RPT : Handle, report CC : Handle

23 COPS-SLS SLS Définition de SLS : Un SLS est un ensemble de paramètres dont leurs valeurs définissent le service offert à un flux de données. Pourquoi COPS-SLS? Protocole flexible permettant la négociation dynamique de SLS. Applique la technologie de gestion de politiques pour la gestion de SLS.

24 Modèle de COPS-SLS SLS

25 Caractéristiques de COPS-SLS SLS Deux phases : Phase de configuration PEP PDP Phase de négociation Utilisation de la PIB pour la représentation de SLS. Répondre à la diversité des paramètres de négociation souhaités par différents fournisseurs réseaux. Classes et attributs. - Nécessaire pour la configuration du processus de négociation. - Nécessaire pour représenter les paramètres d un SLS.

26 Objets de COPS-SLS SLS Instances de classes de la PIB encapsulées dans des objets ClientSI. Named ClientSI utilisés pour la phase de configuration. Signaled ClientSI utilisés pour la phase de négociation Une requête SLS est identifiée par l objet Client-Handle. Contient une valeur unique générée par le PEP. Objet utilisé également par le PDP.

27 Échange de messages : phase de configuration PDP OPN : [client-type = COPS-SLS] PEP CAT : [KA-Timer = 50] REQ : [Handle = req_a; Context = configuration; Named ClientSI = {frwprccapstable, slsnegocapstable, slsslstable}] DEC : [Handle = req_a; Context = configuration; Command = Install; Named ClientSI = {slsnegomode = predefined SLS types, slsnegomaxint = 120, slsslstable}] RPT : [Handle = req_a; Report = Success]

28 change de messages change de messages (Phase de Négociation PDP accepte un SLS) PEP PDP REQ : [Handle = req_b; Context = resource allocation; Signaled ClientSI = {slsslstable}] DEC : [Handle = req_b; Context = resource allocation; Command = Install] RPT : [Handle = req_b; Report = Success]

29 change de messages change de messages (Phase de Négociation PDP propose un autre SLS) PEP PDP REQ : [Handle = req_c; Context = resource allocation; Signaled ClientSI = {slsslstable}] DEC : [Handle = req_c; Context = resource allocation; Command = Install; SignaledClientSI = {slsslstable}] RPT : [Handle = req_c; Report = Success]

30 Implémentations de COPS : Support pour COPS dans les équipements de réseau Vovida : développement VoIP IPHighway Intel COPS Client SDK

31 Intel COPS SDK intégration dans des routeurs supportant DiffServ (provisionning) structure en couches Couche PIB DiffServ Couche COPS-PR Couche COPS Couche de portabilité

32 COPS-MU La mobilité de l utilisateur Composants de l architecture COPS-MU Description de l architecture COPS-MU Les objets COPS-MU Un petit exemple d échange de messages de COPS-MU

33 La mobilité de l utilisateur La mobilité du terminal Changer le point d attachement au réseau sans perdre la connexion en cours (Mobile IP). La mobilité personnelle Utiliser n importe quel terminal mobile ou fixe disponible et à partir de n importe quel réseau pour accéder à ses services personnels.

34 Composants de l architecture COPS-MU Gestion de la mobilité de l utilisateurs: L enregistrement de l utilisateur L enregistrement du terminal La portabilité des services La négociation de la QoS

35 Composants de l architecture HA. (Home Agent) COPS-MU(2) Maintien d une association (mobile binding) entre l adresse permanente (home address) et l adresse transitoire (CoA). Généralement situé dans le routeur d accès au réseau d origine. FA. (Foreign Agent) Maintien une liste des terminaux mobiles visitant le réseau étranger.

36 Composants de l architecture COPS-MU(3) Mobility binding L association entre l adresse du HA et de la CoA. Home Address Une adresse routable attribuée à un terminal mobile de manière permanente pour pouvoir le localiser. CoA. (Care of Address) L adresse du terminal mobile obtenue dans le réseau étranger. Peut être une adresse du FA ou une co-located-coa.

37 Composants de l architecture Terminal COPS-MU(4) User THN Terminal Home Network. TFN Terminal Foreign Network. MT Mobile Terminal. Identifié par sa home address et sa CoA. Terminal profile. Il contient les caractéristiques du terminal tel que le type de système d exploitation, les caractéristiques de traitement, de mémoire et d énergie. UHN User Home Network. UFN User Foreign Network. MU Mobile User. Identifié par un identificateur personnel universel ( ou SIM). User profile. Il contient les informations concernant l utilisateur ainsi que le profil des services personnels auquel il est abonné dans son réseau d origine et étranger.

38 Composants de l architecture Terminal THA Terminal HA. Il contient le profil du terminal et maintient la mobility binding. TPEP Terminal PEP. Le terminal est un PEP capable de dialoguer directement avec le PDP. THPDP Terminal Home PDP. Décisions liées à l enregistrement et la configuration du terminal. THPEP Terminal Home PEP. il interagit avec le THPDP et applique ses décisions politiques. COPS-MU(5) User UHA User HA. Il contient le profile de l utilisateur et maintient la mobility binding. UHPDP User Home PDP. Décisions liées à l enregistrement de l utilisateur mobile, la négociation de la portabilité des services et de la QoS. UHPEP User Home PEP. il interagit avec le UHPDP et applique ses décisions politiques.

39 Composants de l architecture COPS-MU(6) Terminal TFPEP Terminal Foreign PEP. FN Foreign Network. FPEP Mobile Terminal. User UFPEP User Foreign PEP.

40 Description de l architecture COPS-MU L enregistrement du terminal L enregistrement de l utilisateur La portabilité des services La négociation de la QoS

41 MU MT COPS-MU: la négociation de la QoS COPS-PR PDP Core network Wireless network access TPEP COPS-MU Network point of attachement

42 MU MT COPS-MU: la négociation de la QoS(2) THPDP FPDP UHPDP Local ressources 3 THPEP FPEP UHPEP 1 Local ressources 2 Local ressources TPEP

43 Les objets COPS-MU Les objet définis dans Mobile IP(COPS-MIP). Les nouveaux objets définis pour: supporter l enregistrement de l utilisateur. Transporter des paramètres du terminal, du réseau d accès, des services personnels et de profil de mobilité de l utilisateur pour la négociation de la portabilité des services et de la QoS. Les objets d authentification Actuellement, des recherches sont effectuées sur la définition d une nouvelle PIB.

44 Exemple d échange de messages TPEP OPN : (Client-type = COPS-MU) TFPDP CAT : KA Timer REQ : Handle, context = MU registration DEC : Handle, context, command RPT : Handle, report CC : Handle

45 OPS pour client RSVP Rappel de RSVP (Ressource reservation Protocol) Protocole de signalisation Permet l allocation des ressources au niveau des routeurs Permet au destinataire des données d avoir : Une garantie de délai, une bande passante suffisante, et donc, une QoS de bout en bout à travers le réseau

46 OPS pour client RSVP Rappel de RSVP (Ressource reservation Protocol) Serveur de données Path Resv

47 OPS pour client RSVP COPS-RSVP C est l IETF qui a spécifié les fonctionnalités de COPS La signalisation pour la QoS se fait par RSVP (outsourcing) le champ «CLIENT_TYPE» = 1 dans l entête du message COPS (c est le 1er type de client défini pour COPS).

48 OPS pour client RSVP COPS-RSVP : fonctionnement Serveur de règles Domaine administratif accepté supprimé erreur Allocation locale nœud par nœu

49 OPS pour client RSVP COPS-RSVP : fonctionnement (2ème scénarios) Serveur de règles Domaine administratif accepté supprimé erreur Insertion de l objet POLICY_DATA

50 OPS pour client RSVP COPS-RSVP : scénarios pour le contrôle RSVP PEP PDP <Request Message>::=<Common Herader><Handle A> <Context : in & out, PATH> <IN-Int if1><out-int if2> <ClientSI : Objets du message PATH> Interprète les données Consulte les bases Accepte le flux <Decision Message>::=<Common Herader><Handle A> <Context : in & out, PATH> <Decision : Commande, Install> <Request Message>::=<Common Herader><Handle B> <Context : allocation & out, RESV> <IN-Int if1><out-int if2> <ClientSI : Objets du message RESV> Le msg. Path arrive au destinataire Émission du msg. RESV <Decision Message>::=<Common Herader><Handle B> <Context : in, RESV> <Decision : Commande, Install> <Context: allocation, RESV><Decision : stateless, priority = 7> <Context:out, RESV><Decision : Commande, Install> <Decision : remplacement, POLICY_DATA> Interprète les données Initie l allocation POLICY_DATA, priorité,

51 OPS pour client RSVP COPS-RSVP : fonctionnement (résumé) quand le message RSVP est reçu, le PDP peut : accepter le message (donc réservation de ressources) rejeter le message (erreur, objets manquant, ) introduire une priorité (selon les clients) appliquer d autres objets (POLICY_DATA) les objets envoyés au PDP sont encapsulés dans l objet ClientSi les messages RSVP supporté par COPS sont : Path, Resv, PathErr et ResvErr le PDP doit connaître l état des équipements PEP => messages de rafraîchissement RSVP

52 OPS pour client RSVP COPS-RSVP : les bénéfices en RT, le réseau réagit à la demande, en fonction : du profil de l utilisateur des ressources disponibles allocation dynamique et variable dans le temps : bénéficier de la QoS si pas de ressources => mode BE => gestion fine et réactive des ressources

53 En résumé Le protocole COPS - SLS : Utilise les principes de la gestion fondée sur les politiques. Définit 2 phases : Configuration et Négociation. Utilise la notion de PIB pour représenter les informations de SLS.

54 erspectives En résumé Le PBN repose sur les principes d une gestion centralisée basée sur les politiques. L architecture PBN permet principalement : l automatisation de la configuration des nœuds; l application des services différentiés en RT; le support des CoS et de la QoS; le support des contraintes de sécurité, de la politique de l entreprise, SLA avec les clients, etc

55 erspectives En résumé Le protocole COPS permet principalement : la gestion active des équipements du réseau. l introduction de la QoS. la communication entre domaines. la mobilité. de faire la sécurité. Le protocole COPS dispose de plusieurs extensions. COPS est officiellement reconnu par l IETF (RFC2748).

56 erspectives L utilisation des politiques n est possible que si les utilisateurs finaux peuvent être clairement identifiés => un mécanisme robuste d identification. Les défies techniques : gestion des politiques authentification facturation des clients, comptabilité, maintenance, coût