Policy-Based Networks & COPS Protocol

DEA MISI Samir Tohmé Mars 2004

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

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

Les réseaux à base de politiques
Ensemble de règles capables de gérer et de Politique : 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...

PBN ( Internet Télécom )
Point de décision Plan contrôle

erminal 1

Plan utilisateur

Terminal

Architecture détaillée
PDP
Policy Decision Point

Serveur d ’annuaires

PIB PEP
Policy Enforcement Point

erminal

Local PDP

Protocole de transaction : DIAMETER et...

Autres bases, sondes

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é.

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)

Exemple

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.

Le protocole COPS

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).

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

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)

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

La structure des messages COPS (cont.)
Version Flags

Op Code

Client-type

Message Length

OBJET COPS OBJET COPS

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)

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

Les objets COPS

Length(octets)

C-Num

C-Type

Contenue de l ’objet

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

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

Exemple d’échange de messages
OPN :: (Client-type = COPS-MU) OPN (Client-type = COPS-MU)

TPEP

CAT :: KA Timer CAT KA Timer REQ :: Handle, context = MU registration REQ Handle, context = MU registration DEC :: Handle, context, command … DEC Handle, context, command …

TFPDP

RPT : Handle, report

CC :: Handle CC Handle

COPS-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.

Modèle de COPS-SLS

Caractéristiques de COPS-SLS
Deux phases :
Phase de configuration Phase de négociation

PEP … …

PDP

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.

Objets de COPS-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.

Échange de messages : phase
de configuration
PEP
OPN : [client-type = COPS-SLS]

PDP

CAT : [KA-Timer = 50]
REQ : [Handle = re q_A; Context = co nfiguration; Named ClientSI = {frwPrcCapsTable , slsNegoCapsTable , slsSlsTable}]

uration; req_A; Context = config DEC : [Handle = ed ClientSI = Command = Install; Nam SLS types, NegoMode = predefined {sls sSlsTable}] slsNegoMaxInt = 120, sl
RPT : [Handle = re q_A; Report = Suc cess]

Échange de messages
(Phase de Négociation – PDP accepte un SLS)
PEP
REQ : [Handle = re q_B; Context = re source allocation; Signale d ClientSI = {slsS lsTable}]

PDP

ontext = resource EC : [Handle = req_B; C D Install] allocation; Command =
RPT : [Handle = re q_B; Report = Suc

cess]

Échange de messages
(Phase de Négociation – PDP propose un autre SLS)
PEP
REQ : [Handle = re q_C; Context = re source allocation; Signale d ClientSI = {slsS lsTable}]

PDP

; Context = resource DEC : [Handle = req_C lientSI = mand = Install; SignaledC allocation; Com {slsSlsTable}]
RPT : [Handle = re q_C; Report = Suc

cess]

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

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é

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

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.

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

Composants de l’architecture COPS-MU(2)
• HA. (Home Agent)
• 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.

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.

Composants de l’architecture COPS-MU(4)
Terminal 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 (e-mail 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.

Composants de l’architecture COPS-MU(5)
Terminal User
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. 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. UHA User HA. Il contient le profile de l’utilisateur et maintient la mobility binding.

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

User
UFPEP User Foreign PEP.

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

COPS-MU: la négociation de la QoS
COPS-PR

PDP

Core network
Wireless network COPS-MU access TPEP MU Network point of attachement

MT

COPS-MU: la négociation de la
QoS(2)
THPDP

FPDP

2

UHPDP

3
THPEP
Local ressources

1
TPEP
MU

FPEP
Local ressources

UHPEP
Local ressources

MT

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.

Exemple d’échange de messages
TPEP
OPN :: (Client-type = COPS-MU) OPN (Client-type = COPS-MU) CAT :: KA Timer CAT KA Timer REQ :: Handle, context = MU registration REQ Handle, context = MU registration DEC :: Handle, context, command … DEC Handle, context, command …

TFPDP

RPT : Handle, report

CC :: Handle CC Handle

COPS 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

COPS pour client RSVP
Rappel de RSVP (Ressource reSerVation Protocol)

Serveur de données

Path Resv

COPS 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).

COPS pour client RSVP
COPS-RSVP : fonctionnement

Serveur de règles

Domaine administratif

• accepté • supprimé • erreur

Allocation locale nœud par nœu

COPS 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

COPS pour client RSVP
COPS-RSVP : scénarios pour le contrôle RSVP PEP
<Request M essage>::=< Common H <Context : erader><H in & out, P andle A> ATH> <IN-Int if1 ><OUT-In t if2> <Clie ntSI : Obje ts du messa ge PATH>

PDP
•Interprète les données •Consulte les bases •Accepte le flux

ndle erader><Ha <Common H essage>::= <Decision M > & out, PATH <Context : in Install> ommande, <Decision : C

A>

•Le msg. Path arrive au destinataire •Émission du msg. RESV

<Request M essage>::=< Common H <Context : erader><H allocation & andle B> out, RESV> <IN-Int if1 ><OUT-Int if2> <Clien tSI : Objets du message RESV>

le B> ader><Hand o m m o n He r age>::=<C de, Install> 7> ecision Mess n : Comman <D > <Decisio ss, priority = xt : in, RESV ision : statele <Conte ><Dec stall> ation, RESV ommande, In ontext: alloc <C Decision : C > t, RESV>< ICY_DATA <Context:ou ement, POL emplac <Decision : r

•Interprète les données •Initie l’allocation •POLICY_DATA, priorité, …

COPS 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

COPS 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

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.

Perspectives
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

Perspectives
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).

Perspectives
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 …

Sign up to vote on this title
UsefulNot useful