Équipe d'ingénierie de l'Internet (IETF)	K. Jiao, Huawei
Request for Comments : 6737	G. Zorn, Network Zen
Catégorie : Sur la voie de la normalisation	octobre 2012
ISSN: 2070-1721	Traduction Claude Brière de L'Isle

Application de mise à jour de capacité Diameter 

Résumé
Le présent document définit une nouvelle application Diameter et les codes de commande associés. L'application de mise à jour de capacités est destinée à permettre la mise à jour dynamique de certaines capacités d'homologue Diameter lorsque la connexion d'homologue à homologue est dans l'état ouvert.

Statut de ce mémoire
Ceci est un document sur la voie de la normalisation de l'Internet.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc6737 

Notice de droits de reproduction
Copyright (c) 2012 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.
Table des matières
1. Introduction	1
2. Spécification des exigences	2
3. Considérations sur le protocole Diameter	2
4. Mise à jour de capacités	2
4.1 Valeurs de code de commande	3
5. Considérations sur la sécurité	3
6. Considérations relatives à l'IANA	4
6.1 Identifiant d'application	4
6.2 Codes de commande	4
7. Contributeurs	4
8. Remerciements	4
9. Références	4
9.1 Références normatives	4
9.2 Références pour information	4
Adresse des auteurs	4

 	1.	Introduction

L'échange de capacités est un important composant du protocole de base Diameter [RFC6733] qui permet aux homologues d'échanger les identités et les capacités Diameter (numéro de version du protocole, applications Diameter supportées, mécanismes de sécurité, etc.). Comme défini dans la RFC 3588, le processus d'échange de capacités n'a cependant lieu qu'une seule fois, à la création d'une connexion de transport entre une certaine paire d'homologues. Donc, si les capacités d'un homologue changent (par exemple à cause d'une mise à jour de logiciel) la ou les connexions existantes doivent être supprimées (ainsi que toutes les sessions d'utilisateur associées) et redémarrées avant que les capacités modifiées puissent être annoncées.

Le présent document définit une nouvelle application Diameter destinée à permettre la mise à jour dynamique d'un sous ensemble de capacités de l'homologue Diameter sur une connexion existante. Parce que l'application Mise à jour de capacité spécifiée ici opère sur une connexion de transport existante, la modification de certaines capacités est interdite. Précisément, modifier le mécanisme de sécurité utilisé n'est pas permis ; si la méthode de sécurité utilisée entre une paire d'homologues est changée, la connexion affectée DOIT être redémarrée.

 	2.	Spécification des exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Considérations sur le protocole Diameter

Cette Section détaille les relations de l'application Mise à jour de capacités Diameter avec le protocole de base Diameter.

Le présent document spécifie l'identifiant d'application 10. Les nœuds Diameter qui se conforment à la présente spécification DOIVENT annoncer sa prise en charge en incluant la valeur 10 dans le champ Auth-Application-Id des commandes Demande d'échange de capacités (CER, Capabilities-Exchange-Request) et Réponse d'échange de capacités (CEA, Capabilities-Exchange-Answer) [RFC6733].

 	4.	Mise à jour de capacités

Quand les capacités d'un nœud Diameter conforme à la présente spécification changent, le nœud DOIT notifier tous les nœuds avec lesquels il a une connexion de transport ouverte et qui ont aussi annoncé la prise en charge de l'application Mise à jour de capacités en utilisant le message Demande de mise à jour de capacités (CUR, Capabilities-Update-Request) (paragraphe 4.1.1). Ce message permet la mise à jour des capacités d'un homologue (applications Diameter supportées, etc.).

Un nœud Diameter ne produit une certaine commande qu'aux homologues qui ont annoncé la prise en charge de l'application Diameter qui définit la commande ; un nœud Diameter doit mettre en antémémoire les applications supportées afin de s'assurer que des commandes et/ou paires d'attribut-valeur (AVP) non reconnues ne sont pas envoyées sans nécessité à un homologue.

Le receveur de la commande CUR DOIT déterminer les applications communes en calculant l'intersection de son propre ensemble d'identifiants d'applications supportées avec les AVP d'identifiants d'application (Auth-Application-Id, Acct-Application-Id, et Vendor-Specific-Application-Id) présents dans le CUR. La valeur de l'AVP Vendor-Id dans le Vendor-Specific-Application-Id NE DOIT PAS être utilisée durant ce calcul.

Si le receveur d'un CUR n'a pas d'application en commun avec l'envoyeur, il DOIT alors retourner une réponse de mise à jour de capacités (CUA, Capabilities-Update-Answer) (paragraphe 4.1.2) avec l'AVP Code de résultat réglée à DIAMETER_NO_COMMON_APPLICATION (pas d'application Diameter commune) [RFC6733], et il DEVRAIT déconnecter la connexion de couche transport. Cependant, si des sessions actives utilisent la connexion, les homologues PEUVENT retarder la déconnexion jusqu'à ce que les sessions puissent être redirigées ou terminées en douceur. Noter que recevoir un CUA d'un homologue qui s'annonce lui-même comme relais (voir le paragraphe 2.4 de la [RFC6733]) DOIT être interprété comme ayant des applications communes avec l'homologue.

Comme pour les messages CER/CEA, les messages CUR et CUA NE DOIVENT PAS  être passés par un mandataire, redirigés, ou relayés.

Même si les messages CUR/CUA ne peuvent pas être confiés à un mandataire, il est quand même possible à un agent amont de recevoir un message pour lequel aucun homologue n'est disponible pour traiter l'application qui correspond au code de commande. Cela pourrait arriver si, par exemple, les homologues sont trop occupés ou hors service. Dans ce cas, le bit 'E' DOIT être établi dans le message de réponse avec l'AVP Code de résultat réglé à DIAMETER_UNABLE_TO_DELIVER (Diameter incapable de livrer) pour informer l'homologue aval de prendre des mesures (par exemple, de réacheminer les demandes sur un homologue de remplacement).

 	4.1	Valeurs de code de commande
Ce paragraphe définit les valeurs de code de commande [RFC6733] qui DOIVENT être prises en charge par toutes les mises en œuvre de Diameter qui se conforment à la présente spécification. Les codes de commande suivants sont définis dans ce document : Capabilities-Update-Request (CUR, paragraphe 4.1.1) et Capabilities-Update-Answer (CUA, paragraphe 4.1.2). Le format de code de commande Diameter (CCF, Command Code Format) ([RFC6733], paragraphe 3.2) est utilisé dans les définitions.

 	4.1.1	Capabilities-Update-Request
La demande de mise à jour de capacités (CUR, Capabilities-Update-Request) indiquée par le code de commande réglé à 328 et le bit fanions de commandes 'R' établi, est envoyé pour mettre à jour les capacités locales. À la détection d'une défaillance de transport, ce message NE DOIT PAS être envoyé à un homologue de remplacement.

Quand Diameter fonctionne sur le protocole de transmission de commandes de flux (SCTP, Stream Control Transmission Protocol) [RFC4960], qui permet aux connexions de s'étendre sur plusieurs interfaces et plusieurs adresses IP, le message Capabilities-Update-Request DOIT contenir une AVP Adresse IP d'hôte pour chaque adresse IP potentielle qui peut être utilisée localement lors de la transmission des messages Diameter.

Format de message 

<CUR> ::= < en-tête Diameter : 328, REQ >
                { Hôte d'origine }
                { Domaine d'origine }
             1* { Adresse IP d'hôte }
                { Identifiant de fabricant }
                { Nom de produit }
                 [ Identifiant d'état d'origine ]
              * [ Identifiant de fabricant pris en charge ]
              * [ Identifiant d'authentification d'application ]
              * [ Identifiant de compte d'application ]
              * [ Identifiant d'application spécifique du fabricant ]
                 [ Révision du matériel]
              * [ AVP ]

 	4.1.2	Capabilities-Update-Answer
La réponse de mise à jour de capacités (CUA, Capabilities-Update-Answer) indiquée par le code de commande réglé à 328 et le bit Fanions de commandes 'R' réglé à zéro est envoyée en réponse à un message CUR.

Format de message 

<CUA> ::= < En-tête Diameter : 328 >
                     { Hôte d'origine }
                     { Domaine d'origine }
                     { Code de résultat }
                      [ Message d'erreur ]
                    * [ AVP ]

 	5.	Considérations sur la sécurité

Les considérations de sécurité applicables au protocole de base Diameter [RFC6733] sont aussi applicables au présent document.

 	6.	Considérations relatives à l'IANA

Cette Section explique les critères à utiliser par l'IANA pour allouer les numéros dans les espaces de noms utilisés dans ce document.

 	6.1	Identifiant d'application
La présente spécification alloue la valeur 10 (mise à jour de capacités Diameter) dans l'espace de noms Identifiants d'application [RFC6733]. Voir à la Section 3 l'allocation de l'espace de noms dans cette spécification.

 	6.2	Codes de commande
La présente spécification alloue la valeur 328 (Demande de mise à jour de capacités/Réponse de mise à jour de capacité  (CUR/CUA)) dans l'espace de noms Codes de commandes [RFC6733]. Voir au paragraphe 4.1 l'allocation de l'espace de noms dans cette spécification.

 	7.	Contributeurs

Le présent document se fonde sur les travaux de Tina Tsou.

 	8.	Remerciements

Merci à Sebastien Decugis, Niklas Neumann, Subash Comerica, Lionel Morand, Dan Romascanu, Dan Harkins, et Ravi pour leurs utiles relectures et commentaires.

 	9.	Références
 	9.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC6733]	V. Fajardo, J. Arkko, J. Loughney, G. Zorn, "Protocole de base Diameter", octobre 2012. (Remplace les RFC3588, RFC5719) (P.S.)

 	9.2	Références pour information

[RFC4960]	R. Stewart, éd., "Protocole de transmission de commandes de flux (SCTP)", septembre 2007. (Remplace RFC2960, RFC3309 ; P.S. ; voir errata dans RFC8540 ; MàJ par RFC8899)

 	Adresse des auteurs
Jiao Kang	Glen Zorn	
Huawei Technologies	Network Zen	
Section F1, Huawei Industrial Base	227/358 Thanon Sanphawut	
Bantian, Longgang District	Bang Na, Bangkok  10260	
Shenzhen  518129	Thailand	
P.R. China	téléphone : +66 (0) 909-201060	
mél : kangjiao@huawei.com 	mél : glenzorn@gmail.com