Groupe de travail Réseau	A. Vainshtein, éd., Axerra Networks	
Request for Comments : 4553	YJ. Stein, éd., RAD Data Communications	
Catégorie : Sur la voie de la normalisation	juin 2006	
Traduction Claude Brière de L'Isle		

Multiplexage de paquet à répartition dans le temps ignorant la structure (SAToP)

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 Internet Society (2006).

Résumé
Le présent document décrit une encapsulation de pseudo filaire pour les flux binaires en multiplexage par répartition dans le temps (TDM, Time Division Multiplexing) (T1, E1, T3, E3) qui ne tient pas compte de toute structure qui pourrait être imposée à ces flux, en particulier la structure imposée par le tramage TDM standard.
Table des matières
1. Introduction	2
2. Terminologie et modèles de référence	2
2.1 Terminologie	2
2.2 Modèles de référence	3
3. Services émulés	3
4. Couche d'encapsulation SAToP	3
4.1. Format de paquet SAToP	3
4.2 En-têtes de couche de démultiplexage de PSN et PW	3
4.3 En-tête SAToP	4
5. Couche de charge utile SAToP	6
5.1 Charges utiles générales	6
5.2. T1 aligné sur l'octet	7
6. Fonctionnement de SAToP	7
6.1 Considérations communes	7
6.2 Fonctionnement d'IWF	8
6.2.1 Direction liée au PSN	8
6.3 Défauts de SAToP	9
6.4 Surveillance des performances de PW  SAToP	9
7. Questions de qualité de service (QS)	9
8. Contrôle d'encombrement	10
9. Considérations sur la sécurité	11
10. Déclaration d'applicabilité	11
11. Considérations relatives à l'IANA	12
12. Remerciements	12
13. Coauteurs	12
14. Références normatives	12
15. Références pour information	13
Appendice A. Ancien mode d'encapsulation SAToP sur L2TPv3	14
Appendice B. Paramètres qui DOIVENT être acceptés durant l'établissement de PW	14
Adresse des éditeurs 	15
Déclaration complète de droits de reproduction	15

 	1.	Introduction

Le présent document décrit une méthode pour encapsuler les flux binaires (T1, E1, T3, E3) en multiplexage par répartition dans le temps (TDM, Time Division Multiplexing) comme des pseudo-filaires sur les réseaux de commutation de paquets (PSN, Packet-Switching Network). Il vise seulement le transport ignorant de la structure, c'est-à-dire que le protocole ignore complètement toute structure qui pourrait éventuellement être imposée à ces signaux, en particulier la structure imposée par le tramage TDM standard [G.704]. Cette émulation est appelée "émulation de circuits TDM non structurés" dans la [RFC4197] et convient aux applications où les PE n'ont pas besoin d'interpréter les données TDM ou de participer à la signalisation TDM.

La solution SAToP présentée dans ce document se conforme à l'architecture de PWE3 décrite dans la [RFC3985] et satisfait à la fois aux exigences générales pertinentes mentionnées dans la [RFC3916] et aux exigences spécifiques pour les signaux TDM non structurés présentées dans la [RFC4197].

Comme avec tous les PW, les PW SAToP peuvent être configurés manuellement ou établis en utilisant le protocole de contrôle de PWE3 [RFC4447]. Les extensions au protocole de contrôle de PWE3 exigées pour l'établissement et la maintenance des pseudo-filaires SAToP et les allocations de codets utilisées à cette fin sont décrites dans des documents séparés ([RFC5287] et [RFC4446], respectivement).

 	2.	Terminologie et modèles de référence

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].

 	2.1	Terminologie
Les acronymes suivants utilisés dans le présent document sont définis dans les [RFC3985] et [RFC4197] :
ATM (Asynchronous Transfer Mode) mode de transfert asynchrone
CE (Customer Edge) côté consommateur
CES (Circuit Emulation Service) service d'émulation de circuits
NSP (Native Service Processing) traitement de service natif
PE (Provider Edge) côté fournisseur
PDH (Plesiochronous Digital Hierarchy) hiérarchie numérique plésiochrone
PW (Pseudowire) pseudo-filaire
SDH (Synchronous Digital Hierarchy) hiérarchie numérique synchrone
SONET (Synchronous Optical Network) réseau optique synchrone
TDM (Time Division Multiplexing) multiplexage par répartition dans le temps

De plus, les termes spécifiques de TDM suivants sont nécessaires :

o	Perte de signal (LOS, Loss of Signal) : condition du circuit de rattachement TDM dans laquelle le signal entrant ne peut pas être détecté. Les critères pour entrer et quitter la condition de LOS se trouvent dans [G.775].

o	Signal d'indication d'alarme (AIS, Alarm Indication Signal) : schéma binaire spécial (par exemple, décrit dans [G.775]) dans le flux binaire TDM qui indique la présence d'une panne du circuit amont. Pour les circuits E1, T1, et E3, le schéma d'AIS est une séquence de valeurs de "1" binaires de durée appropriée (le schéma "tout de uns") et donc il peut être détecté et généré par des moyens qui ignorent la structure. Le schéma AIS de T3 exige le tramage T3 (voir au paragraphe 2.5.3.6.1 de [G.704]) et ne peut donc être traité que par un NSP tenant compte de la structure.

On utilise aussi le terme de fonction d'inter fonctionnement (IWF, InterWorking Function) pour décrire le bloc fonctionnel qui segmente et encapsule TDM dans des paquets SAToP et qui dans la direction inverse désencapsule les paquets SAToP et reconstitue TDM.

 	2.2	Modèles de référence
Les modèles génériques définis aux paragraphes 4.1, 4.2, et 4.4 de la [RFC3985] s'appliquent pleinement à SAToP.

Le service natif visé dans le présent document est un cas particulier du type de charge utile de flux binaire défini au paragraphe 3.3.3 de la [RFC3985].

Le modèle de référence de synchronisation de réseau et les scénarios de déploiement pour l'émulation des services TDM sont décrits au paragraphe 4.3 de la [RFC4197].

 	3.	Services émulés

La présente spécification décrit l'émulation bord à bord des services TDM suivants décrits dans [G.702] :
1. E1 (2048 kbit/s)
2. T1 (1544 kbit/s) ; ce service est aussi appelé DS1
3. E3 (34  368 kbit/s)
4. T3 (44  736 kbit/s) ; ce service est aussi appelé DS3

Le protocole utilisé pour l'émulation de ces services ne dépend pas de la méthode par laquelle les circuits de rattachement sont livrés aux PE. Par exemple, un circuit de rattachement T1 est traité de la même façon sans considération de si il est livré au PE sur du cuivre [G.703], multiplexé dans un circuit T3 [T1.107], transposé en tributaire virtuel d'un circuit SONET/SDH [G.707], ou porté sur un réseau ATM en utilisant un service d'émulation de circuit (CES, Circuit Emulation Service) ATM non structuré [ATM-CES]. La terminaison de toutes "couches de transport" spécifiques utilisées entre PE et CE est effectuée par un NSP approprié.

 	4.	Couche d'encapsulation SAToP
 	4.1.	Format de paquet SAToP
Le format de base des paquets SAToP est montré à la Figure 1.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ...                               |
|      En-têtes de couche de démultiplexage de PSN et de PW     |
|                             ...                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                             ...                               |
+--                                                           --+
|              En-tête d'encapsulation SAToP                    |
+--                                                           --+
|                             ...                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                             ...                               |
|                      Données de TDM (charge utile)            |
|                             ...                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 : Format de base de paquet SAToP

 	4.2	En-têtes de couche de démultiplexage de PSN et PW
UDP et L2TPv3 [RFC3931] peuvent tous deux fournir les mécanismes de démultiplexage de PW pour les PW SAToP sur un PSN IPv4/IPv6. L'étiquette de PW fournit la fonction de démultiplexage pour un PSN MPLS comme décrit au paragraphe 5.4.2 de la [RFC3985].

La taille totale d'un paquet SAToP pour un PW spécifique NE DOIT PAS excéder la MTU de chemin entre la paire de PE terminant ce PW. Les mises en œuvre de SAToP qui utilisent un PSN IPv4 DOIVENT marquer les datagrammes IPv4 qu'elles génèrent comme "Ne pas fragmenter" [RFC0791] (voir aussi la [RFC4623]).

 	4.3	En-tête SAToP
L'en-tête SAToP DOIT contenir le mot de contrôle SAToP (4 octets) et PEUT aussi contenir un en-tête RTP fixe [RFC3550]. Si l'en-tête RTP est inclus dans l'en-tête SAToP, il DOIT suivre immédiatement le mot de contrôle SAToP dans tous les cas excepté de multiplexage UDP, où il DOIT le précéder (voir les Figures 2a, 2b, et 2c).

Note : un tel arrangement se conforme à l'usage traditionnel de RTP pour le PSN IPv4/IPv6 avec le multiplexage UDP tout en protégeant les PW SAToP du multi chemins de coût égal (ECMP, Equal Cost Multi-Path) pour le PSN MPLS en assurant la discrimination de paquets PW-IP (voir au paragraphe 5.4.3 de la [RFC3985]). De plus, il facilite un point sans couture des segments fondés sur L2TPv3 et MPLS des PW SAToP (voir la [RFC6073]).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ...                               |
|    En-têtes IPv4/IPv6 et UDP (couche de démultiplexage de PW) |
|                             ...                               |
+===============+===============+===============+===============+
|                                                               |
+--                     FACULTATIF                            --+
|                                                               |
+--              En-tête fixe RTP (voir la [RFC3550])         --+
|                                                               |
+===============+===============+===============+===============+
|                 Mot de contrôle SAToP                         |
+===============+===============+===============+===============+
|                            ...                                |
|                     Données TDM (charge utile)                |
+---------------+---------------+---------------+---------------+

Figure 2a : Format de paquet SAToP pour PSN IPv4/IPv6 avec démultiplexage de PW UDP

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ...                               |
| En-têtes IPv4/IPv6 et L2TPv3 (couche de démultiplexage de PW) |
|                             ...                               |
+===============+===============+===============+===============+
|                  Mot de contrôle SAToP                        |
+===============+===============+===============+===============+
|                                                               |
+--                     FACULTATIF                            --+
|                                                               |
+--               En-tête fixe RTP (voir la [RFC3550])        --+
|                                                               |
+===============+===============+===============+===============+
|                             ...                               |
|                      Données TDM (charge utile)               |
|                             ...                               |
+---------------+---------------+---------------+---------------+

Figure 2b : Format de paquet SAToP pour PSN IPv4/IPv6 avec démultiplexage de PW L2TPv3

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ...                               |
|                     Pile d'étiquettes MPLS                    |
|                             ...                               |
+===============+===============+===============+===============+
|                   Mot de contrôle SAToP                       |
+===============+===============+===============+===============+
|                                                               |
+--                     FACULTATIF                            --+
|                                                               |
+--               En-tête fixe RTP (voir la [RFC3550])        --+
|                                                               |
+===============+===============+===============+===============+
|                             ...                               |
|                    Données TDM (charge utile)                 |
|                             ...                               |
+---------------+---------------+---------------+---------------+

Figure 2c : Format de paquet SAToP pour PSN MPLS

 	4.3.1	Usage et structure du mot de contrôle
L'usage du mot de contrôle SAToP permet :
1. la détection des paquets perdus ou déclassés
2. la différentiation entre les problèmes de PSN et de circuit de rattachement comme causes de panne du service émulé
3. la conservation de la bande passante du PSN en ne transférant pas les données invalides (AIS)
4. la signalisation au PW d'entrée des fautes détectées au PW de sortie.

La structure du mot de contrôle SAToP est montrée à la Figure 3.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R|RSV|FRG| Longueur  |    Numéro de séquence         |
+-+-+-+-+-+-+---+---+-----------+---------------+---------------+

Figure 3 : Structure du mot de contrôle SAToP

L'utilisation des bits 0 à 3 est décrite dans la [RFC4385]. Ces bits DOIVENT être réglés à zéro sauf si ils sont utilisés pour indiquer le début d'un en-tête de canal associé (ACH, Associated Channel Header). Un ACH est nécessaire si l'état du PW SAToP est surveillé en utilisant la vérification de connexité de circuit virtuel [RFC5085].

L : établi à 1, il indique que des données TDM portées dans la charge utile sont invalides à cause d'une faute d'un circuit de rattachement. Quand le bit L est établi, la charge utile PEUT être omise afin de conserver la bande passante. L'IWF liée au CE DOIT exécuter une quantité appropriée de données de remplissage sans considération de la taille de charge utile. Une fois établi, si la faute est rectifiée, le bit L DOIT être mis à zéro.

Note : le présent document ne spécifie pas quelles conditions de fautes de TDM sont traitées comme invalidant les données portées dans les paquets SAToP. Des exemples possibles incluent, sans s'y limiter LOS et AIS.

R : si il est établi par l'IWF liée au PSN, il indique que son IWF locale liée au CE est dans l'état de perte de paquets, c'est-à-dire, a perdu un nombre pré configuré de paquets consécutifs. Le bit R DOIT être mis à zéro par l'IWF liée au PSN une fois que son IWF locale liée au CE est sortie de l'état de perte de paquets, c'est-à-dire, a reçu un nombre pré configuré de paquets consécutifs.

RSV et FRG (bits 6 à 9) : DOIVENT être réglés à 0 par l'IWF liée au PSN et DOIVENT être ignorés par l'IWF liée au CE. RSV est réservé. FRG est fragmentation ; voir la [RFC4623].

Longueur (bits 10 à 15) : PEUT être utilisé pour porter la longueur du paquet SAToP (définie comme la taille de l'en-tête SAToP + la taille de charge utile) si elle fait moins de 64 octets, et DOIT être réglée à zéro autrement. Quand le champ Longueur est réglé à 0, la taille pré configurée de la charge utile du paquet SAToP DOIT être supposée être comme décrit au paragraphe 5.1, et si la taille réelle du paquet n'est pas cohérente avec cette longueur, le paquet DOIT être considéré comme mal formé.

Numéro de séquence : utilisé pour assurer la fonction courant de séquence de PW ainsi que la détection des paquets perdus.  Il DOIT être généré selon les règles définies au paragraphe 5.1 de la [RFC3550] pour le numéro de séquence RTP :
o	c'est un espace circulaire de 16 bits non signés
o	sa valeur initiale DEVRAIT être aléatoire (imprévisible).
Il DOIT être incrémenté à chaque paquet de données SAToP envoyé dans le PW spécifique.

 	4.3.2	Usage de l'en-tête RTP
Quand RTP est utilisé, les champs suivants de l'en-tête fixe RTP (voir le paragraphe 5.1 de la [RFC3550]) DOIVENT être réglés à zéro : P (bourrage), X (extension d'en-tête), CC (compte CSRC), et M (marqueur).

Le champ PT (type de charge utile) est utilisé comme suit :

1. Une valeur de PT DOIT être allouée dans la gamme des valeurs dynamiques (voir [RTP-TYPES]) pour chaque direction du PW. La même valeur de PT PEUT être réutilisée pour les deux directions du PW et aussi entre différents PW.

2. L'IWF liée au PSN DOIT régler le champ PT dans l'en-tête RTP à la valeur allouée.

3. L'IWF liée au CE PEUT utiliser la valeur reçue pour détecter les paquets mal formés.

Le numéro de séquence DOIT être le même que le numéro de séquence dans le mot de contrôle SAToP.

Les horodatages RTP sont utilisés pour porter les informations horaires sur le réseau. Leurs valeurs sont générées en accord avec les règles établies dans la [RFC3550].

La fréquence de l'horloge utilisée pour générer les horodatages DOIT être un entier multiple de 8 kHz. Toutes les mises en œuvre de SAToP DOIVENT prendre en charge l'horloge à 8 kHz. D'autres multiples de 8 kHz PEUVENT être utilisés.

La valeur de SSRC (source de synchronisation) dans l'en-tête RTP PEUT être utilisée pour la détection de mauvaises connexions, c'est-à-dire, une interconnexion incorrecte des circuits de rattachement.

La génération d'horodatages PEUT être utilisée dans les modes suivants :
1. Mode absolu : l'IWF liée au PSN règle l'horodatage en utilisant l'horloge récupérée du circuit de rattachement TDM entrant. Par conséquent, l'horodatage est étroitement corrélé aux numéros de séquence. Toutes les mises en œuvre de SAToP qui prennent en charge l'usage de l'en-tête RTP DOIVENT prendre en charge ce mode.
2. Mode différentiel : les deux IWF ont accès à une source horaire commune de bonne qualité, et cette source est utilisée pour la génération de l'horodatage. La prise en charge de ce mode est FACULTATIVE.

L'usage de l'en-tête RTP fixe dans un PW SAToP et toutes les options associées à cet usage (la fréquence de l'horloge d'horodatage, le mode d'horodatage, les valeurs choisies de PT et SSRC) DOIVENT faire l'objet d'un accord entre les deux PW SAToP durant l'établissement de PW, comme décrit dans la [RFC5287]. D'autres méthodes spécifiques de RTP (par exemple, voir la [RFC3551]) NE DOIVENT PAS être utilisées.

 	5.	Couche de charge utile SAToP
 	5.1	Charges utiles générales
Afin de faciliter le traitement des pertes de paquet dans le PSN, tous les paquets qui appartiennent à un certain PW SAToP sont OBLIGÉS de porter un nombre fixe d'octets remplis de données TDM reçues du circuit de rattachement. La taille de charge utile du paquet DOIT être définie durant l'établissement de PW, DOIT être la même pour les deux directions du PW, et DOIT rester inchangée pour la durée de vie du PW.

Les IWF côté CE et côté PSN DOIVENT s'accorder sur la taille de charge utile de paquet SAToP durant l'établissement de PW (les valeurs de taille de charge utile par défaut définies ci-dessous garantissent qu'un tel accord est toujours possible). La taille de charge utile de paquet SAToP peut être échangée sur le protocole de contrôle PWE3 ([RFC5287]) en utilisant la sous TLV Émulation de circuit sur paquet (CEP)/Octets de charge utile TDM de la TLV Paramètres d'interface [RFC4446].

SAToP utilise l'ordre suivant pour la mise en paquets des données TDM :
o	l'ordre des octets de charge utile correspond à leur ordre sur le circuit de rattachement ;
o	les bits consécutifs venant du circuit de rattachement remplissent chaque octet de charge utile en allant du bit de poids fort au bit de moindre poids.

Toutes les mises en œuvre de SAToP DOIVENT être capables de prendre en charge les tailles de charge utile suivantes :
o	E1 - 256 octets
o	T1 - 192 octets
o	E3 et T3 - 1024 octets.

Notes :
1. Quelle que soit la taille de charge utile choisie, SAToP ne suppose pas l'alignement sur une structure sous-jacente imposée par le tramage TDM (alignement d'octet, de trame, ou de multi trames).
2. Quand le bit L dans le mot de contrôle SAToP est établi, les paquets SAToP PEUVENT omettre les données TDM invalides afin de préserver la bande passante du PSN.
3. Les tailles de charge utile qui sont des multiples de 47 octets PEUVENT être utilisées en conjonction avec ATM-CES non structuré [ATM-CES].

 	5.2.	T1 aligné sur l'octet
Un circuit de rattachement T1 non structuré est parfois déjà bourré à un nombre entier d'octets, comme décrit dans l'Annexe B de [G.802]. Cela se produit quand le T1 est transposé d'un tributaire/conteneur virtuel SONET/SDH, ou quand il est "détramé" par un trameur E1/T1 en mode duel.

Afin de faciliter le fonctionnement dans de tels cas, SAToP définit un mode de transport spécial "T1 aligné sur l'octet". Dans ce mode, la charge utile SAToP consiste en un certain nombre de sous trames de 25 octets, chaque sous trame portant 193 bits de données TDM et 7 bits de bourrage. Ce mode est décrit dans la Figure 4.

|     1         |        2      | ...   |      25       |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ...   |0 1 2 3 4 5 6 7|
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|       Données TDM                       |  bourrage   |
+---------------+---------------+---------+-------------+
|            .................................          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Données TDM                       |  bourrage   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Figure 4 : Format de charge utile SAToP pour transport T1 aligné sur l'octet

Notes :
1. Le non alignement sur la structure de trames qui peut être imposé au flux binaire T1 est implicite.
2. Un avantage supplémentaire du mode de transport T1 aligné sur l'octet est la capacité de choisir la latence de mise en paquet de SAToP comme un multiple entier arbitraire de 125 microsecondes.

La prise en charge du mode de transport T1 aligné sur l'octet est FACULTATIVE. Un PW SAToP T1 aligné sur l'octet ne peut pas inter-fonctionner avec un PW SAToP T1 qui porte un flux binaire non aligné, comme décrit au paragraphe précédent.

Les mises en œuvre qui prennent en charge le mode de transport T1 aligné sur l'octet DOIVENT être capables de prendre en charge une taille de charge utile de 200 octets (c'est-à-dire, une charge utile de huit sous trames de 25 octets) correspondant à précisément 1 milliseconde de données TDM.

 	6.	Fonctionnement de SAToP
 	6.1	Considérations communes
L'émulation bord à bord d'un service TDM utilisant SAToP n'est possible que quand les deux circuits de rattachement de PW sont du même type (T1, E1, T3, E3). Le type de service est échangé à l'établissement de PW comme décrit dans la [RFC4447].

 	6.2	Fonctionnement d'IWF
 	6.2.1	Direction liée au PSN
Une fois le PW établi, l'IWF SAToP côté PSN opère comme suit :
Les données TDM sont mises en paquets en utilisant le nombre configuré d'octets de charge utile par paquet.
Les numéros de séquence, les fanions, et les horodatages (si l'en-tête RTP est utilisé) sont insérés dans les en-têtes SAToP.
Les en-têtes SAToP, de couche de démultiplexage de PW, et de PSN sont ajoutés aux données de service mises en paquets.
Les paquets résultants sont transmis sur le PSN.

 	6.2.2	Direction liée au CE
L'IWF SAToP liée au CE DEVRAIT inclure une mémoire tampon de gigue où mémoriser la charge utile des paquets SAToP reçus avant l'exécution sur le circuit de rattachement TDM local. La taille de cette mémoire tampon DEVRAIT être localement configurable pour permettre de s'accommoder des variations de délai de paquet spécifiques du PSN.

L'IWF SAToP liée au CE DEVRAIT utiliser le numéro de séquence dans le mot de contrôle pour la détection de paquets perdus et en désordre. Si l'en-tête RTP est utilisé, les numéros de séquence RTP PEUVENT être utilisés pour le même propos.

Note : Avec SAToP, un numéro de séquence valide peut toujours être trouvé dans les bits 16 à 31 du premier mot de 32 bits qui suit immédiatement l'en-tête de démultiplexage de PW sans considération du type spécifique de PSN, de la méthode de multiplexage, de l'usage ou non de l'en-tête RTP, etc. Cette approche simplifie les mises en œuvre qui prennent en charge plusieurs types d'encapsulation ainsi que la mise en œuvre de PW multi-segments qui utilisent des types d'encapsulation différents dans des segments différents.

L'IWF SAToP liée au CE PEUT réordonner les paquets en désordre. Les paquets en désordre qui ne peuvent pas être réordonnés DOIVENT être éliminés et traités comme perdus.

La charge utile des paquets SAToP reçus marqués avec le bit L établi DEVRAIT être remplacée par la quantité équivalente de schéma "tout de uns" même si elle n'a pas été omise.

La charge utile de chaque paquet SAToP perdu DOIT être remplacée par la quantité équivalente des données de remplacement. Le contenu des données de remplacement est spécifique de la mise en œuvre et PEUT être localement configurable. Par défaut, toutes les mises en œuvre de SAToP DOIVENT prendre en charge la génération du schéma "tout de uns" comme données de remplacement. Avant qu'un PW soit établi et après qu'un PW a été supprimé, l'IWF DOIT exécuter le schéma "tout de uns" à son circuit de rattachement TDM.

Une fois que le PW a été établi, l'IWF liée au CE commence à recevoir les paquets SAToP et à mémoriser leur charge utile dans la mémoire tampon de gigue mais elle continue d'exécuter le schéma "tout de uns" à son circuit de rattachement TDM. Cet état intermédiaire persiste jusqu'à ce qu'une quantité pré configurée de données TDM (généralement la moitié de la mémoire tampon de gigue) ait été reçue dans des paquets SAToP consécutifs ou jusqu'à ce qu'expire un temporisateur d'état intermédiaire pré configuré (démarré quant l'établissement de PW est achevé).

Une fois la quantité pré configurée de données TDM reçue, l'IWF SAToP liée au CE entre dans son état de fonctionnement normal où elle continue de recevoir des paquets SAToP et de mémoriser leur charge utile dans la mémoire tampon de gigue tout en exécutant le contenu de la mémoire tampon de gigue en accord avec l'horloge requise. Dans cet état, l'IWF SAToP liée au CE effectue la récupération d'horloge, PEUT surveiller les défauts de PW, et PEUT collecter les données de surveillance de performances du PW.

Si l'IWF SAToP liée au CE détecte la perte d'un nombre pré configuré de paquets consécutifs ou si le temporisateur d'état intermédiaire expire avant que la quantité requise de données TDM ait été reçue, elle entre dans son état de perte de paquet.  Dans cet état, l'IWF SAToP liée au PSN local DEVRAIT marquer chaque paquet qu'elle transmet avec le bit R établi. L'IWF SAToP liée au CE quitte cet état et passe à l'état normal une fois qu'un nombre pré configuré de paquets SAToP valides consécutifs ont été reçus. (Les paquets réordonnés avec succès contribuent au compte des paquets consécutifs.)

L'IWF SAToP liée au CE DOIT fournir une indication de validité des données TDM au CE. Ce peut être fait en transportant ou en générant l'indication native AIS. Comme mentionné précédemment, l'AIS T3 ne peut pas être détectée ou générée par des moyens qui ignorent la structure, et donc un NSP conscient de la structure DOIT être utilisé lors de la génération d'un schéma AIS valide.

 	6.3	Défauts de SAToP
En plus de l'état de perte de paquet de l'IWF SAToP liée au CE défini ci-dessus, elle PEUT détecter les défauts suivants :
o	les paquets égarés
o	les paquets mal formés
o	un taux excessif de perte de paquet
o	un débordement de mémoire tampon
o	une perte de paquet distante

À chaque défaut correspond un état de défaut à l'IWF, un critère de détection qui déclenche une transition de l'état de fonctionnement normal à l'état de défaut approprié, et une alarme qui PEUT être rapportée au système de gestion et supprimée ensuite. Les alarmes ne sont rapportées que quand l'état de défaut persiste pendant un délai pré configuré (normalement 2,5 secondes) et DOIVENT être libérées après que le défaut correspondant n'est pas détecté pendant un second délai pré configuré (normalement 10 secondes). Les temps de déclenchement et de libération des diverses alarmes peuvent être indépendants.

Les paquets égarés PEUVENT être détectés par les couches de démultiplexage de PSN et PW. Quand RTP est utilisé, le champ SSRC dans l'en-tête RTP PEUT aussi être utilisé à cette fin. Les paquets égarés DOIVENT être éliminés par l'IWF liée au CE, et leur détection NE DOIT PAS affecter les mécanismes de détection de perte de paquet.

Les paquets mal formés sont détectés par une discordance entre la taille de paquet attendue (en prenant en compte la valeur du bit L) et la taille réelle du paquet déduite des couches de démultiplexage de PSN et PW. Quand RTP est utilisé, le manque de correspondance entre la valeur de PT et celle allouée pour cette direction du PW PEUT aussi être utilisé à cette fin. Les paquets mal formés en ordre DOIVENT être éliminés par l'IWF liée au CE et des données de remplacement générées comme avec les paquets perdus.

Un taux excessif de perte de paquets est détecté en calculant le taux moyen de perte de paquet sur un délai configurable et en le comparant à un seuil pré configuré.

Le débordement de mémoire tampon est détecté dans l'état de fonctionnement normal quand la mémoire tampon de gigue de l'IWF liée au CE ne peut pas accommoder les nouveaux paquets SAToP arrivés.

La perte de paquet à distance est indiquée par la réception de paquets dont le bit R est établi.

 	6.4	Surveillance des performances de PW SAToP
Les paramètres de surveillance des performances (PM, Performance Monitoring) sont collectés régulièrement pour les services TDM et fournissent un important mécanisme de maintenance dans les réseaux TDM. La capacité de collecter des paramètres de PM compatibles pour les PW SAToP améliore leurs capacités de maintenance.

La collecte des paramètres de surveillance des performances de PW SAToP est FACULTATIVE et, si elle est mise en œuvre, n'est effectuée qu'après que l'IWF liée au CE est sortie de son état intermédiaire.

SAToP définit comme suit les événements d'erreur, les blocs erronés, et les défauts :

o	Un événement d'erreur SAToP est défini comme l'insertion d'un seul paquet de remplacement dans la mémoire tampon de gigue (le remplacement de la charge utile des paquets SAToP qui ont le bit L établi n'est pas considéré comme une insertion d'un paquet de remplacement).

o	Un bloc de données SAToP erroné est défini comme un bloc de données exécuté sur le circuit de rattachement TDM et d'une taille définie en accord avec les règles de [G.826] pour le service TDM correspondant qui a rencontré au moins un événement d'erreur SAToP.

o	Un défaut SAToP est défini comme l'état de perte de paquet de l'IWF SAToP liée au CE.

Les paramètres PM de PW SAToP (Erroné, Sévèrement erroné, et Secondes indisponibles) sont déduits de ces définitions en accord avec [G.826].

 	7.	Questions de qualité de service (QS)

SAToP DEVRAIT employer les capacités de qualité de service existantes du PSN sous-jacent.

Si le PSN qui assure la connexité entre les appareils PE a la capacité Diffserv et fournit un PDB [RFC3086] qui garantit une faible gigue et de faibles pertes, le PW SAToP DEVRAIT utiliser ce PDB en conformité avec les règles d'admission et d'allocation que le PSN a mis en place pour ce PDB (par exemple, marquer les paquets selon les instructions du PSN).

Si le PSN a la capacité Intserv, alors le service garanti (GS, Guaranteed Service) de la [RFC2212] avec la réservation de  bande passante appropriée DEVRAIT être utilisé afin de fournir une garantie de bande passante égale ou supérieure à celle du trafic TDM agrégé.

 	8.	Contrôle d'encombrement

Comme expliqué dans la [RFC3985], le PSN qui porte le PW peut subir de l'encombrement. Les PW SAToP représentent des flux inélastiques de débit binaire constant (CBR, Constant Bit-Rate) et ne peuvent pas répondre à l'encombrement d'une manière favorable à TCP comme prescrit par la [RFC2914], bien que le pourcentage de bande passante totale qu'ils consomment reste constant.

Si des précautions appropriées ne sont pas prises, une demande non diminuée de bande passante par les PW SAToP peut contribuer à un encombrement du réseau qui peut impacter les protocoles de contrôle du réseau.

Chaque fois que possible, les PW SAToP DEVRAIENT être portés sur des PSN à ingénierie du trafic qui fournissent la réservation de bande passante et le contrôle d'admission ou des mécanismes de conditionnement de priorisation et limitation de trafic. Les domaines à capacité IntServ qui prennent en charge le service garanti [RFC2212] et les domaines à capacité DiffServ [RFC2475] qui prennent en charge la transmission accélérée (EF, Expedited Forwarding) [RFC3246] sont des exemples de tels PSN. Ces mécanismes vont combattre, dans une certaine mesure, les effets des PW SAToP sur les flux voisins. Afin de faciliter le conditionnement du trafic frontière du trafic SAToP sur les PSN IP, le paquet IP SAToP NE DEVRAIT PAS utiliser la valeur de codet DiffServ (DSCP) réservée pour le comportement par bond par défaut (PHB, Default Per-Hop Behavior) [RFC2474].

Si les PW SAToP fonctionnent sur un PSN qui fournit un service au mieux, ils DEVRAIENT surveiller les pertes de paquet afin de détecter un "encombrement sévère". Si une telle condition est détectée, un PW SAToP DEVRAIT fermer la bidirectionnalité pendant un certain temps comme décrit au paragraphe 6.5 de la [RFC3985].

Noter que :
1.	L'IWF SAToP peut naturellement fournir la mesure de perte de paquet car les taux attendus d'arrivée de paquets SAToP sont fixés et connus.
2.	Les résultats de la mesure de perte de paquet SAToP peuvent n'être pas une indication fiable de la présence ou absence d'encombrement sévère si le PSN fournit une livraison améliorée. Par exemple :
a) si le trafic SAToP à la préséance sur le trafic non SAToP, un encombrement sévère peut se développer sans pertes significatives de paquet SAToP.
b) si le trafic non SAToP a la préséance sur le trafic SAToP, SAToP peut subir des pertes de paquet substantielles à cause de salves de court terme de trafic a priorité élevée.
3.	Les services TDM émulés par les PW SAToP ont des objectifs de grande disponibilité (voir [G.826]) qui DOIVENT être pris en compte pour décider d'une fermeture temporaire des PW SAToP.

La présente spécification ne définit pas les critères exacts pour détecter un "encombrement sévère" en utilisant le taux de perte de paquet SAToP ou les méthodes spécifiques pour la fermeture bidirectionnelle des PW SAToP (quand un tel encombrement sévère a été détecté) et leur redémarrage ultérieur après un délai convenable. Ceci fera l'objet d'une étude ultérieure. Cependant, les considérations suivantes peuvent être utilisées comme lignes directrices pour la mise en œuvre du mécanisme SAToP de fermeture en cas d'encombrement sévère :

1.	Les techniques de surveillance de performances SAToP (voir au paragraphe 6.4) fournissent des critères d'entrée et de sortie pour l'état de PW SAToP "Indisponible" qui le rendent étroitement corrélé à l'état "Indisponible" du circuit TDM émulé, comme spécifié dans [G.826]. Utiliser les mêmes critères pour la détection "d'encombrement sévère" peut diminuer le risque de fermeture du PW SAToP alors que le circuit TDM émulé est encore considéré comme disponible par le CE.

2.	Si le PW SAToP a été établi en utilisant le protocole de contrôle PWE3 [RFC4447] ou L2TPv3 [RFC3931], les procédures régulières de suppression de PW de ces protocoles DEVRAIENT être utilisées.

3.	Si un des points d'extrémité du PW SAToP arrête la transmission des paquets pendant une période suffisamment longue, son homologue (en observant une perte de paquets de 100 %) va nécessairement détecter un "encombrement sévère" et arrêter aussi la transmission, réalisant donc une fermeture bidirectionnelle du PW.

 	9.	Considérations sur la sécurité

SAToP n'améliore pas ni ne dégrade les performances de sécurité du PSN sous-jacent ; il s'appuie plutôt sur les mécanismes du PSN pour le chiffrement, l'intégrité, et l'authentification chaque fois que nécessaire.

Les PW SAToP partagent la susceptibilité à un certain nombres d'attaques de pseudo-filaires et vont utiliser tous les mécanismes de confidentialité, intégrité, et authentification développés pour les PW généraux. Ces méthodes sortent du domaine d'application du présent document.

Bien que les PW SAToP PUISSENT employer un en-tête RTP quand un transfert explicite d'informations de synchronisation est requis, les mécanismes de SRTP (voir la [RFC3711]) NE SONT PAS RECOMMANDÉS comme substitut de la sécurité de la couche PW.

Les capacités de détection de mauvaise connexion de SAToP augmentent sa résilience aux mauvaises configurations et à certains types d'attaques de déni de service.

L'initialisation aléatoire des numéros de séquence, dans le mot de contrôle et dans l'en-tête RTP facultatif, rendent plus difficiles les attaques de texte en clair connu sur les PW SAToP chiffrés. Le chiffrement des PW sort du domaine d'application de ce document.

 	10.	Déclaration d'applicabilité
SAToP est une couche d'encapsulation destinée à porter les circuits TDM (E1/T1/E3/T3) sur un PSN d'une façon qui ignore la structure.

SAToP se conforme entièrement au principe d'intervention minimale, minimisant donc les frais généraux et la puissance de calcul requis pour l'encapsulation.

SAToP fournit des fonctions de séquençage et de synchronisation nécessaires pour l'émulation des flux binaires TDM, incluant la détection des paquets perdus ou en désordre et les compensations appropriées.

Les flux binaires TDM portés sur les PW SAToP peuvent subir des délais excédant ceux des réseau TDM natifs normaux. Ces délais incluent le délai de mise en paquet SAToP, le délai de bord à bord du PSN sous-jacent, et le délai ajouté par la mémoire tampon de gigue. Il est recommandé d'estimer le délai et la variation de délai avant d'établir un PW SAToP.

SAToP porte les flux TDM sur le PSN dans leur intégralité, incluant toute la signalisation TDM contenue avec les données. Par conséquent, les services TDM émulés sont sensibles à la perte de paquet sur le PSN. Une génération appropriée de données de remplacement peut être utilisée pour empêcher la fermeture de l'interface CE TDM à cause de pertes occasionnelles de paquet. Les autres effets de la perte de paquet sur cette interface (par exemple, des blocs erronés) ne peuvent pas être empêchés.

Note : l'émulation de TDM sensible à la structure (voir la [RFC5086] ou la [RFC5087]) cache complètement les effets de la perte de paquet dans le PSN sur l'interface CE TDM (parce que le tramage et les contrôles de redondance cyclique sont générés en local) et permet l'usage de méthodes de dissimulation de perte de paquet spécifiques de l'application pour minimiser les effets sur les applications qui utilisent le service d'émulation TDM.

SAToP peut être utilisé en conjonction avec divers scénarios de synchronisation de réseau (voir la [RFC4197]) et techniques de récupération d'horloge. La qualité de l'horloge TDM récupérée par l'IWF SAToP peut être spécifique de la mise en œuvre. La qualité peut être améliorée en utilisant RTP si une horloge commune est disponible des deux côtés du PW SAToP.

SAToP fournit un isolement efficace des fautes en portant des indications d'échec du circuit de rattachement local.

L'option de ne pas porter les données TDM invalides permet la conservation de la bande passante de PSN.

SAToP permet la collecte des fautes de style TDM et des paramètres de surveillance des performances et donc émule les services "classiques" de transporteur de TDM.

SAToP fournit une capacité indépendante du transporteur pour détecter les mauvaises connexions et les paquets mal formés. Cette caractéristique augmente la résilience du service émulé aux mauvaises configurations et attaques de déni de service.

Étant un service à débit binaire constant, SAToP ne peut pas fournir un comportement favorable à TCP en cas d'encombrement du réseau.

La fidélité d'un PW SAToP peut être augmentée en exploitant les caractéristiques de qualité de service du PSN sous-jacent.

SAToP ne fournit aucun mécanisme de protection contre les pannes du PSN, et donc sa résistance à de telles pannes est limitée. Cependant, les mécanismes de remplacement de paquet perdu et de remise en ordre des paquets augmentent la résistance du service émulé aux événements de changement brusque de chemin du PSN.

 	11.	Considérations relatives à l'IANA

L'allocation des types de pseudo-filaires pour les PW SAToP correspondants est définie dans la [RFC4446].

 	12.	Remerciements

On remercie de leurs travaux Gil Biran et Hugo Silberman qui ont mis en œuvre le transport TDM sur IP en 1998.
Nous tenons à remercier Alik Shimelmits des nombreuses discussions productives et Ron Insler de son assistance dans le déploiement de TDM sur PSN.
Nous exprimons notre profonde gratitude à Stephen Casner qui a révisé en détails un des prédécesseurs de ce document et a fourni des retours précieux concernant divers aspects de l'usage de RTP, et à Kathleen Nichols qui a fourni le texte actuel de la section de qualité de service sur les PSN à capacité Diffserv.
Merci aussi à William Bartholomay, Robert Biksner, Stewart Bryant, Rao Cherukuri, Ron Cohen, Alex Conta, Shahram Davari, Tom Johnson, Sim Narasimha, Yaron Raz, et Maximilian Riegel de leurs précieuses réactions.

 	13.	Coauteurs
Les personnes suivantes sont les coauteurs de ce document :
Motty Anavi, RAD Data Communications
Tim Frost, Zarlink Semiconductors
Eduard Metz, TNO Telecom
Prayson Pate, Overture Networks
Akiva Sadovski
Israel Sasson, Axerra Networks
Ronen Shashoua, RAD Data Communications

 	14.	Références normatives

[G.702]	Recommandation UIT-T G.702, "Débits binaires de hiérarchie numérique". (11/1988) 

[G.703]	Recommandation UIT-T G.703, "Caractéristiques physiques/électriques des interfaces numériques hiérarchiques". (10/1998)

[G.704]	Recommandation UIT-T G.704, "Structures de trame synchrones utilisées aux niveaux hiérarchiques 1544, 6312, 2048, 8448 et 44 736 kbit/s". (10/1998)

[G.707]	Recommandation UIT-T G.707, "Interface de nœud réseau pour la hiérarchie numérique synchrone (SDH)", mai 1996.

[G.775]	Recommandation UIT-T G.775, "Détection des défauts perte de signal (LOS), signal d'indication d'alarme (AIS) et indication de défaut distant (RDI) et critères de d'élimination pour les signaux PDH". (10/1998)

[G.802]	Recommandation UIT-T G.802, "Interfonctionnement entre réseaux fondés sur des hiérarchies numériques et des lois de codage de la parole différentes". (11/1988)

[G.826]	Recommandation UIT-T G.826, "Paramètres et objectifs de performances d'erreur pour les chemins numériques internationaux à débit bunaire constant au débit primaire ou au dessus". (02/1999)

[RFC0791]	J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

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

[RFC2474]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (P.S. ; MàJ par RFC3168, RFC3260, RFC8436)

[RFC2475]	S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre  1998. (MàJ par RFC3260)

[RFC2914]	S. Floyd, "Principes du contrôle d'encombrement", BCP 41, septembre 2000.

[RFC3086]	K. Nichols, B. Carpenter, "Définition des comportements de services différenciés par domaine et règles de leur spécification", avril 2001. (Information)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3931]	J. Lau et autres, "Protocole de tunnelage de couche deux - version 3 (L2TPv3)", mars 2005. (P.S.)

[RFC4385]	S. Bryant et autres, "Mot de contrôle d'émulation bord à bord pseudo filaire (PWE3) à utiliser sur un PSN MPLS", février 2006. (P.S.)

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de bord à bord pseudo filaire (PWE3)", avril 2006. (BCP0116)

[RFC4447]	L. Martini et autres, "Établissement et maintenance de pseudo filaires avec le protocole de distribution d'étiquettes", avril  2006. (MàJ par la RFC6723) (P.S. ; Remplacé par RFC8077 STD 84)

[RTP-TYPES]	RTP PARAMETERS, <http://www.iana.org/assignments/rtp-parameters >.

[T1.107]	American National Standard for Telecommunications, "Digital Hierarchy - Format Specifications", ANSI T1.107-1988.

 	15.	Références pour information

[ATM-CES]	ATM forum specification af-vtoa-0078 (CES 2.0) "Circuit Emulation Service Interoperability Specification Ver. 2.0".

[RFC2212]	S. Shenker, C. Partridge, R. Guerin, "Spécification de la qualité de service garantie", septembre 1997. (P.S.)

[RFC3246]	B. Davie et autres, "Comportement par bond de transmission accélérée", mars 2002. (P.S.)

[RFC3551]	H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003. (MàJ par RFC8860)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S.)

[RFC3916]	X. Xiao, D. McPherson et P. Pate, éd., "Exigences pour l'émulation bord à bord pseudo filaire (PWE3)", septembre  2004. (Information)

[RFC3985]	S. Bryant et autres, "Architecture d'émulation bord à bord pseudo-filaire (PWE3)", mars 2005. (Information)

[RFC4197]	M. Riegel, éd., "Exigences pour l'émulation de bord à bord de circuits à multiplexage temporel (MRT) sur les réseaux à commutation de paquets", octobre 2005. (Information)

[RFC4623]	A. Malis, M. Townsley, "Fragmentation et réassemblage d'émulation bord à bord pseudo filaire (PWE3)", août 2006. (P.S.)

[RFC5085]	T. Nadeau et C. Pignataro, éditeurs, "Vérification de connexité de circuit virtuel pseudo filaire (VCCV) : un canal de contrôle pour les pseudo filaires", décembre 2007. (MàJ par RFC5586) 

[RFC5086]	A. Vainshtein et autres, "Service d'émulation de circuit multiplexé par répartition dans le temps (MRT) en fonction de la structure sur un réseau à commutation de paquets (CESoPSN)", décembre 2007. (Information)

[RFC5087]	Y(J). Stein et autres, "Multiplexage à répartition dans le temps sur IP (TDMoIP)", décembre 2007. (Information)

[RFC5287]	A. Vainshtein, Y(J). Stein, "Extensions au protocole de contrôle pour l'établissement de pseudo filaires à multiplexage à répartition dans le temps (MRT) dans les réseaux MPLS", août 2008. (P.S.)

[RFC6073]	L. Martini, et autres, "Pseudo-fils segmentés", janvier 2011. (MàJ par la RFC6723) (P.S.)

 	Appendice A.	Ancien mode d'encapsulation SAToP sur L2TPv3

Les précédentes versions de cette spécification définissaient une encapsulation de PW SAToP sur L2TPv3, qui diffère de celle décrite au paragraphe 4.3 et la Figure 2b. Dans ces versions, l'en-tête RTP, si il est utilisé, précède le mot de contrôle SAToP.

Les mises en œuvre existantes de l'ancien mode d'encapsulation DOIVENT être distinguées des encapsulations conformes à la présente spécification via l'établissement de PW SAToP.

 	Appendice B.	Paramètres qui DOIVENT être acceptés durant l'établissement de PW

Les paramètres suivants de l'IWF SAToP DOIVENT faire l'objet d'un accord entre les IWF des homologues durant l'établissement de PW. Un tel accord peut être obtenu via une configuration manuelle ou via un des protocoles d'établissement de PW :

1. Type du circuit de rattachement (AC)
Comme mentionné à la Section 3, SAToP prend en charge les types d'AC suivants :
i)   E1  (2048 kbit/s)
ii)  T1  (1544 kbit/s) ; ce service est aussi appelé DS1
iii) E3 (34368 kbit/s)
iv) T3 (44736 kbit/s) ; ce service est aussi appelé DS3
Les PW SAToP ne peuvent pas être établis entre des AC de différents types.

2. Usage du mode aligné sur l' octet pour T1
a) Ce mode FACULTATIF d'émulation des flux binaires T1 avec les PW SAToP est décrit au paragraphe 5.2.
b) Les deux côtés DOIVENT s'accorder sur l'utilisation de ce mode pour qu'un PW SAToP soit opérationnel.

3. Taille de charge utile, c'est-à-dire, quantité de données TDM valides dans un paquet SAToP
a) Comme mentionné au paragraphe 5.1 :
i) La même taille de charge utile DOIT être utilisée dans les deux directions du PW SAToP.
ii) La taille de charge utile ne peut pas être changée une fois que le PW a été établi.
b) Dans la plupart des cas, toute valeur mutuellement acceptée peut être utilisée. Cependant, si le mode d'encapsulation T1 aligné sur l'octet est utilisé, la taille de charge utile DOIT être un multiple entier de 25, et elle exprime la quantité de données TDM valides incluant le bourrage.

4. Usage de l'en-tête RTP dans l'encapsulation
a) Les deux côtés DOIVENT s'accorder sur l'utilisation d'en-tête RTP dans le PW SAToP.
b) Dans le cas d'un PW SAToP sur L2TPv3 qui utilise l'en-tête RTP, les deux côtés DOIVENT s'accorder sur l'usage de "l'ancien mode" décrit dans l'Appendice A.

5. Paramètres dépendants de RTP. Les paramètres suivants DOIVENT être acceptés mutuellement si l'usage de l'en-tête RTP pour le PW SAToP a été accepté.
a)	Mode d'horodatage (absolu ou différentiel) ; ce mode PEUT être différent pour les deux directions du PW, mais le receveur et l'émetteur DOIVENT s'accorder sur le mode d'horodatage pour chaque direction du PW
b) Fréquence d'horloge de l'horodatage :
i) La fréquence de l'horodatage DOIT être un multiple entier de 8 kHz.
ii) La fréquence de l'horodatage PEUT être différente pour les deux directions du PW, mais le receveur et l'émetteur DOIVENT s'accorder sur le mode d'horodatage pour chaque direction du PW.
c) Valeur du type de charge utile RTP ; toute valeur allouée dynamiquement peut être utilisée avec les PW SAToP.
d) Valeur de source de synchronisation (SSRC) ; l'émetteur DOIT accepter d'envoyer la valeur de SSRC demandée par le receveur.

 	Adresse des éditeurs 
Alexander ("Sasha") Vainshtein	Yaakov (Jonathan) Stein	
Axerra Networks	RAD Data Communications	
24 Raoul Wallenberg St.,	24 Raoul Wallenberg St., Bldg C	
Tel Aviv 69719	Tel Aviv 69719	
Israel	Israel	
mél : sasha@axerra.com 	mél : yaakov_s@rad.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

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 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 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 pourrait ê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 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 fourni par l'activité de soutien administratif (IASA) de l'IETF.