Groupe de travail Réseau	A. Malis, Ascend Communications, Inc.
Request for Comments : 2615 	W. Simpson, DayDreamer
RFC rendue obsolète : 1619	juin 1999
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

PPP sur SONET/SDH

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (1999). Tous droits réservés.

Résumé
Le protocole point à point (PPP) [RFC1661] fournit une méthode standard pour transporter des datagrammes multi protocoles sur des liaisons point à point. Le présent document décrit l'utilisation de PPP sur des circuits de réseau optique synchrone (SONET, Synchronous Optical Network) et de hiérarchie numérique synchrone (SDH, Synchronous Digital Hierarchy).

Le présent document remplace et rend obsolète la RFC 1619. Voir à la Section 7 le résumé des changements par rapport à la RFC 1619.
Table des matières
1. Introduction	1
2. Exigences de la couche physique	2
3. Tramage	3
4. Description du brasseur X**43 + 1	3
5. Détails de configuration 	4
6. Considérations sur la sécurité	4
7. Changements par rapport à la RFC 1619	4
8. Propriété intellectuelle	5
9. Remerciements	5
10. Références	5
11. Adresse des auteurs	5
12. Déclaration complète de droits de reproduction	6

 	1.	Introduction

PPP a été conçu comme une méthode standard de communication sur des liaisons point à point. Les déploiements initiaux ont été faits sur de courtes lignes locales, des liaisons louées, et le service téléphonique traditionnel, en utilisant des modems. Avec l'introduction de nouveaux services de paquets et de lignes à plus grande vitesse, PPP est facilement déployé aussi dans ces environnements.

La présente spécification est principalement concernée par l'utilisation de l'encapsulation PPP sur des liaisons SONET/SDH. Comme SONET/SDH est par définition un circuit point à point, PPP convient bien pour être utilisé sur ces liaisons.

Les différences réelles entre SONET et SDH (autres que de terminologie) sont mineures ; pour les besoins de l'encapsulation de PPP sur SONET/SDH, elles sont sans conséquence ou non pertinentes.

Pour l'agrément du lecteur, on fait la liste des termes équivalents ci-dessous :

SONET	SDH
SPE	VC (circuit virtuel)
STS-SPE	VC d'ordre spérieur (VC-3/4/4-Nc)
Trame STS-1	Trame STM-0 (rarement utilisé)
STS-1-SPE	VC-3
Charge utile STS-1	C-3
Trame STS-3c	Trame STM-1, AU-4
STS-3c-SPE	VC-4
Charge utile STS-3c	C-4
Trame STS-12c/48c/192c	Trame STM-4/16/64, AU-4-4c/16c/64c
STS-12c/48c/192c-SPE	VC-4-4c/16c/64c
Charge utile STS-12c/48c/192c	C-4-4c/16c/64c

Les seuls SPE/VC SONET/SDH actuellement pris en charge sont les suivants :

SONET	SDH
STS-3c-SPE	VC-4
STS-12c-SPE	VC-4-4c
STS-48c-SPE	VC-4-16c
STS-192c-SPE	VC-4-64c

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.	Exigences de la couche physique

PPP traite le transport SONET/SDH comme des liaisons synchrones en mode octet. Les liaisons SONET/SDH sont bidirectionnelles (full-duplex) par définition.

Format d'interface
PPP en tramage de style HDLC présente une interface d'octet à la couche physique. Il n'y a pas de dispositions pour que des sous octets soient fournis ou acceptés [T1.105], [G.707].

Le flux d'octets est transposé dans le VC d'ordre supérieur SONET STS-SPE/SDH, avec les limites d'octet alignées sur les limites d'octet de VC d'ordre supérieur SONET STS-SPE/SDH.

Le brassage est effectué durant l'insertion dans le VC d'ordre supérieur SONET STS-SPE/SDH pour fournir la transparence adéquate et protéger contre de potentielles menaces pour la sécurité (voir la Section 6). Pour la rétro compatibilité avec la RFC 1619 (STS-3c-SPE/VC-4 seulement) le brasseur PEUT avoir une capacité marche/arrêt où le brasseur est entièrement court-circuité quand il est en mode arrêt. Si cette capacité est fournie, le brasseur DOIT être activé par défaut.

Pour PPP sur SONET/SDH, la charge utile SONET/SDH entière (VC d'ordre supérieur SONET STS-SPE/SDH moins les frais généraux de chemin et tout bourrage fixé) est brassée en utilisant un brasseur auto synchrone de polynome X**43 + 1. Voir à la Section 4 la description du brasseur.

Le bon ordre de fonctionnement est :

À l'émission :

IP -> PPP -> génération de FCS -> bourrage d'octets -> brassage  -> tramage SONET/SDH

À la réception :

tramage SONET/SDH -> débrassage -> débourrage d'octets -> détection de FCS -> PPP -> IP

L'étiquette de signal de chemin (C2) indique le contenu du VC d'ordre supérieur SONET STS-SPE/SDH. La valeur de 22 (16 en hexadécimal) est utilisée pour indiquer PPP avec brassage X^43 + 1 [T1.105.02].

Pour la compatibilité avec la RFC 1619 (STS-3c-SPE/VC-4 seulement) si le brassage a été configuré comme désactivé, alors la valeur 207 (CF en hexadécimal) est utilisée pour que l'étiquette de signal de chemin indique PPP sans brassage.

L'indicateur de multi trame (H4) n'est pas utilisé, et DOIT être zéro.

Signaux de contrôle
PPP n'exige pas l'utilisation de signaux de contrôle. Quand ils sont disponibles, l'utilisation de tels signaux peut permettre plus de fonctionnalités et de performances. Les implications sont discutées dans la [RFC1662].

 	3.	Tramage

Le tramage pour les liaisons synchronisées à l'octet est décrit dans "PPP en trames de style HDLC" [RFC1662].

Les trames PPP sont localisées par rangées au sein de la charge utile du VC d'ordre supérieur SONET STS-SPE/SDH. Parce que les trames sont de longueur variable, il est permis aux trames de franchir les frontières de VC d'ordre supérieur SONET STS-SPE/SDH.

 	4.	Description du brasseur X**43 + 1

Le fonctionnement du brasseur X**43 + 1 en émission et en réception est le suivant :

Schéma en émission :

                                              Données non brassées
                                                     |
                                                     v
        +---------------------------------------+  +---+
     +->| --> registre de décalage de 43 bits -->  |--->|OUX|
     |  +---------------------------------------+  +---+
     |                                               |
     +-----------------------------------------------+
                                                     |
                                                     v
                                               Données brassées

Schéma en réception :

                                               Données brassées
                                                     |
     +-----------------------------------------------+
     |                                               |
     |                                               v
     |  +---------------------------------------+  +---+
     +->| --> registre de décalage de 43 bits --> |--->|OUX|
        +---------------------------------------+  +---+
                                                     |
                                                     v
                                             Données non brassées

Note : tandis que la séquence de contrôle de trame (FCS, Frame Check Sequence) HDLC est calculée avec le bit de moindre poids en premier comme on le montre ci-dessous :

<-  <-  <-  <-
A   B   C   D

(c'est-à-dire que le calculateur de FCS est alimenté comme suit : A[0], A[1], ... A[7], B[0], B[1], etc...), le brassage est fait en sens opposé, le bit de poids fort en premier, comme montré ci-dessous :

->  ->  ->  ->
A   B   C   D.

c'est-à-dire que le brasseur est alimenté comme suit : A[7], A[6], ... A[0], B[7], B[6], etc...

Le brasseur opère de façon continue à travers les octets du VC d'ordre supérieur SONET STS-SPE/SDH, outrepassant les octets de frais généraux de chemin SONET et tout bourrage fixe (voir la Figure 20 de ANSI T1.105 [T1.105] ou la Figure 10-17 de la Recommandation UIT-T G.707 [G.707]). L'état de brassage au début d'un VC d'ordre supérieur SONET STS-SPE/SDH est l'état à la fin du précédent VC d'ordre supérieur SONET STS-SPE/SDH. Donc, le brasseur fonctionne en continu et n'est pas réinitialisé à chaque trame. Le germe initial est choisi au hasard par l'émetteur pour améliorer la sécurité de fonctionnement (voir la Section 6). Par conséquent, les 43 premiers bits transmis à la suite du démarrage ou d'une opération de retramage ne vont pas se débrasser correctement.

 	5.	Détails de configuration 

À part la longueur de FCS (voir ci-dessous) la configuration standard de synchronisation de LCP par défaut s'applique aux liaisons SONET/SDH.

Les options de configuration suivantes sont RECOMMANDÉES pour STS-3c-SPE/VC-4 :
Numéro magique
Pas de compression de champ Adresse et Contrôle
Pas de compression de champ Protocole

Pour le fonctionnement à STS-12c-SPE/VC-4-4c et au dessus, la compression de champ Adresse et Contrôle et la compression de champ Protocole sont NON RECOMMANDÉES. L'option Numéro magique reste RECOMMANDÉE.

Concernant la longueur de FCS, avec une exception, la FCS de 32 bits DOIT être utilisée pour tous les débits de SONET/SDH. Pour STS-3c-SPE/VC-4 seulement, la FCS de 16 bits PEUT être utilisée, bien que la FCS de 32 bits soit RECOMMANDÉE. La longueur de la FCS est réglée au provisionnement et n'est pas négociée.

 	6.	Considérations sur la sécurité

Le changement majeur par rapport à la RFC 1619 est l'ajout du brassage de charge utile à l'insertion des paquets PPP en tramage de style HDLC dans le VC d'ordre supérieur SONET STS- SPE/SDH. Le fonctionnement de la RFC 1619 s'est révélé permettre que des utilisateurs malveillants génèrent des paquets avec des schémas de bits qui pourraient créer des problèmes de synchronisation de faible densité de transition de couche SONET/SDH, d'émulation du schéma d'établissement/rétablissement de brasseur SDH, et la réplication du mot de verrouillage de trame STM-N.

L'utilisation du brasseur auto synchronisé x^43 + 1 a été introduite pour alléger ces problèmes potentiels de sécurité. Prédire le résultat du brasseur exige la connaissance de l'état de 43 bits de l'émetteur lorsque le brassage d'une entrée connue est commencé. Cela exige la connaissance à la fois de l'état initial de 43 bits du brasseur quand il a démarré et de chaque octet de données brassées par l'appareil depuis son démarrage. Les chances de deviner correctement sont 1/2**43, avec la probabilité supplémentaire de 1/127 qu'une conjecture correcte laisse la trame correctement alignée dans la charge utile SONET/SDH, ce qui résulte en une probabilité de 9e-16 contre être capable de causer délibérément des problèmes à la couche SONET/SDH. Cela semble raisonnablement sûr pour cette application.

Ce brasseur est aussi utilisé à l'émission de ATM sur SONET/SDH, et les transporteurs de réseaux publics ont une expérience considérable de son utilisation.

Un problème de sécurité connu est la réduction de bande passante par la transmission intentionelle de caractères ou séquences exigeant la transparence du traitement en incluant des caractères de fanion et/ou d'échappement dans les données d'utilisateur. Un utilisateur peut causer jusqu'à 100 % d'augmentation de la bande passante requise pour transmettre ses paquets en remplissant le paquet avec des caractères fanions et/ou d'échappement.

 	7.	Changements par rapport à la RFC 1619

Comme mentionné à la section précédente, le changement majeur par rapport à la RFC 1619 a été l'ajout du brassage de la charge utile lors de l'insertion des paquets PPP à tramage de style HDLC dans le VC d'ordre supérieur SONET STS-SPE/SDH. Les autres changements sont :

La terminologie a été mise à jour pour mieux correspondre à celle utilisée par l'ANSI et l'UIT-T.

L'applicabilité de la spécification est maintenant spécifiquement restreinte à :

SONET	SDH
STS-3c-SPE	VC-4
STS-12c-SPE	VC-4-4c
STS-48c-SPE	VC-4-16c
STS-192c-SPE	VC-4-64c

L'étiquette de signal de chemin (C2) est réglée à 22 (16 en hexadécimal) quand on utilise le brassage X^43 + 1.

La FCS de 32 bits est exigée sauf pour le fonctionnement avec STS-3c-SPE/VC-4, et dans ce cas la FCS de 16 bits est permise (mais la FCS de 32 bits est toujours recommandée).

La section des considérations sur la sécurité a été ajoutée.

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

 	9.	Remerciements

La description du brasseur a été fournie par J. Manchester, S. Davida, B. Doshi, et J. Anderson de Lucent Technologies, R. Broberg de Cisco Systems, et Peter Lothberg de Sprint Corporation. L'analyse de la sécurité a été fournie par Iain Verigin de PMC-Sierra et Larry McAdams de Cisco Systems. Les auteurs tiennent aussi à remercier les membres du groupe de travail Extensions au protocole point à point de l'IETF pour leurs nombreuses suggestions et améliorations au texte.

 	10.	Références

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

[RFC1661]	W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC2153)

[RFC1662]	W. Simpson, éditeur, "PPP en trames de style HDLC", STD 51, juillet 1994. (Remplace la RFC1549)

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

[T1.105]	American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats," ANSI T1.105-1995.

[T1.105.02]	American National Standards Institute, "Synchronous Optical Network (SONET)--Payload Mappings," T1.105.02-1998.

 	11.	Adresse des auteurs

Andrew G. Malis	William Allen Simpson	
Ascend Communications, Inc.	DayDreamer	
1 Robbins Road	Computer Systems Consulting Services	
Westford, MA 01810	1384 Fontaine	
USA	Madison Heights, Michigan  48071	
téléphone : +1 978 952 7414	USA	
mél : malis@ascend.com 	mél : wsimpson@GreenDragon.com 	

 	12.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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.

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