Groupe de travail Réseau	M. Tuexen, Muenster Univ. of Applied Sciences
Request for Comments : 4820	R. Stewart, Cisco Systems, Inc.
Catégorie : Sur la voie de la normalisation	P. Lei, Cisco Systems, Inc.
Traduction Claude Brière de L'Isle	mars 2007

Tronçon de bourrage et paramètres pour le protocole de transmission de contrôle de flux (SCTP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir 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 IETF Trust (2007).

Résumé
Le présent document définit un tronçon de bourrage et un paramètre de bourrage et décrit les procédures requises du côté receveur. Le tronçon de bourrage est utilisé pour bourrer un paquet du protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol) à une taille arbitraire. Le paramètre de bourrage est utilisé pour bourrer un tronçon INIT SCTP à une taille arbitraire.
Table des matières
1. Introduction	1
2. Conventions	1
3. Tronçon de bourrage (PAD)	2
4. Paramètre de bourrage (PAD)	2
5. Considerations relatives à l'IANA	3
5.1 Nouveau type de tronçon	3
5.2 Nouveau type de paramètre	3
6. Considérations sur la sécurité	3
7. Remerciements	3
8. Références	3
8.1 Références normatives	3
8.2 Références pour information	3
Adresse des auteurs	4
Déclaration complète de droits de reproduction	4

 	1.	Introduction

Le présent document définit un tronçon de bourrage et un paramètre de bourrage et décrit les procédures requises du côté receveur. Le tronçon de bourrage est utilisé pour bourrer un paquet SCTP à une taille arbitraire. Le paramètre de bourrage est utilisé pour bourrer un tronçon INIT SCTP à une taille arbitraire. L'usage du tronçon PAD pour la découverte de la MTU de chemin est décrit dans la PMTU [RFC4821]. L'usage inapproprié du paramètre PAD ou du tronçon PAD peut résulter en un gaspillage de bande passante.

 	2.	Conventions

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.	Tronçon de bourrage (PAD)

Ce tronçon est utilisé pour bourrer un paquet SCTP. Un tronçon PAD peut être utilisé pour élargir le paquet de 4 à 65536  octets par pas de 4 octets. Un paquet SCTP PEUT contenir plusieurs tronçons PAD.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x84   |   Fanions=0   |             Longueur          |
+---------------+---------------+---------------+---------------+
|                                                               |
\                         Données de bourrage                   /
/                                                               \
+---------------+---------------+---------------+---------------+

Figure 1

Type : 1 octet (entier non signé). Cette valeur DOIT être réglée à 0x84 pour tous les tronçons PAD.

Fanions : 1 octet (entier non signé). Cette valeur DEVRAIT être réglée à zéro à l'émission et DOIT être ignorée à réception.

Longueur : 2 octets (entier non signé). Cette valeur contient la longueur des données de bourrage plus 4.

Données de bourrage : n octets (entier non signé). Cela contient les données de bourrage. Les données de bourrage DOIVENT être ignorées par le receveur.

Le receveur du tronçon PAD DOIT éliminer ce tronçon et continuer le traitement du reste des tronçons du paquet. Noter que c'est aussi le comportement de traitement requis pour tout tronçon inconnu qui a les mêmes deux bits de poids fort de type que le tronçon PAD.

 	4.	Paramètre de bourrage (PAD)

Ce paramètre est utilisé pour bourrer un tronçon INIT. Un paramètre PAD peut être utilisé pour élargir le tronçon INIT de 4  octets au minimum jusqu'à la taille maximum du tronçon INIT par pas de 4 octets. Un tronçon INIT PEUT contenir plusieurs paramètres PAD.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type de paramètre = 0x8005   |     Longueur de paramètre     |
+---------------+---------------+---------------+---------------+
/                                                               /
\                      Données de bourrage                      \
/                                                               /
+---------------+---------------+---------------+---------------+

Figure 2

Type de paramètre : 2 octets (entier non signé). Cette valeur DOIT être réglée à 0x8005.

Longueur de paramètre : 2 octets (entier non signé). Cette valeur contient la longueur des données de bourrage plus 4.

Le paramètre PAD NE PEUT être inclus QUE dans le tronçon INIT. Il NE DOIT PAS être inclus dans un autre tronçon. Le receveur du paramètre PAD DOIT éliminer en silentce ce paramètre et continuer le traitement du reste du tronçon INIT. Cela signifie que la taille du paramètre COOKIE généré dans le INIT-ACK NE DOIT PAS dépendre de l'existence du paramètre PAD dans le tronçon INIT. Un receveur d'un paramètre PAD NE DOIT PAS inclure le paramètre PAD dans un paramètre Cookie d'état qu'il génère.

 	5.	Considerations relatives à l'IANA

Le présent document est la référence pour tous les enregistrements décrits dans cette section. La liste de tous les enregistrements figure dans le document disponible dans les paramètres sctp de [IANA]. Les changements sont décrits ci-dessous.

 	5.1	Nouveau type de tronçon
Un type de tronçon pour le tronçon PAD a été alloué par l'IANA. La valeur allouée est décrite à la Figure 1. Ce qui suit a été ajouté au tableau "CHUNK TYPES" de sctp-parameters [IANA] :

Types de tronçons

Valeur de l'identifiant	Type de tronçon	Référence
132(0x84)	Tronçon de bourrage (PAD)	[RFC4820]

 	5.2	Nouveau type de paramètre
Un type de paramètre a été alloué par l'IANA au paramètre PAD. La valeur a été allouée comme décrit à la Figure 2. Ce qui suit a été ajouté au tableau "CHUNK PARAMETER TYPES" dans sctp-parameters [IANA] :

Types de paramètre de tronçon INIT

Type de paramètre de tronçon	Valeur
Bourrage 	32773(0x8005)

 	6.	Considérations sur la sécurité

Le présent document n'ajoute aucune considération de sécurité supplémentaire à celles de la [RFC2960].

 	7.	Remerciements

Les auteurs souhaitent remercier Matthew J. Zekauskas et Lars Eggert de leur précieux commentaires.

 	8.	Références
 	8.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)

[RFC2960]	R. Stewart et autres, "Protocole de transmission de commandes de flux", octobre 2000. (Obsolète, voir RFC4960) (P.S.)

 	8.2	Références pour information

[IANA]	"IANA registry", <http://www.iana.org/assignments/sctp-parameters>.

[RFC4821]	M. Mathis, J. Heffner, "Découverte de la MTU de chemin de couche de mise en paquet", mars 2007. (P.S.)

 	Adresse des auteurs

Michael Tuexen	Randall R. Stewart	Peter Lei	
Muenster Univ. of Applied Sciences	Cisco Systems, Inc.	Cisco Systems, Inc.	
Stegerwaldstr. 39	4875 Forest Drive	955 Happfield Dr.	
48565 Steinfurt	Suite 200	Arlington Heights, IL  60004	
Germany	Columbia, SC 29206 USA	US	
mél : tuexen@fh-muenster.de 	mél : rrs@cisco.com 	mél : peterlei@cisco.com 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

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

Le présent document et les informations contenues sont fournies 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, le IETF TRUST 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
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.

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