1、 Union internationale des tlcommunicationsUIT-T J.179SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE LUIT (11/2005) SRIE J: RSEAUX CBLS ET TRANSMISSION DES SIGNAUX RADIOPHONIQUES, TLVISUELS ET AUTRES SIGNAUX MULTIMDIAS IPCablecom Prise en charge du multimdia par IPCablecom Recommandation UIT-T J
2、.179 Rec. UIT-T J.179 (11/2005) i Recommandation UIT-T J.179 Prise en charge du multimdia par IPCablecom Rsum La prsente Recommandation dcrit le dveloppement de services multimdias gnraux en fournissant une dfinition technique de plusieurs interfaces de signalisation fondes sur IP qui tirent parti d
3、es capacits centrales de gestion de politique et de qualit de service inhrentes aux cblo-modems. Les services multimdias sont dfinis comme tant des services fonds sur IP (par exemple, jeux en ligne, visioconfrence, transfert de mdia en continu, etc.) ncessitant des ressources de rseau fondes sur la
4、qualit de service (par opposition des services comme la navigation sur le Web, la messagerie lectronique, la messagerie instantane et le partage de fichiers qui sont habituellement fournis en utilisant des flux au mieux). Alors que la tlphonie ou les services fonds sur la voix ne sont pas spcifiquem
5、ent exclus de cette dfinition, lensemble des Recommandations IPCablecom-T porte spcifiquement sur ce type de fourniture de service et ces Recommandations devraient donc tre consultes en tant que de besoin. Source La Recommandation UIT-T J.179 a t approuve le 29 novembre 2005 par la Commission dtudes
6、 9 (2005-2008) de lUIT-T selon la procdure dfinie dans la Recommandation UIT-T A.8. ii Rec. UIT-T J.179 (11/2005) AVANT-PROPOS LUIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications. LUIT-T (Secteur de la normalisation de
7、s tlcommunications) est un organe permanent de lUIT. Il est charg de ltude des questions techniques, dexploitation et de tarification, et met ce sujet des Recommandations en vue de la normalisation des tlcommunications lchelle mondiale. LAssemble mondiale de normalisation des tlcommunications (AMNT)
8、, qui se runit tous les quatre ans, dtermine les thmes dtude traiter par les Commissions dtudes de lUIT-T, lesquelles laborent en retour des Recommandations sur ces thmes. Lapprobation des Recommandations par les Membres de lUIT-T seffectue selon la procdure dfinie dans la Rsolution 1 de lAMNT. Dans
9、 certains secteurs des technologies de linformation qui correspondent la sphre de comptence de lUIT-T, les normes ncessaires se prparent en collaboration avec lISO et la CEI. NOTE Dans la prsente Recommandation, lexpression “Administration“ est utilise pour dsigner de faon abrge aussi bien une admin
10、istration de tlcommunications quune exploitation reconnue. Le respect de cette Recommandation se fait titre volontaire. Cependant, il se peut que la Recommandation contienne certaines dispositions obligatoires (pour assurer, par exemple, linteroprabilit et lapplicabilit) et considre que la Recommand
11、ation est respecte lorsque toutes ces dispositions sont observes. Le futur dobligation et les autres moyens dexpression de lobligation comme le verbe “devoir“ ainsi que leurs formes ngatives servent noncer des prescriptions. Lutilisation de ces formes ne signifie pas quil est obligatoire de respecte
12、r la Recommandation. DROITS DE PROPRIT INTELLECTUELLE LUIT attire lattention sur la possibilit que lapplication ou la mise en uvre de la prsente Recommandation puisse donner lieu lutilisation dun droit de proprit intellectuelle. LUIT ne prend pas position en ce qui concerne lexistence, la validit ou
13、 lapplicabilit des droits de proprit intellectuelle, quils soient revendiqus par un Membre de lUIT ou par une tierce partie trangre la procdure dlaboration des Recommandations. A la date dapprobation de la prsente Recommandation, lUIT navait pas t avise de lexistence dune proprit intellectuelle prot
14、ge par des brevets acqurir pour mettre en uvre la prsente Recommandation. Toutefois, comme il ne sagit peut-tre pas de renseignements les plus rcents, il est vivement recommand aux responsables de la mise en uvre de consulter la base de donnes des brevets du TSB. UIT 2006 Tous droits rservs. Aucune
15、partie de cette publication ne peut tre reproduite, par quelque procd que ce soit, sans laccord crit pralable de lUIT. Rec. UIT-T J.179 (11/2005) iii TABLE DES MATIRES Page 1 Domaine dapplication 1 2 Rfrences. 1 2.1 Rfrences normatives 1 2.2 Rfrences informatives . 2 3 Termes et dfinitions 2 4 Abrvi
16、ations, acronymes et conventions 3 4.1 Abrviations et acronymes . 3 4.2 Conventions 5 5 Aperu gnral technique . 5 5.1 Bases de la qualit de service . 5 5.2 Architecture 9 6 Description de linterface dAutorisation 19 6.1 Portes: cadre du contrle de qualit de service 19 6.2 Transitions de porte 26 6.3
17、 Profil COPS pour IPCablecom multimdia 32 6.4 Formats de message du protocole de commande de porte . 35 6.5 Fonctionnement du protocole de commande de porte 59 7 Description de linterface dchange de message dvnements . 69 7.1 Introduction 69 7.2 Exigences du Serveur darchivage 71 7.3 Exigences gnral
18、es pour llment de rseau IPCablecom multimdia 72 7.4 Messages dvnement pour IPCablecom multimdia . 74 7.5 Attributs dchange de messages dvnement pour IPCablecom multimdia 80 7.6 Protocole RADIUS de comptabilit . 87 8 Exigences de scurit 89 8.1 Interface de QS CMTS CM (pkt-mm-1) . 89 8.2 Interface COP
19、S Serveur de politique CMTS (pkt-mm-2). 89 8.3 Interface COPS gestionnaire dapplication Serveur de politique (pkt-mm-3) . 90 8.4 Interface de message dvnement Serveur de politique RKS (pkt-mm-4) . 90 8.5 Interface de message dvnement CMTS RKS (pkt-mm-5) 91 9 Mappage dun Profil de trafic spec de flux
20、 en DOCSIS . 91 9.1 Mappage de Spec de flux en type de programmation DOCSIS . 91 9.2 Mappage des Spec de flux en Paramtres de trafic DOCSIS. 92 9.3 Paramtres amont DOCSIS 94 9.4 Paramtres DOCSIS aval . 98 iv Rec. UIT-T J.179 (11/2005) Page 10 Flux de messages 100 10.1 Squence de messages de base. 10
21、0 10.2 Squence de messages dtaille . 102 11 Questions encore ltude 120 Appendice I Informations de base 122 I.1 Introduction 122 I.2 Objectifs et domaine dapplication dIPCablecom multimdia. 123 I.3 Cadre IPCablecom multimdia. 125 I.4 Qualit de service mandate avec politique pousse (Scnario 1) . 131
22、I.5 QS demande par le client avec politique pousse (scnario 2). 140 I.6 Qualit de service demande par le client avec politique pousse (Scnario 3) 149 I.7 Comparaison dIPCablecom-T et dIPCablecom multimdia. 151 Appendice II Lignes directrices concernant lattribution du numro de version 156 Rec. UIT-T
23、 J.179 (11/2005) 1 Recommandation UIT-T J.179 Prise en charge du multimdia par ICablecom 1 Domaine dapplication La prsente Recommandation dcrit le dveloppement de services multimdias gnraux en fournissant une dfinition technique de plusieurs interfaces de signalisation fondes sur IP qui tirent parti
24、 des capacits centrales de gestion de politique et de qualit de service inhrentes aux cblo-modems. Les services multimdias sont dfinis comme tant des services fonds sur IP (par exemple, jeux en ligne, visioconfrence, transfert de mdia en continu, etc.) ncessitant des ressources de rseau fondes sur l
25、a qualit de service (par opposition des services comme la navigation sur le Web, la messagerie lectronique, la messagerie instantane et le partage de fichiers qui sont habituellement fournis en utilisant des flux au mieux). Alors que la tlphonie ou les services fonds sur la voix ne sont pas spcifiqu
26、ement exclus de cette dfinition, lensemble des Recommandations IPCablecom-T porte spcifiquement sur ce type de fourniture de service et ces Recommandations devraient donc tre consultes en tant que de besoin. 2 Rfrences 2.1 Rfrences normatives La prsente Recommandation se rfre certaines dispositions
27、des Recommandations UIT-T et textes suivants qui, de ce fait, en sont partie intgrante. Les versions indiques taient en vigueur au moment de la publication de la prsente Recommandation. Toute Recommandation ou tout texte tant sujet rvision, les utilisateurs de la prsente Recommandation sont invits s
28、e reporter, si possible, aux versions les plus rcentes des rfrences normatives suivantes. La liste des Recommandations de lUIT-T en vigueur est rgulirement publie. La rfrence un document figurant dans la prsente Recommandation ne donne pas ce document, en tant que tel, le statut dune Recommandation.
29、 1 Recommandation UIT-T J.112 Annexe B (2004), Spcifications de linterface du service de transmission de donnes par cble: interface radiolectrique. 2 IETF RFC 1305 (1992), Network Time Protocol (Version 3) Specification, Implementation and Analysis (Spcification du protocole temporel de rseau (versi
30、on 3), mise en uvre et analyse). 3 IETF RFC 2210 (1997), The Use of RSVP with IETF Integrated Services (Utilisation du protocole RSVP avec des services intgrs de lIETF). 4 IETF RFC 2211 (1997), Specification of the Controlled-Load Network Element Service (Spcification du service dlment de rseau char
31、ge contrle). 5 IETF RFC 2212 (1997), Specification of Guaranteed Quality of Service (Spcification de la qualit de service garantie). 6 IETF RFC 2474 (1998), Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (Dfinition du champ de services diffrentis dans les en-
32、ttes Ipv4 et Ipv6). 7 IETF RFC 2748 (2000), The COPS (Common Open Policy Service) Protocol (Le protocole COPS (Service commun de politique ouverte). 8 IETF RFC 2866 (2000), RADIUS Accounting (Comptabilit RADIUS). 2 Rec. UIT-T J.179 (11/2005) 9 Recommandation UIT-T J.163 (2005), Qualit de service dyn
33、amique pour la fourniture de services en temps rel sur les rseaux de tlvision par cble utilisant des cblo-modems. 10 Recommandation UIT-T J.164 (2005), Prescriptions relatives aux messages dvnement pour la prise en charge des services en temps rel sur les rseaux de tlvision par cble utilisant des cb
34、lo-modems. 11 Recommandation UIT-T J.170 (2005), Spcification de la Scurit sur IPCablecom. 12 Recommandation UIT-T J.125 (2004), Confidentialit des liaisons pour les implmentations de cblo-modems. 2.2 Rfrences informatives 13 IETF RFC 1633 (1994), Integrated Services in the Internet Architecture: An
35、 Overview. (Services intgrs dans larchitecture Internet: vue densemble). 14 IETF RFC 2205 (1997), Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification (Protocole de rservation de ressources (RSVP) Version 1 de la spcification fonctionnelle) 15 IETF RFC 2216 (1997), Network Element
36、 Service Specification Template (Modle de spcification de service dlment de rseau). 16 IETF RFC 2475 (1998), An Architecture for Differentiated Services (Architecture de services diffrentis). 17 IETF RFC 2670 (1999), Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS Complian
37、t RF Interfaces (Base dinformations de gestion dinterface radio frquence pour interfaces RF conformes MCNS/DOCSIS). 18 IETF RFC 2753 (2000), A Framework for Policy-based Admission Control (Cadre gnral pour le contrle dadmission fond sur la politique). 19 IETF RFC 3084 (2001), COPS Usage for Policy P
38、rovisioning (COPS-PR) (Utilisation de COPS pour la configuration de politique (COPS-PR). 20 IETF RFC 3175 (2001), Aggregation of RSVP for IPv4 and IPv6 Reservations (Agrgation de RSVP pour les rservations IPv4 et IPv6). 21 CableLabs (http:/ 22 IETF RFC 2751 (2000), Signaled Preemption Priority Polic
39、y Element. 3 Termes et dfinitions La prsente Recommandation dfinit les termes suivants: 3.1 client de type 1: le client de type 1 reprsente les points dextrmit ordinaires existants (par exemple, des applications pour micro-ordinateur, des consoles de jeu) qui ne possdent pas de capacits spcifiques d
40、e prise en charge ou de signalisation de qualit de service. Ce client ne sait rien des cblo-modems, dIPCable2Home, ou de lchange de messages IPCablecom, et par consquent, on ne peut rien exiger de sa part pour ce qui les concerne. De tels clients vont des simples appareils de prsentation analogiques
41、 audio et vido des priphriques en rseau et dispositifs lectroniques complexes, tels que les botiers-dcodeurs ou les consoles de jeu. Ce client communique avec un gestionnaire dapplication pour ses demandes de service, et na pas besoin de demander des ressources de qualit de service directement lopra
42、teur du rseau daccs. La prsente Recommandation ne prend en charge que le client de type 1. 3.2 client de type 2: le client de type 2 est semblable un adaptateur MTA de tlphonie dIPCablecom-T en ce quil assure la signalisation de qualit de service fonde sur la qualit de Rec. UIT-T J.179 (11/2005) 3 s
43、ervice dynamique dIPCablecom. Ce client prend en charge la qualit de service multimdia dIPCablecom et communique avec un gestionnaire dapplication pour demander le service et obtenir un jeton pour les ressources du rseau daccs. Ce client prsente alors ce jeton lorsquil demande des ressources de qual
44、it de service du rseau daccs (pkt-mm-1, pkt-mm-6). La prise en charge du client de type 2 par la prsente Recommandation fera lobjet dun complment dtude. 3.3 client de type 3: le client de type 3 demande de la qualit de service sur la base du protocole RSVP sans interagir avec un gestionnaire dapplic
45、ation. Ce client prend en charge le protocole RSVP fond sur les normes de lIETF et utilise ce protocole pour demander des ressources de qualit de service du rseau daccs directement au systme CMTS. La prise en charge du client de type 3 par la prsente Recommandation fera lobjet dun complment dtude. 3
46、.4 DOCSIS: dcrit une technologie spcifique des cblo-modems qui est dveloppe par les Laboratoires de Tlvision par cble, Inc. (“CableLabs“) et dont la spcification se trouve ladresse: http:/ La version internationale est dfinie lAnnexe B/J.112. 3.5 IPCablecom-T: srie des Recommandations de lUIT-T sur
47、IPCablecom qui prend en charge le service tlphonique. 4 Abrviations, acronymes et conventions 4.1 Abrviations et acronymes La prsente Recommandation utilise les abrviations suivantes: AM gestionnaire dapplication (application manager). Systme qui sert dinterface au ou aux serveurs de politique pour demander un service fond sur la qualit de service au nom de lutilisateur final ou du systme de gestion de rseau. BCID identifiant de corrlation de facturation (billing correlation ID). Dfini dans la Reco
