Network Working Group B

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

Un routeur de services intégrés (int-serv, Integrated Services ) effectue le contrôle d’admission et l’allocation de ressources sur la base des informations contenues dans une TSpec (entre autres choses). Comme elles sont actuellement définies, les TSpec portent des informations sur le débit de données (en utilisant un baquet de jetons) et les gammes de tailles de paquet du flux en question. Cependant, la TSpec peut n’être pas une représentation précise des ressources nécessaires pour prendre en charge la réservation si le routeur est capable de compresser les données au niveau liaison. La présente spécification décrit une extension à la TSpec qui permet à un envoyeur de données potentiellement compressibles de fournir des indications aux routeurs int-serv sur la compressibilité qu’ils peuvent obtenir. Les routeurs qui prennent en charge la compression appropriée tirent parti de l’indication dans leurs décisions de contrôle d’admission et leurs procédures d’allocation de ressources ; les autres routeurs ignorent l’indication. Une application initiale de cette approche est de notifier aux routeurs qui effectuent la compression d’en-tête du protocole de transport en temps réel (RTP, real-time transport protocol) qu’ils peuvent allouer moins de ressources aux flux RTP.

Table des Matières

1. Introduction 1

2. Ajout d’une indication à la TSpec de l’envoyeur 2

3. Contrôle d’admission et allocation de ressource 2

4. Format d’objet 4

4.1 Numérotation des indications 5

5. Rétro compatibilité 5

6. Considérations pour la sécurité 6

7. Considérations relatives à l’IANA 6

8. Remerciements 6

9. Références 6

10. Adresse des auteurs 6

Déclaration complète de droits de reproduction 7

Dans un réseau à intégration de services, RSVP [RFC2205] peut être utilisé comme protocole de signalisation par lequel les nœuds d’extrémité et les éléments de réseau échangent des informations sur les exigences de ressource, la disponibilité des ressources, et l’établissement et la suppression des réservations de ressources. L’architecture de services intégrés définit actuellement deux services, la charge contrôlée [RFC2211] et le service garanti [RFC2212]. Lors de l’établissement d’une réservation qui utilise l’un ou l’autre service, RSVP demande que diverses informations soient fournies par le ou les envoyeurs et receveurs pour une certaine réservation qui sont utilisées pour les besoins du contrôle d’admission et de l’allocation de ressources à cette réservation. Certaines de ces informations sont fournies par le receveur dans un objet FLOWSPEC; et certaines sont fournies par l’envoyeur dans un objet SENDER_TSPEC [RFC2210].

Une situation qui n’est pas bien traitée par les spécifications actuelles se produit lorsque un routeur qui prend une décision de contrôle d’admission est capable d’effectuer une sorte de compression sur le flux pour lequel une réservation est demandée. Par exemple, supposons qu’un routeur soit capable d’effectuer la compression d’en-tête IP/UDP/RTP sur une de ses interfaces [RFC2508]. La bande passante nécessaire pour s’accommoder d’un flux compressible sur cette interface sera inférieure à la quantité contenue dans la SENDER_TSPEC. Donc, le routeur peut rejeter à tort une réservation qui pourrait en fait être accordée. En même temps, l’envoyeur n’a pas la liberté de réduire sa TSpec pour tenir compte de la compression des données, car il ne sait pas si les routeurs le long du chemin sont en fait capables d’effectuer la compression. De plus, il est probable que seul un sous ensemble des routeurs sur le chemin (par exemple, ceux qui sont connectés à des liaisons série à bas débit) vont effectuer la compression.

La présente spécification décrit un mécanisme par lequel l’envoyeur peut fournir une indication aux éléments de réseau en ce qui concerne la compressibilité du flux de données qu’il va générer. Les éléments de réseau peuvent utiliser cette indication comme élément supplémentaire de données lors de la prise de décisions de contrôle d’admission et d’allocation de ressource.

La présente spécification se restreint au seul cas où la compression est effectuée liaison par liaison, comme avec la compression d’en-tête. D’autres cas (par exemple, transcodage, détection de silence audio) qui affecteraient la bande passante consommée à tous les nœuds vers l’aval feront l’objet d’études ultérieures. Dans ces derniers cas, il sera nécessaire de modifier la TSpec d’un envoyeur lorsque elle est passée à travers un nœud compresseur. Dans l’approche présentée ici, la TSpec d’envoyeur apparaît non modifiée sur le réseau, comme spécifié dans la [RFC2210].

L’endroit approprié pour une "indication de compressibilité" est la TSpec d’envoyeur. Les raisons de ce choix sont que :

- l’envoyeur est celui qui sait le mieux à quoi vont ressembler les données,

- à la différence de l’AdSpec, la TSpec d’envoyeur n’est pas modifiée dans le transit,

- du point de vue de RSVP, la TSpec d’envoyeur est un ensemble opaque de paramètres qui sont passés au "contrôle de trafic" (contrôle d’admission et allocation de ressources) ; l’indication de compressibilité est juste un tel paramètre.

Une alternative au placement de ces informations dans la TSpec serait d’utiliser un objet supplémentaire dans le message RSVP PATH. Bien qu’on puisse le faire fonctionner pour RSVP, cela ne règle pas le problème de comment obtenir les mêmes informations pour un routeur intserv lorsque des mécanismes autres que RSVP sont utilisés pour réserver des ressources. Cela impliquerait aussi un changement du traitement du message RSVP juste pour obtenir plus d’informations pour des entités qui sont logiquement extérieures à RSVP (contrôle d’admission et allocation de ressources). L’inclusion des informations dans la TSpec semble préférable et plus cohérente avec l’architecture des services intégrés.

Le contenu de l’indication va probablement varier selon le scénario exact. L’indication doit dire aux routeurs qui le reçoivent :

- suffisamment d’informations pour permettre à un routeur de déterminer le taux de compression qui peut probablement être réalisé.

Dans un cas simple comme celui de la compression d’en-tête IP/UDP/RTP, il peut être suffisant de ne rien dire de plus aux routeurs que le fait que des données IP/UDP/RTP sont envoyées. Sachant cela, la taille maximum de paquet du flux (d’après la TSpec) et les conditions locales au niveau du routeur, peuvent être suffisantes pour permettre au routeur de déterminer la réduction de bande passante que la compression va permettre. Dans d’autres cas, il peut être utile ou nécessaire que l’envoyeur inclue des informations quantitatives supplémentaires pour aider au calcul du taux de compression. Pour traiter ces cas, des paramètres supplémentaires contenant des quantités diverses d’informations peuvent être ajoutés à la TSpec de l’envoyeur. On décrit ici les détails du codage de ces paramètres, suivant l’approche décrite à l’origine dans la [RFC2210].

Les routeurs des services intégrés prennent leurs décisions de contrôle d’admission et d’allocation de ressources sur la base, entre autres choses, des informations de la TSpec de l’envoyeur. Si un routeur reçoit une TSpec d’envoyeur qui contient une indication de compressibilité, il peut utiliser l’indication pour calculer une "TSpec compressée" qui peut être utilisée comme entrée dans le processus de contrôle d’admission et d’allocation de ressources en place dans la TSpec fournie par l’envoyeur. Pour rendre cela concret, considérons le simple exemple suivant. Un routeur reçoit une demande de réservation pour un service à charge contrôlée où :

- les TSpec d’envoyeur et de receveur contiennent des paramètres de baquet de jetons identiques ;

- la TSpec d’envoyeur contient une indication de compressibilité disant que les données sont IP/UDP/RTP ;

- l’indication de compressibilité comporte un facteur de compression de 70 %, signifiant que la compression d’en-tête IP/UDP/RTP va causer une réduction de la bande passante consommée au niveau liaison d’un facteur de 0,7 (résultat de la compression de 40 octets d’en-tête IP/UDP/RTP à 4 octets sur un paquet de 120 octets) ;

- l’interface sur laquelle la réservation est à installer est capable d’effectuer la compression d’en-tête IP/UDP/RTP.

Le routeur peut donc conclure qu’il peut réduire les paramètres du baquet de jetons r et b d’un facteur 0,7 c’est-à-dire respectivement, de 33,6 kbit/s et 84 octets. M peut être réduit du même facteur (à 84 octets) mais un calcul différent devrait être utilisé pour m. Si l’envoyeur envoie en fait un paquet de taille m, son en-tête peut être compressé de 40 octets à 4, réduisant donc le paquet à 28 octets ; cette valeur devrait être utilisée pour m.

Noter que si la source envoie toujours des paquets de la même taille et si IP/UDP/RTP fonctionne toujours de façon parfaite, le facteur de compression n’est pas strictement nécessaire. Le routeur peut déterminer indépendamment qu’il peut compresser les 40 octets de l’en-tête IP/UDP/RTP à 4 octets (avec une forte probabilité). Pour déterminer le pire cas de gain (le plus petit) fourni par la compression, il peut supposer que l’envoyeur envoie toujours les paquets de la taille maximum à 48 kbit/s, c’est-à-dire, un paquet de 120 octets toutes les 20 millisecondes. Le routeur peut conclure que ces paquets seront compressés à 84 octets, donnant un débit de baquet de jetons de 33,6 kbit/s et une profondeur de baquet de jetons de 84 octets comme auparavant. Si l’envoyeur veut permettre un calcul indépendant du gain de compression par le routeur, le facteur de compression explicite peut être omis de la TSpec. Les détails du codage de la TSpec sont donnés ci-dessous.

Pour généraliser la discussion, supposons que la TSpec d’envoyeur consiste en valeurs (r, b, p, M, m) que le facteur de compression explicite fourni par l’envoyeur soit f pour cent, et que le nombre d’octets économisés par la compression soit N, indépendamment de la taille du paquet. Les paramètres dans la TSpec compressée seraient :

Les calculs pour r' et b' reflètent le fait que f est exprimé en pourcentage et doit donc être divisé par 100. Les calculs pour M' et m' ne tiennent que dans le cas où l’algorithme de compression réduit les paquets d’un certain nombre d’octets indépendant du contenu ou de la longueur du paquet, comme c’est vrai pour la compression d’en-tête. D’autres algorithmes de compression peuvent n’avoir pas cette propriété. Pour déterminer la valeur de N, le routeur peut avoir besoin de faire des hypothèses de plus mauvais cas sur le nombre d’octets qu’il peut retirer par compression, qui dépendent de facteurs tels que la présence de sommes de contrôle UDP et de la linéarité des horodatages RTP.

Toutes ces valeurs ajustées ont utilisées dans la TSpec compressée. Les algorithmes de contrôle d’admission et d’allocation de ressource du routeur devraient se comporter comme si la TSpec d’envoyeur contenait ces valeurs. La [RFC2205] donne un ensemble de règles par lesquelles les TSpec d’envoyeur et de receveur sont combinées pour calculer une seule TSpec `effective' qui est passée au contrôle d’admission. Lorsque une réservation couvrant plusieurs envoyeurs doit être installée, il est nécessaire de réduire chaque TSpec d’envoyeur du facteur de compression approprié. L’ensemble des TSpec d’envoyeur qui s’appliquent à une seule réservation sur une interface a été totalisé pour former la TSpec d’envoyeur effective qui est passée au contrôle de trafic. La TSpec de receveur effective n’a pas besoin d’être modifiée ; le contrôle de trafic retient la plus forte limite inférieure de ces deux TSpec pour prendre ses décisions de contrôle d’admission et d’allocation de ressource.

Le traitement de la RSpec de receveur dépend de si on utilise le service à charge contrôlée ou le service garanti. Dans le cas de la charge contrôlée, aucun traitement supplémentaire n’est nécessaire sur la RSpec. Cependant, une RSpec de service garanti contient un terme de débit R qui n’a pas besoin d’être ajusté vers le bas pour tenir compte de la compression. Pour déterminer comment R devrait être ajusté, on note que le receveur a choisi R pour satisfaire un certain objectif de délai, et que les termes dans l’équation de délai qui dépendent de R sont b/R et C/R (quand le débit de crête est grand). La sporadicité b est dans ce cas la somme de la taille de salve de tous les envoyeurs pour cette réservation, et chacun de ces nombres a été réduit du facteur de compression approprié. Donc, R devrait être réduit en utilisant un facteur de compression moyen :

où bk est la taille de salve de l’envoyeur k et fk est le facteur de compression correspondant pour cet envoyeur. Noter que f_avg, comme les fi individuels, est un pourcentage. Noter aussi qu’il résulte de ceci un facteur de compression de f dans le cas où tous les envoyeurs utilisent le même facteur de compression f.

Pour empêcher une augmentation de délai causée par le terme C/R lorsque est utilisée la valeur réduite de R pour la réservation, il est nécessaire pour ce bond de "gonfler" la valeur de C en la divisant par (f_avg/100). Ceci va être cause que la contribution au délai faite par le terme C de ce bond sera ce que le receveur attendrait lorsque il choisira sa valeur de R.

Il y a certains risques à ajuster vers le bas les exigences de ressources pour les besoins du contrôle d’admission et de l’allocation de ressource. La plupart des algorithmes de compression ne sont pas complètement déterministes, et il y a donc un risque qu’un flux se retrouve dans un état moins compressible qu’il n’avait été supposé par le contrôle d’admission. Ce risque est réduit par l’utilisation du facteur explicite de compression fourni par l’envoyeur, et peut être minimisé si le routeur fait des hypothèses de pire des cas sur la quantité de compression qui peut être réalisée. Ceci est un peu analogue au compromis entre les hypothèses de pire des cas lorsque on fait le contrôle d’admission et des hypothèses plus optimistes, comme dans le cas d’un contrôle d’admission fondé sur des mesures. Si un flux se trouve être moins compressible qu’on ne l’avait supposé lorsque on effectue un contrôle d’admission, tout trafic supplémentaire va devoir être régulé conformément aux règles normales de intserv. Par exemple, si le routeur supposait que le flux à 48 kbit/s de ci-dessus pourrait être compressé à 33,6 kbit/s et qu’il serait finalement possible de le compresser à 35 kbit/s, les 1,4 kbit/s supplémentaires seraient traités comme un excédent. Le traitement exact d’un tel excédent dépend du service.

Un scénario similaire peut survenir si un envoyeur prétend que des données pour certaines sessions sont compressibles alors qu’en fait elles ne le sont pas, ou exagère la portée de leur compressibilité. Cela peut être cause que le flux soit admis par erreur, et cause l’allocation de ressources insuffisantes. Pour empêcher un tel comportement d’affecter d’autres flux réservés, tout flux qui envoie une indication de compressibilité devrait être régulé (dans tout routeur qui a fait usage de cette indication pour son contrôle d’admission) dans l’hypothèse, bien sûr, où il est compressible, c’est-à-dire, en utilisant la TSpec compressée. C’est-à-dire que si il se trouve que le flux est moins compressible qu’annoncé, le trafic supplémentaire qui doit être transmis par le routeur au-dessus de la TSpec compressée sera régulé selon les règles d’intserv qui sont appropriées pour le service. Noter que les services qui utilisent la taille maximum de datagramme M pour les besoins de la régulation (par exemple, le service garanti [RFC2210]) devraient continuer d’utiliser la valeur non compressée de M pour laisser la possibilité que certains paquets ne soient pas bien compressés.

Noter que RSVP n’exige généralement pas que les flux soient régulés à chaque bond. Pour citer la [RFC2205] : “Certains services de QS peuvent exiger une régulation du trafic à certaines ou toutes (1) les bordures du réseau, (2) à un point de fusion de données provenant d’envoyeurs multiples, et/ou (3) un point de séparation où les flux de trafic provenant de l’amont peuvent être supérieurs à la réservation demandée vers l’aval. RSVP sait où surviennent de tels points et doit l’indiquer au mécanisme de contrôle de trafic".

Pour des besoins de régulation, un routeur qui utilise l’indication de compressibilité dans une TSpec d’envoyeur devrait se comporter comme si il était à la bordure du réseau, parce qu’il est en position de recevoir du trafic d’un envoyeur qui, lorsque il est passé par la régulation à la bordure réelle du réseau, peut quand même avoir besoin d’une régulation si la quantité de données envoyée excède la quantité décrite par la TSpec compressée.

L’indication de compressibilité peut être incluse dans la TSpec d’envoyeur en utilisant les règles de codage de l’Appendice A de la [RFC2210]. La TSpec d’envoyeur complète est la suivante :

La différence entre cette TSpec et celle décrite dans la [RFC2210] est que la longueur globale contenue dans le premier mot est augmentée de 3, comme l’est la longueur de "données du service 1", et les paramètres de la TSpec originale sont suivis par un nouveau paramètre, l’indication de compressibilité. Ce paramètre contient l’en-tête standard de paramètre, et un numéro alloué qui indique le type de compression qui est possible sur ces données. Des valeurs différentes de l’indication vont impliquer des algorithmes différents de compression qui peuvent être appliqués aux données. Les détails du schéma de numérotation des indications sont donnés plus loin.

Après la valeur de l’indication se trouve le facteur de compression f, exprimé par un entier de 32 bits qui représente le facteur par une valeur de pourcentage. La gamme valide de ce facteur est {0, 100}. Un envoyeur qui ne sait pas quelle valeur utiliser ou souhaite laisser le calcul du facteur de compression à la discrétion des routeurs peut utiliser la valeur réservée de 0 pour indiquer ce fait. Zéro est réservé parce qu’il n’est pas possible de compresser un flux de données de zéro bits par seconde. La valeur 100 indique qu’aucune compression n’est attendue sur ce flux.

Dans certains cas, des informations quantitatives supplémentaires sur le trafic peuvent être nécessaires pour permettre à un routeur de déterminer la quantité de compression possible. Dans ce cas, un codage différent du paramètre sera nécessaire.

Dans certains cas, il peut être souhaitable d’inclure plus d’une indication dans une TSpec (par exemple, parce que plus d’un schéma de compression peut être appliqué aux données). Dans ce cas, plusieurs instances du paramètre 126 peuvent apparaître dans la TSpec et la longueur globale de la TSpec et la longueur des données du Service 1 seraient augmentées d’autant.

Noter que l’indication de compression est, comme la TSpec de baquet de jetons, non spécifique d’un seul service, et donc, a une valeur de paramètre de moins de 128. Il est aussi inclus au titre des informations par défaut/globales (numéro de service 1).

Les indications sont représentées par un champ de 32 bits, avec les 16 bits de poids fort qui sont le numéro de protocole de compression IP comme défini dans la [RFC1332] et la [RFC2509]. Les 16 bits de moindre poids sont une sous option pour les cas où le numéro de protocole de compression IP seul serait insuffisant pour les besoins de int-serv. Les valeurs d’indication suivantes sont exigées au moment de la présente publication :

- indication = 0x002d0000 : données IP/TCP qui peuvent être compressées selon la [RFC1144]

- indication = 0x00610000 : données IP qui peuvent être compressées selon la [RFC2507]

- indication = 0x00610100 : données IP/UDP/RTP qui peuvent être compressées selon la [RFC2508]

Il est souhaitable qu’un routeur intserv qui reçoit ce nouveau format de TSpec et ne comprend pas l’indication de compressibilité ignore en silence l’indication plutôt que de rejeter la TSpec entière (ou le message qui le contient) comme mal formée. Bien que la [RFC2210] spécifie clairement le format des TSpec de façon qu’elles puissent être analysées même lorsque elles contiennent des paramètres inconnus, elle ne spécifie pas quelle action devrait être effectuée lorsque des objets inconnus sont reçus. Donc il est assez possible que certaines mises en œuvre de RSVP éliminent des messages PATH qui contiennent une TSpec avec l’indication de compressibilité. Dans un tel cas, le routeur devrait envoyer un message PathErr à l’hôte envoyeur. Le message devrait indiquer une TSpec mal formée (code d’erreur 21, sous code 04). L’hôte peut en conclure que l’indication a causé le problème et envoyer un nouveau PATH sans l’indication.

Pour les besoins de la présente spécification, il serait préférable que les paramètres inconnus de TSpec soient ignorés en silence. Dans le cas où un paramètre est ignoré en silence, le nœud devrait se comporter comme si ce paramètre n’était pas là, mais laisser le paramètre inconnu intact dans l’objet qu’il transmet. Ceci devrait être le comportement par défaut pour les paramètres inconnus du type décrit dans la [RFC2210].

Il est possible que des modifications futures à la [RFC2210] exigent que les types de paramètre inconnus causent une réponse d’erreur. Cette situation est analogue à celle du traitement par RSVP des objets inconnus, qui permet trois réponses différentes à un objet inconnu, sur la base des deux bits de plus fort poids du Class-Num. Une façon de traiter ceci serait de rediviser l’espace de paramètres par rapport à ce qui est déjà fait dans la [RFC2216]. Par exemple, les numéros de paramètre de la forme x1xxxxxx pourraient être ignorés en silence si ils ne sont pas reconnus, tandis que les numéros de paramètre de la forme x0xxxxxx pourraient causer une réponse d’erreur si ils ne sont pas reconnus. (La signification du bit de poids fort est déjà fixée par la [RFC2216].) Une troisième possibilité existe, qui est de retirer le paramètre non reconnu avant la transmission, mais cela ne semble pas utile.

Les extensions définies dans le présent document posent essentiellement le même risque pour la sécurité que celles de la [RFC2210]. Le risque qu’un envoyeur déclare faussement que ses données sont compressibles est équivalent à celui que l’envoyeur fournisse une TSpec insuffisante et est traitée de la même façon.

La présente spécification s’appuie sur les numéros alloués par l’IANA pour l’indication de schéma de compression. Lorsque possible, le schéma de numérotation existant pour l’identification d’algorithme de compression dans PPP a été utilisé, mais il pourra être nécessaire à l’avenir que l’IANA alloue les numéros d’indications pour les seuls besoins de int-serv.

Carsten Borman et Mike DiBiasio ont apporté beaucoup de retours utiles sur le présent document.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	B. Davie, C. Iturralde & D. Oran, Cisco Systems, Inc
Request for Comments : 3006	S. Casner, Packet Design
Catégorie : En cours de normalisation	J. Wroclawski, MIT LCS
Traduction Claude Brière de L’Isle	novembre 2000

Bruce Davie	Carol Iturralde	Dave Oran	Stephen L. Casner
Cisco Systems, Inc.	Cisco Systems, Inc.	Cisco Systems, Inc.	Packet Design
250 Apollo Drive	250 Apollo Drive	170 Tasman Drive	66 Willow Place
Chelmsford, MA, 01824	Chelmsford, MA, 01824	San Jose, CA, 95134	Menlo Park, CA 94025
mél : bsd@cisco.com	mél : cei@cisco.com	mél : oran@cisco.com	mél : casner@acm.org