RFC3033 Allocation des champs Information et ID Suzuki
|
Groupe de travail Réseau |
M. Suzuki, NTT |
|
Request for Comments : 3033 |
janvier 2001 |
|
Catégorie : En cours de normalisation |
Traduction Claude Brière de L’Isle |
Allocation du champ Information et de l’identifiant de protocole dans l’identifiant générique Q.2941 et la signalisation d’usager à usager Q.2957 pour le protocole Internet
Statut de ce mémoire
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.
Notice de copyright
Copyright (C) The Internet Society (2001). Tous droits réservés.
Résumé
L’objet de ce document est de spécifier l’allocation du champ Information et de l’identifiant de protocole dans l’identifiant générique Q.2941 et la signalisation d’usager à usager Q.2957 pour le protocole Internet. L’allocation, qui est spécifiée à la section 4 du document, est conçue pour la prise en charge de la signalisation du RNIS-LB évolué par le protocole Internet, en particulier la prise en charge de la signalisaion du RNIS-LB pour la connexion qui correspond à la session dans le protocole Internet, ce qui est précisé à la section 2. Cette spécification donne un cadre indispensable pour la mise en œuvre de session de longue durée et des transferts de session sensibles à la QS sur ATM.
Table des Matières
1. Objet du document 1
2. Connexion ATM en rapport avec la session 2
2.1 Signalisation de session à longue durée de vie 2
2.2 Signalisation de session sensible à la QS 3
3. Vue d’ensemble de l’identifiant générique et de la signalisation d’usager à usager 4
3.1 Vue d’ensemble de l’identifiant générique 4
3.2 Vue d’ensemble de la signalisation d’usager à usager 5
4. Allocation du champ Information et de l’identifiant de protocole 6
4.1 Allocation de l’élément d’information Identifiant générique 6
4.2 Allocation dans l’élément d’information Usager à usager 9
5. Questions ouvertes 11
6. Considérations relatives à l’IANA 11
7. Considérations pour la sécurité 12
Appendice Champ Information et allocation d’identifiant de protocole pour ST2+ 12
A.1 Identifiant de session ST2+ 12
A.2 SCMP ST2+ 12
Références 13
Remerciements 14
Adresse de l’auteur 14
Déclaration complète de droits de reproduction 14
L’objet du présent document est de spécifier l’allocation des champs Informations et Identifiant de protocole dans l’identifiant générique Q.2941 et la signalisation d’usager à usager Q.2957 pour le protocole Internet.
L’allocation, qui est spécifiée à la Section 4 de ce document, est conçue pour la prise en charge de la signalisation du RNIS-LB avancé par le protocole Internet, en particulier la prise en charge de la signalisation du RNIS-LB pour la connexion qui correspond à la session dans le protocole Internet qui est précisée à la Section 2. Il n’est pas besoin de dire que l’objet de la présente spécification ne se limite pas à cette prise en charge, et qu’elle devrait aussi être applicable à d’autres objets.
La présente spécification donne un cadre indispensable pour la mise en œuvre de sessions de longue durée et de transferts de sessions sensibles à la QS sur ATM. Noter que ce document spécifie seulement l’allocation du champ Informations et de l’identifiant de protocole, et qu’il peut ne pas spécifier le protocole complet qui permet des mises en œuvre interopérables parce que cela sort du domaine d’application de ce document et sera spécifié dans un document distinct.
2. Connexion ATM en rapport avec la session
Avec le développement de nouvelles applications multimédia sur l’Internet actuel, la demande de prise en charge du multimédia augmente dans le réseau IP, qui prend actuellement en charge les communications au mieux. En particulier, la demande de prise en charge de communications à qualité de service garantie est en augmentation avec le développement d’applications de communications vocales, audios, et vidéos. Et il peut aussi être nécessaire d’introduire le mécanisme qui peut efficacement transférer les énormes volumes de trafic attendus avec ces applications.
Les caractéristiques majeures du RNIS-LB sont le haut débit, le multiplexage logique avec le VP/VC, et la gestion souple de la QS par VC, de sorte qu’il est assez naturel d’utiliser ces fonctions distinctives du RNIS-LB pour mettre en œuvre un mécanisme de prise en charge du multimédia dans le réseau IP. Les fonctions de gestion souple de la QS et de multiplexage logique dans le RNIS-LB sont la méthode attendue de mise en œuvre de communications à qualité de service garantie dans l’Internet. Et lorsque une session à longue durée de vie est prise en charge par un circuit virtuel particulier, une transmission de paquet efficace est rendue possible en utilisant le haut débit et le multiplexage logique du RNIS-LB
La présente section précise les fonctions de signalisation du RNIS-LB qui sont nécessaires lorsque la session est prise en charge par le circuit virtuel, pour la prise en charge de la signalisation du RNIS-LB avancé par le protocole Internet.
Un exemple de scénario pour établir un circuit virtuel pour une session à longue durée de vie est présenté à la Figure 1.
Routeur IP CTT ATM CTT ATM Routeur IP
+----+ VC par défaut +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| | | / \ | | / \ | | |
+------+ +-----+ +-----+ +------+
A. Nouvelle session initialement transmise sur un VC par défaut.
Routeur IP CTT ATM CTT ATM Routeur IP
+----+ VC par défaut +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-+--------+-\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |========| X |==||===| \__|.....|
| |<------+-/-\-+--------+-/-\-+------>| |
+------+ +-----+ +-----+ +------+
Le nouveau VC est établi
B. Un nouveau VC est établi pour la session à longue durée.
Routeur IP CTT ATM CTT ATM Routeur IP
+----+ VC par défaut +----+
| WS | +------+ UNI +-----+ +-----+ UNI +------+ | WS |
+--+-+ | |<------+-\-/-+--------+-\-/-+------>| | +-+--+
|.....|__ |===||==| X |========| X |==||===| __|.....|
| \-->|<------+-/-\-+--------+-/-\-+------>|<--/ |
+------+ +-----+ +-----+ +------+
Nouveau VC
C. Transfert de la session à longue durée sur un nouveau VC.
Figure 1 : Exemple de scénario pour établir un VC pour session de longue durée
CTT ATM = commutateur ATM
D’abord, une session est multiplexée dans le VC par défaut qui connecte les routeurs. Ensuite, si un routeur détecte que c’est une session à longue durée, il établit un nouveau VC pour la session. Si le nouveau VC est bien établi, la session à longue durée est déplacée dans le nouveau VC.
Dans cette procédure qui implique l’établissement d’un circuit virtuel ATM, l’entité de signalisation du RNIS-LB dans le routeur côté appelé doit détecter que l’appel entrant correspond à une session du protocole Internet et notifier ce fait à l’entité de couche IP. Sur la base de ces informations, l’entité de couche IP déplace la session sur le nouveau VC.
Donc, pour mettre en œuvre cette procédure de signalisation, la signalisation RNIS-LB doit inclure un identifiant de session comme élément d’information. Les éléments d’information B-LLI, B-HLI, Usager-usager, et Identifiant générique sont tous capables de transférer ces informations. Considérant l’objet original de ces éléments d’information, celui dont l’utilisation est la plus appropriée est l’élément d’information Identifiant générique.
La différence majeure entre la signalisation de session sensible à la QS et la signalisation de session à longue durée est que l’établissement d’appel n’est pas initié par la détection d’une session à longue durée, mais est explicitement initiée par le protocole d’établissement, comme RSVP. Pour mettre en œuvre la signalisation de session sensible à la QS en utilisant ATM, le réseau ATM entre les routeurs doit transmettre non seulement l’identifiant de session mais aussi le protocole d’établissement.
Il y a deux schémas pour transmettre le protocole d’établissement. L’un d’eux est de multiplexer le protocole dans un VC par défaut qui connecte les routeurs, ou de transmettre le protocole sur un VC particulier. Dans ce cas, la session sensible à la QS et le VC ATM sont établis l’un après l’autre. Le second schéma est de transmettre le protocole d’établissement comme un élément d’information dans la signalisation RNIS-LB. Dans ce cas, la session sensible à la QS et le VC ATM sont établis simultanément. Ce dernier schéma présente les avantages suivants par rapport au premier :
o il est plus facile à mettre en œuvre :
- le contrôle d’admission est simplifié parce qu’il peut être fait simultanément pour les couches IP et ATM,
- le traitement du temporisateur de surveillance est simplifié parce qu’il n’est pas besoin de surveiller successivement l’établissement de la couche IP et de la couche ATM.
o si le protocole d’établissement supporte la négociation, un VC ATM dont la QS se fonde sur le résultat de la négociation peut alors être établi.
Cependant, le second schéma ne peut pas, au moins, prendre en charge un cas où un PVC est utilisé pour soutenir une session sensible à la QS. Donc, les deux procédures devraient être prises en compte.
Un exemple de séquence de messages qui établissent simultanément une session sensible à la QS et un VC ATM est montré à la Figure 2.
Routeur IP CTT ATM CTT ATM Routeur IP
+----+ Signalisation RNIS-LB +----+
| WS | +------+ UNI +-----+Protocole+-----+ UNI +------+ | WS |
+--+-+ | /->|<------+-\-/-- établi --\-/-+------>|<-\ | +-+--+
|.....|__/ |===||==| X |=========| X |==||===| \__|.....|
| \-->|<------+-/-\-+---------+-/-\-+------>|<--/ |
+------+ +-----+VC QS dnn+-----+ +------+
N-CONNECT | |
---------->| | | | | |
|->| SETUP | | | |
| |------------>| | | |
| |<------------| | | |
| | CALL PROC |----------->| SETUP | |
| | | |------------>| |
| | | | |->| N-CONNECT
| | | | | |---------->
| | | | | |<----------
| | | | CONN |<-| N-CONNECT-ACK
| | | |<------------| |
| | | |------------>| |
| | CONN |<-----------| CONN ACK |->|
| |<------------| | | |
| |------------>| | | |
|<-| CONN ACK | | | |
<----------| | | | | |
N-CONNECT | |
-ACK
Figure 2 : Exemple de procédure pour l’établissement simultané d’une session sensible à la QS et d’un VC ATM
RSVP est actuellement proposé pour protocole d’établissement et de nouveaux protocoles d’établissement seront vraisemblablement développés à l’avenir. Donc, pour généraliser l’exposé, la procédure pour le protocole d’établissement dans cet exemple est la procédure générale d’établissement de connexion qui utilise le service confirmé.
Pour mettre en œuvre cette procédure de signalisation, la signalisation RNIS-LB doit inclure l’élément d’information Usager à usager disant que la capacité est suffisante pour transmettre le protocole d’établissement.
3. Vue d’ensemble de l’identifiant générique et de la signalisation d’usager à usager
L’identifiant générique permet le transfert de bout en bout d’identifiants entre usagers dans le réseau ATM, et est défini dans la partie 1 de Q.2941 [3] et la partie 2 de Q.2941 [4] comme un élément d’information facultatif pour le protocole de signalisation UNI de Q.2931 [1] et Q.2971 [2]. Les messages SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, et DROP PARTY ACK qui sont transférés de bout en bout entre les usagers dans le réseau ATM peuvent contenir jusqu’à trois éléments d’information Identifiant générique. Le réseau ATM transfère l’élément d’information Identifiant générique de façon transparente si il ne contient pas d’erreur de règle de codage.
Le format de l’élément d’information Identifiant générique spécifié dans Q.2941 est montré à la Figure 3.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| ID d'IE = |
| IE de transport d'identifiant générique(0x7F) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme | Champ d'instruction d'IE |
| Ext | de codage |Fanio|Rés. |indic action d'IE| 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur de contenu d’élément d’information | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Norme/application en rapport avec l'ID | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d’identifiant | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d’identifiant | 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Valeur d’identifiant | 8-
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d’identifiant |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d’identifiant |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Valeur d’identifiant |
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig. 3.1 : Format de l'élément d’information identifiant générique
L’usage des quatre premiers octets des champs est spécifié à la section 4 de Q.2931.
Le champ Norme/application en rapport avec l’identifiant identifie la norme ou l’application qui utilise l’identifiant. L’allocation du champ Norme/application en rapport avec l’identifiant pour le protocole Internet est le suivant. Un 0x en –tête signifie un hexadécimal.
0x03 : IPv4.
0x04 : ST2+.
0x05 : IPv6.
0x06 : MPLS.
Note : DSM-CC, H.310/H.321, MPOA, VC ATMC Trunking, AAL2, et H.323/H.245 sont aussi pris en charge.
Un identifiant transféré est donné par la combinaison des champs Type d’identifiant, Longueur et valeur, et un élément d’information Identifiant générique peut contenir plusieurs identifiants.
L’allocation du champ Type d’identifiant pour le protocole Internet est la suivante. Un 0x en tête signifie un hexadécimal.
0x01 : Session.
0x02 : Ressource.
0x10-0xFD : Réservé pour allocation par l’IANA.
0xFE : Expérimental/spécifique d’une organisation.
La longueur maximum de l’élément d’information Identifiant générique est de 63 octets.
Voir dans Q.2941.1 et le projet Q.2941.2 les spécifications détaillées du protocole pour l’identifiant générique.
La signalisation d’usager à usager permet le transfert des informations entre les usagers d’extrémité à extrémité dans le réseau ATM, et elle est définie dans Q.2957 [5], [6] et dans Q.2971 annexe D [2] comme un élément d’information facultatif pour le protocole de signalisation UNI Q.2931 [1] et Q.2971 [2]. Les messages SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE, PROGRESS, ADD PARTY, PARTY ALERTING, ADD PARTY ACK, ADD PARTY REJECT, DROP PARTY, et DROP PARTY ACK qui sont transférés entre les usagers d’extrémité à extrémité dans le réseau ATM peuvent contenir un élément d’information Usager à usager. Le réseau ATM transfère l’élément d’information Usager à usager de façon transparente si il ne contient pas d’erreur de règle de codage.
Du point de vue des applications de signalisation du RNIS-LB, il semble que l’Identifiant générique et la signalisation d’usager à usager sont des fonctions similaires. Mais leurs règles de traitement des exceptions ne sont pas complètement identiques, parce que leur objet est différent. L’Identifiant générique est conçu pour le transfert des identifiants entre les plans c, tandis que la signalisation d’usager à usager est conçue pour le transfert des données d’utilisateur via les plans c. Une autre différence est que le dernier prend en charge l’inter fonctionnement avec l’élément d’information Usager à usager dans la signalisation RNIS de Q.931, mais pas l’Identifiant générique. Noter que le réseau ATM peut vérifier le contenu de l’élément d’information Identifiant générique, mais il ne vérifie pas le contenu de l’élément d’information Usager à usager.
Le format de l’élément d’information Usager à usager est montré à la Figure 3.2.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant d'élément d'information = |
| élément d’information Usager à usager (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme | Champ instruction d'IE |
| Ext | de codage |Fanio|Rés. |indic. action IE | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur du contenu de l'élément d’information| 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Discriminateur de protocole | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Informations d'utilisateur | 6-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3.2 : Format de l’élément d’information Usager à usager
L’usage des quatre premiers octets des champs est spécifié à la section 4 de Q.2931.
Le champ Discriminateur de protocole identifie le protocole de couche supérieure qui utilise les informations d’usager à usager.
Le champ Informations d’usager contient les informations d’usager à usager à transférer.
La longueur maximum de l’élément d’information usager à usager est 133 octets.
Voir dans Q.2957, le projet Q.2957 amendement 1, et Q.2971 annexe D les spécifications de protocole détaillées de la signalisation d’usager à usager.
4. Allocation du champ Information et de l’identifiant de protocole
Le principe d’allocation du champ Information et de l’identifiant de protocole pour le protocole Internet dans l’élément d’information Identifiant générique est montré à la Figure 4.1.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant d'élément d'information = |
| IE transport d'identifiant générique (0x7F) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme de | Champ instruction d'IE |
| Ext | codage |Fanio|Rés. |Indic. action IE | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur du contenu de l'élément d’information| 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
|Norme/application en rapport avec l'identifiant|
| = IPv4, ST2+, IPv6, ou MPLS | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d'identifiant |
| = Session, Ressource, ou Expérimental | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d'identifiant | 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Valeur de l'identifiant | 8-
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d'identifiant |
| = Session, Ressource, ou Expérimental |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d'identifiant |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Valeur d'identifiant |
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.1 : Principe d’allocation dans l’élément d’information Identifiant générique
Le champ Norme/application relative à l’identifiant est IPv4, ST2+, IPv6, ou MPLS.
Le champ Type d’identifiant est Session, Ressource, ou Expérimental/spécifique d’organisation.
Le champ Valeur d’identifiant est alloué aux Informations relatives au protocole Internet qui sont identifiées par le champ Norme/application relative à l’identifiant et le champ Type d’identifiant. Les identifiant suivants sont spécifiés.
Identifiant Norme/application Type d’identifiant
identifiant de session IPv4 IPv4 Session
identifiant de session IPv6 IPv6 Session
VCID MPLS MPLS Ressource
Exp./spécifique d’org. IPv4/ST2+/IPv6/MPLS Expérimental
Comme décrit au paragraphe 3.1, le message de signalisation RNIS-LB transféré entre les utilisateurs d'extrémité à extrémité peut contenir jusqu'à trois éléments d’information Identifiant générique. Ces éléments peuvent contenir plusieurs identifiants. Le présent document ne spécifie pas l'ordre des identifiants lorsque plusieurs apparaissent dans un message de signalisation.
Le présent document ne spécifie pas non plus la sémantique lorsque plusieurs identifiants du même type apparaissent dans un message de signalisation, ou lorsque un message de signalisation contient un élément d’information Identifiant générique qui ne contient pas d'identifiant.
Lorsque un message de signalisation RNIS-LB contenant un élément d’information Identifiant générique entre dans un réseau ATM qui n'accepte pas l'identifiant générique, le réseau élimine l'appel, élimine l'élément d’information, ou élimine le message de signalisation. (Voir les détails aux paragraphes 4.5.1 et 5.6.8.1 de Q.2931 et au paragraphe 9.3 de Q.2941.1.)
Pour permettre un transfert fiable de l'élément d’information Identifiant générique, lorsque l'appelant envoie un message SETUP (établissement) ou ADD PARTY (ajouter un participant) avec jusqu'à trois éléments d’information Identifiant générique, le message CONNECT (connexion) ou ADD PARTY ACK (accusé de réception d'ajout de participant) retourné par l'appelé doit contenir au moins un élément d’information Identifiant générique. L'appelé peut ne pas répondre avec les mêmes identifiants que reçus de l'appelant. L'appelant devrait confirmer que le message de réponse contient au moins un élément d’information Identifiant générique. Cette règle permet la négociation d'identifiant ; le présent document ne spécifie pas les détails de procédure de cette négociation.
4.1.2 Identifiant de session IPv4
Si le champ Norme/application en rapport avec l'identifiant dans l'élément d’information Identifiant générique est IPv4, et si le champ Type d'identifiant dans l'identifiant est Session, l'identifiant est l'identifiant de session IPv4. Le format de l'identifiant de session IPv4 est montré à la Figure 4.2.
Bits Longueur
8 7 6 5 4 3 2 1 en octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d'identifiant = Session (0x01) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d'identifiant = 13 octets (0xOD) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Adresse de source IPv4 | 4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Adresse de destination IPv4 | 4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocole | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Accès de source | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Accès de destination | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.2 : Identifiant de session IPv4
Le champ Type d'identifiant est Session (0x01).
La longueur de l'identifiant est de 13 octets.
L'adresse de source IPv4, l'adresse de destination IPv4, le protocole, l'accès de source et l'accès de destination [7], [9], [10] sont alloués dans cet ordre au champ Valeur d'identifiant.
Note : Cet identifiant de session spécifique est destiné à être utilisé seulement avec la réservation explicite. Si des associations de caractère générique sont nécessaires ultérieurement, un autre type d'identifiant sera utilisé.
4.1.3 Identifiant de session IPv6
Si le champ Norme/application en rapport avec l'identifiant dans l'élément d’information Identifiant générique est IPv6, et si le champ Type d'identifiant dans l'identifiant est Session, l'identifiant est l'identifiant de session IPv6. Le format de l'identifiant de session IPv6 est montré à la Figure 4.3.
Bits Longueur
8 7 6 5 4 3 2 1 en octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d'identifiant = Session (0x01) |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d'identifiant = 37 octets (0x25) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Adresse de source IPv6 | 16
+-----+-----+-----+-----+-----+-----+-----+-----+
| Adresse de destination IPv6 | 16
+-----+-----+-----+-----+-----+-----+-----+-----+
| Protocole | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Accès de source | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Accès de destination | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.3 : Identifiant de session IPv6
Le champ Type d'identifiant est Session (0x01).
La longueur de l'identifiant est de 37 octets.
L'adresse de source IPv6, l'adresse de destination IPv6, le protocole, l'accès de source et l'accès de destination [8], [9], [10] sont alloués dans cet ordre au champ Valeur d'identifiant.
Note : Cet identifiant de session spécifique est destiné à être utilisé seulement avec la réservation explicite. Si des associations de caractère générique sont nécessaires ultérieurement, un autre type d'identifiant sera utilisé.
4.1.4 VCID MPLS
Si le champ Norme/application en rapport avec l'identifiant dans l'élément d’information Identifiant générique est MPLS, et si le champ Type d'identifiant dans l'identifiant est Ressource, l'identifiant est MPLSVCID. Le format du VCID MPLS est donné à la Figure 4.4.
Bits Longueur
8 7 6 5 4 3 2 1 en octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d'identifiant = Ressource (0x02) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d'identifiant = 4 octets (0x04) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| MPLS VCID | 4
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.4 : VCID MPLS
Le champ Type d'identifiant est Ressource (0x02).
La longueur d'identifiant est 4 octets.
Le VCID MPLS [13] est alloué au champ Valeur d'identifiant.
4.1.5 Spécifique d’expérience/organisation
Si le champ Norme/application en rapport avec l'identifiant dans l'élément d’information Identifiant générique est IPv4, ST2+, IPv6, ou MPLS, et si le champ Type d'identifiant dans l'identifiant est spécifique de l'expérience/organisation, l'identifiant est spécifique de l'expérience/organisation. Le format spécifique d'expérience/organisation est donné à la Figure 4.5.
Bits Longueur
8 7 6 5 4 3 2 1 en octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d'identifiant = |
| spécifique de l'expérience/organisation (0xFE)| 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d'identifiant | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant univoque d'organisation (OUI) | 3
+-----+-----+-----+-----+-----+-----+-----+-----+
| Informations spécifiques |
= de l'expérience/organisation =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.5 : Spécifique de l'expérience/organisation
Le champ Type d'identifiant est spécifique de l'expérience/organisation (0xFE).
Les trois premiers octets du champ Valeur d'identifiant doivent contenir l'identifiant univoque d'organisation (OUI) (comme spécifié au paragraphe 5.1 de IEEE 802-1990).
Le principe de l'allocation du champ Information et du champ Identifiant de protocole pour le protocole Internet dans l'élément d’information Utilisateur à utilisateur est donné à la Figure 4.6.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant d'élément d'information = |
| élément d’information Usager à usager(0x7E)| 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme de | Champ instruction d'IE |
| Ext | codage |Fanio|Rés. |Indic. action IE | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur de contenu d'élément d’information | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Discriminateur de protocole |
| = protocole Internet/application (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant de protocole Internet/application| 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Informations en rapport avec le | 7-
= protocole Internet/application =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.6 : Principe d’allocation dans l’élément d’information Usager à usager
Le champ Discriminateur de protocole est le protocole/application Internet (0x06). Dans ce cas,le premier octet dans le champ Informations d'utilisateur est le champ Identifiant de protocole/application Internet.
L'allocation du champ Identifiant de protocole/application Internet est la suivante (un 0x en tête signifie hexadécimal) :
0x00 : Réservé.
0x01 : Réservé pour ST2+.
0x02 : Message RSVP.
0x03-0xFD : Réservé pour allocation par l'IANA.
0xFE : Spécifique d'expérience/organisation.
0xFF : Réservé.
Le champ qui suit le champ Identifiant de protocole/application Internet est alloué aux informations en rapport avec le protocole/application Internet qui est identifié par le champ Identifiant de protocole/application Internet.
Lorsque un message de signalisation RNIS-LB contenant un élément d’information Utilisateur à utilisateur entre dans un réseau ATM qui n'accepte pas la signalisation d'utilisateur à utilisateur, le réseau élimine l'appel, l'élément d’information, ou élimine le message de signalisation. (Voir les détails aux paragraphes 4.5.1 et 5.6.8.1 de Q.2931, au paragraphe 1.9 de Q.2957, et à l'annexe D de Q.2971.)
Pour permettre un transfert fiable de l'élément d’information Utilisateur à utilisateur, lorsque l'appelant envoie un message SETUP ou ADD PARTY avec un élément d’information Utilisateur à utilisateur, le message CONNECT ou ADD PARTY ACK retourné par l'appelé doit contenir un élément d’information Utilisateur à utilisateur. L'appelé peut ne pas répondre avec les mêmes informations d'utilisateur que reçues de l'appelant. L'appelant devrait confirmer que le message de réponse contient un élément d’information Utilisateur à utilisateur. Cette règle permet la négociation ; le présent document ne spécifie pas le détail des procédures de cette négociation.
4.2.2 Message RSVP
Le format du message RSVP est donné à la Figure 4.7.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| ID d'IE = IE Usager à usager (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme de | Champ instruction d'IE |
| Ext | codage |Fanio|Rés. |Indic. action IE | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur de contenu d'élément d’information | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Discriminateur de protocole = |
| protocole/application Internet (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant protocole/application Internet |
| = message RSVP (0x02) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Message RSVP | 7-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.7 : Message RSVP
Le champ Identifiant de protocole/application Internet est le message RSVP (0x02).
Le message RSVP [12] est alloué au champ Informations en rapport avec le protocole/application Internet. Le message SETUP peut contenir le message Resv RSVP. Le message CONNECT peut contenir le message ResvConf RSVP. Le message RELEASE peut contenir le message RSVP ResvErr ou ResvTear.
4.2.3 Spécifique de l’expérience/organisation
Le format du champ Spécifique de l’expérience/organisation est montré à la Figure 4.8.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant d’élément d’information = |
| élément d’information Usager à usager(0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme de | Champ instruction d’IE |
| Ext | codage |Fan. |Rés. |Indic. action IE | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur du contenu de l’élément d’information| 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Discriminateur de protocole = |
| protocole/application Internet (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
|Identifiant de protocole/application Internet =|
|Spécifique d’ l’expérience/organisation (0xFE) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant unique d’organisation (OUI) | 7-9
+-----+-----+-----+-----+-----+-----+-----+-----+
| Info. spécifiques d’expérience/organisation | 10-
= =
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4.8 : Spécifique d’expérience/organisation
Le champ Identifiant de protocole/application Internet est spécifique de l’expérience/organisation (0xFE).
Les trois premiers octets dans le champ Informations relatives au protocole/application Internet doivent contenir l’identifiant unique d’organisation (OUI) (comme spécifié dans la norme IEEE 802-1990, section 5.1).
Les questions suivantes restent ouvertes dans le présent document.
o Prise en charge de d’identifiant générique pour l’agrégation de session.
La prise en charge de l’agrégation de session peut être nécessaire dans un environnement de cœur de réseau. Un identifiant de session agrégé de style caractère générique peut être faisable. Cependant, avant de spécifier pour lui une prise en charge de l’identifiant générique, le modèle d’agrégation de session dans les VC ATM devrait être précisé.
o Prise en charge de d’identifiant générique pour l’étiquette de flux IPv6 et les classes de trafic.
La prise en charge de l’étiquette de flux IPv6 et des classes de trafic peut être nécessaire à l’avenir. Cependant, leur sémantique n’est actuellement pas claire.
6. Considérations relatives à l’IANA
Lorsque le champ Identifiant en rapport avec la norme/application dans l’élément d’information Identifiant générique Q.2941.2 est IPv4, ST2+, IPv6, ou MPLS, les numéros entre 0x10 et 0xFD sont réservés dans le champ Type d’identifiant pour allocation par l’IANA (voir au paragraphe 3.1). Suivant les politiques mentionnées en [14], ces numéros sont alloués par action de consensus de l’IETF.
Lorsque le champ Discriminateur de protocole dans l’élément d’information Usager à usager de Q.2957 est protocole/application Internet, les numéros entre 0x03 et 0xFD dans le champ Identifiant de protocole/application Internet sont réservés pour allocation par l’IANA (voir au paragraphe 4.2.1). Suivant les politiques mentionnées dans [14], ces numéros sont alloués par action de consensus de l’IETF.
7. Considérations pour la sécurité
Le présent document spécifie le champ Information et l’allocation de l’identifiant de protocole dans l’Identifiant générique de la Recommandation UIT-T Q.2941 et la signalisation d’usager à usager de la Recommandation UIT-T Q.2957 pour le protocole Internet, de sorte que ceux-ci n’affaiblissent pas la sécurité de la signalisation du RNIS-LB.
Dans la partie "appelé" de la signalisation RNIS-LB, si le message SETUP entrant contient le numéro de l’appelant et si il est vérifié et passé par le réseau ATM ou si il est fourni par le réseau, il est alors possible d’utiliser le numéro de l’appelant pour une partie de l’authentification de l’appelant pour renforcer la sécurité.
Appendice Champ Information et allocation d’identifiant de protocole pour ST2+
Le présent appendice spécifie le champ Information et l’allocation d’identifiant de protocole dans l’identifiant générique et la signalisation d’usager à usager pour ST2+. Noter que cet appendice NE FAIT PAS partie de la norme.
Si le champ Identifiant en rapport avec la norme/application dans l’élément d’information Identifiant générique est ST2+, et si le champ Type d’identifiant dans l’identifiant est Session, l’identifiant est l’identifiant de session ST2+. Le format de l’identifiant de session ST2+ est montré à la Figure A.1.
Bits Longueur
8 7 6 5 4 3 2 1 en octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Type d’identifiant = Session (0x01) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur d’identifiant = 6 octets (0x06) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant de flux (SID) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure A.1 : identifiant de session ST2+
Le champ Type d’identifiant est Session (0x01).
La longueur d’identifiant est 6 octets.
L’identifiant de flux (SID, Stream ID) [11] est alloué au champ Valeur d’identifiant.
Le format de l’élément d’information Usager à usager pour le protocole de message de contrôle de flux (SCMP, Stream Control Message Protocol) ST2+ est montré à la Figure A.2.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant d’élément d’information = |
| élément d’information Usager à usager (0x7E) | 1
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | Norme de | Champ Instruction d’IE |
| Ext. | codage |Fan.|Res. |Indic. action IE | 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Longueur du contenu d’élément d’information | 3-4
+-----+-----+-----+-----+-----+-----+-----+-----+
| Discriminateur de protocole = |
| protocole/application Internet (0x06) | 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| Identifiant de protocole/application Internet |
| = SCMP ST2+ (0x01) | 6
+-----+-----+-----+-----+-----+-----+-----+-----+
| SCMP ST2+ | 7-
= =
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure A.2 : SCMP ST2+
Le champ Identifiant de protocole/application Internet est SCMP ST2+ (0x01).
Le SCMP ST2+ [11] est alloué au champ Informations en rapport avec le protocole/application Internet. Les messages SETUP et ADD PARTY peuvent contenir le message CONNECT SCMP ST2+. Les messages CONNECT et ADD PARTY ACK peuvent contenir le message ACCEPT SCMP ST2+. Les messages RELEASE et DROP PARTY peuvent contenir le message DISCONNECT SCMP ST2+. Les messages RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, et DROP PARTY peuvent contenir le message REFUSE SCMP ST2+.
[1] Recommandation UIT-T Q.2931, "Broadband Integrated Services Digital Network (B-ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control", septembre 1995.
[2] Recommandation UIT-T Q.2941.1, "Broadband Integrated Services Digital Network (B-ISDN)-Digital Subscriber Signaling System No. 2 (DSS 2)-User-Network Interface Layer 3 Specification for Point-to-Multipoint Call/Connection Control", octobre 1995.
[3] Recommandation UIT-T Q.2941.1,"Broadband Integrated Services Digital Network (B-ISDN) Digital Subscriber Signaling System No. 2 (DSS 2): Generic Identifier Transport", sptembre1997.
[4] Recommandation UIT-T Q.2941.2, "Broadband Integrated Services Digital Network (B-ISDN) Digital Subscriber Signaling System No. 2 (DSS 2): Generic Identifier Transport Extensions", décembre 1999.
[5] Recommandation UIT-T Q.2957, "Stage 3 Description for Additional Information Transfer Supplementary Service Using B-ISDN Digital Subscriber Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signalling (UUS)", février 1995.
[6] Recommandation UIT-T Q.2957, Amendement 1, "Stage 3 Description for Additional Information Transfer Supplementary Service Using B-ISDN Digital Subscriber Signaling System No. 2 (DSS 2)-Basic Call Clause 1-User-to-User Signalling (UUS)", décembre 1999.
[7] [RFC0791] J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.
[8] [RFC2460] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6) ", décembre 1998. (MàJ par 5095,6564 ; D.S)
[9] [RFC0768] J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.
[10] [RFC0793] J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7, septembre 1981.
[11] [RFC1819] L. Delgrossi et L. Berger, éditeurs "Spécification du protocole de flux Internet version 2 (ST2) - Version ST2+", août 995. (Expérimentale)
[12] [RFC2205] R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)
[13] [RFC3038] K. Nagami et autres, "Notification de VCID sur liaison ATM pour LDP", janvier 2001. (P.S.)
[14] [RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)
[15] P. Newman, T. Lyon, and G. Minshall, "Flow Labelled IP: A Connectionless Approach to ATM," Proc. IEEE Infocom, mars 1996.
[16] S. Damaskos and A. Gavras, "Connection Oriented Protocols over ATM: A case study," Proc. SPIE, Vol. 2188, pp.226-278, février 1994.
[17] Recommandation UIT-T I.320, "Integrated Services Digital Network (ISDN) Overall Network Aspects and Functions ISDN Protocol Reference Model", novembre 1993.
[18] Recommandation UIT-T Q.923, "Digital Subscriber Signaling System No. 1 (DSS 1) Specification of a Synchronization and Coordination Function for the Provision of the OSI Connection-mode Network Service in an ISDN Environment", février 1995.
Je tiens à remercier Kenichi Kitami de NTT Information Sharing Lab. Group, qui est aussi le président du SG11 WP1 de l’UIT-T, Shinichi Kuribayashi de NTT Information Sharing Platform Labs., Hiroshi Yao et Takumi Ohba du NTT Network Service Systems Labs., et Noriyuki Takahashi du NTT Information Sharing Platform Labs., de leurs précieux commentaires et discussions.
Et je voudrais aussi remercier les membres actifs de l’IETF, de l’UIT-T, et de l’ATM Forum, spécialement Joel Halpern de Newbridge Networks, Andrew Malis de Ascend Communications, George Swallow et Bruce Davie de Cisco Systems, Rao Cherukuri de IBM, Rajiv Kapoor de AT&T, Greg Ratta de Lucent, Kaoru Kenyoshi de NEC, Hiroto Uno de Hitachi, Hiroshi Esaki et Kenichi Nagami de Toshiba, et Noritoshi Demizu de NAIST de leurs précieux commentaires et suggestions.
La présente spécification est aussi fondées sur diverses discussions durant le projet ST2+ sur ATM au NTT Multimedia Joint Project avec NACSIS. Je tiens à remercier le professeur Shoichiro Asano du National Center for Science Information Systems de ses irremplaçables conseils dans ce domaine.
Muneyoshi Suzuki
NTT Information Sharing Platform Laboratories
3-9-11, Midori-cho
Musashino-shi, Tokyo 180-8585
Japon
téléphone : +81-422-59-2119
Fax : +81-422-37-7691
mél : suzuki.muneyoshi@lab.ntt.co.jp
Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2001). Tous droits réservés.
Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.
Remerciement
Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.
page-