CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
Annexe I - Tarifs
IT pr - / 4 nl LE=
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Annexe | — Tarification OPERA Office — 92240 Malakoff
Table des matières
1. STRUCTURE TARIFAIRE - LIGNE OPERA OFFICE nee 3
2. TARIFS LIGNE OPERA OFFICE nnrnrennrnnrenennrennennnnmennenenennnennnnnnnnnnnnnnnnnnnnnnnnneneennnnnnnnennenennnnnee 3
2.1 Composante ACCÈS. nr 3
2.2 Composante Porte de Livraison... 4
2.3 Prestations optionnelles rennes 4
2.3. Option de GTR 10 Heures Ouvrables rennes 4
2.3.2 Prestation optionnelle d'installation de l'équipement terminal... sn 4
2.4 Prestations sur le Raccordement Client Final... sssssnnnrneennnnneneenennnnnnes 4
2.4. Bordereau de prix unitaire sur de la surlongueur ere 4
2.4.2 Prestation nouvelle intervention pour modification de l'emplacement du PTO. nn 5
2.4.3 Remplacement du PTO. nn 5
La présente annexe décrits les tarifs du service de ligne OPERA Office pour les réseaux des Mandantes jointes en annexe 1 des conditions Générales. Les pénalités relatives au service sont décrites dans l'annexe l.A. axione 152 avenue Pierre Brossolette Annexe | - Tarification OPERA Office
— 92240 Malakoff
1. STRUCTURE TARIFAIRE — LIGNE OPERA OFFICE
Selon le mode de souscription, la tarification de la Ligne OPERA Office comprend :
Une composante Accès qui comprend :
Les frais de raccordement lissés
La fourniture et pose de l'ONT
La prestation de brassage
L'activation d’une Ligne FTTH depuis le Local FTTH de l’'Abonné jusqu’à la Porte de Livraison
La souscription d’une bande passante entre le Local FTTH de l’Abonné et la Porte de Livraison
Une composante Porte de Livraison qui correspond à la mise en place de l'interconnexion entre les réseaux du Fournisseur et du Client pour la livraison des lignes OPERA Office,
Tous les tarifs annoncés dans l'annexe sont en euros Hors Taxe et s’appliqueront à compter du 1° mai 2025.
2. TARIFS LIGNE OPERA OFFICE
Pour rappel la facturation est à terme à échoir sans pro-rata temporis, étant précisé que
le premier mois n’est pas facturé,
le mois de résiliation est facturé.
2. Composante Accès
FAS Abonnement mensuel
Par accès Office Basic 120 € 27 € **
Par accès Office Pro 60 € 25 € *
Par accès Office 100 Mbps 60 € 60 €
L'année de référence de l'indexation pour cette tarification est 2022.
(*) Le tarif pourra évoluer annuellement par indexation dans la limite de 75% de la dernière variation annuelle de l'indice du coût du travail - Coût horaire - Information, communication (NAF rév.2 section J) - Base 100 en 2020 (identifiant 010762010). La révision dudit tarif donne lieu à la publication d’un nouveau millésime applicable.
Lorsque le Fournisseur décide d'appliquer l’évolution annuelle des tarifs au titre de ladite indexation, il utilise comme référence le dernier indice publié et l'évolution sur une année de cet indice.
A titre d'exemple : si lors de la mise à jour du tarif, le dernier indice publié est celui du 3°" trimestre de l'année N, alors le nouveau tarif de l'abonnement mensuel sera au maximum égal à :
Ces tarifs intègrent la mise à disposition par le Fournisseur du Raccordement FTTH Passif nécessaire au raccordement du Local FTTH concerné.
O 3
2e
•
o
o
o
o
o
•
•
•
𝑇 1 = 𝑇 0 ∗ (1 + 0,75 ∗ [𝐼3𝑡(𝑁) − 𝐼3𝑡(𝑁−1) 𝐼
3𝑡(𝑁−1)
]) axione 152 avenue Pierre Brossolette Annexe | - Tarification OPERA Office
— 92240 Malakoff
(**) Le tarif pourra évoluer annuellement sur la base des indices de référence INSEE ICT (001565183) et ICC du coût de la
construction (ICC 000008630), selon la formule suivante :
F Î F Î
L ] L ]
Etant entendu que :
Indice N = dernier indice mensuel publié à la date de révision
Indice N-1 = indice mensuel publié 12 mois avant l'Indice nouveau.
2.2 Composante Porte de Livraison
La Composante Porte de Livraison correspond à la mise en place de l'interconnexion entre les réseaux du Fournisseur et du Client pour la livraison des lignes OPERA Office. Cette interconnexion est réalisée dans un POP du Fournisseur.
Porte de livraison - Niveau 3 FAS
Porte de livraison — Interface 10G-LR 4 500 €
2.3 Prestations optionnelles
2.31 Option de GTR 10 Heures Ouvrables
L'option de GTR 10H n'est pas disponible pour les produits OPERA Office Basic et OPERA Office 100 Mbps.
FAS Abonnement mensuel
Par accès Office Pro 70€ 15 €
Les FAS ne sont pas facturés lorsque l'Option GTR 10h est souscrite à la Commande de Ligne OPERA Office.
2.3.2 Prestation optionnelle d'installation de l'équipement terminal
Cette prestation correspond à une durée d'installation moyenne de 30 minutes au moment de la mise en service de la Ligne OPERA Office.
Cette prestation n'est pas disponible pour le produit OPERA Office Basic.
Prestation forfaitaire d'installation de l'Equipement Terminal mutualisée avec 50 €
le Raccordement du Local FTTH
2.4 Prestations sur le Raccordement Client Final
24.1 Bordereau de prix unitaire sur de la surlongueur
Création d’un Raccordement FTTH Passif sur une distance supérieure ou 2,00 €/ml au-delà du égale à 50 ml en domaine privé forfait
𝑇 1 = 𝑇 0 ∗ (1 + 0,33 ∗ [𝐼𝐶𝑇(𝑁) − 𝐼𝐶𝑇(𝑁−1) 𝐼𝐶𝑇
(𝑁−1)
] + 0,33 ∗ [𝐼𝐶𝐶(𝑁) − 𝐼𝐶𝐶(𝑁−1) 𝐼𝐶𝐶
(𝑁−1)
]) axione 152 avenue Pierre Brossolette Annexe | - Tarification OPERA Office
92240 Malakoff
Ces raccordements au-delà du linéaire contractuel ne feront pas l'objet d’une tarification supplémentaire sur la plaque FTTH de THD 42.
242 Prestation nouvelle intervention pour modification de l'emplacement du PTO
Suite à la demande d’un Utilisateur Final, le Client peut commander au Fournisseur une prestation de nouvelle
intervention chez l'Utilisateur Final afin de modifier l'emplacement du PTO actuellement en place et précédemment posé par le Fournisseur.
Prestation forfaitaire pour la modification de l'emplacement d'un PTO précédemment installé par le Fournisseur chez un Utilisateur Final 350 €
24.3 Remplacement du PTO
Le Client peut faire la demande au Fournisseur de remplacer le PTO en cas de dégradation de celui-ci.
Remplacement de PTO par le Fournisseur sur Accès Office Pro ou Office 100
Mbps 130 €
Remplacement de PTO par le Fournisseur sur Accès Office Basic 300 € CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
Annexe IA - Pénalités
GPERA pr - / 4 nl LE=
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Annexe |A — Pénalités OPERA Office — 92240 Malakoff
Table des matières
1. PENALITES A LA CHARGE DU CLIENT nr
1.1 Pénalités sur les commandes non conformes... inner
1.2 Pénalités sur les mises en service... inner
1.3 Pénalités SAV nn
2. PENALITES À LA CHARGE DU FOURNISSEUR mme
2.1 Pénalités sur les mises en Service... rennes
2.2 Pénalités de retard sur la mise à disposition du Line d'Accès auprès du Client Final. ss
2.3 Pénalités SAV nn axiIone 152 avenue Pierre Brossolette 92240 Malakoff Annexe IA - Pénalités OPERA Office
1. PENALITES A LA CHARGE DU CLIENT
Les pénalités à la charge du Client ne sont applicables que pour un taux de non-conformité supérieur à 5% des cas considérés sauf cas de déplacement du Fournisseur.
Le Fournisseur s'engage à notifier le Client de la survenance de non-conformités supérieures à ce taux préalablement à toute facturation de pénalités.
Toute notification du Fournisseur n'ayant pas donné suite de la part du Client à une remise en conformité
(soit un retour en dessous du taux de 5%) des commandes dans un délai d’un (1) mois suivant la notification rendra automatiquement exigibles les pénalités.
I.
1.3
Pénalités sur les commandes non conformes
Libellé Prestation Unité Montant unitaire
Pénalité forfaitaire pour commande Ligne OPERA Office A1€
non conforme
Pénalités sur les mises en service
Libellé Prestation Unité Montant unitaire
Pénalité de déplacement à tort — Ligne OPERA Office 120 €
Abonné absent
Pénalité pour commande d'installation
modifiée ou annulée à l'initiative du ee us pre 8 Commande modifiée
Client dans un délai inférieur à cinq (5) , / ou annulée dans un A1 € jours ouvrés de la date de rendez-vous pee v , 2 délai insuffisant d'installation prévue (à régler par le
Client au Fournisseur)
Pénalité pour refus d'intervention de Ligne OPERA Office 120 €
l'Abonné de l'Usager
Pénalité de déplacement à tort -
Annulation de commande après Commande annulée 120 €
déplacement du technicien
Pénalités SAV
En application des Conditions Particulières.
Libellé Prestation Unité Montant unitaire
Signalisation Pénalité de signalisation transmise à tort nn 125,77 € transmise à tort
Pénalité d'absence de l’'Abonné lors du Déplacement à tort 120 € rendez-vous
Pénalité Remise en Conformité de la Desserte Interne 350 €
Desserte Interne axione 152 avenue Pierre Brossolette Annexe |A — Pénalités OPERA Office — 92240 Malakoff
2. PENALITES A LA CHARGE DU FOURNISSEUR
2. Pénalités sur les mises en service
En application des Conditions Particulières.
Libellé Prestation Unité Montant unitaire
Pénalité Absence du Fournisseur Absence du 120 € Fournisseur
Pénalité pour commande d'installation
modifiée ou annulée à l'initiative du Commande modifiée
Fournisseur dans un délai inférieur à ou annulée dans un AI €
cinq (5) jours ouvrés de la date de délai insuffisant
rendez-vous d'installation prévue
2.2 Pénalités de retard sur la mise à disposition du Ligne d'Accès auprès du Client Final
En cas de non-respect des engagements tels qu'indiqués dans les Conditions Particulières, le Fournisseur s'engage à verser à la demande du Client, les pénalités ci-dessous :
Libellé Prestation Unité Montant Plafond
unitaire
Pénalité de retard sur le Ligne OPERA X*1€ 10€
raccordement Client Final Office
avec X = nombre de Jours Ouvrés de retard.
2.3 Pénalités SAV
Libellé Prestation Unité Montant unitaire
Pénalité d'absence du technicien lors Absence du 120 €
du RDV Fournisseur CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
Annexe IB - Bordereau travaux
complémentaires sur le domaine privé
SIL et “OFFICE
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Annexe IB - BPU Domaine Privé
— 92240 Malakoff
Table des matières
| Travaux sur le domaine privé. nn
2. INdeXAtiON nnnnnrrrrrrrrrrrrrrnrenranrrnraneaneanesnernranesneeneanesnesnesnesnesnesnesnesnrenesne enr ane ann aneanesnesneeneenreneeneaneaneanesnnaneenneneennenneneeneeneeneannennenneneennenneneenennnnenne
Conformément à l’article 3 des Conditions Particulières, la présente annexe n'est pas modifiable unilatéralement, sauf
dans les conditions prévues aux Conditions Particulières.
Tous les tarifs annoncés dans l'annexe sont Hors Taxe et sur la base des droits et redevances connus à la date de
publication de la présente annexe.
La tarification de référence du contrat de prestations dépend des travaux d’une part et de la Mandante d'autre part
selon la grille ci-dessous.
Certains travaux peuvent ne pas être indiqués dans la présente Annexe. Dans ce cas, les travaux feront tout de même
l’objet d’un devis du Fournisseur auprès du Client. axiIone 152 avenue Pierre Brossolette 92240 Malakoff
1. TRAVAUX SUR LE DOMAINE PRIVE
Annexe IB — BPU Domaine Privé
Mandante (s) Description Unité Tarif Unitaire
Forfait unitaire d'ouverture de chantier THD 59-62 ; o » ,
pour la création d'infrastructure d'accueil
LFP ; de génie civil en partie privative dans le Forfait 200,00 €
Sartel THD : cadre de la mise en service d'un
Raccordement abonné.
Création d'une d'infrastructure d'accueil
THD 59-62 : de génie civil en partie privative dans le
cadre de la mise en service d’un
LFP ; Raccordement Abonné ml 51,00 €
Sartel THD ;
Tranchée traditionnelle sous terrain naturel ou
stabilisé charge 0,4m.
Création d'une d'infrastructure d'accueil
THD 59-62 : de génie civil en partie privative dans le
cadre de la mise en service d’un
LFP ; Raccordement Abonné ml 167,00 €
Sartel THD ;
Tranchée traditionnelle sous chemin dallé ou
pavé charge 0,4m.
THD 59-62 ;
LFP : Création d'un percement supplémentaire Forfait 30,00 €
ou supérieur à 30 cm d'épaisseur.
Sartel THD ;
THD 59-62 ;
LFP : Création de cheminement en goulotte, Forfait 3,00 €
faux plancher ou faux plafond existants
Sartel THD ; axione 152 avenue Pierre Brossolette Annexe IB - BPU Domaine Privé
— 92240 Malakoff
2. INDEXATION
Le tarif pourra évoluer annuellement par indexation en prenant en compte la durée restante de la Convention de Délégation de Service Public.
Lorsque le Fournisseur décide d'appliquer l’évolution annuelle des tarifs au titre de ladite indexation, il utilise comme
référence le dernier indice publié et l’évolution sur une année de cet indice.
L'indexation sera calculée comme suit :
PI= PO x (0.15 + 0.85 x NAF al / NAF ao)
Où,
PI = coût révisé
PO = coût d’origine
NAF a0 = indice d’origine
NAF al = indice révisé
Pour la Mandante THD 59-62 :
L'indexation ne sera pas appliquée avant la 6°"° année de la Convention
NAF a0 = indice INSEE mensuel du coût horaire du travail révisé - Salaires et charges - Industries mécaniques et électriques (NAF rév. 2 postes 25-30 32-33) du dernier mois de la dixième année de la Convention
NAF al = dernier indice INSEE mensuel du coût horaire du travail révisé - Salaires et charges - Industries mécaniques et électriques (NAF rév. 2 postes 25-30 32-33) connu à la date de révision
Pour les Mandantes LFP et Sartel THD :
L'indexation ne sera pas appliquée avant la fin du Premier Etablissement de Réseau
NAF a0 = indice INSEE mensuel du coût horaire de travail révisé — réseaux de communication en fibre optique du dernier mois de la dixième année la Convention
NAF al = indice INSEE mensuel du coût horaire de travail révisé — réseaux de communication en fibre optique
connu à la date de révision.
-
-
-
-
-
- CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
Annexe 2A — STAS OPERA Office Basic
ST mm. “OFFICE
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Table des matières
|. Présentation du document... inner 3
2. Description du Service rennes 4
2.1 Description générale du Service... rennes 4
2.2 Schémas de principe ner 5
2.3 Classes de service rÉSEQU... nr rnrnnrnrnnrnnrnnrnnnnrnrnnnennnnnnnnnnennnnnnnnnnnnnnnnrnnnnnnnnnnnnnnnnnnnnnnnennnnnnnes 5
3. Infrastructure de collecte... sine 6
3.1 Collecte Point-MulItipoint..nnn rennes 6
3.1.1 SYnoOptIQUeE nn 6
3.1.2 Caractéristiques des éléments actifs inner 6
4. Interface d'accès au Service... nn 7
AU L'interface AbONNÉ nn 7
AIT Spécifications du port Ethernet de l'ONT rennes 8
4.1.2 Raccordement Abonné sur interface 10-BaseT ou 100-BaseT rennes 8
4.1.3 Raccordement Abonné sur interface 1000-BaseT inner 9
AÏA4 Spécifications IP. rennes 9
4.1.5 Format des trames prises en charge... inner 9
4.2 L'interface de Livraison... inner 10
4.21 Spécification des interfaces Physiques rennes Il
4.2.2 Interconnexion IP. rennes (l
5. Architecture de service... rennes 12
5.1 Principe et modélisation de la livraison L2TP nn 12
5.2 Tunnel L2TP rennes 14
5.3 Format de l'identifiant et du mot de passe Ghonné.... rennes 14
5.4 Adressage IP des abonnés... rennes 15
5.5 Profil de QoS Abonné PPP nn 15
5.51 Trafic descendant... iirrenennenennnenennnennnnneneeenennnnneeneenennnnennnnes 15
5.5.2 Trafic montant... inner 15
5.6 RADIUS nn rrrnrnrnnrnnrnnnnnrnrnnnnnnnnrnnnennnnnnnnnnennnnnnnnrnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnennnnnnnnnennennnnnnnnnnee 16
5.6.1 Proxys RADIUS Fournisseur et serveur RADIUS Client... nn 16
5.6.2 Attributs RADIUS échangés rennes 16
5.7 Synthèse des échanges pour l'établissement d'une session... ire 19
Annexe | : Glossaire... rennes 20 axiIone 152 avenue Pierre Brossolette Annexe 2A - STAS OPERA Office Basic — 92240 Malakoff
Liste des Figures
Figure 1 - Schéma de principe... nn ns 5
Figure 2 - Modélisation ODN......nn nn 6
Figure 3 - Interfaces de Service... nn 7
Figure 4 - Connecteur femelle RI45 rm 8
Figure 5 - Sécurisation de l'interface de Collecte... nn 10
Figure 6 - Architecture PPP livrée en L2TP
Figure 7 - Transport session PPP dans tunnel L2TP.
Figure 8 - Synthèse des échanges pour la création d'une session PPP-L2TP.
Liste des Tableaux
Tableau 1 - Liste des flux transportés. 4
Tableau 2 - Caractéristiques de l'interface de service Abonné
Tableau 3 - Appairage et Brochage du connecteur pour interface 10 Base-T ou 100 Base-T..
Tableau 4 - Appairage et Brochage du connecteur pour interface 1000 Base-T nine 9
Tableau 5 - Caractéristiques de l'interface de Livraison nn Il
Tableau 6 - Attributs BGP des préfixes échangés... inner 12 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
I. PRESENTATION DU DOCUMENT
Ce document décrit les conditions techniques d'accès au service OPERA Office Basic.
Il se compose des parties suivantes :
Présentation du Service ;
Description de l'infrastructure de collecte ;
Description des interfaces de livraison (abonné et collecte) ;
Gestion des abonnés ;
Echanges RADIUS entre le Client et le Fournisseur ;
Règles de Quality Of Service (GQoS).
Le respect des conditions décrites dans le présent document est fondamental pour la garantie de fourniture du service par le Fournisseur. Le Fournisseur ne pourrait pas garantir la fourniture du service dans le cas de non-respect de ces conditions.
Dans ce document les termes « Client », « Abonné » et « ONT » ont la signification suivante :
Client : fait référence au Client ou l'usager utilisant les infrastructures de collecte et transport du Fournisseur afin de délivrer un service à ses utilisateurs ;
Abonné : fait référence à un utilisateur final de type professionnel ayant souscrit un service auprès du Client ;
ONT : Optical Network Terminal, fait référence à l'équipement de terminaison PON installé chez l'abonné.
2. DESCRIPTION DU SERVICE
2. Description générale du service
Le service OPERA Office Basic est une offre de collecte de trafic depuis des Locaux FTTH permettant à un opérateur de services, client du Fournisseur, d'assurer le raccordement et la collecte de ses abonnés professionnels à travers les infrastructures fibres optiques.
L'offre comprend le transport du trafic IP unicast Abonné jusqu'au site de livraison défini conjointement par le Client et le Fournisseur.
Le trafic IP unicast Abonné est acheminé, selon les règles de transport et d'authentification énoncées ci-dessous :
Service Accès Transport / Identification Authentification Abonné (à Abonné Livraison Client faire par le Client)
Data PPPOE L2TP sur Basée sur le RADIUS : Identifiant / mot de Ethernet Realm passe
Tableau 1 - Liste des flux transportés
Les caractéristiques du service sont les suivantes :
Livraison du service chez l’Abonné sur une interface Ethernet ;
Débit d'accès de la OPERA Office Basic permet au Client, selon les caractéristiques des infrastructures optiques, de proposer des services Data avec des débits asymétriques et non garantis jusqu'à 1 Gbits/s dans le sens
descendant, et jusqu'à 500 Mbits/s dans le sens montant. Cependant AXIONE garanti 20Mbits/s dans les deux sens ;
Identification de l’'Abonné basée sur le Realm de l'identifiant PPP ;
Collecte PPPOE et livraison en L2TP ;:
Adressage Abonné IPv4, IPvé ou dual stack IPv4/1Pvé6 géré par l'opérateur Client ;
•
•
•
•
•
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Ségrégation du trafic dans un contexte MPLS/VPN dans le réseau du Fournisseur ; Point d’interconnexion avec le réseau du Client :
Porte de livraison Nationale, située dans un POP Fournisseur ou dans un POP opérateur Tiers éligible au service ;
Redondance possible avec une seconde porte de même catégorie.
L'accès Abonné est basé sur un modèle Point-Multipoint avec une technologie PON.
2.2 Schémas de principe
Interface abonné
Réseau de
Collecte
Figure 1 - Schéma de principe
Les infrastructures d'accès Point-Multipoint sont en liaison avec un réseau de collecte Ethernet (Eth/MPLS) pour joindre les BNGs du Fournisseur. Elles s'appuient d'une part sur des équipements de commutation Ethernet, tels que ONT/OLT pour l'accès, et d'autre part sur des équipements de commutation de labels MPLS pour la collecte.
Dans ces réseaux de collecte Ethernet, le cloisonnement des flux Client est assuré par l'implémentation d'une instance de commutation dont une des spécificités est d'interdire l'échange de trafic entre Abonnés.
Les équipements de commutation Ethernet ainsi que ceux du domaine Eth/MPLS apprennent les adresses MAC tel que décrit dans les standards IEEE 802.1D et RFC 4762.
Les BNGs ont pour rôle d'appliquer la limitation de débit des abonnés et d'établir un tunnel L2TP (rôle LAC) jusqu'au LNS Client.
Les collectes d'abonné sont gérées par 2 BNGs nationaux redondants en mode active/active.
2.3 Classes de service réseau
L'offre OPERA Office Basic, ne comprend qu'une seule classe de service Best Effort. Le réseau du Fournisseur ne prend
pas en compte le marquage Client. Tous les flux sont transportés en Best Effort dans le réseau du Fournisseur.
•
•
o
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
3. INFRASTRUCTURE DE COLLECTE
3. Collecte Point-Multipoint
3.1.1 Synoptique
Les arbres PON peuvent adresser de 16 à 128 abonnés au maximum. Certains arbres PON peuvent être restreints à 16
abonnés afin de servir les Points de Mutualisation les plus éloignés de leur NRO et préserver le budget optique total des lignes des abonnés. Le schéma ci-après modélise quelques exemples de solutions de raccordement possibles des abonnés sans en dresser la liste exhaustive :
= Connecteur (soudé)
@ soudure
Repoplique
smielatetelelats/atstatelate [als
Abonné
Rep optique
OOUOOOOOOOON OOODOOOODON X)OQID) BO0000OOOOOONOD MOO0O0O00O0CIONC
PM
Abonné
ER r (er-—1s Rep optique Ol
NRO
Figure 2 - Modélisation ODN
Les NRO peuvent prendre le rôle de PM afin de raccorder des abonnés.
L'utilisation de coupleurs 1:8, 1:16, 1:32 ou 1:64 dans les points de mutualisation est fonction de la distance PM / NRO.
3.1.2 Caractéristiques des éléments actifs
3.1.2.1 ONT
L'ONT est un équipement d'intérieur pourvu d’une alimentation externe en 220v AC. L’Abonné doit fournir une prise électrique permettant son alimentation.
C'est un modèle Bridge Ethernet dont les ports ont les caractéristiques suivantes :
Port optique avec connecteur SC-APC ;
Port cuivre gigabit-Ethernet par interface Abonné.
3.1.2.2 OLT
O LE
•
• axiIone
L'OLT est une plate-forme multiservices de haute capacité dont l'architecture du châssis permet de satisfaire aux besoins actuels et futurs. De fait, elle est adaptée au marché des services résidentiels ou entreprises hauts débits (FTTH, FTTB,
152 avenue Pierre Brossolette
92240 Malakoff
Annexe 2A — STAS OPERA Office Basic
FTTO) tout en permettant de déployer simultanément plusieurs technologies d'accès basée sur la fibre optique.
L'OLT supporte les types d'accès listés ci-après :
GPON ;
EPON ;
NG-PON (XG-PON, XGS-PON... :
P2P Fast-Ethernet/Gigabit-Ethernet/TenGigabit-Ethernet.
À. INTERFACE D'ACCES AU SERVICE
Le service OPERA Office Basic définit deux interfaces permettant, d’une part, le raccordement de l'installation Abonné
(interface Abonné), et d'autre part, l'interconnexion entre le Client Opérateur de services et celui du Fournisseur (interface de Livraison).
Interface Aboñté
4. L'interface Abonné
Figure 3 - Interfaces de service
Interface de
ivraison
L'interface Abonné est de type cuivre, son débit peut prendre les valeurs 10 Mbps, 100 Mbps ou 1000 Mbits/s.
Les types d'interfaces d'accès supportées sont listés dans le tableau ci-dessous :
Topologie |Type Debit Média Portée Connecteur Normes Interface | interface (mètres)
Point- 1000- 1000 Mbit/s |4 paires de cuivre |100m IEEE 802.3ab Multipoint |BaseT Impédance 100
GPON Oh
TS ISO/IEC 8802.3
Câble UTP 6
Point- 100-BaseT 100 Mbit/s |2 paires de cuivre |100m IEEE 802.3u
Multipoint Impédance 100
GPON Ohms RI-A5 ISO/IEC 8802.3
Câble UTP 5
minimum ISO 8877
•
•
•
• axione 152 avenue Pierre Brossolette
92240 Malakoff
Annexe 2A — STAS OPERA Office Basic
Point- 10-BaseT 10 Mbit/s |2 paires de cuivre |100m (support for IEEE 802.3i
Multipoint Imoéd 100 automatic GPON One inversion MDI
/ MDKX) ISO/IEC 8802.3
Câble UTP 5
Tableau 2 - Caractéristiques de l'interface de service Abonné
Remarque :
L'indication de portée est conforme au standard ISO/IEC 8802.3. Il conviendra de tenir compte des pertes inhérentes aux divers points de coupure (répartiteurs, catégorie des câbles et des jarretières utilisées) et de recalculer la longueur maximale admissible.
Le connecteur est de type ISO 8877 (RJ 45) femelle, il est présenté par la figure suivante :
12345678
Di
Figure 4 - Connecteur femelle RJ45
AIT Spécifications du port Ethernet de l'ONT
Les caractéristiques physiques de l'interface Ethernet sont :
Interface Cuivre ;
Connecteur RIJ-45 femelle ;
Vitesse auto : 10/100/1000 Mbit/s ;
Port MDI / MDI-X avec détection automatique du câble droit ou croisé.
A.I.2 Raccordement Abonné sur interface 10-BaseT ou 100-BaseT
Appairage des paires de cuivre et le brochage du connecteur sont présentés dans les tableaux ci-dessous :
Media Paires utilisées
2 paires (1; 2)et(3;6)
] TxD + ———+ |]Transmission de données vers l'équipement terminal (+)
2 TxD - —— |Jransmission de données vers l'équipement terminal (-)
3 RxD + æ—— |Réception de données provenant de l'Equipement Terminal (+)
4 NC Non utilisé
5 NC Non utilisé
6 RxD - æ—— |Réception de données provenant de l'Equipement Terminal (-)
7 NC Non utilisé
8 NC Non utilisé
Tableau 3 - Appairage et Brochage du connecteur pour interface 10 Base-T ou 100 Base-T
O
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Le raccordement de l'équipement Abonné doit être réalisé avec un câble dont les caractéristiques sont au moins équivalentes à la catégorie 5.
L'interface Ethernet de l'équipement Abonné doit être conforme à la norme IEEE 802.3u (100-BaseT) ou IEEE 802.3i (10-
BaseT).
A.1.3 Raccordement Abonné sur interface 1000-BaseT
Appairage des paires de cuivre et le brochage du connecteur sont présentés dans les tableaux ci-dessous :
Media Paires utilisées
À paires (1:2)(3;:6)(4;5)et(7;8)
BILDA+ | >» | paire Bi-directionnelle À + —
BI_DA- é—+ | paire Bi-directionnelle A -
BI_DB+ ——— | poire Bi-directionnelle B +
BI_DC+ <— | paire Bi-directionnelle € +
BI_DC- e— | poire Bi-directionnelle C -
Bl_DB- *— | paire Bi-directionnelle B -
BI_DD+ t—+ | paire Bi-directionnelle D +
©O|
|
|
C1]
|
©)
N
BI_DD- *—+ | paire Bi-directionnelle D -
Tableau 4 - Appairage et Brochage du connecteur pour interface 1000 Base-T
Le raccordement de l'équipement Abonné doit être réalisé avec un câble dont les caractéristiques sont équivalentes à la catégorie 6.
L'interface Ethernet de l'équipement Abonné doit être conforme à la norme IEEE 802.3ab (1000-BaseT) et configurée en mode auto-négociation avec une vitesse de transmission de 1000 Mbits/s.
414 Spécifications IP
L'IAD Client ne doit pas envoyer vers le réseau des paquets IP avec une taille supérieure à 1500 octets.
4.1.5 Format des trames prises en charge
Les trames envoyées par lIAD Client doivent correspondre à la norme IEEE 802.1Q et doivent avoir le format suivant :
Ta Type/ DA 0 _ ds Data FCS
(6 (6 Length |
octets) | octets) | (4 octets) (2 octets) (46 à 1 500 octets) (4 octets)
La taille du tag 802.1Q est de 4 octets et se décompose de la façon suivante : axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
En
D Me
TPID est un champ de contrôle définissant le type de tag. La valeur de ce champ doit être fixée à 0x8100 ;
TCI est constitué de 3 éléments :
3 bits User-Priority définis par l'IEEE 802.1P. Ces 3 bits doivent être fixés à 0 ;
1 bit CFI (Canonical Format Indicator) qui détermine si le tag s'applique à une trame de type ethernet ou token-ring. Ce bit doit être à 0;
12 bits VID (VLAN Identifier) pour identifier le numéro du VLAN auquel la trame appartient, soit au total 4 096 VLANSs. Le VID doit être à 4001.
A.2 L'interface de Livraison
L'interface de Livraison livre l'ensemble du trafic montant et descendant des abonnés sur le réseau de l'opérateur Client.
Elle est matérialisée par une ou plusieurs portes de livraison situées dans des points de présence du Fournisseur.
Le Client a la possibilité de souscrire au maximum deux portes. Lorsque le trafic est livré sur deux portes, il n’y a pas de partage de charge : une porte nominale et une porte de secours. La porte de secours peut avoir un débit inférieur à la porte nominale.
Figure 5 - Sécurisation de l'interface de Collecte
Afin d'autoriser la cohabitation des flux Unicast Abonné et les échanges RADIUS, des interfaces logiques (VLAN) distinctes sont définies sur l'interface de collecte :
O 10
•
•
o
o
o
TPID (2 octets)
Ethertype 0x8100 TCI (2 octets)
Tag 802.1Q
(4 octets)
CFI Vlan-ID User-Priority IEEE 802.1p
3 bits 1 bits 12 bits axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Un VLAN Data ;
Un VLAN RADIUS.
L'interface de livraison peut être composée de plusieurs ports physiques, dans ce cas le protocole LACP devra être configuré par le Client.
421 Spécification des interfaces physiques
Seul l'accès fibre optique est disponible, les caractéristiques de l'interface sont les suivantes :
Debit à Type Normes Type Interface | ;hterface Média (mtres) . Connecteur
IEEE 802.3z
1000Base-LX |1Gbit/s |FiPre Optique |Kks |Duplex |LC/PC Monomode ISO/IEC 8802.3
10GBase-LR |10 Gbits/s |Fibre Optique Ki [Duplex |LC/PC IEEE 802.30e Monomode
Tableau 5 - Caractéristiques de l'interface de Livraison
Remarque :
L'indication de portée est conforme au standard ISO/IEC 8802.3. Il conviendra de tenir compte des pertes inhérentes aux divers points de coupure (répartiteurs optiques, pertes liées aux connecteurs des jarretières) et de recalculer la longueur maximale admissible.
Sur ces interfaces, le client ne doit pas activer de mécanismes de spanning-tree. Il ne doit pas envoyer de paquets BPDU sur le port d'interconnexion.
A2.2 Interconnexion |P
Comme spécifié au paragraphe 4.2, deux VLANSs sont définis sur les interfaces de Livraison afin de séparer les échanges RADIUS des flux Data :
Un VLAN Data pour le transport des flux data des abonnés ;
Un VLAN RADIUS pour les échanges RADIUS.
Les numéros de VLAN sont spécifiés dans la fiche d’interconnexion.
Deux réseaux IP d'interconnexions sont nécessaires pour acheminer les échanges RADIUS et les flux Data :
Un réseau en adressage ip publique IPv4 de type /30 ou /31 pour l’interconnexion RADIUS :
Un réseau en adressage ip publique ou privée |Pv4 de type /30 ou /31 pour le VLAN Data Unicast.
Pour les adressages IP publiques, le Client doit disposer d’un numéro d’AS public.
Une session eBGP est établie entre le Fournisseur et le client ISP au niveau de chaque VLAN de l'interface de Livraison.
4.2.2.1 Caractéristiques de la session eBGP data
Adressage IP fourni par le client ISP ;
La fonctionnalité GTSM (RFC 5082) peut être activée pour sécuriser à minima la session eBGP en contrôlant qu'elle est établie avec le premier équipement IP joignable par cette interconnexion ;
La fonctionnalité BFD peut être activée pour optimiser la durée de détection de la perte de la session eBGP ;
Le Fournisseur annonce les préfixes BGP contenant les adresses IPv4 de ses LAC ;
Le Client annonce les préfixes BGP contenant les adresses IPv4 de ses LNS ;
•
•
•
•
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Le Fournisseur appliquera un filtre sur les annonces BGP-4 du Client pour autoriser uniquement les adresses faisant partie des blocs d'adresses LNS préalablement déclarés par le Client ;
Les communautés utilisées par le client seront ignorées sur le réseau du Fournisseur.
4.2.2.2 Caractéristiques de la session eBGP RADIUS
Adressage IP fourni par le client ISP ;
La fonctionnalité GTSM (RFC 5082) peut être activée pour sécuriser à minima la session eBGP en contrôlant qu'elle est établie avec le premier équipement IP joignable par cette interconnexion ; La fonctionnalité BFD peut être activée pour optimiser la durée de détection de la perte de la session eBGP ; Le Fournisseur annonce les adresses IPv4 de ses Proxy RADIUS ;
Le Client annonce les adresses IPv4 de ses serveurs RADIUS ;
Le Fournisseur appliquera un filtre sur les annonces BGP-4 du Client pour autoriser uniquement les adresses faisant partie des blocs d'adresses des serveurs RADIUS préalablement déclarés par le Client ;
Les communautés utilisées par le client seront ignorées sur le réseau du Fournisseur ;
A.2.2.3 Attributs BGP
Les routes annoncées en BGP par le Client auront l’attribut local-preference positionné de la manière suivante sur les interfaces de livraison :
Nominale 200
Secours 100
Tableau 6 - Attributs BGP des préfixes échangés
De la même façon, le Client devra marquer avec une locale préférence plus grande les routes apprises sur les interfaces de livraison nominale.
5. ARCHITECTURE DE SERVICE
5. Principe et modélisation de la livraison L2TP
Figure 6 - Architecture PPP livrée en L2TP
Le Fournisseur transporte les sessions PPP initialisées par les IAD jusqu'à l'interface de livraison. Les sessions sont ainsi prolongées et livrées à travers des tunnels L2TP (Layer 2 Tunnelling Protocol - RFC-2661) jusqu'au réseau du client.
Le Fournisseur dispose de BNGs redondants qui jouent le rôle de LAC. Les tunnels L2TP sont établis en IPv4 entre les
BNGs et un ou plusieurs LNS client.
O 12
•
•
•
•
•
•
•
•
•
ONT
PEs de
Livraison Infra PON
OLT BNG
Interfaces de
livraison
Interface Abonné
Réseau
Client
LNS
Primaire
Client
PE
LNS
Backup
Porte Nominale
Porte Secours
BNG
Tunnel L2TP
Session PPP IAD
Abonné axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
En préalable à l'établissement des tunnels L2TP et des sessions PPP, une vérification du Realm de l'identifiant PPP de l’abonné est faite par le Fournisseur pour lui permettre d'identifier le Client. Un dialogue RADIUS est nécessaire entre le Fournisseur et le Client permettant d'échanger les informations nécessaires à l'établissement des tunnels L2TP. Il incombe
au Client de gérer l’authentification et la configuration des IAD Abonné.
Ces deux mécanismes permettent un partage des responsabilités entre le Fournisseur et le client :
Le Fournisseur a la charge du transport des sessions PPP depuis les sites Abonné jusqu'à l'interface de livraison ;
Le Client est responsable de l’authentification des IAD, la terminaison des sessions PPP des abonnés et leur configuration (assignation d'adresse IP, ….).
Le schéma ci-après modélise les couches protocolaires mises en œuvre :
> IP +
session PPP Tunnel L2TP
+ Cle = 5 < session PPPoE »
a LS sr { = = + er ) Î ‘ pee « !
> =, L 4 « _—_—.......….— )
up KD or sens ce VPN IP ISP ) | Es ISP
PM PPPOE-IA LAC D DES LNS*.—— s \
PPPOE-IA = PPPOE Intermediate Agent Proxy-Radius Radius-ISP L2TP = Layer 2 Tunnelng Protocol Fournisseur LAC = L2TP Access Concentrator
LNS = L2TP Network Server
10/N*10/100GigE 10/N*10/100GigE
Figure 7 - Transport session PPP dans tunnel L2TP
Pour chaque abonné, une session L2TP est créée à l'intérieur du tunnel. Cette session est négociée au moment de prolonger la session PPP jusqu'au LNS du Client (i.e. une fois que le BNG a autorisé l’abonné),.
Une fois le tunnel et la session établis, la session PPP entre l'Abonné et le Client peut être initialisée de façon complètement transparente pour le Fournisseur.
L'initialisation de la session PPP se déroule comme suit :
L'IAD initie une session PPPOE pour découvrir les BNG susceptibles de le prendre en charge ; L'IAD initie une session PPP qui est interceptée par le BNG ;
Le BNG demande à l'IAD de s'authentifier ;
L'IAD envoie les paramètres d'authentification (identifiant / mot de passe) au BNG ; Le BNG envoie une requête RADIUS d'autorisation au Proxy RADIUS Fournisseur ; Le Proxy RADIUS Fournisseur transmet la requête au serveur RADIUS du Client ; Le serveur RADIUS du client authentifie l'IAD et envoie un message d'autorisation au BNG (relayé par le Proxy RADIUS Fournisseur) ;
Le BNG prolonge la session PPP jusqu'au LNS du Client à travers un tunnel L2TP ; 9. L'IAD s'authentifie auprès du Client et récupère ses paramètres réseaux.
NOURWN—
œ
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
5.2 Tunnel L2TP
Le tunnel L2TP est créé entre deux équipements : le LAC (L2TP Access Concentrator) et le LNS (L2TP Network Server).
La fonction de LAC est assurée par un équipement Fournisseur identifié par une adresse IP publique ou privée que le Client aura fournie dans la fiche d'interconnexion.
La fonction de LNS doit être assurée par un équipement sous la responsabilité du Client. Le LNS est identifié par une
adresse IP publique ou privée que le client aura fournie dans la fiche d’interconnexion.
La méthode de Tunnel L2TP implique plusieurs protocoles (PPP/L2TP/UDP/IP) pour transporter les paquets IP des abonnés à travers les réseaux Fournisseur et Client. La décomposition de cette surcouche est précisée ci-après :
Entête PPP = 4 voire 8 octets max ;
Entête L2TP = 16 octets max ;
Entête UDP (port 1701) = 8 octets :
Entête IP = 20 octets.
La surcouche protocolaire entraine par conséquent un overhead de 52 octets maximums pour le trafic IP des abonnés et 44 octets en considérant uniquement le transport des sessions PPP pour le présent service.
Aussi, afin de se prémunir de problème MTU, l'interface du LNS ainsi que celle du LAC sur laquelle est monté le tunnel L2TP doit avoir une MTU égale à 2000. Les équipements intermédiaires (entre le LAC et le LNS) doivent avoir aussi une MTU supérieure ou égale à 2000.
Le tunnel L2TP doit être établi dynamiquement : le serveur RADIUS du Client communique les informations nécessaires à son établissement. L'établissement du tunnel suit le processus suivant :
Un IAD abonné lance une demande de connexion via une requête PPP ;
Sur réception de cette requête, le Fournisseur envoie un message RADIUS access_request au serveur RADIUS du Client ;
Le serveur RADIUS du Client répond par un message access_accept précisant le tunnel L2TP dans lequel transporter la session PPP de l'abonné ;
Dans le cas où le tunnel n'est pas encore créé, le LAC Fournisseur négocie l'établissement du tunnel L2TP avec le LNS du client.
Une sécurisation du LNS peut être mise en place. Pour cela, le client doit disposer d’un LNS primaire et d’un LNS de backup. Les attributs L2TP du message RADIUS « access-accept » doivent, dans ce cas, être tagués. Le Fournisseur prendra en compte l’attribut « tunnel-preference » pour identifier le LNS primaire. En cas d'échec lors de la tentative de création du tunnel sur le LNS primaire, le tunnel sera monté sur le LNS de backup.
5.3 Format de l'identifiant et du mot de passe abonné
Le Client doit identifier ses abonnés sur la base de leur identifiant PPP.
Lors de la phase d'authentification, l'abonné se présente à travers le couple « identifiant / mot de passe » attribué par le Client. Le protocole d'authentification CHAP devra être utilisé pour l'authentification des abonnés.
Le format de l'identifiant devra être composé d'un maximum de 50 caractères et avoir le format
est une valeur alphanumérique. La chaîne de caractère doit contenir au moins un caractère ;
est une valeur alphanumérique qui identifie le Client. Le Client indique au moment de la commande le « Realm » à utiliser. Le Realm doit respecter les règles suivantes :
Le Client ne doit pas utiliser un identifiant correspondant à un terme déposé à l'ICANN (Internet Corporation for Assigned Names and Numbers) ;
Le Client ne pourra pas utiliser un Realm s'il est déjà utilisé par un autre Client ;
Il doit terminer par le suffixe « .ohb2.axione.fr », en fonction de l'éligibilité (où est le nom du Client).
•
•
•
•
•
•
•
•
•
•
o
o
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Le Fournisseur se base sur la partie pour identifier les requêtes du Client. Le Client a la possibilité d'ajouter des caractères avant le suffixe mais dans ce cas il devra utiliser le séparateur «.>» afin d'obtenir un suffixe au format « *..ohb.axione.fr » ou « *..ohb2.axione.fr ».
| @|
50 caractères au maximum
Le « mot_de_passe » utilisé par le client pour identifier un abonné devra être une valeur en alphanumérique.
Le Fournisseur définit un caractère alphanumérique comme tout caractère alphabétique de À à Z ou chiffre de O à 9. Un
même caractère en majuscule et minuscule représente deux caractères alphabétiques différents.
5.4 Adressage IP des abonnés
Les IAD peuvent être adressés en IPv4, IPv6 ou dual stack IPv4/1Pvé.
Le choix des adresses des IAD Abonné est de la responsabilité du Client. Le Fournisseur ne participe pas au routage des
adresses du Client.
5.5 Profil de QoS Abonné PPP
Un seul profil QoS est disponible pour cette offre. Ce profil QGoS ne comprend qu'une seule classe de service Best Effort. Un PIR global est défini pour l’'abonné pour l'ensemble des files d'attentes. Tout le trafic Abonné doit être transporté en Best Effort.
Les valeurs de ce profil sont données dans le tableau ci-dessous :
DATA OM 500M OM 1G
Le débit pour un abonné est : IGbps / 500Mbps.
5.51 Trafic descendant
Dans le sens Client vers l’Abonné, afin de respecter le marquage, le Client devra placer la valeur des 3 bits de poids fort du champ DSCP (ou IP Precedence) de l’entête IP des paquets de l’Abonné dans l'entête IP ajoutée et utilisée pour la session L2TP à O.
5.5.2 Trafic montant
Dans le sens Abonné vers Client, afin de respecter le marquage, le CPE abonné devra marquer la valeur des 3 bits de poids fort du champ DSCP (ou IP Precedence) à 0.
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
5.6 RADIUS
5.6.1 Proxys RADIUS Fournisseur et serveur RADIUS Client
Le Fournisseur dispose d'un proxy RADIUS qui relaye les flux RADIUS (authentification et accounting) des abonnés jusqu'aux serveurs RADIUS du client. Le Client est responsable de l’authentification et du comptage.
Le Client peut installer un ou plusieurs serveurs RADIUS pour l’authentification des abonnés et un ou plusieurs serveurs pour le comptage. Le partage de charge entre les différents serveurs est possible sur le proxy RADIUS Fournisseur. L'algorithme Round Robin permet de distribuer uniformément les requêtes sur les différents serveurs RADIUS.
Le Client peut regrouper la fonction d'authentification et comptage sur les mêmes serveurs RADIUS.
Lors de la souscription au service, le client communiquera au Fournisseur :
L'adresse IP publique du ou des serveurs RADIUS d’authentification ;
L'adresse IP publique du ou des serveurs RADIUS de comptage ;
Le secret RADIUS (mot de passe partagé entre le Serveur RADIUS et le Proxy RADIUS).
Le Client et le Fournisseur devront convenir d'un numéro de port UDP à utiliser pour les communications RADIUS entre le
Proxy RADIUS et le serveur RADIUS. Le Fournisseur propose l'utilisation du port standard UDP 1812 pour l'authentification et 1813 pour le comptage.
Mécanisme Status-Server :
La fonctionnalité Status-Server (RFC 5997) doit être activée sur les serveurs Radius Client. Cette fonctionnalité est une extension du protocole RADIUS permettant à un client radius (ici les proxys RADIUS Fournisseur) de vérifier l'état opérationnel d'un serveur radius (ici les serveurs RADIUS Client). Il faut noter que ce mécanisme n'est pas équivalent à un "Keep Alive" permanent et transmis à travers un Access-Requets (RFC2865), mais est déclenché par le client radius lorsque le serveur radius est soupçonné d'être indisponible.
Sur l'absence de réponse à un Access-Request, le client radius envoie immédiatement un message status-server et détermine ensuite l'état opérationnel ou l'accessibilité du serveur par la réception ou l'absence de réponse de ce dernier
au message status-server.
Dans le cas d'un radius client disposant de serveurs redondants, un tel mécanisme permet de détecter l'inaccessibilité d'un serveur et solliciter immédiatement un autre serveur sans attendre plusieurs requêtes et l'expiration d'un timeout.
Les messages status-server sont transmis au serveur radius à travers un Access-Request où un Accounting-Request.
Le radius serveur répond par un message de type Access-Accept (authentication port) ou Accounting-Response (accounting port) aux sollicitations de type request Authenticator.
Sonde Radius :
Le Fournisseur dispose d’un serveur sonde RADIUS pour effectuer des statistiques de joignabilité RADIUS avec le serveur RADIUS client.
Lors de la souscription au service, le client communiquera au Fournisseur :
Un couple « User-name » / « User-password » dédié à la sonde RADIUS ;
Le secret RADIUS (par défaut il sera identique à celui partagé entre le Serveur RADIUS et le Proxy RADIUS).
Le Client devra, au même titre que pour les proxys RADIUS du Fournisseur, autoriser la sonde RADIUS à interroger son ou ses serveurs RADIUS.
5.6.2 Attributs RADIUS échangés
Les échanges entre le Proxy RADIUS Fournisseur et les serveurs RADIUS du client sont détaillés ci-dessous. Les attributs RADIUS mentionnés sont définis dans les RFC 2865 et 2868 pour l'authentification et RFC 2866 et 2867 pour le comptage.
O 16
LE
•
•
•
•
• axiIone 152 avenue Pierre Brossolette Annexe 2A - STAS OPERA Office Basic — 92240 Malakoff
Remarque : La liste des attributs radius spécifiés dans les messages ci-après n'est pas exhaustive et peut présenter des différences avec la réalité. axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
5.6.2.1 Access-Request
Ce message est émis par le Proxy RADIUS Fournisseur vers le serveur RADIUS Client.
User-name ] Nom de l’abonné Voir paragraphe 5.3
NAS-IP-Address |4 Adresse IP du BNG XXXDIIXXX Fournisseur
Interface logique de collecte du BNG NAS-Port-ID 87 NAS port ID er / associée à l'abonné
Service-Type 6 Type du service Framed
Fromed-Protocol 7 Indique la trame à utiliser ppp
pour l'accès par trame.
Acct-Session-Id A4 Identifiant de la session Session ID
CHAP-Password 8 Mot de Passe CHAP de Password l'abonné
CHAP-Challenge 60 Challenge CHAP Challenge
5.6.2.2 Access-Accept
Dans le mode dynamique, le serveur RADIUS du client envoie au BNG les paramètres nécessaires à la création ou à identification du tunnel L2TP. Le tableau ci-dessous liste les attributs RADIUS spécifiant le tunnel L2TP à utiliser. Ces attributs sont ajoutés au message « access_accept » envoyé par le serveur RADIUS du client.
Tunnel-Type 64 Type de tunnel à établir : valeur fixée à 3 pour L2TP
Tunnel-Medium-Type 65 Type de protocole de transport : valeur fixée à 1 pour IPv4
Tunnel-Server-Endpoint 67 Adresse IP du LNS terminant le tunnel L2TP
Tunnel-Assignment-ID 82 Cet attribut détermine l’identificateur du tunnel L2TP qui sera ultérieurement utilisé par le BNG pour
déterminer le tunnel à utiliser pour le transport de
chacun des paquets des abonnés. Ce champ doit
contenir l'adresse IP du LNS.
Le Client peut envoyer la description de 2 tunnels. Les attributs doivent dans ce cas être tagués conformément à la RFC 2868. Pour chaque tunnel, le client doit renseigner l'attribut « tunnel-préférence ». Le BNG Fournisseur prend en compte cet attribut pour identifier le tunnel L2TP primaire et le tunnel L2TP de Backup (le tunnel primaire est celui ayant la préférence la plus faible).
Caractéristiques de l’attribut « Tunnel-Preference » :
Tunnel-Preference 83 Préférence permettant de définir le tunnel L2TP primaire (celui qui a la préférence la plus faible)
Remarques : Les attributs RADIUS permettant de caractériser les tunnels L2TP sont spécifiés dans la RFC 2868.
O 18 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office Basic — 92240 Malakoff
Le Client peut demander que le LAC Fournisseur (BNG) envoie une valeur spécifique de l'Attribute Value Pairs (AVPs) Host Name (Attribute Type 7, RFC 3931) lors de l'établissement du tunnel L2TP. Le Client déclara cette valeur au Fournisseur, à travers la fiche d'interconnexion.
5.7 Synthèse des échanges pour l'établissement d’une session
Le schéma ci-dessous synthétise les messages PPP, L2TP et RADIUS échangés lors de l'ouverture d'une session PPP.
Figure 8 -— Synthèse des échanges pour la création d'une session PPP-L2TP
Lan
Abonné
Réseau
Ethernet / MPLS
Fournisseur
Proxy Radius
Fournisseur
Radius Client
Réseau
Transport IP/MPLS
Fournisseur
Reseau
du FAI
BNG
Fournisseur
LNS
Client
PPP (PADI)
PPP (PADO)
PPP (PADR + pppoe tag)
PPP (PADS)
LCP Config Request (option 3 = CHAP)
LCP Config Request
LCP Config Ack
PAP/CHAP Authentification Response
Radius Access Request
Radius Access Request
Détermination ISP par
analyse attribut Radius
« Agent-Circuit-Id »
Radius Access Accept
Radius Access Accept
ICRQ (Incoming Call Request)
ICRP (Incoming Call Reply)
ICCN (Incoming Call Connected)
ZBL ACK (Zero Length Body)
IPCP Config Request (adresse IP proposée = 0.0.0.0)
IPCP NAK (adresse IP propososée = IP_Abonné)
IPCP Config Request (adresse IP proposée = IP_Abonné)
IPCP ACK (adresse IP acceptée = IP_Abonné)
Session
L2TP
Transparent pour
Fournisseur
SCCRQ (Start Control Call Request)
SCCRP (Start Control Call Reply)
SCCCN (Start ControlCall Connected)
ZBL ACK (Zero Length Body)
Création du
tunnel L2TP si
L2TP en mode
dynamique
Interface
Livraison
OLT
Fourni
sseur
IAD
PPP (PADI + pppoe tag)
PPP (PADI)
PAP/CHAP Authentification Challenge
LCP Config Request (option 3 = CHAP)
LCP Config Ack (option 3 = CHAP)
PAP/CHAP Authentification Success Annexe 2A — STAS OPERA Office Basic 152 avenue Pierre Brossolette
axione 92240 Malakoff
ANNEXE I : GLOSSAIRE
BGP Border Gateway Protocol
BNG Broadband Network Gateway
CIR Committed Information Rate
DSCP Differenciated Service Code Point
EPON Ethernet Passive Optical Network
FTTB Fiber to the Building
FTTO Fiber to the Office
FTTH Fiber to the Home
GPON Gigabit Passive Optical Network
lAD Integrated Access Device
L2TP Layer Two Tunneling Protocol
LAC L2TP Access Concentrator
LNS L2TP Network Server
NG-PON Next Generation Passive Optical Networks
NRO Nœud de Raccordement Optique
OLT Optical Line Terminal
ONT Optical Network Terminal
P2P Point to Point
PIR Peak Information Rate
PPP Point-to-Point Protocol
PPPOE Point-to-Point Protocol over Ethernet
RFC Request For Comment
VLAN Virtual LAN
VPN Virtual Private Network
XG-PON 10 Gigabit Passive Optical Network
XGS-PON 10 Gigabit Symmetrical Passive Optical Network
20 CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
Annexe 2B — STAS OPERA Office Pro
ST mm. “OFFICE
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro
92240 Malakoff
Table des matières
1.
2.
Présentation du document... rennes 4
Description du Service nn 4
2.1 Description générale du Service... rennes 4
2.2 Schémas de principe ner 5
2.3 Classes de service rÉSEQU... nr rnrnnrnrnnrnnrnnrnnnnrnrnnnennnnnnnnnnennnnnnnnnnnnnnnnrnnnnnnnnnnnnnnnnnnnnnnnennnnnnnes 6
Infrastructure de collecte... ss 7
3.1 Collecte Point-MulItipoint..nnn rennes 7
3.1.1 SYnoOptIQUeE nn 7
3.1.2 Caractéristiques des éléments actifs inner 8
3.2 Format du Circuit-ID rennes 9
3.2.1 Circuit-ID nr 9
3.2.2 DHCPVA nr 9
3.2.3 DHCPVÉ nn rrnrrnrnrnnrnnrnennrnrnennennnennrnnnenennnnnennnnennnnnnnnnnnnnnnnnnnennnnnnenennnnnnnnnnnennnnnnennnennnes 10
3.2.4 PPPOËE Tag... nn 10
3.2.5 SYSNGME NN rnnrnnrnnnnnnrnennrnennnnennnennnnennnnnnnrnnnnnnnnnennnennnnennnnnnnenennnnennnennnne nee 10
3.2.6 Format du Circuit-ID spécifique aux OLTS.. rennes 10
Interface d'accès au Srvice nn rrrnnnnnnennnnnnennnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnes 12
AU L'interface AbONNÉ nn 12
AIT Spécifications du port Ethernet de l'ONT nr 13
4.1.2 Raccordement Abonné sur interface 10-BaseT ou 100-BaseT ii irrrnnnnnnnnnnns 13
4.1.3 Raccordement Abonné sur interface 1000-BaseT inner 14
AÏA4 Spécifications IP. rennes 14
4.2 L'interface de Collecte... sise 14
4.21 Spécification des interfaces physiques rennes 15
4.2.2 Interconnexion IP rennes 15
Mode d'accès et livraison IPOE nr nnnnnnnnnnnnnnrnee 17
51 Gestion IP/DHCP AbOnNÉ nee 17
5.2 Gestion profil de QoS AbONNÉ nn rennes 18
5.3 Paramétrage IP et DHCP. rennes 18
5.3.1 Durée de vie des adresses IPV6... nn 18
5.3.2 Compteur DHCP nn 19
5.4 Mode DHCP et RADUIS nn rrnrnrrnrnrnnennnennnnnnennnnnennnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnes 19
5.41 Authentification et adressage IP de l'abonné.... iirrrrnrrnrnnnnneennnnnnnnnnes 19
5.4.2 Détail des échanges RADIUS et DHCPVA4. nr 19
5.4.3 Détail des échanges RADIUS et DHCPVÉ nr 22
5.5 Mode Full RADUIS nn 25
5.5.1 Authentification et adressage IP de l'abonné..... ire 26
5.5.2 Détail des échanges RADUIS et DHCP. rennes 26
5.5.3 Détail des échanges RADUIS et DHCPVÉ nn 28
5.5.4 Limitation CONNUE... rennes 31 axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
5.6 Adressage IP des abonnés... rennes 32
5.6.1 Type d'adressage inner 32
5.6.2 Gestion des pools IP des GhOonnÉs.... rennes 32
5.6.3 Adresses IP réservées... irrrrnnnnennnnnnnnnnnnnnnennnnnennnennennennnnneennnnnrnes 33
5.7 Profils de QoS Abonné IPOE nn 33
6. Mode d'accès PPP et Livraison L2TP nn 34
6.1 Principe et modélisation de la livraison L2TP nn 34
6.2 Tunnel L2TP nn 35
6.3 Identification AbONNÉ.... LL rrnnrrnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnennnnnnnnnnnnnnnes 36
6.3.1 Identification sur la base du « User-Name ».. rennes 36
6.3.2 Identification sur la base du « Agent-Circuit-1d >... nee 37
6.4 Adressage IP des abonnés... rennes 37
6.5 Profils de QoS Abonné PPP nr 37
6.51 Trafic descendant... inner 38
6.5.2 Trafic montant... inner 38
7... Echanges RADUIS... nn 38
71 Serveurs RADIUS Fournisseur et ISP... nn 38
7.2 Echanges RADIUS en mode IPOE.... rennes 39
7.2.1 Access-Request envoyé au client... nn 39
7.2.2 Access-Accept du client... nine 40
7.3 Echanges RADIUS en mode PPPOE... nr A]
7.31 Etablissement des tunnels L2TP. eee 4]
7.3.2 Synthèse des échanges lors de l'établissement d'une session PP-L2TP. ii ennnnnns A]
7.3.3 Attributs Radius échangés... nee 42
Annexe | : Glossaire... rennes 45
Annexe 2 : Dictionnaire RadiuS rennes 46 axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
I. PRESENTATION DU DOCUMENT
Ce document décrit les conditions techniques d'accès au service OPERA Office Pro.
Il se compose des parties suivantes :
Présentation du Service OPERA Office avec type d'accès Pro ;
Description de l'infrastructure de collecte ;
Description des interfaces de livraison (abonné et collecte) :
Gestion des abonnés (IP/DHCP, PPP/L2TP) ;
Echanges RADIUS entre l'ISP et le Fournisseur ;
Profils de QosS client sur les BNG Fournisseur.
Le respect des conditions décrites dans le présent document est fondamental pour la garantie de fourniture du service
par le Fournisseur. Le Fournisseur ne pourrait pas garantir la fourniture du service dans le cas de non-respect de ces conditions. Dans tous les cas, la compatibilité des échanges entre le Fournisseur et le client sera validée lors d'une phase de tests préalables au démarrage du service. Des modifications seront étudiées en cas d'incompatibilité.
Dans ce document les termes « Client », « Abonné » et « ONT » ont la signification suivante :
Client : fait référence au Client ou l'usager utilisant les infrastructures de collecte et transport du Fournisseur afin de délivrer un ou plusieurs services à ses utilisateurs ;
Abonné : fait référence à un utilisateur final de type professionnel ayant souscrit un service auprès du Client ;
ONT : Optical Network Terminal, fait référence à l'équipement de terminaison GPON installé chez l’abonné.
2. DESCRIPTION DU SERVICE
2. Description générale du service
Le service « OPERA Office Pro » est une offre de collecte de trafic depuis des Locaux FTTH permettant à un opérateur de services, client du Fournisseur, d'assurer le raccordement et la collecte de ses abonnés professionnels à travers les infrastructures fibres optiques déployées dans les plaques opérées par le Fournisseur.
L'offre comprend le transport du trafic IP unicast Abonné jusqu'au site de livraison défini conjointement par le Client et le Fournisseur.
Le trafic IP unicast Abonné est acheminé, au choix du client ISP, selon les règles de transport et d'authentification énoncées ci-dessous :
Service Accès Transport / | Authentification | Identification Abonné Abonné Livraison
Data/VolP | IPOE IP sur RADIUS + DHCP | RADIUS : attribut Agent-Circuit-id
Ethernet DHCPv4/vé: option 82/18
Data PPPOE L2TP sur RADIUS RADIUS : login/password Ethernet + Agent-Circuit-id
Tableau 1 -— Liste des flux transportés
Remarque :
Dans le mode d'accès IPOE, la ligne est transparente à l'option DHCP 60 ;
O 4
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Les caractéristiques du service sont les suivantes :
Livraison du service chez l’'abonné sur une interface Ethernet ;
Débit d'accès de la « OPERA Office Pro » permet au Client, selon les caractéristiques des infrastructures optiques, de proposer des services Data jusqu’à 1 Gbits/s dans le sens descendant, et jusqu'à 500 Mbits/s dans le sens montant. Cependant, Axione garantit 20 Mbits/s dans les deux sens ;
Authentification Abonné par RADIUS de l'opérateur Client ;
Collecte et livraison trafic abonné selon 2 modes au choix du client : Collecte IP/DHCP et livraison en IPoE ;
Collecte PPPOE et livraison en L2TP ;
Adressage IP Abonné géré par l'opérateur Client en IPv4 et / ou IPvé ;
Uniquement IPv4 pour le mode d'accès PPPOE ;
Dans le mode d'accès IPOË, allocation des IP abonnés par le protocole DHCP (serveur DHCP Client ou Fournisseur suivant le mode retenu « DHCP et RADIUS » ou « FUlIRADIUS ») :
Dans le mode d'accès IPOE, gestion dynamique des profils abonnés depuis le serveur RADIUS de l'opérateur Client :
Type de service : 2-Play (2 classes de services disponibles) ;
Contrôle de la bande passante par classe de service (3 bits IP precedence du champ TOS - soit les 3 bits de poids forts du champ DSCP) et global par abonné ;
Ségrégation du trafic dans un contexte MPLS/VPN pour chacun des modes d'accès dans le réseau du Fournisseur :
Point d'interconnexion avec le réseau du Client :
Porte de collecte Locale où Nationale, située dans un POP Fournisseur ou dans un POP opérateur Tiers éligible au service ;
Redondance possible avec une seconde porte de même catégorie.
L'accès Abonné est basé sur un modèle Point-Multipoint avec la technologie GPON.
2.2 Schémas de principe
<— | _
ps Sn
a
Figure 1 - Schéma de principe Mode d'accès IPOE
•
•
•
•
o
o
o
o
•
•
o
o
•
•
o
o
IP/MPLS
Network
Plaque 3
IP/
MPLS Network
Plaque 1
IP/
MPLS Networ
k
Plaque 2
OLT
ONT
Réseaux Clients
Routeur
Client
Interface de Collecte
Nationale
VLAN Unicast
OLT
ONT
IPoE Unicast ( Data, VOIP)
Collecte Eth/MPLS
Collecte Eth/MPLS
Transport VPN IP/MPLS
Réseau Fournisseur
Interface Abonné
BNG
BNG
BNG
Routeur
Collecte
Infra GPON
Infra GPON
Infra GPON
IAD
IAD
IAD
OLT
ONT
Infra ISP-A
Routeur
Client
VLAN Unicast
Infra ISP-B
Collecte Eth/MPLS
Interface de Collecte
Locale axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Figure 2 - Schéma de principe Mode d'accès PPPOE
Les infrastructures d'accès Point-Multipoint sont en liaison avec un réseau de collecte Ethernet (Eth/MPLS) pour joindre les BNGs du Fournisseur. Elles s'appuient d'une part sur des équipements de commutation Ethernet, tels que ONT/OLT pour l'accès, et d'autre part sur des équipements de commutation de labels MPLS, tels que les OLTSs et des routeurs multiservice MPLS pour la collecte.
Dans ces réseaux de collecte Ethernet, le cloisonnement des flux Client est assuré par l'implémentation d'une instance de commutation dont une des spécificités est d'interdire l'échange de trafic entre Abonnés.
Les équipements de commutation Ethernet ainsi que ceux du domaine Eth/MPLS apprennent les adresses MAC tel que décrit dans les standards IEEE 802.1D et RFC 4762.
Le nombre d'adresses MAC par abonné est limité à 5 et leur « aging-time » est fixé, dans la chaine de collecte niveau 2, à 2 heures. La durée des baux DHCP (ou preferred-lifetime en DHCPvé) et des timers ARP doit y être inférieure (avec timer ARP = Bail DHCP / 2) pour assurer un service sans discontinuité et éviter la diffusion de trafic de type « Unknown » ou « Broadcast » à travers les infrastructures du Fournisseur.
Les BNGs ont pour rôle d'appliquer le profil de service des abonnés et les mettre en relation avec l'infrastructure de transport de niveau 3 (VPN IP / MPLS) pour être accessibles depuis la porte de collecte. L'infrastructure globale assure une pleine transparence vis-à-vis du trafic échangé entre les Abonnés et le réseau de l'opérateur Client.
Les zones de collecte d'abonné sont gérées par 2 BNGs redondants en mode active/standby.
Les BNGs affectés à une zone de collecte sont choisis pour être au plus proche de celle-ci.
À noter qu'à travers les infrastructures d'accès Point-Multipoint, l'opérateur Client est en mesure d'adresser ses abonnés en |Pv4 et / ou IPv6.
La combinaison des 2 modes de collecte IPOE et PPPOE, est permise, mais ne l’est pas au niveau Abonné.
2.3 Classes de service réseau
La correspondance entre les classes de service du réseau du Fournisseur et les différents types de trafic associés est basée sur la valeur présentée par les 3 bits de l'IP Precedence du champ TOS contenu dans l’entête des paquets IP. La
liste de ces correspondances est présentée dans le tableau ci-dessous :
O 6
2e
IP/MPLS
Network
Plaque 3
IP/
MPLS Network
Plaque 1
IP/
MPLS Networ
k
Plaque 2
OLT
ONT
Réseaux Clients
LNS
Client
Interface de Collecte
Nationale
OLT
ONT
Collecte Eth/MPLS
Collecte Eth/MPLS
Transport VPN IP/MPLS
Réseau Fournisseur
Interface Abonné
BNG
BNG
BNG
Routeur
Collecte
Infra GPON
Infra GPON
Infra GPON
IAD
IAD
IAD
OLT
ONT
Infra ISP-A
LNS
Client
PPPoE
Infra ISP-B
Collecte Eth/MPLS
Interface de Collecte
Locale
Session L2TP
PPPoE
PPPoE
Session L2TP axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
VOIP 9, 6,7
Tableau 1 - Correspondance Trafic et CoS Fournisseur
3. INFRASTRUCTURE DE COLLECTE
3. Collecte Point-Multipoint
3.1.1 Synoptique
Le réseau de collecte dépeint ci-après est basé sur une infrastructure GPON et reprend le schéma de principe de la Figure I.
=
Figure 2 - Réseau de collecte GPON du service OPERA Office
Les arbres PON adressent 32 voire 64 Abonnés au maximum. Toutefois, certains arbres PON peuvent être restreints à 16 abonnés afin de servir les Points de Mutualisation les plus éloignés de leur NRO et préserver le budget optique total des lignes Abonné. Le schéma ci-après modélise différentes solutions de raccordement des abonnés sans en faire la liste exhaustive :
RG ONT
(bridge)
BNG OLT
[PE]
Desserte
(Eth sur GPON)
Agrégation
(Eth sur MPLS)
VPLS axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
—ter—+#s]
Figure 3 - Modélisation ODN
Les NRO peuvent prendre le rôle de PM afin de raccorder des Abonnés.
L'utilisation de coupleurs 1 :16 ou 1:32 ou 1:64 dans les points de mutualisation est fonction de la distance PM / NRO.
Avec le niveau de couplage 1:32, la distance optique maximale entre l'OLT et l'ONT avoisine 18 kms avec des modules optiques GPON de classe C+ au niveau de l'OLT.
3.1.2 Caractéristiques des éléments actifs
3.1.2.1 ONT
L'ONT est un équipement d'intérieur pourvu d’une alimentation externe en 220v AC. L’Abonné doit fournir une prise électrique permettant son alimentation.
C'est un modèle Bridge Ethernet dont les ports ont les caractéristiques suivantes :
port optique Class B+ avec connecteur SC-APC ;
port cuivre gigabit-Ethernet par interface Abonné.
L'implémentation de la technologie GPON respecte les recommandations G.984.x de l'ITU-T :
Nombre de T-CONT = 4 minimum ;
Nombre de files d'attente associées à une interface Abonné = 8 ;
Ordonnanceur des files d'attente supporte les modes « strict-priority », Weighted Fair Queuing » ainsi que la combinaison des deux dans le sens montant. Dans la voie descendante, seul le mode « strict-priority » est supporté.
3.1.2.2 OLT
O
NRO
Abonné
PM
OLT
Rep optique Rep optique
Rep optique OI PTO
Connecteur (soudé)
soudure
Abonné
P
M
Rep optique OI
PBO
PTO PBO
Coupleur 1:64
Coupleur 1:32
Abonné
PM
Rep optique Rep optique
Rep optique OI PTO PBO
Coupleur 1:32
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
L'OLT est une plate-forme multiservices de haute capacité dont l'architecture du châssis permet de satisfaire aux besoins actuels et futurs puisqu'elle met à disposition de chaque carte de service une double connexion à 100 Gbits/s. De fait, elle est adaptée au marché des services résidentiels ou entreprises hauts débits (FTTH, FTTB, FTTO) tout en permettant
de déployer simultanément plusieurs technologies d'accès basée sur la fibre optique.
En plus du mode d'accès GPON, retenu pour l'infrastructure de collecte point-multipoint, l'OLT supporte les types d'accès listés ci-après :
EPON ;
NG-PON ( 10G XG-PONI, XGS-PON : NG-POND) :
P2P Fast-Ethernet/Gigabit-Ethernet/TenGigabit-Ethernet.
3.2 Format du Circuit-ID
3.2.1 Circuit-ID
La notion de « Circuit ID » est communément employée dans les réseaux d'accès pour identifier de façon unique un
Abonné en transmettant une information relative à l'équipement d'agrégation et au port d'accès, qu'il soit physique ou logique, auquel le client DHCP ou le client PPPOE est rattaché.
Mode IPoE :
Dans les transactions DHCPv4 le « Circuit-ld » est transmis par l'intermédiaire de l'option n°82 insérée par l'équipement d'agrégation des infrastructures de collecte Point-Multipoint. Elle est de taille variable et peut-être constituée d'une suite de sous options. Les codes des sous options Agent Circuit ID et Agent Remote ID sont respectivement 1 et 2.
Dans les transactions DHCPvé le « Circuit-Id » est transmis par l'intermédiaire de l'option n°18 (Interface-ID) qui peut être complétée par l'option 37 (Relay Agent Remote-lD). L'équipement d'agrégation se comporte en relai DHCP de niveau 2 aussi appelé Lightweight DHCPvé Relay Agent (LDRA), les options 18 et 37 sont définies respectivement par les RFC3315 et RFC4649.
Par analogie avec DHCPv4, l'option DHCPv6 n°18 correspond à la sous-option 1 de l'option 82 et l'option DHCPvé6 n°37 correspond à la sous-option 2 de l'option 82.
Mode PPPoE :
Durant les échanges PPPoE, le « Circuit-ld » est transmis par l'intermédiaire d'un PPPOE Tag inséré par l'équipement d'agrégation des infrastructures de collecte Point-Multipoint en suivant les recommandations du Broadband Forum TR- 156 (Architecture de collecte Ethernet pour services Broadband sur accès GPON - Using GPON access in the context of TR-101).
Dans ce contexte, les OLT sont appelés PPPOE Relay, ou PPPOE-Intermediate Agent. Ils insèrent les PPPOE Tag dans les messages PPPOE montants (émis par les IAD vers le réseau), c'est-à-dire durant la phases découverte et terminaison PPPOE en utilisant les messages PADI, PADR et PADT.
Le format du PPPOE Tag est défini dans le document BBF TR-I0I 8 3.9.2. Il se compose de plusieurs champs dont le TAG_ID (0x0105 = Vendor-Specific) et le TAG_ VALUE (vendor id= 0Ox000DE9 = BBF) suivis d'une suite de sous options selon les besoins. Par analogie à l'option 82 DHCPv4, les codes des sous options Agent Circuit ID et Agent Remote ID
sont respectivement | et 2.
3.2.2 DHCPv4
3.2.2.1 Agent Circuit-ID
Cette sous-option de l'option 82 contient la totalité des informations d'identification du circuit d'accès des Abonnés sur l'équipement d'agrégation. Elle est par conséquent systématiquement délivrée.
3.2.2.2 Agent Remote-ID
O 9
LE
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Cette sous-option de l'option 82 contient uniquement l'information du Sysname de l'équipement d'agrégation. Cette information est redondante avec celles contenues dans l'Agent Circuit-ID.
3.2.3 DHCPvé
3.2.3.1. Interface-ID
Cette option 18 à la même signification et reprend le format de l'Agent Circuit ID de l'option 82 de DHCPva.
3.2.3.2. Relay Agent remote-IlD
L'information transportée par l'option 37 est spécifique à l'équipement d'agrégation, elle peut être utilisée par exemple
pour transmettre un numéro de VLAN, une description de port, …
Dans le cas du présent service, l'option 37 n'est pas ajoutée.
3.2.4 PPPOE Tag
3.2.4.1. Agent Circuit-ID
La sous-option n°1 contient la totalité des informations d'identification du circuit d'accès des Abonnés sur l'équipement d'agrégation. Elle est par conséquent systématiquement délivrée.
Elle à la même signification et reprend le format de l'Agent Circuit ID de l'option 82 de DHCPv4.
3.2.4.2. Agent Remote-IlD
Cette sous-option n°2 permet d'identifier l'abonné. C'est une chaine de 63 caractères au maximum.
Dans le cas du présent service, cette sous option n'est pas ajoutée.
3.2.5 Sysname
Le Sysname correspond au nom de l'équipement auquel est raccordé l’abonné.
l'est contenu dans les champs circuit-id / remote-id de l'option 82 DHCPv4, dans l'option 18 DHCPvé et dans le Tag PPPOE.
Le format du sysname des OLT pour la collecte Point-MultiPoint en GPON est le suivant :
Valable pour tous | olt-xxxdd-yy
OLT Avec :
xxx = le trigramme NRO (en minuscule)
dd = le numéro du département
yy = l'identifiant OLT rattachés à un même NRO
La chaine de caractères xxxdd identifie le NRO.
3.2.6 Format du Circuit-ID spécifique aux OLTs
Dans les réseaux d'accès GPON, les options DHCP (82 ou 18) ou les PPPOE Tag sont insérés par l'OLT dans les messages DHCPv4, DHCPvé ou PPPOE des transactions initiées par l'équipement Abonné.
Pour les OLT, le format du « Circuit-ID » pourra prendre deux formes en fonction du modèle d'OLT sur lequel l’'Abonné est
raccordé :
O 10
LE
-
-
- axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Access_Node_ID PON Rack/Frame/Slot/PON/ONU/OnusSit/UNI/1I-VID
Access_Node_ID = Le sysname de l'équipement ;
PON = Indiquant la technologie de collecte ;
Rack = Identifiant de baie de l’'OLT toujours à la valeur |;
Frame = Identifiant de châssis OLT toujours à la valeur |;
Slot = Identifiant du Slot de l'OLT, de O1 à 16;
PON = Identifiant de port de la carte GPON, de O1 à 16. Par défaut des cartes 8 ports PON mais dans les NRO denses des cartes 16 ports PON pourront être utilisées ;
ONU = Identifiant ONT par arbre PON, de 1 à 128 (infra Fournisseur = 64 maximum) ; OnusSit = slot de l'ONT, toujours à |;
UNI — Identifiant de port sur l'ONT représentant l'interface Abonné, toujours à | ;
I-VID = Identifiant VLAN utilisé par l'équipement Abonné raccordé à l'UNI :
Celui-ci est vide si le trafic Abonné n'est pas marqué par une étiquette VLAN.
Access_Node_ID XPON Frame/Slot/Subslot/PON:ONU.gem.vlanid
Access_Node_ID = Le sysname de l'équipement ;
XPON = indiquant la technologie de collecte ;
Frame = Identifiant de châssis OLT toujours à la valeur 0 ;
Slot = Identifiant du Slot de l'OLT, de 1 à 5;
Subslot — Identifiant de la carte fille toujours à 0 ;
PON = Identifiant de port de la carte GPON, de 0 à 15;
ONU = Identifiant ONT par arbre PON, de O à 127 (infra Fournisseur = 64 maximum) ; Gem = Identifiant du gemport de l'ONT portant l'identification de l’'Abonné, toujours à |; Vlanid = Identifiant VLAN utilisé entre l'ONT et l'OLT, toujours à 1 ;
Pour le présent service, le « Circuit-ID » qui permet d'identifier de façon unique l’Abonné dans le réseau, pourra donc prendre les formes :
« sysname pon 1/1/Slot/PON/ONU/1/Uni »
Exemple :
dans son format ascii : olt-bsn42-01 pon 1/1/01/01/4/1/1/
dans son format hexadécimal correspondant aux codes ascii :
6f6c/42d62736e34322d303120706f6e20312f312f30312f30312f342#312f312f
« sysname xpon 0/Slot/0/PON:ONU.. »
Exemple :
dans son format ascii : olt-bsn42-01 xpon 0/1/0/0:4.1.
dans son format hexadécimal correspondant aux codes ascii :
6f6c/42d62736e34322d30312078706f6e20302f312f302f303a342e312e3l
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
-
-
•
•
o
o 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro
92240 Malakoff axiIone
À. INTERFACE D'ACCES AU SERVICE
Le service OPERA Office Pro définit deux interfaces permettant, d'une part, le raccordement de l'installation Abonné (interface Abonné), et d'autre part, l'interconnexion entre le Client Opérateur de services et celui du Fournisseur (interface
de Collecte).
27
Je
€ > . LL re D.
».: FF « FF
a Es
Figure 5 - Interfaces de service
A. L'interface Abonné
L'interface Abonné est de type cuivre, son débit peut prendre les valeurs 10 Mbps, 100 Mbps ou 1000 Mbits/s.
Les types d'interfaces d'accès supportées sont listés dans le tableau ci-dessous :
Topologie |Type Debit Média Portée Connecteur Normes Interface | interface (mètres)
Point- 1000- 1000 Mbit/s |4 paires de cuivre |100m IEEE 802.3ab Multipoint | BaseT Impédance 100
GPON Ohms
ISO/IEC 8802.3
Câble UTP 6
Point- 100-BaseT 100 Mbit/s |2 paires de cuivre |100m IEEE 802.3u . RJ-45 Multipoint Imoéd 100
GPON One ISO 8877
£ ISO/IEC 8802.3
Câble UTP 5 (support for + automatic
INIUM inversion MDI
Point- 10-BaseT 10 Mbit/s |2 paires de cuivre |100m / MDWX) IEEE 802.3
Multipoint Impédance 100 GPON Ohms
ISO/IEC 8802.3
Câble UTP 5
Tableau 3 - Caractéristiques de l'interface de service Abonné
Remarque :
L'indication de portée est conforme au standard ISO/IEC 8802.53. Il conviendra de tenir compte des pertes inhérentes aux divers points de coupure (répartiteurs, catégorie des câbles et des jarretières utilisées) et de recalculer la longueur maximale
admissible.
Le connecteur est de type ISO 8877 (RJ 45) femelle, il est présenté par la figure suivante :
O 12
ONT
(bridge)
BNG
OLT
[PE]
Desserte L2 over MPLS network
Interface
Abonné
VPLS
Interface de
Collecte
VPN IP
Routeur
Collecte
L3 over MPLS network axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Figure 4 - Connecteur femelle RJ45
AIT Spécifications du port Ethernet de l'ONT
Les caractéristiques physiques de l'interface Ethernet sont :
Interface Cuivre ;
Connecteur RIJ-45 femelle ;
Vitesse auto : 10/100/1000 Mbit/s ;
Port MDI / MDI-X avec détection automatique du câble droit ou croisé.
A.I.2 Raccordement Abonné sur interface 10-BaseT ou 100-BaseT
Appairage des paires de cuivre et le brochage du connecteur sont présentés dans les tableaux ci-dessous :
Media Paires utilisées
2 paires (1; 2)et(3;6)
] TxD + ———+ |Transmission de données vers l'équipement terminal (+)
2 TxD - —— |Jransmission de données vers l'équipement terminal (-)
3 RxD + æ———— |Réception de données provenant de l'Equipement Terminal (+)
4 NC Non utilisé
5 NC Non utilisé
6 RxD - æ—— |Réception de données provenant de l'Equipement Terminal (-)
7 NC Non utilisé
8 NC Non utilisé
Tableau 4 - Appairage et Brochage du connecteur pour interface 10 Base-T ou 100 Base-T
Le raccordement de l'équipement Abonné doit être réalisé avec un câble dont les caractéristiques sont au moins équivalentes à la catégorie 5.
L'interface Ethernet de l'équipement Abonné doit être conforme à la norme IEEE 802.3u (100-BaseT) ou IEEE 802.3i (10-
BaseT).
O
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
A.1.3 Raccordement Abonné sur interface 1000-BaseT
Appairage des paires de cuivre et le brochage du connecteur sont présentés dans les tableaux ci-dessous :
Media Paires utilisées
À paires (1:2)(3;6)(4;5)et(7;8)
BILDA+ | >» | paire Bi-directionnelle À + —
BI_DA- é—+ | paire Bi-directionnelle A -
BI_DB+ ——— | poire Bi-directionnelle B +
BI_DC+ <— | paire Bi-directionnelle € +
BI_DC- e— | poire Bi-directionnelle C -
Bl_DB- *— | paire Bi-directionnelle B -
BI_DD+ t—+ | paire Bi-directionnelle D +
©O|
|
|
C1]
|
©)
N
BI_DD- *—+ | paire Bi-directionnelle D -
Tableau 5 - Appairage et Brochage du connecteur pour interface 1000 Base-T
Le raccordement de l'équipement Abonné doit être réalisé avec un câble dont les caractéristiques sont équivalentes à la catégorie 6.
L'interface Ethernet de l'équipement Abonné doit être conforme à la norme IEEE 802.3ab (1000-BaseT) et configurée en mode auto-négociation avec une vitesse de transmission de 1000 Mbits/s.
414 Spécifications IP
L'abonné ne doit pas envoyer vers le réseau des paquets IP avec une taille supérieure à 1500 octets.
Le contenu du champ DSCP des paquets IP n'est pas modifié et peut-être utilisé par le client ISP pour faire correspondre ses flux avec les classes de services du réseau Fournisseur.
La valeur des 3 bits de poids fort du champ DSCP (ou IP Precedence) doit respecter les règles suivantes :
Precedence — 5, 6, 7 pour le trafic associé à la classe de service VolP
Precedence = O, I, 2, 3, 4 pour le trafic associé à la classe de service Data
L'IAD installé chez l'abonné doit fonctionner en Ethernet « natif ». Le trafic ne doit pas être tagué avec un numéro de VLAN.
4.2 L'interface de Collecte
L'interface de Collecte livre l'ensemble du trafic montant et descendant des abonnés sur le réseau de l'opérateur client.
Elle est matérialisée par une ou plusieurs portes de livraison situées dans des points de présence du Fournisseur :
Une porte Locale collecte uniquement les flux unicast issus d’une même DSP ;
Une porte Nationale collecte les flux unicast de l'ensemble des réseaux opérés par le Fournisseur (accès issus de n'importe quel réseau de Délégation de Service).
Le client a la possibilité de souscrire au maximum 2 portes qui doivent être du même niveau (Locale ou Nationale). Lorsque le trafic est livré sur 2 portes, il ny a pas de partage de charge : une porte nominale et une porte de secours. La porte de secours peut avoir un débit inférieur à la porte nominale.
O 14
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
D Det |
+ —Ps = + 7 7
Figure 7 - Sécurisation de l'interface de Collecte
Afin d'autoriser la cohabitation des flux Unicast Abonné et les échanges radius, des interfaces logiques (VLAN) distinctes sont définies sur l'interface de collecte :
Un VLAN Data ;
Un VLAN RADIUS.
L'interface de collecte peut être composée de plusieurs ports physiques, dans ce cas le protocole LACP devra être configuré par le client ISP.
421 Spécification des interfaces physiques
Seul l'accès fibre optique est disponible, les caractéristiques de l'interface sont les suivantes :
Type Debit . Portée Type Normes Interface interface Média (mètres) |Eibre Connecteur
IEEE 802.3z
1000Base-LX |1Gbit/s [Fibre Optique | [Duplex [LC/PC Monomode ISO/IEC 8802.3
Fibre Optique 10GBase-LR |10 Gbits/s 10Kms Duplex LC/PC IEEE 802.3ae Monomode
Tableau 6 - Caractéristiques de l'interface de Collecte
Remarque :
L'indication de portée est conforme au standard ISO/IEC 8802.3. Il conviendra de tenir compte des pertes inhérentes aux divers points de coupure (répartiteurs optiques, pertes liés aux connecteurs des jarretières) et de recalculer la longueur maximale admissible.
Sur ces interfaces, le client ne doit pas activer de mécanismes de spanning-tree. Il ne doit pas envoyer de paquets BPDU sur le port d'interconnexion.
A2.2 Interconnexion |P
Comme spécifié au paragraphe 4.2, deux VLANS sont définis sur les interfaces de collecte afin de séparer les échanges RADIUS des flux Data :
un VLAN Data pour le transport des flux data (IPOE et/ou L2TP) des abonnés :
un VLAN RADUIS pour les échanges RADIUS.
Les numéros de VLAN sont spécifiés dans la fiche d’interconnexion.
Deux réseaux IP d'interconnexions sont nécessaires pour acheminer les échanges RADUIS et les flux Data :
Un réseau en adressage publique IPv4 /30 ou /31 pour l'interconnexion RADIUS
O 15
LE
•
•
•
•
•
•
•
•
ONT
(bridge)
BNG
OLT
[PE]
Desserte L2 over MPLS network
Interface
Abonné
VPLS VPN IP
L3 over MPLS network
Interfaces de
Collecte
Routeurs
Collecte axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Un réseau en adressage IP publique ou privée IPv4 de type /30 ou/31, voire IPv6 de type /127 pour le VLAN Data Unicast.
Pour les adressages ip publiques, le Client ISP doit disposer d’un numéro d’AS public.
Une session eBGP est établie entre le Fournisseur et le client ISP au niveau de chaque VLAN de l'interface de collecte.
Caractéristiques de la session eBGP data
Adressage IP fourni par le client ISP ;
La fonctionnalité GTSM (RFC 5082) peut être activée pour sécuriser à minima la session eBGP en contrôlant qu'elle est établie avec le premier équipement IP joignable par cette interconnexion ;
La fonctionnalité BFD peut être activée pour optimiser la durée de détection de la perte de la session eBGP.
Le Fournisseur annonce les préfixes BGP contenant les adresses IP des lADs en mode IPOE ainsi que les préfixes BGP contenant les adresses IP de ses LAC pour le mode PPPOE :
Mode IPoËE : A la convenance du Client ISP, les pools IP ou les préfixes spécifiques /32 pour IPv4 ou les préfixes spécifiques lA_NA en /64 et IA_PD, de /32 à /64, pour IPv6 par lAD ;
Mode PPPoE : Les adresses de ses LAC
sur une porte nationale, le Fournisseur annonce les adresses IP des LAC des réseaux d'initiative public pour lesquels le client a opté pour une livraison nationale ;
sur une porte locale, le Fournisseur annonce uniquement les adresses IP des LAC locaux.
Le client annonce :
Mode IPoE : Une route par défaut
Mode PPPoE : Les adresses de ses LNS
Le Fournisseur appliquera un filtre sur les annonces BGP-4 du client pour autoriser :
Mode IPoE : Route par défaut uniquement ;
Mode PPPoE :
Limitation du nombre total de routes annoncées par le client sur une interface de collecte à 300 ;
Seules les adresses faisant partie des blocs d'adresses LNS préalablement déclarés par le client sont redistribués dans le réseau du Fournisseur.
Les communautés utilisées par le client seront ignorées sur le réseau du Fournisseur.
Caractéristiques de la session eBGP RADIUS
Adressage IP fourni par le Client ISP ;
La fonctionnalité GTSM (RFC 5082) peut être activée pour sécuriser à minima la session eBGP en contrôlant qu'elle est établie avec le premier équipement IP joignable par cette interconnexion ;
La fonctionnalité BFD peut être activée pour optimiser la durée de détection de la perte de la session eBGP.
Le Fournisseur annonce :
les adresses IP de ses Proxy RADIUS
O 16
LE
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Le client annonce :
les adresses IP de ses serveurs RADIUS
Le Fournisseur appliquera les filtres suivants sur les annonces BGP-4 du client :
Limitation du nombre total de routes annoncées par le client sur une interface de collecte au nombre de serveurs RADIUS du client ;
Seules ces adresses sont redistribuées dans le réseau du Fournisseur.
Les communautés utilisées par le client seront ignorées sur le réseau du Fournisseur.
Attributs BGP et gestion du mode de redondance
Les routes annoncées en BGP par le client auront l'attribut local-preference positionné de la manière suivante sur les interfaces de livraison :
Type de livraison Valeur attribut Local-Pref
Locale nominale 220
Locale secours 210
Nationale nominale 200
Nationale secours 100
Tableau 2 - Attributs BGP des préfixes échangés
De la même façon, le client devra marquer avec une locale préférence plus grande les routes apprises sur les interfaces de livraison nominale.
5. MODE D'ACCES ET LIVRAISON IPOE
5. Gestion IP/DHCP Abonné
Le présent service permet d'établir des sessions IP DHCP entre IAD et BNG, sans « switching » inter-abonné, routables jusqu'au réseau de l'opérateur client. Celui-ci est en mesure d'attribuer, à chacun de ses abonnés, au plus une adresse parmi les types suivants :
IPv4 : une adresse /32 par lAD;
IA_NA (IPv6) sur infrastructure Point-Multipoint uniquement : une adresse /128 par IAD issu d’un range /64 dédié. Soit 1 range /64 par lAD;
IA_PD (IPvé) sur infrastructure Point-Multiboint uniquement : un préfixe de taille /32 à /64 par lAD.
L'opérateur client a le choix de gérer ses abonnés selon 2 méthodes ; « DHCP et RADIUS » ou « FULL RADIUS ».
Dans le mode « DHCP et RADIUS », le BNG du Fournisseur se comporte en relai DHCP entre les IAD abonnés et le serveur DHCP du client opérateur.
Dans le mode « FULL RADIUS », le BNG du Fournisseur se comporte en serveur DHCP vis-à-vis des IAD abonnés et leurs
paramètres IP sont transmis par le serveur Radius du client opérateur.
O 17
2e
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Les échanges DHCP et RADIUS des 2 méthodes sont détaillées ci-après dans cette même section du document.
5.2 Gestion profil de QoS Abonné
La gestion du profil de QoS de l'abonné se fait dynamiquement à chaque nouvel échange DHCP entre l'abonné et le
serveur DHCP (DHCPv4-Discover / DHCPv4-Renew ou DHCPvé-Solicit / DHCPvé-Renew). La valeur de 3 bits de poids fort du champs DSCP (ou IP Precedence) pour les échanges DHCP doit être à O.
Quel que soit le mode de gestion des abonnés, le BNG initie une transaction Radius lui permettant de récupérer le profil
de l’'abonné.
Pour cela l'opérateur client renvoie dans un message RADIUS Access-Accept l’attribut Class précisant le profil de labonné. Ce dernier est ensuite interprété par le réseau du Fournisseur et le profil de QoS associé est automatiquement activé au niveau du BNG:.
5.3 Paramétrage IP et DHCP
5.31 Durée de vie des adresses IPv6
L'attribution d'une adresse IPv6 à une interface est temporaire et les différents états de sa durée de vie sont présentés par la figure suivante :
Y
Figure 8 - Etats successifs d'une adresse IPv6 sur une interface
Les compteurs « Durée de vie » et « Durée de Préférence » contrôlent le cycle de vie des adresses IP sur une interface.
Selon le mode d'auto-configuration, le compte à rebours démarre dès réception du message d'annonce d'un routeur ou d'un message DHCPvé Reply.
La durée de vie (valid lifetime) indique la durée pendant laquelle l'adresse IP est associée à une interface.
La durée de préférence (preferred lifetime) est la durée pendant laquelle l'adresse IP est utilisable sans restriction dès lors que son unicité a été vérifiée. Cette durée est assimilable à la durée du bail DHCPv4.
Le cycle de vie d’une adresse IPv6 est régi par les états suivants :
Etat Provisoire (tentative) : L'adresse a été attribuée par le mécanisme d’auto-configuration mais son unicité sur le lien n'a pas encore été vérifiée par le processus de Détection d'Adresse Dupliquée (DAD). Une adresse provisoire ne peut servir dans une communication ;
Etat valide (valid) : L’unicité a été contrôlée, l'adresse est active sur une interface ; Préféré (preferred) : L'adresse peut être utilisée sans restriction ;
Déprécié (deprecated) : L'adresse ne peut plus être utilisée pour de nouvelles communications mais reste active pour les connexions existantes ;
Invalide (invalid) : L'adresse ne peut plus du tout être utilisée. Elle n'est plus active sur l'interface.
Provisoire Préféré Déprécié
Valide Invalide
Création Allocation
Durée de Préférence
Durée de vie
•
•
o
o
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
5.3.2 Compteur DHCP
En supplément de la durée du bail pour IPv4 où de la durée à l’état préféré pour IPvé, les clients DHCP gèrent 2 compteurs définis par T1 et T2 dans les RFC2131 pour DHCPv4 et RFC3315 pour DHCPvé. Ces compteurs sont à leur valeur par défaut telle que définie dans les RFC ou configurables par les serveurs sous formes d'options.
Le premier, T1, stipule la durée à partir de laquelle le client demande à son serveur un renouvellement de la durée d'utilisation de son adresse IP. Le second, T2, entre en action lorsque la demande de renouvellement a échoué en renégociant une nouvelle adresse IP en s'adressant à tous les serveurs susceptibles de répondre.
T2 doit être compris entre TI et l'expiration du bail DHCPv4 ou de l'état préféré en DHCPvé.
Pour DHCPv4, TI et T2 ne sont pas transmis au client DHCP. Lorsque le client DHCP utilise les valeurs par défaut, les compteurs sont :
Bail = 7200 secondes (2 heures) :
TI = Renew = 0,5*Bail (valeur par défaut selon RFC2131) = 3600 secondes : T2 = Rebind = 0,875*Bail (valeur par défaut selon RFC2131) = 6300 secondes.
Pour DHCPvé, à la différence de DHCPv4, TI et T2 sont toujours transmis au client DHCP. Les valeurs imposées par le Fournisseur sont les suivantes :
Preferred lifetime = 7200 secondes (2 heures) ;
Valid lifetime = 10800 secondes (3 heures) ;
TI = Renew = 0,5*“Bail = 3600 secondes ;
T2 = Rebind = 1,5*T1 = 5400 secondes.
5.4 Mode DHCP et RADUIS
54.1 Authentification et adressage IP de l’abonné
À chaque nouvel échange IP/DHCP (DHCPv4-Discover / DHCPv4-Renew ou DHCPvé-Solicit / DHCPvé-Renew), une demande d'authentification RADIUS (RADIUS Access-Request) est envoyée au serveur RADIUS Client au travers d’un Proxy-RADIUS du Fournisseur.
Une fois la demande d'authentification validée par le serveur RADIUS client (RADIUS AccessAccept), le BNG du Fournisseur relaye la demande DHCP de l’abonné aux serveurs DHCP de l'opérateur client.
Une fois la phase d’authentification passée, le dialogue IP/DHCP client/serveur se déroule de façon standard.
L'opérateur client attribuera des adresses IP pour une durée de 2 heures (bail DHCPv4 / preferred-lifetime pour DHCPvé = 2 heures).
5.4.2 Détail des échanges RADIUS et DHCPv4
5.4.2.1 DHCPv4-Discover
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Figure 9 - Mode DHCP et RADIUS (transaction DHCPv4-Discover)
IA CO
1) L'IAD envoie un DHCP-Discover sur son port réseau.
OLT d'accès
(2) Celui-ci insère l'option 82 dans le DHCP-Discover du client en y renseignant les informations suivantes :
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BNG
À réception du DHCP-Discover le BNG Nominal bloquera le DHCP-Discover de lIAD Abonné. Il générera un RADIUS Access-Request à destination du Proxy RADIUS Fournisseur (3) afin d'identifier l’'abonné en recopiant certains champs du DHCP-Discover dans sa requête (circuit-id, remote-id et vendor-dhcp).
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’'abonné sur la base de son circuit-id et proxifie l'Access- Request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access- request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id=;
ADSL-Agent-Remote-id=.
O 20
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
3
5
7
DHCP Discover 1 DHCP Discover 2
RADIUS Request 4 RADIUS Request
6 RADIUS Accept RADIUS Accept
DHCP offer DHCP offer
9
DHCP Ack DHCP ack 12
DHCP Discover
8
10
DHCP Request DHCP Request
11
BACKBONE FOURNISSEUR
IAD
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Les attributs radius suivants seront transmis sur demande du client :
Alc-DHCP-Vendor-Class-ld = ;
Calling-Station-Id :
° Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS Access-Accept (5) au proxy-RADIUS Fournisseur contenant les informations suivantes :
Class = FTTH-PRO- DLmk-ULmk
: La valeur du débit HSI down max en Mbit/s
: La valeur du débit HSI up max en Mbit/s
: La valeur du débit VolP down max en kbit/s
: La valeur du débit VolP up max en kbit/s.
L'attribut Class permet de distinguer le profil de débit à appliquer à l'abonné. Il est construit en se référant aux valeurs maximales des débits descendants DATA/VOIP et des débits montants DATA/VOIP.
Ci-après un exemple:
OPERA Office Pro avec débit symétrique Data 100Mbps et voix de 500Kbps. Class = FTTH-PRO-DLI00m500k-ULI00m500k
Le proxy-Radius Fournisseur transmet le Radius Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6) :
Identifiant Service du client ;
Identifiant de l'abonné ;
Profile de QoS (attribut Class renvoyé par le Radius Client).
À réception de l’Access-Accept, l'abonné est instancié, au sein du BNG, dans le VPN du client avec son profil de Qos.
A ce stade l'abonné n'a toujours pas obtenu d'IP. Le BNG relaie alors le DHCP-Discover (7) de l'abonné vers le serveur DHCP du client.
S'ensuit alors un dialogue DHCP standard, DHCP-Offer(8), DHCP-Request(9) et DHCP-Ack(10) entre l'IAD de l'abonné et le serveur DHCP du client.
Le DHCP-Ack permet au BNG Fournisseur de connaître l'adresse IP de l’abonné et la durée du bail DHCP.
5.4.2.2 DHCPv4-Renew
Chaque DHCP-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les bases RADIUS client la procédure de renouvellement de bail entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCP et RADIUS relatifs à un renouvellement de bail :
O 21
•
•
•
o
o
o
o
•
•
•
• 152 avenue Pierre Brossolette
axione 92240 Malakoff
54.3 Détail des échanges RADIUS et DHCPvé
5.4.3.1 DHCPvé-Solicit
Annexe 2B - STAS OPERA Office Pro
22
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
15
16
17
DHCP Request 13 DHCP Request 14
RADIUS Request RADIUS Request
RADIUS Accept RADIUS Accept
DHCP Ack DHCP Ack
DHCP Request
18
BACKBONE FOURNISSEUR
19
IAD
(13) L’IAD de l’abonné envoie un message unicast de type DHCP-Request pour renouveler le bail dhcp en conservant la même adresse IP.
(14) Le DHCP- Request est intercepté et l’option 82 de l’équipement d’accès est insérée.
(15) Le DHCP- Request est bloqué au niveau du BNG qui envoie un RADIUS Access-Request.
(16) En retour le RADIUS Client répond avec un RADIUS Access-Accept. Le BNG met à jour le profil de l’abonné sur la base des informations descendues par le serveur RADIUS.
(17) Le DHCP- Request est alors retransmis par le BNG jusqu’au serveur DHCP du client.
(18) Le serveur DHCP répond alors par un DHCP-Ack à l’abonné.
(19) Le BNG enregistre l’adresse IP de l’abonné en analysant le DHCP-Ack pour mettre à jour sa table DHCP. Celle-ci faisant correspondre l’adresse mac et l’adresse IP de l’abonné. axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Figure 11- Mode DHCP et RADIUS (transaction DHCPvé-Solicit)
IA OÜ
1) L'IAD envoie un DHCPvé-Solicit sur son port réseau.
Equipement d'accès (OLT)
(2) L'équipement d'accès se comporte en relai DHCPvé en encapsulant la requête Solicit dans un message DHCPvé6 Relay-Forward et y insère le circuit-id de l'abonné. Le circuit-ID étant l'option 18, Interface-ID, faisant apparaitre les informations suivantes :
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BNG
Sur réception du message DHCPvé Relay-Forward (Solicit), le BNG Nominal bloque la transaction jusqu'à ce que l’abonné soit identifié. Pour cela le BNG génère un RADIUS Access-Request à destination du Proxy RADIUS Fournisseur (3) en recopiant certains champs du message DHCP dans sa requête dont le circuit-id.
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’'abonné sur la base de son circuit-id et proxifie l'Access- Request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access- request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
O 23
LE
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
3
5
7
DHCPv6 Solicit 1 DHCPv6 Relay-Forward (Solicit) 2
RADIUS Request 4 RADIUS Request
6 RADIUS Accept RADIUS Accept
DHCPv6 Relay-Reply (Relay-Reply (Advertise))
DHCPv6 Relay-Reply (Relay-Reply (Reply))
DHCPv6 Relay-Forward (Relay-Forward (Solicit))
8
14
DHCPv6 Relay-Forward (Relay-Forward (Request))
15
BACKBONE FOURNISSEUR
IAD
DHCPv6 Request DHCPv6 Relay-Forward (Request)
9
DHCPv6 Reply DHCPv6 Relay-Forward (Reply)
11 12 13
16
DHCPv6 Advertise DHCPv6 Relay-Reply (Advertise) 10
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id = :;
Les attributs radius suivants seront transmis sur demande du client :
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS Access-Accept (5) au proxy-RADIUS Fournisseur contenant
les informations suivantes :
Class = FTTH-PRO- DLmk-ULmk
: La valeur du débit HSI down max en Mbit/s
: La valeur du débit HSI up max en Mbit/s
: La valeur du débit VolP down max en kbit/s
: La valeur du débit VolP up max en kbit/s.
L'attribut permet de distinguer le profil de débit à appliquer à l'abonné. Il est construit en se référant aux valeurs maximales des débits descendants DATA/VOIP et des débits montants DATA/VOIP.
Ci-après un exemple de code offre :
OPERA Office PRO avec débit symétrique Data 100Mbps et voix de 500Kbps. Class= FTTH-PRO-DLI00m500k-ULI00m500k
Le proxy-Radius Fournisseur transmet le Radius Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6) :
Identifiant Service du client ;
Identifiant de l'abonné ;
Profile de QoS (Class renvoyé par le Radius Client).
À réception de l'Access-Accept, l'abonné est instancié, au sein du BNG, dans le VPN du client avec son profil de Qos.
À ce stade l'abonné n'a toujours pas obtenu d’IP. Le BNG relaie alors le message DHCPvé6 qui a déjà été relayé par l'OLT vers le serveur DHCP du client (7).
Ici le BNG se comporte en relai DHCPvé6 et vient ajouter une seconde encapsulation de type Relay-Forward au message Solicit de l’'abonné.
S'ensuit alors un dialogue DHCPvé standard entre l'IAD de l'abonné, les 2 relais DHCP (OLT et BNG) et le serveur DHCP du client :
DHCPvé Relay-Reply(Relay-Reply(Advertise)) (8) ;
DHCPvé Relay-Reply(Advertise) (9) :
DHCPvé Advertise (10) ;
DHCPvé Request (11) :
DHCPvé Relay-Forward (Request) (12) ;
DHCPvé Relay-Forward (Relay-Forward (Request)) (13) ;
DHCPvé Relay-Reply(Relay-Reply(Reply)) (14) :
DHCPvé Relay-Reply(Reply) (15) ;
DHCPvé Reply (16).
O 24
•
•
•
•
•
o
•
o
o
o
o
•
•
•
•
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Le DHCPvé Relay-Reply(Relay-Reply(Reply)) (14) permet au BNG Fournisseur de connaître l'adresse IP de l'abonné, la durée du preferred-lifetime et la valeur des compteurs T1/T2 (Renew/Rebind DHCP).
5.4.3.2 DHCPvé6-Renew
Chaque DHCPvé-Renew entraîne une nouvelle authentification de l’abonné. Si le profil de l'abonné a changé dans les bases RADIUS client la procédure de renouvellement de bail (réinitialisation du compteur preferred-lifetime) entrainera la
mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCPvé6 et RADIUS relatifs à un renouvellement de bail :
Figure 6 - Mode DHCP et RADIUS (renouvellement du Preferred-Lifetime DHCPvé)
(17) L'IAD de l’abonné envoie un message de type DHCPvé-Renew pour renouveler le bail dhcp en conservant la même adresse IP.
(18) DHCPvé-Renew est intercepté par l'équipement d'accès (OLT) et relayé dans un message DHCPvé Relay-Forward
(Renew) en y insérant le circuit-id de l’'abonné. Le circuit-id étant l'option 18 DHCPveé.
(19) (20) Le message DHCPvé6 Relay-Forward (Renew) est bloqué au niveau du BNG qui envoie un RADIUS Access- Request à destination du serveur client via le proxy Fournisseur.
(21) (22) En retour le RADIUS Client répond avec un RADIUS Access-Accept. Le BNG met à jour le profil de l'abonné sur la base des informations descendues par le serveur RADIUS.
(23) Le message DHCPvé6 Relay-Forward (Renew) est alors relayé par le BNG jusqu'au serveur DHCP du client.
(24) Le serveur DHCP client répond alors par un DHCPvé Reply encapsulé par un message Relay-Reply permettant d'adresser les 2 relais DHCPvé, BNG et OLT, pour joindre l'IAD de l'abonné.
(25) Le BNG enregistre les paramètres IP de l'abonné en analysant le message DHCPvé reçu pour mettre à jour sa table DHCP. Celle-ci faisant entre autre correspondre l'adresse mac et l'adresse IP de l'abonné.
Le BNG retransmet le message DHCPvé6 après avoir supprimé l'entête Relay-Reply le concernant.
(26) L'équipement d'accès (OLT) retransmet à l'IAD de l’abonné le message DHCPv6 après avoir supprimé l'entête Relay- Reply le concernant.
5.5 Mode Full RADUIS
Dans le mode Full RADIUS, le client n’a pas à maintenir un serveur DHCP, c'est le BNG Fournisseur qui prend ce rôle.
O 25
LE
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
21
23
RADIUS Request RADIUS Request
RADIUS Accept RADIUS Accept
DHCPv6 Relay-Reply (Relay-Reply (Reply))
DHCPv6 Relay-Forward (Relay-Forward (Renew))
24
BACKBONE FOURNISSEUR
25
IAD
DHCPv6 Renew DHCPv6 Relay-Forward (Renew) 17 18
19
20
22
DHCPv6 Reply DHCPv6 Relay-Forward (Reply) 26 axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Le client a la possibilité :
soit, d'attribuer des adresses IP fixes à ses abonnés ;
soit, d'attribuer des adresses IP dynamiques pour une durée de 2 heures.
5.5.1 Authentification et adressage IP de l’abonné
À chaque nouvel échange IP/DHCP (DHCPv4-Discover / DHCPv4-Renew ou DHCPvé-Solicit / DHCPvé-Renew), une demande d'authentification RADIUS (RADIUS Access-Request) est envoyée au serveur RADIUS Client au travers d’un Proxy-RADIUS Fournisseur.
Une fois cette demande d'authentification validée par le serveur RADIUS client (RADIUS Access-Accept), le BNG Fournisseur joue le rôle de serveur DHCP en répondant à la demande DHCP (Discover ou Renew) de l'abonné.
Une fois la phase d’authentification passée, le dialogue IP/DHCP client/serveur se déroule de façon standard.
Le BNG Fournisseur attribuera des adresses IP pour une durée de 2 heures (bail DHCPv4 / preferred-lifetime pour DHCPvé = 2 heures).
Pour une requête DHCPv4, le BNG servira une IPv4.
Pour une requête DHCPvé, le BNG servira un IA_NA et un IA_PD.
Dans le cas d'IAD adressés en double pile, IPv4/1Pv6, le serveur Radius Client renvoie les paramètres IPv4 et IPvé6 de
l'abonné dans le même message Radius Access-Accept.
5.5.2 Détail des échanges RADUIS et DHCP
5.5.2.1 DHCPv4-Discover
Hagus “Hi pra
rpg
fl! LI
Figure 7 - Mode FULL RADIUS (transaction DHCPv4-Discover)
OÜ A
(1) L'IAD envoie un DHCP Discover sur son port réseau.
Equipement FTTH d'accès
O 7
•
•
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
3
5
7
DHCP Discover 1 DHCP Discover 2
RADIUS Request 4 RADIUS Request
6 RADIUS Accept RADIUS Accept
DHCP Offer
8
DHCP Ack 9
DHCP Request
BACKBONE FOURNISSEUR
IAD axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
(2) Celui-ci insère l'option 82 dans le DHCP Discover du client en y renseignant les informations suivantes :
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BNG
(3) À réception du DHCP Discover, le BNG Nominal bloquera le DHCP Discover de l'IAD Abonné. Il générera un RADIUS Access Request à destination du proxy-RADIUS Fournisseur afin d'identifier l'abonné en recopiant certains champs du DHCP Discover dans sa requête (circuit-id, remote-id et vendor-dhcp).
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’abonné sur la base de son circuit-id et proxifie l'access- request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access-
request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id=;
ADSL-Agent-Remote-id=.
Les attributs radius suivants seront transmis sur demande du client :
Alc-DHCP-Vendor-Class-ld = ;
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS access-accept (5) au proxy-RADIUS Fournisseur contenant les informations suivantes :
Class ;
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns.
Proxy-RADIUS Fournisseur
Le PROXY-RADIUS Fournisseur transmet le RADIUS Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6).
Identifiant Service du client ;
Identifiant de l'abonné ;
Profil de QoS (dérive de l'attribut Class renvoyé par le client).
O 27
•
•
•
•
•
•
•
•
•
•
o
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
À réception de l'Access-Accept, l'abonné est instancié dans le VPN du client avec son profil de Qos.
Le BNG répond à l’abonné (DHCP-Offer) en proposant les paramètres réseaux qui lui ont été communiqués par le serveur RADIUS (7).
L'abonné envoie un DHCP-Request (8). Le BNG, qui joue le rôle de serveur DHCP, lui retourne un DHCP-Ack(9).
L'abonné dispose d’un bail de 2 heures.
5.5.2.2 DHCPv4-Renew
Chaque DHCP-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les
bases RADIUS client la procédure de renouvellement de bail entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCP et RADIUS relatifs à un renouvellement de bail :
Figure 8 - Mode FULL RADIUS (renouvellement du Bail DHCPv4)
10) L'IAD de l’abonné envoie un DHCP-Request. (
(11) Le DHCP-Request est intercepté et l'option 82 de l'équipement d'accès est insérée.
(12) Le DHCP-Request est bloqué au niveau du BNG qui envoie un RADIUS Access-Request.
( 13) En retour le RADIUS du client répond avec un RADIUS Access-Accept. Le message doit contenir les attributs suivants : Class ;
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns.
(14) Le BNG met à jour le profil de l’abonné sur la base des informations descendues par le serveur RADIUS. Il envoie un message DHCP-ACK à l'abonné contenant les paramètres réseaux descendus par RADIUS.
5.5.3 Détail des échanges RADUIS et DHCPvé
5.5.3.1 DHCPvé-Solicit
O 28
LE
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
MC Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
12
13
14
DHCP Request 10 DHCP Request 11
RADIUS Request RADIUS Request
RADIUS Accept RADIUS Accept
DHCP Ack
BACKBONE FOURNISSEUR
IAD
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
(il
Figure 9 - Mode FULL RADIUS (transaction DHCPvé-Solicit)
> D
1) L'IAD envoie un DHCPvé-Solicit sur son port réseau. TS
Equipement d'accès (OLT)
(2) L'équipement d'accès se comporte en relai DHCPvé en encapsulant la requête Solicit dans un message DHCPvé6 Relay-Forward et y insère le circuit-id de l'abonné. Le circuit-ID étant l'option 18, Interface-ID, faisant apparaitre les informations suivantes :
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BN
Sur réception du message DHCPvé Relay-Forward (Solicit), le BNG Nominal bloque la transaction jusqu'à ce que l’abonné soit identifié. Pour cela le BNG génère un RADIUS Access-Request à destination du Proxy RADIUS Fournisseur (3) en recopiant certains champs du message DHCP dans sa requête dont le circuit-id.
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’abonné sur la base de son circuit-id et proxifie l'access- request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access- request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id=;
O 29
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Axione Serveurs RADIUS et DHCP
3
5
RADIUS Request 4 RADIUS Request
6 RADIUS Accept RADIUS Accept
BACKBONE AXIONE
IAD
DHCPv6 Solicit 1 DHCPv6 Relay-Forward (Solicit) 2
DHCPv6 Request DHCPv6 Relay-Forward (Request)
7
DHCPv6 Reply DHCPv6 Relay-Reply (Reply)
9 10
11
12
DHCPv6 Advertise DHCPv6 Relay-Reply (Advertise) 8
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Les attributs radius suivants seront transmis sur demande du client :
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS access-accept (5) au proxy-RADIUS Fournisseur contenant les informations suivantes :
Class ;
Paramètres IPv4 en cas d’abonné en double pile
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns ;
Paramètres lpvé
Alc-lpvé-Address ;
Delegated-IPv6-Prefix ;
Alc-lpvé-Primary-DNS ;
Alc-Ipvé-Secondary-DNS.
Proxy-RADIUS Fournisseur
Le PROXY-RADIUS Fournisseur transmet le RADIUS Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6) :
Identifiant Service du client ;
Identifiant de l'abonné ;
Profil de QoS (dérive de l'attribut Class renvoyé par le client).
À réception de l'Access-Accept, l'abonné est instancié, au sein du BNG, dans le VPN du client avec son profil de Qos.
Le BNG prend le rôle de serveur DHCP. Il renseigne les paramètres réseaux de l'abonné, qui lui ont été communiqués par le serveur RADIUS, dans un message DHCPv6 Advertise puis l’'encapsule par un entête Relay-Reply à destination de l'équipement d'accès, l'OLT (7).
S'ensuit alors un dialogue DHCPvé6 standard entre l'IAD de l'abonné, 1 relais DHCP et le serveur DHCP du BNG :
DHCPvé Relay-Reply(Advertise) (7)
DHCPvé Advertise (8)
DHCPvé Request (9) ;
DHCPvé Relay-Forward (Request) (10) :
DHCPvé Relay-Reply(Reply) (11) :
DHCPvé Reply (12).
L'abonné dispose d’un bail (ou preferred-lifetime) de 2 heures.
5.5.3.2 DHCPvé-Renew
Chaque DHCP-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les bases RADIUS client la procédure de renouvellement de bail entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCP et RADIUS relatifs à un renouvellement de bail :
O 30
•
o
•
o
•
•
•
•
•
o
•
•
•
•
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Figure 10- Mode FULL RADIUS (renouvellement du Preferred-Lifetime DHCPvé)
(13) L'IAD de l'abonné envoie Un message de type DHCPvé-Renew pour renouveler le bail dhcp en conservant la même adresse |P.
(14) DHCPvé-Renew est intercepté par l'équipement d'accès (OLT) et relayé dans un message DHCPvé Relay-Forward (Renew) en y insérant le circuit-id de l’'abonné. Le circuit-id étant l'option 18 DHCPveé.
(15) (16) Le message DHCPvé Relay-Forward (Renew) est bloqué au niveau du BNG qui envoie un RADIUS Access- Request à destination du serveur client via le proxy Fournisseur.
(17) En retour le RADIUS du client répond avec un RADIUS Access-Accept. Le message doit contenir les attributs suivants
Class ;
Paramètres IPv4 en cas d’abonné en double pile
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns ;
Paramètres lpvé
Alc-lpvé-Address ;
Delegated-IPv6-Prefix ;
Alc-lpvé-Primary-DNS ;
Alc-Ipvé-Secondary-DNS.
(18) Le BNG met à jour le profil de l'abonné sur la base des informations descendues par le serveur RADIUS.
(19) Le BNG renseigne les paramètres réseaux de l’abonné, qui lui ont été communiqués par le serveur RADIUS, dans un
message DHCPvé Reply puis l'encapsule par un entête Relay-Reply à destination de l'équipement d'accès, l'OLT.
(20) L'équipement d'accès OLT désencapsule le message DHCPvé6 et le transmet à l'IAD de l'abonné.
5.5.4 Limitation connue
Dans le mode Full Radius, l'option DHCPvé n°64 « Dual-Stack Lite AFTR Name » ne peut pas être délivrée au client DHCP. Le BNG Fournisseur est à l'origine de cette limitation car il ne reconnaît pas l'attribut RADIUS contenant le nom de domaine de l’AFTR.
O 31
LE
BNG
RESEAU RIP RESEAU USAGER RESEAU ABONNE
ONT Equipement d’accès (OLT) BNG Routeur Backbone Routeur usager Proxy RADIUS Serveurs RADIUS et DHCP
17
19
RADIUS Request RADIUS Request
RADIUS Accept RADIUS Accept
BACKBONE FOURNISSEUR
IAD
DHCPv6 Renew DHCPv6 Relay-Forward (Renew) 13 14
15
DHCPv6 Reply DHCPv6 Relay-Forward (Reply) 20
16
18
•
o
•
•
•
•
•
o
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
5.6 Adressage IP des abonnés
5.6.1 Type d'adressage
L'adressage IP des abonnés est sous la responsabilité du client. Il peut être de type public, privé ou réservé selon les besoins de ses services.
Pour rappel les ranges d'adresses IP privées définis par l'IANA sont décrits dans le RFCI918 (Address Allocation for Private Internets) :
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Le range d'adresses IP globales partagées est défini dans le RFC6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) :
100.64.0.0 - 100.127.255.255 (100.64/10 prefix)
Cet espace d'adressage se rapproche, de par son utilisation, des ranges IP privés du RFCI918. Il n'est pas routé sur le réseau internet et est destiné à la numérotation des interfaces IPv4 des infrastructures mettant en relation les Carrier Grade Nat avec les équipements CPE des abonnés. Son usage permettant d'une part de contourner les éventuels
dysfonctionnements du NAT des CPE lorsque la numérotation des interfaces inside et outside est de type privée, et d'autre part pour ne pas avoir de conflit entre l'adressage du lan des abonnés et wan des CPE.
5.6.2 Gestion des pools IP des abonnés
Lorsque les abonnés sont collectés dans les plaques Point-Multipoint (technologie GPON), le client ISP à la possibilité de gérer les pools IP en mode mutualisé ou par zone.
5.6.2.1 Mutualisation des pools IP
Avec ce mode d’adressage, le client ISP est en mesure de mutualiser les pools IP de ses abonnés entre plusieurs plaques Point-Multipoint du réseau du Fournisseur où bien entre ses opérateurs de collecte.
En conséquence, les annonces de la session eBGP_Data sur l'interface de Collecte permettront de distinguer individuellement chacun des abonnés avec un préfixe spécifique /32 pour IPv4 ou les préfixes spécifiques IA_Na en /64 et IA_PD, de /32 à /64, pour IPvé6 par lAD.
Dans ce mode, il est du ressort du client ISP de garantir l’unicité des adresses IP allouées aux abonnés. C'est-à-dire que le Fournisseur n'effectuera aucun contrôle sur les réponses Radius ; par exemple si une même adresse IP est allouée à deux abonnés différents sur 2 BNG différents, le préfixe spécifique sera annoncé en doublon.
En cas de transfert d'une plaque FTTH exploitée par le Fournisseur vers un autre opérateur de collecte, et vice-versa, il sera de la responsabilité du client ISP de gérer le nouvel adressage.
5.6.2.2 Gestion des pools IP par zone dans le réseau du Fournisseur
Dans ce mode d'adressage, le client ISP déclare au Fournisseur, à travers le fichier « Fiche d’interco FTTH », la liste des ranges d'adresses IPv4 et/ou IPvé des abonnés ainsi que leur zone d'affectation.
Les routes spécifiques (/32 en IPv4 ou /32 à /64 en IPv6) des IAD sont filtrées par les BNG et seuls les ranges d'adresses sont annoncés dans le VPN IP.
Les pools IPv4 et/ou IPv6 fournis par le client sont associés au réseau de collecte d'une plaque.
Remarque : Pour chaque plaque, le client attribue une ou plusieurs plages IPv4 dont la taille à minima est celle d’un
réseau de classe C (256 adresses).
O 32
LE
•
•
•
•
En conséquence, les annonces de la session eBGP_Data sur l’interface de Collecte annonceront le préfixe correspondant à chacun des pools IP IAD. axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
5.6.3 Adresses IP réservées
Dans le mode « DHCP & Radius », les BNGs du Fournisseur utilisent une adresse de loopback active dans le contexte de
routage dédié à l'opérateur client pour relayer les messages DHCP vers le serveur DHCP.
Au choix du client ces adresses de loopback, IPv4 ou IPvé6 selon les besoins du service, sont :
Soit les 2 premières adresses du premier sous réseau géré par les BNGSs ;
Soit 2 adresses appartenant à des sous réseaux distincts.
5.7 Profils de QoS Abonné IPOE
Le client peut demander l'implémentation de 3 profils de QoS maximum. Chaque profil est associé à une « Class »qui est échangée lors de l'authentification RADIUS comme décrit à la section « Echange Radius en mode IPoE».
Les profils sont gérés au niveau du BNG Fournisseur.
Pour chaque profil de Qos, un maximum de 2 files d'attentes ingress et egress (sens montant et descendant) est instancié par abonné.
Le trafic de l'abonné est mappé dans l’une ou l’autre de ces files d'attentes en fonction du champ IP PRECEDENCE.
VolP : IP Precedence = 5, 6, 7
DATA : IP Precedence = 0, 1, 2, 3,4
Chaque file d'attente peut disposer d’une valeur de CIR et PIR qui lui est propre.
Un PIR global est défini pour l'abonné pour l'ensemble des files d'attentes
Les valeurs maximales de chaque classe de service sont données dans le tableau ci-dessous :
Service CIR Up PIR Up CIR Down PIR Down Remarque
VolP 500k 500k 500k 500k Pour ce service : CIR=PIR
DATA OM 500M OM 1G
Le débit maximum total pour un abonné est : IGbps / 500Mbps.
Le schéma ci-dessous présente la gestion de la QoS par abonné OPERA Office Pro :
Max_Ingress
090 Figure 11 - Profil de QoS en mode IPoE O 33
•
•
•
•
Aggregate-Scheduler = Max_Ingress
Aggregate-Scheduler Max_Egress
Ingress= trafic montant
Egress= trafic descendant
VoIP
Prec 5,6, 7
CIR=PIR=MaxVoIP
CIR-PIR Level 7
Data
Prec Default
PIR=Max_Ingress
CIR-PIR Level 1
VoIP
Prec 5,6, 7
CIR=PIR=MaxVoIP
CIR-PIR Level 7
Data
Prec Default
PIR=Max_Egress
CIR-PIR Level 1 axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
6. MODE D'ACCES PPP ET LIVRAISON L2TP
6. Principe et modélisation de la livraison L2TP
)
Figure 12 — Architecture collecte PPP livrée en L2TP
Le Fournisseur transporte les sessions PPP initialisées par les IAD jusqu'à l'interface de collecte. Les sessions sont ainsi prolongées et livrées à travers des tunnels L2TP (Layer 2 Tunnelling Protocol - RFC-2661) jusqu'au réseau du client.
Le Fournisseur dispose de BNG redondant au sein des réseaux d'initiative publique qui jouent le rôle de LAC. Les tunnels L2TP sont établis entre les BNG et un ou plusieurs LNS client.
En préalable à l'établissement des tunnels L2TP et des sessions PPP, un dialogue RADIUS est nécessaire entre le Fournisseur et le client permettant l'authentification et la configuration des IAD Abonné.
Ces deux mécanismes permettent un partage des responsabilités entre le Fournisseur et le client :
Le Fournisseur est en charge du transport des sessions PPP depuis les sites Abonné jusqu'à l'interface de collecte
Le client est responsable de l'authentification des IAD, la terminaison des sessions PPP des abonnés et leur configuration (assignation d'adresse IP, ….).
Le schéma ci-après modélise les couches protocolaires mises en œuvre :
O 34
Proxy Radius
BNG
dupont@client1
Flux Radius Reseau Client1
Interface
abonné
Interface collecte
OLT
IAD
Réseau
Collecte
Réseau
Transport
Radius
Client
LNS
Backup
LNS
primaire
Porte Nominale
Porte Secours
Session PPP
Tunnel L2TP
Infrastructure Fournisseur
ONT
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
< IP z
session PPP Fe Tunnel L2TP |
+ Te E= 7 +
< session PPPOE >
ce ll SZ Ù = AT J , . Ta
es KD or see ce VPN IP ISP = Es ER?
ONT PPPOE-IA LAC = ENS s \
PPPOE-IA = PPPOE Întermediate Agent Proxy-Radius Radius-ISP L2TP = Layer 2 Tunnelng Protocol Fournisseur LAC = L2TP Access Concentrator
LNS = L2TP Network Server
10/N°*10/100GigE
Figure 13 - Transport session PPP dans tunnel L2TP
Pour chaque abonné, une session L2TP est créée à l'intérieur du tunnel. Cette session est négociée au moment de prolonger la session PPP jusqu'au LNS du Client (i.e. une fois que le BNG a authentifié l'abonné).
Une fois le tunnel et la session établis, la session PPP entre l'abonné et le client peut être initialisée de façon complètement transparente pour le Fournisseur.
L'initialisation de la session PPP se déroule comme suit :
L'IAD initie une session PPPOE pour découvrir les BNG susceptibles de le prendre en charge ;
L'IAD initie une session PPP qui est interceptée par le BNG ;
Le BNG demande à l'IAD de s'authentifier ;
L'IAD envoie les paramètres d'authentification (identifiant / mot de passe) au BNG : Le BNG envoie une requête RADIUS d’authentification au Proxy RADIUS Fournisseur ; Le Proxy RADIUS Fournisseur transmet la requête au serveur RADIUS du client ; Le serveur RADIUS du client authentifie l'IAD et envoie un message d'autorisation au BNG (relayé par le Proxy RADIUS Fournisseur) ;
Le BNG prolonge la session PPP jusqu'au LNS du client à travers un tunnel L2TP ;
L'IAD s'authentifie auprès du client et récupère ses paramètres réseaux.
NO
UE
W
D
—
©
9
6.2 Tunnel L2TP
Le tunnel L2TP est créé entre deux équipements : le LAC (L2TP Access Concentrator) et le LNS (L2TP Network Server).
La fonction de LAC est assurée par un équipement Fournisseur identifié par une adresse IP publique ou privée que le
Client aura fournie dans la fiche d'interconnexion.
La fonction de LNS doit être assurée par un équipement sous la responsabilité du Client. Le LNS est identifié par une
adresse IP publique ou privée que le Client aura fournie dans la fiche d’interconnexion.
O 35 axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
La méthode de Tunnel L2TP implique plusieurs protocoles (PPP/L2TP/UDP/IP) pour transporter les paquets IP des
abonnés à travers les réseaux Fournisseur et Client. La décomposition de cette surcouche est précisée ci-après :
Entête PPP = 4 voire 8 octets max
Entête L2TP = 16 octets max
Entête UDP (port 1701) = 8 octets
Entête IP = 20 octets
La surcouche protocolaire entraine par conséquent un overhead de 52 octets maximum pour le trafic IP des abonnés et
44 octets en considérant uniquement le transport des sessions PPP pour le présent service.
Aussi, afin de se prémunir de problème MTU, l'interface du LNS ainsi que celle du LAC sur laquelle est monté le tunnel
L2TP doit avoir une MTU égale à 2000. Les équipements intermédiaires (entre le LAC et le LNS) doivent avoir aussi une MTU supérieure ou égale à 2000.
Le tunnel L2TP doit être établi dynamiquement : le serveur RADIUS du Client communique les informations nécessaires à
son établissement. L'établissement du tunnel suit le processus suivant :
Un IAD abonné lance une demande de connexion via une requête PPP ;
Sur réception de cette requête, le Fournisseur envoie un message RADIUS access_request au serveur RADIUS du
client ;
Le serveur RADIUS du client répond par un message access_accept précisant le tunnel L2TP dans lequel
transporter la session PPP de l'abonné ;
Dans le cas où le tunnel n'est pas encore créé, le LAC Fournisseur négocie l'établissement du tunnel L2TP avec le LNS du client.
Une sécurisation du LNS peut être mise en place. Pour cela, le client doit disposer d’un LNS primaire et d’un LNS de
backup. Les attributs L2TP du message RADIUS « access-accept » doivent, dans ce cas, être tagués. Le Fournisseur
prendra en compte l’attribut « tunnel-preference » pour identifier le LNS primaire. En cas d'échec lors de la tentative de
création du tunnel sur le LNS primaire, le tunnel sera monté sur le LNS de backup.
6.3 Identification Abonné
Le Client peut identifier ses abonnés sur la base des attributs Radius « User-Name (attribut standard n°1)» et/ou « ADSL-
Agent-Circuit-ld (attribut ADSL-Forum 356] - n°1)».
6.3.1 Identification sur la base du « User-Name »
Lors de la phase d'authentification, l'abonné se présente à travers le couple [< nom_ abonné », « mot_de_passe »]
attribué par le client.
Le format du « nom_abonné » devra être avec :
est une valeur alphanumérique. La chaîne de caractère doit contenir au moins un caractère et ne doit pas dépasser 64 caractères
est une valeur alphanumérique qui identifie le client. Le client indique au moment de la commande « l'identifiant-client » à utiliser. L'identifiant du client doit respecter les règles suivantes : Le client ne doit pas utiliser un identifiant correspondant à un terme déposé à l'ICANN (Internet Corporation for Assigned Names and Numbers)
Le client ne pourra pas utiliser un s'il est déjà utilisé par un autre client L'identifiant-client doit contenir au moins 2 caractères et ne doit pas dépasser 63 caractères
O 36
•
•
•
•
•
•
•
•
•
•
o
o
o 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro
92240 Malakoff axiIone
Le client peut demander au Fournisseur d'ajouter l’ dans le « nom_abonné » à condition que ce dernier ne contienne que l’ lorsque l'abonné se présente
Le « mot_de_passe » utilisé par le client pour identifier un abonné devra être une valeur en alphanumérique.
Le Fournisseur définit un caractère alphanumérique comme tout caractère alphabétique de À à Z ou chiffre de O à 9. Un même caractère en majuscule et minuscule représente deux caractères alphabétiques différents.
L'attribut « ADSL-Agent-Circuit-id » est utilisé par le Proxy RADIUS Fournisseur pour identifier l’Utilisateur Final et le serveur RADIUS Client capable de traiter la requête.
6.3.2 Identification sur la base du « Agent-Circuit-ld »
Les équipements OLT ajoutent le PPPOE Tag aux messages PADI/PADR/PADT avec la sous-option Ox01 (Agent-Circuit-
Id).
Le format du PPPOE Tag est défini dans le document BBF TR-I0I 8 3.9.2. Il se compose de plusieurs champs dont le
TAG_ID (0x0105 = Vendor-Specific) et le TAG_ VALUE (vendor id= 0Ox000DE9 = BBF) suivis d'une suite de sous options selon les besoins. Par analogie à l'option 82 DHCPv4, les codes des sous options Agent Circuit ID et Agent Remote ID sont respectivement | et 2.
Le BNG recopie le Circuit-ld dans l’attribut Radius ADSL-Agent-Circuit-Id échangé avec le serveur Radius client.
Le format de l’attribut Radius ADSL-Agent-Circuit-Id est précisé au paragraphe « 3.2.6.Format du Circuit-ID spécifique aux
OLTs » du présent document.
6.4 Adressage IP des abonnés
Dans le mode de collecte PPPoE, les IAD doivent être adressés en IPv4 et/ou IPv6.
Le choix des adresses IPv4 des IAD Abonné est de la responsabilité du Client. Le Fournisseur ne participe pas au routage
des adresses IPv4 du client.
6.5 Profils de QoS Abonné PPP
Le peut demander l'implémentation de 3 profils de QoS maximum. Chaque profil est associé à une « Class » qui est
échangée lors de l’authentification RADIUS comme décrit à la section « Echange Radius en mode PPPoP». Les profils sont gérés au niveau du BNG Fournisseur.
Pour chaque profil de QosS, un maximum de 2 files d'attentes ingress et egress (sens montant et descendant) est instancié par abonné. Chaque file d'attente peut disposer d’une valeur de CIR et PIR qui lui est propre.
Un PIR global est défini pour l'abonné pour l'ensemble des files d'attentes.
Les valeurs maximales de chaque classe de service sont données dans le tableau ci-dessous :
Service CIR Up PIR Up CIR Down | PIR Down Remarque
VolP 500k 500k 500k 500k Pour ce service : CIR=PIR
DATA OM 500M OM 1G
Le débit maximum total pour un abonné est : IGbps / 500Mbps.
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
6.51 Trafic descendant
Dans le sens Client vers l’abonné, afin de différencier les différentes Classes de Service, le Client devra recopier la valeur
des 3 bits de poids fort du champ DSCP (ou IP Precedence) de l'entête IP des paquets de l’'Abonné dans l’entête IP
ajoutée et utilisée pour la session L2TP. Par défaut tout le trafic abonné sera transporté en Best Effort.
VolP : IP Precedence = 5, 6, 7:
DATA : IP Precedence = 0, 1, 2, 3, 4.
6.5.2 Trafic montant
Dans le sens Abonné vers Client, afin de différencier les différentes Classes de Service, le CPE abonné devra
marquer la valeur des 3 bits de poids fort du champ DSCP (ou IP Precedence). Par défaut tout le trafic abonné
sera transporté en Best EffortVolP : IP Precedence = 5, 6, 7;
DATA : IP Precedence = 0, 1, 2, 3, 4.
7. ECHANGES RADUIS
7. Serveurs RADIUS Fournisseur et ISP
Le Fournisseur dispose d'un proxy RADIUS qui relaye les flux RADIUS (authentification et accounting) des abonnés jusqu'aux serveurs RADIUS du client. Le client est responsable de l’authentification et du comptage.
Le client ISP peut installer un ou plusieurs serveurs RADIUS pour l’authentification des abonnés et un ou plusieurs serveurs pour le comptage. Le partage de charge entre les différents serveurs est possible sur le proxy RADIUS Fournisseur. L'algorithme Round Robin permet de distribuer uniformément les requêtes sur les différents serveurs RADIUS.
Le client peut regrouper la fonction d’authentification et comptage sur les mêmes serveurs RADIUS.
Lors de la souscription au service, le client communiquera au Fournisseur :
L'adresse IP publique du ou des serveurs RADIUS d’authentification ;
L'adresse IP publique du ou des serveurs RADIUS de comptage ;
Le secret RADIUS (mot de passe partagé entre le Serveur RADIUS et le Proxy RADIUS).
Le client et le Fournisseur devront convenir d’un numéro de port UDP à utiliser pour les communications RADIUS entre le Proxy RADIUS et le serveur RADIUS. Le Fournisseur propose l'utilisation du port standard UDP 1812 pour l'authentification et 1813 pour le comptage.
Mécanisme Status-Server :
La fonctionnalité Status-Server (RFC 5997) doit être activée sur les serveurs Radius ISP. Cette fonctionnalité est une extension du protocole RADIUS permettant à un client radius (ici les proxys RADIUS Fournisseur) de vérifier l'état opérationnel d'un serveur radius (ici les serveurs RADIUS ISP). Il faut noter que ce mécanisme n'est pas équivalent à un "Keep Alive" permanent et transmis à travers un Access-Requets (RFC2865), mais est déclenché par le client radius lorsque le serveur radius est soupçonné d'être indisponible.
Sur l'absence de réponse à un Access-Request, le client radius envoie immédiatement un message status-server et détermine ensuite l'état opérationnel ou l'accessibilité du serveur par la réception ou l'absence de réponse de ce dernier au message status-server.
Dans le cas d'un radius client disposant de serveurs redondants, un tel mécanisme permet de détecter l'inaccessibilité d'un serveur et solliciter immédiatement un autre serveur sans attendre plusieurs requêtes et l'expiration d'un timeout.
Les messages status-server sont transmis au serveur radius à travers un Access-Request où un Accounting-Request.
O 38
LE
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Le radius serveur répond par un message de type Access-Accept (authentication port) ou Accounting-Response (accounting port) aux sollicitations de type request Authenticator.
Sonde Radius :
Le Fournisseur dispose d’un serveur sonde RADIUS pour effectuer des statistiques de joignabilité RADIUS avec le serveur RADIUS client.
Lors de la souscription au service, le client communiquera au Fournisseur :
Un couple « User-name » / « User-password » dédié à la sonde RADIUS
Le secret RADIUS (par défaut il sera identique à celui partagé entre le Serveur RADIUS et le Proxy RADIUS).
Le client devra, au même titre que pour les proxys RADIUS du Fournisseur, autoriser la sonde RADIUS à interroger son ou ses serveurs RADIUS.
7.2 Echanges RADIUS en mode IPOE
Les sections « Détails des échanges RADIUS et DHCP » ont déjà décrit les échanges RADIUS.
Ce chapitre présente spécifiquement la médiation entre les attributs RADIUS communiqués par l'ISP et par le Fournisseur.
#5 e
Y
À
À
Figure 14 - Détails des Echanges Radius
7.2.1 Access-Request envoyé au client
Le message Access-Request, associé à un échange DHCPv4 et envoyé au client, contient les champs suivants :
User-Name : l'adresse MAC de l'IAD est envoyée dans l’attribut User-Name ; Le client peut demander au
Fournisseur d'ajouter un realm (RFC 2486 83) dans le User-name
User-Password : mot de passe identique quel que soit l’'abonné ;
O 39
•
•
Access-Request
User-Name = 00:17:33:74:ca:95
User-Password = cemoi
ADSL-Agent-Circuit-Id =
0x000601f400010006010e6564672d76616c39322d30313031
ADSL-Agent-Remote-Id =
0x000e6564672d76616c39322d30313031
Alc-DHCP-Vendor-Class-Id = "ISP-BOX version x.y"
NAS-IP-Address = 10.10.10.1
Proxy-Access-Request
Proxy-Access-Accept
Class = « FTTH-GP-“Code-Offre”»
Access-Accept
BNG Fournisseur
Proxy-Radius
Fournisseur Radius Client
Proxy de l’access-
request
Proxy de l’access-
accept
User-Name = 00:17:33:74:ca:95
User-Password = cemoi
ADSL-Agent-Circuit-Id =
0x000601f400010006010e6564672d76616c39322d30313031
ADSL-Agent-Remote-Id =
0x000e6564672d76616c39322d30313031
NAS-IP-Address = 10.10.10.1
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
NAS-IP-Address: adresse IP du NAS (BNG) Fournisseur;
ADSL-Agent-Circuit-ID et ADSL-Agent-Remote-lD. Il s'agit de la recopie des sous options 82 Circuit-id et Remote-id. Ils sont utilisés pour identifier la ligne de l’abonné.
Ces sous options sont encodées au format TLV (Type-Length-Value) dans le datagramme DHCP. Lorsque le BNG recopie
le DHCP Circuit-ID (respectivement Remote ID) dans l'attribut Agent-Circuit-ID (respectivement Agent-Remote-ID), les 2 premiers octets (sub-option-type et length) sont retirés.
Pour un accès point multipoint :
DHCP Circuit-ID : 01216f6c/742d62736e34322d303120706f6e20312f312f30312f30312f342f312f312f
RADIUS Agent-Circuit-ID : Oxéféc/42d62736e343224d303120706f6e20312f312f30312f30312f342f312f312f
Remarque :
Pour les OLT, la totalité de l'attribut radius Agent-Circuit-ld représente l'expression hexadécimale de codes ascii. Il peut
être interprété comme une chaine de caractères ASCII comme le stipule la RFC 4679 (DSL Forum Vendor-Specific RADIUS
Attributes).
Les attributs radius suivants seront transmis sur demande du client :
Alc-DHCP-Vendor-Class-Id : contenant l'option 60 DHCP (Vendor class identifier) de l'IAD. Cette option permet
de connaitre le type d’IAD installé chez l’'abonné ;
Calling-Station-Id : contenant le nom du fournisseur et le type d'équipement d’agrégation. Cette option peut
être utilisée par le client pour identifier l'opérateur de collecte et le type d'infrastructure de collecte. Exemple :
Pour un accès point multipoint Calling-Station-ld = #OLT#
7.2.2 Access-Accept du client
Le RADIUS Client authentifie l'abonné et renvoie un RADIUS Access-Accept (5) au proxy-RADIUS Fournisseur contenant
informations suivantes :
Class = FTTH-PRO- DLmk-ULmKk
: La valeur du débit HSI down max en Mbit/s
: La valeur du débit HSI up max en Mbit/s
: La valeur du débit VolP down max en kbit/s
: La valeur du débit VolP up max en kbit/s.
Le champ Class, défini dans la RFC 2865, permet de différencier les profils à appliquer. Le BNG se base sur cet attribut
pour identifier le profil de QoS devant être appliqué.
Les informations complémentaires suivantes sont requises dans le mode Full RADIUS
Framed-IP-Address
Framed-IP-Netmask
Alc-Default-Router
Alc-Primary-Dns
Alc-Secondary-Dns
O A0
•
•
•
•
o
•
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
7.3 Echanges RADIUS en mode PPPoE
Le protocole d'authentification CHAP devra être utilisé pour l'authentification des abonnés.
Les attributs RADIUS échangés entre le Proxy RADIUS Fournisseur et le serveur RADIUS du client sont listés en annexe.
7.3.1 Etablissement des tunnels L2TP
Dans le mode dynamique, le serveur RADIUS du client envoie au BNG les paramètres nécessaires à la création ou à
identification du tunnel L2TP. Le tableau ci-dessous liste les attributs RADIUS spécifiant le tunnel L2TP à utiliser. Ces
attributs sont ajoutés au message « access_accept » envoyé par le serveur RADIUS du client.
Nom de l'attribut dis Description
Tunnel-Type 64 Type de tunnel à établir : valeur fixée à 3 pour L2TP
Tunnel-Medium-Type 65 Type de protocole de transport : valeur fixée à 1 pour IPv4
Tunnel-Server-Endpoint 67 Adresse IP publique du LNS terminant le tunnel L2TP
Tunnel-Assignment-ID 82 Cet attribut détermine l'identificateur du tunnel L2TP qui sera ultérieurement utilisé par le BNG pour déterminer le tunnel
à utiliser pour le transport de chacun des paquets des
abonnés. Ce champ doit contenir l'adresse IP publique du
LNS.
Le client peut envoyer la description de 2 tunnels. Les attributs doivent dans ce cas être tagués conformément à la RFC
2868. Pour chaque tunnel, le client doit renseigner l'attribut « tunnel-préférence ». Le BNG Fournisseur prend en compte
cet attribut pour identifier le tunnel L2TP primaire et le tunnel L2TP de Backup (le tunnel primaire est celui ayant la
préférence la plus faible).
Caractéristiques de l’attribut « Tunnel-Preference » :
Numéro de Nom de lattribut l'Attribut Description
Tunnel-Preference 83 Préférence permettant de définir le tunnel L2TP primaire (celui qui
a la préférence la plus faible)
Remarques : Les attributs RADIUS permettant de caractériser les tunnels L2TP sont spécifiés dans la RFC 2868.
Le client ISP peut demander à ce que le LAC Fournisseur (BNG) envoie une valeur spécifique de l'Attribute Value Pairs
(AVPSs) Host Name (Attribute Type 7, RFC 3931) lors de l'établissement du tunnel L2TP. Le client ISP déclara cette valeur au Fournisseur, à travers le fichier « Fiche d'interco FTTH ».
7.3.2 Synthèse des échanges lors de l'établissement d’une session PP-L2TP
Le schéma ci-dessous synthétise les messages PPP, L2TP et RADIUS échangés lors de l'ouverture d'une session PPP.
O A] axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Y Y
À
À
À
À
Y
À
Y
<<
Y
Y
À
A
A
Figure 15 - Synthèse des échanges pour la création d'une session PPP-L2TP
7.3.3 Attributs Radius échangés
Les échanges entre le Proxy RADIUS Fournisseur et les serveurs RADIUS du client sont détaillés ci-dessous. Les attributs RADIUS mentionnés sont définis dans les RFC 2865 et 2868 pour l'authentification et RFC 2866 et 2867 pour le comptage.
Remarque : La liste des attributs radius spécifiés dans les messages ci-après n'est pas exhaustive et peut présenter des
différences avec la réalité.
O 42
Lan
Abonné
Réseau
Ethernet / MPLS
Fournisseur
Proxy Radius
Fournisseur
Radius Client
Réseau
Transport IP/MPLS
Fournisseur
Reseau
du FAI
BNG
Fournisseur
LNS
Client
PPP (PADI)
PPP (PADO)
PPP (PADR + pppoe tag)
PPP (PADS)
LCP Config Request (option 3 = CHAP)
LCP Config Request
LCP Config Ack
PAP/CHAP Authentification Response
Radius Access Request
Radius Access Request
Détermination ISP par
analyse attribut Radius
« Agent-Circuit-Id »
Radius Access Accept
Radius Access Accept
ICRQ (Incoming Call Request)
ICRP (Incoming Call Reply)
ICCN (Incoming Call Connected)
ZBL ACK (Zero Length Body)
IPCP Config Request (adresse IP proposée = 0.0.0.0)
IPCP NAK (adresse IP propososée = IP_Abonné)
IPCP Config Request (adresse IP proposée = IP_Abonné)
IPCP ACK (adresse IP acceptée = IP_Abonné)
Session
L2TP
Transparent pour
Fournisseur
SCCRQ (Start Control Call Request)
SCCRP (Start Control Call Reply)
SCCCN (Start ControlCall Connected)
ZBL ACK (Zero Length Body)
Création du
tunnel L2TP si
L2TP en mode
dynamique
Interface
Livraison
OLT
Fourni
sseur
IAD
PPP (PADI + pppoe tag)
PPP (PADI)
PAP/CHAP Authentification Challenge
LCP Config Request (option 3 = CHAP)
LCP Config Ack (option 3 = CHAP)
PAP/CHAP Authentification Success axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
L'authentification RADIUS
Message « access-request » émis par le Proxy RADIUS Fournisseur vers le RADIUS du client
Attibuts associés au paquet RADIUS « ACCESS_REQUEST >»
re Numéro NN Nom de l'attribut PTT Description Syntaxe
User-name ] Nom de l'abonné identifiant_abonné@identifiant_ client
NAS-IP-Address 4 Adresse IP du BNG Fournisseur XXXDOOCXXXIOCX
ADSL | Circuit Id de l'abonné Access_Node_ID PON
Adsl-Agent-Circuit-ld Forum Rack/Frame/Slot/PON/ONU/Onuslt/UNI/1- N° VID
NAS-Port-ID 87 NAS port ID Interface logique de collecte du BNG associée à l'abonné
_Client- _ Alcatel
Alc-Client-Hardware Adresse MAC IAD Abonné XX.XX.XX.XX.XX.XX Addr N° 27
Acct-Session-ld 44 Identifiant de la session
Calling-Station-ld 81 [Identifiant Fournisseur et type équipement #Nom-Fournisseur#OLT d'accès
CHAP-Password 2 Mot de Passe CHAP de l'abonné Password
CHAP-Challenge 60 Challenge CHAP Challenge
Message « access-accept » émis par le RADIUS du client vers le Proxy RADIUS Fournisseur
Attributs associés au paquet RADIUS « ACCESS_ACCEPT »
Numéro Nom de lattribut Attribut Description Sa Lte
Profil à appliquer à l’'Abonné FTTH-PRO-DLmKk- Class 25 ULmk
Attribut obligatoire dans Access-Accept.
Tunnel-Typet) 64 Spécifie le type de tunnel à établir : valeur fixée à 3 pour 3
L2TP.
Attribut obligatoire dans Access-Accept.
Tunnel-Medium-Typet) 65 Spécifie le type de protocole de transport pour le tunnel I
L2TP : valeur fixée à 1 pour IPv4.
Tunnel-Server-Endpoint{) 67 Adresse IP publique du LNS terminant le tunnel L2TP XXX-XXX.XXX.XXX
Cet attribut détermine l’identificateur du tunnel L2TP qui
sera ultérieurement utilisé par le BNG pour déterminer
le tunnel à utiliser pour le transport de chacun des
paquets des abonnés. L’identificateur du tunnel doit
désigner de manière unique un LNS. Le Fournisseur
recommande d'utiliser l'adresse IP publique du LNS pour
cet identificateur. Dans le cas où plusieurs tunnels
doivent être créés entre un BNG et un ENS, Le
Fournisseur recommande d'ajouter une chaîne
supplémentaire à l'adresse IP du LNS.
Tunnel-Assignment-ID) 82 XXX-XXX.XXXXXX
(1) : Envoyé uniquement lors d’un établissement dynamique du tunnel L2TP
O 43
•
• axione 152 avenue Pierre Brossolette Annexe 2B - STAS OPERA Office Pro — 92240 Malakoff
Message « access-reject » émis par le RADIUS du client vers le Proxy RADIUS Fournisseur
Aucun attribut n'est requis dans ce message.
A4
• 152 avenue Pierre Brossolette
axione 92240 Malakoff
ANNEXE I : GLOSSAIRE
Annexe 2B - STAS OPERA Office Pro
ACL Access Control List
BGP Border Gateway Protocol
BNG Broadband Network Gateway
CIR Committed Information Rate
DHCP Dynamic Host Configuration Protocol
DSCP Differenciated Service Code Point
GPON Gigabit Passive Optical Network
HSI High Speed Internet
IAD Integrated Access Device
IGMP Internet Group Management Protocol
LAN Local Area Network
MSDP Multicast Source Discovery Protocol
NRO Nœud de Raccordement Optique
OLT Optical Line Terminal
ONT Optical Network Terminal
PIM-SM Protocol Independant Multicast - Sparse Mode
PIM-SSM Protocol Independant Multicast - Source Specific Multicast
PIR Peak Information Rate
PPP Point-to-Point Protocol
PPPOE Point-to-Point Protocol over Ethernet
RFC Request For Comment
RP Rendez-vous Point
STB Set Top Box
VLAN Virtual LAN
VoD Vidéo on Demand
VolP Voice Over IP
VPN Virtual Private Network
VPLS Virtual Private Lan Service
A5 152 avenue Pierre Brossolette
axione 92240 Malakoff
ANNEXE 2 : DICTIONNAIRE RADIUS
Annexe 2B - STAS OPERA Office Pro
# Standard
#
ATTRIBUTE User-Name 1
ATTRIBUTE User- Password 2
ATTRIBUTE NAS-IP-Address 4
ATTRIBUTE NAS-Port 5
ATTRIBUTE Service-Type 6
ATTRIBUTE Framed-IP-Address 8
ATTRIBUTE Framed-IP-Netmask 9
ATTRIBUTE Class 25
ATTRIBUTE Configuration-Token 78
ATTRIBUTE Calling-Station-ld 31
ATTRIBUTE Tunnel-Type 64
ATTRIBUTE Tunnel-Medium 65
ATTRIBUTE Tunnel- Server-Endpoint 67
ATTRIBUTE Tunnel- Assignment 82
ATTRIBUTE NAS-Port-Id 87
ATTRIBUTE Delegated IPvé Prefix 123
#
# Alcatel vendor specifics
#
VENDORATTR 6527 Alc-DHCP-Vendor-Class-Id
VENDORATTR 6527 Alc-Default-Router
VENDORATTR 6527 Alc-Primary-Dns
VENDORATTR 6527 Alc-Secondary-Dns
VENDORATTR 6527 Alc-Client-Hardware-Addr
VENDORATTR 6527 Alc-Ipvé-Address
VENDORATTR 6527 Alc-1pvé-Primary-DNS
VENDORATTR 6527 Alc-Ipvé-Secondary-DNS
#
#ADSL-Forum
#
VENDORATTR 3561 ADSL-Agent-Circuit-Id
VENDORATTR 3561 ADSL-Agent-Remote-ld
string
string
ipaddr
integer
integer
ipaddr
ipaddr
string
string
string
string
string
string
string
string
ipvépref
36 string
18 ipaddr
9 ipaddr
10 ipaddr
27 MAC addr
99 ipvéadar
105 ipvéadar
106 ipvéadar
1 string
2 string
46 CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
Annexe 2B — STAS OPERA Office 100M
ST mm. “OFFICE
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M 92240 Malakoff
Table des matières
1.
2.
Présentation du document... rennes 4
Description du Service nn 4
2.1 Description générale du Service... rennes 4
2.2 Schémas de principe ner 6
2.3 Classes de service rÉSEQU... nr rnrnnrnrnnrnnrnnrnnnnrnrnnnennnnnnnnnnennnnnnnnnnnnnnnnrnnnnnnnnnnnnnnnnnnnnnnnennnnnnnes 7
Infrastructure de collecte... ss 7
3.1 Collecte Point-MulItipoint..nnn rennes 7
3.1.1 SYnoOptIQUeE nn 7
3.1.2 Caractéristiques des éléments actifs inner 9
3.2 Format du Circuit-ID rennes 9
3.2.1 Circuit-ID nr 9
3.2.2 DHCPVA ii nnrnrnrnrnenrnnrnennennnnnnnnnnnnnnnennnennnnnnnnnnnnnennnnennnnnnenennnnnennnnneennnnnnnnnnnennnes 10
3.2.3 DHCPVÉ nn rrnrrnrnrnnrnnrnennrnrnennennnennrnnnenennnnnennnnennnnnnnnnnnnnnnnnnnennnnnnenennnnnnnnnnnennnnnnennnennnes 10
3.2.4 PPPOËE Tag... nn 10
3.2.5 SYSNGME NN rnnrnnrnnnnnnrnennrnennnnennnennnnennnnnnnrnnnnnnnnnennnennnnennnnnnnenennnnennnennnne nee 10
3.2.6 Format du Circuit-ID spécifique aux OLTS... rennes Il
Interface d'accès au Srvice nn rrrnnnnnnennnnnnennnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnes 12
AU L'interface AbONNÉ nn 12
AIT Spécifications du port Ethernet de l'ONT nr 13
4.1.2 Raccordement AbONNÉ... nn 13
AÏA4 Spécifications IP. rennes 14
4.2 L'interface de Collecte... sise 14
4.21 Spécification des interfaces physiques rennes 14
4.2.2 Interconnexion IP rennes 15
Modes d'acces et liVraison poemes 17
51 Gestion IP/DHCP AbOnNÉ nee 17
5.2 Gestion profil de QoS AbONNÉ nn rennes 17
5.3 Paramétrage IP et DHCP. rennes 17
5.3.1 Durée de vie des adresses IPV6.. nn 17
5.3.2 Compteurs DHCP nn 18
5.4 Mode DHCP et RADIUS nr 19
5.41 Authentification et adressage IP de l'AbONNÉ.... nr 19
5.4.2 Détail des échanges RADUIS et DHCPVA4 rennes 19
5.4.3 Détail des échanges RADUIS et DHCPVÉ LL nnnrrnnrnnrnrnnnnrnnnnnnnrnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnee 21
5.5 Mode full RADIUS rennes 24
5.5.1 Authentification et adressage IP de l'abonné..... ire 25
5.5.2 Détail des échanges RADIUS et DHCP. rennes 25
5.5.3 Détail des échanges RADIUS et DHCPVÉ rennes 27
5.5.4 Limitation CONNUE... nn nnnnnennnnnnnee 30
5.6 Adressage IP des abonnés... rennes 31
O 2 LE axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
5.6.1 Type d'adressage inner 3]
5.6.2 Gestion des pools IP des GhOonnÉs.... rennes 3]
5.6.3 Adresses IP réservées... inner 32
5.7 Profil de QoS Abonné IPOE rennes 32
6. Modes d'acces PPP et livraison L2TP.. nn 33
6.1 Principe et modélisation de la livraison L2TP nn 33
6.2 Tunnel L2TP nn 35
6.3 Identification AbONNÉ.... LL rrnnrrnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnennnnnnnnnnnnnnnes 35
6.3.1 Identification sur la base du « User-Name ».. rennes 36
6.3.2 Identification sur la base du « Agent-Circuit-1d >... nr 36
6.4 Adressage IP des abOnnÉS.... ire 36
6.5 Profils de QoS des Abonné PPP.. nn 36
6.51 Trafic descendant... ire 37
6.5.2 Trafic montant... inner 37
7... Echanges Radius.... nee nnnneenennnnnnnnnnennnnnes 37
7.1 Serveurs RADIUS Fournisseur et ISP... nee 37
7.2 Echanges RADIUS en mode IPOE.... rennes 38
7.2.1 Access-Request envoyé au Client. 39
7.2.2 Access-Accept du Client ner 40
7.3 Echanges RADIUS en mode PPPOE... nr 40
7.31 Etablissement des tunnels L2TP. nn 40
7.3.2 Synthèse des échanges lors de l'établissement d'une session PPP-L2TP nn A]
7.3.3 Attributs RADIUS échangés nee 42
Annexe 1 : Dictionnaire RadiuS.….... ire 45
Annexe 2 : GIOSSGIrE rene nnnennnnnnnnnnnnnnnnnnnennnnes 46 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
1. PRESENTATION DU DOCUMENT
Ce document décrit les conditions techniques d'accès au service OPERA Office 100M.
Il se compose des parties suivantes :
Présentation du Service OPERA Office 100M :
Description de l'infrastructure de collecte ;
Description des interfaces de livraison (abonné et collecte) :
Gestion des abonnés (IP/DHCP, PPP/L2TP) ;
Echanges RADIUS entre l'ISP et le Fournisseur ;
Profils de QosS client sur les BNG Fournisseur.
Le respect des conditions décrites dans le présent document est fondamental pour la garantie de fourniture du service
par le Fournisseur. Le Fournisseur ne pourrait pas garantir la fourniture du service dans le cas de non-respect de ces conditions. Dans tous les cas, la compatibilité des échanges entre le Fournisseur et le client sera validée lors d'une phase de tests préalables au démarrage du service. Des modifications seront étudiées en cas d'incompatibilité.
Dans ce document les termes « Client », « Abonné » et « ONT » ont la signification suivante :
Client : fait référence au Client ou l'usager utilisant les infrastructures de collecte et transport du Fournisseur afin de délivrer un ou plusieurs services à ses utilisateurs ;
Abonné : fait référence à un utilisateur final de type professionnel ayant souscrit un service auprès du Client ;
ONT : Optical Network Terminal, fait référence à l'équipement de terminaison GPON installé chez l’abonné.
2. DESCRIPTION DU SERVICE
2. Description générale du service
Le service « Ligne OPERA Office I00M » est une offre de collecte de trafic depuis des Locaux FTTH permettant à un opérateur de services, client du Fournisseur, d'assurer le raccordement et la collecte de ses abonnés professionnels à travers les infrastructures fibres optiques déployées dans les plaques opérées par le Fournisseur.
L'offre comprend le transport du trafic IP unicast Abonné jusqu'au site de livraison défini conjointement par le Client et le Fournisseur.
Le trafic IP unicast Abonné est acheminé, au choix du client ISP, selon les règles de transport et d'authentification énoncées ci-dessous :
Service Accès Transport / | Authentification | Identification Abonné
Abonné Livraison
Data/Business/VolP | IPOE IP sur RADIUS + DHCP | RADIUS : attribut Agent- Ethernet Circuit-id
DHCPv4/vé: option 82/18
Data/Business/VolP | PPPOE L2TP sur RADIUS RADIUS : login/password
Ethernet + Agent-Circuit-id
Tableau 1 -— Liste des flux transportés
Remarque :
Dans le mode d'accès IPOE, la ligne est transparente à l'option DHCP 60 ;
Les caractéristiques du service sont les suivantes :
O 4
2e
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Livraison du service chez l’'abonné sur une interface Ethernet ;
Débit d'accès de la « Ligne OPERA Office I00M » permet au Client, selon les caractéristiques des infrastructures
optiques, de proposer des services Data jusqu'à 1 Gbits/s dans le sens descendant, et jusqu'à 500 Mbits/s dans le sens montant ;
Authentification Abonné par RADIUS de l'opérateur Client ;
Collecte et livraison trafic abonné selon 2 modes au choix du client : Collecte IP/DHCP et livraison en IPoE ;
Collecte PPPOE et livraison en L2TP ;
Adressage IP Abonné géré par l'opérateur Client :
IPv4 et / ou IPv6 pour le mode d'accès IPOE ;
Uniquement IPv4 pour le mode d'accès PPPOE ;
Dans le mode d'accès IPOË, allocation des IP abonnés par le protocole DHCP (serveur DHCP Client ou Fournisseur suivant le mode retenu « DHCP et RADIUS >» ou « Full-RADIUS ») ;
Gestion dynamique des profils abonnés depuis le serveur RADIUS de l'opérateur Client : Type de service : 3-Play (3 classes de services disponibles) ;
Contrôle de la bande passante par classe de service (3 bits IP precedence du champ TOS - soit les 3 bits de poids forts du champ DSCP) et global par abonné ;
Trois classes de services sont disponibles :
Data (débit asymétrique de 1 Gbits/s en descendant et 500 Mbits/s en montant) Business (débit symétrique garanti de 100 Mbits/s)
Voix (débit symétrique garanti de 1500Kbit/s maximum)
Dépassement des classes Voix et Business non autorisé ;
Ségrégation du trafic dans un contexte MPLS/VPN pour chacun des modes d'accès dans le réseau du Fournisseur :
Point d'interconnexion avec le réseau du Client :
Porte de collecte Locale où Nationale, située dans un POP Fournisseur ou dans un POP opérateur Tiers éligible au service ;
Redondance possible avec une seconde porte de même catégorie.
L'accès Abonné est basé sur un modèle Point-Multipoint avec la technologie GPON.
•
•
•
•
o
o
•
o
o
•
•
o
o
•
o
o
o
•
•
•
o
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
2.2 Schémas de principe
Figure 2 - Schéma de principe Mode d'accès PPPOE
Les infrastructures d'accès Point-Multipoint sont en liaison avec un réseau de collecte Ethernet (Eth/MPLS) pour joindre les BNGs du Fournisseur. Elles s'appuient d'une part sur des équipements de commutation Ethernet, tels que ONT/OLT pour l'accès, et d'autre part sur des équipements de commutation de labels MPLS, tels que les OLTSs et des routeurs multiservice MPLS pour la collecte.
O
IP/MPLS
Network
Plaque 3
IP/
MPLS Network
Plaque 1
IP/
MPLS Networ
k
Plaque 2
OLT
ONT
Réseaux Clients
Routeur
Client
Interface de Collecte
Nationale
VLAN Unicast
OLT
ONT
IPoE Unicast ( Data, VOIP)
Collecte Eth/MPLS
Collecte Eth/MPLS
Transport VPN IP/MPLS
Réseau Fournisseur
Interface Abonné
BNG
BNG
BNG
Routeur
Collecte
Infra GPON
Infra GPON
Infra GPON
IAD
IAD
IAD
OLT
ONT
Infra ISP-A
Routeur
Client
VLAN Unicast
Infra ISP-B
Collecte Eth/MPLS
Interface de Collecte
Locale
IP/MPLS
Network
Plaque 3
IP/
MPLS Network
Plaque 1
IP/
MPLS Networ
k
Plaque 2
OLT
ONT
Réseaux Clients
LNS
Client
Interface de Collecte
Nationale
OLT
ONT
Collecte Eth/MPLS
Collecte Eth/MPLS
Transport VPN IP/MPLS
Réseau Fournisseur
Interface Abonné
BNG
BNG
BNG
Routeur
Collecte
Infra GPON
Infra GPON
Infra GPON
IAD
IAD
IAD
OLT
ONT
Infra ISP-A
LNS
Client
PPPoE
Infra ISP-B
Collecte Eth/MPLS
Interface de Collecte
Locale
Session L2TP
PPPoE
PPPoE
Session L2TP axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Dans ces réseaux de collecte Ethernet, le cloisonnement des flux Client est assuré par l'implémentation d'une instance de commutation dont une des spécificités est d'interdire l'échange de trafic entre Abonnés.
Les équipements de commutation Ethernet ainsi que ceux du domaine Eth/MPLS apprennent les adresses MAC tel que
décrit dans les standard IEEE 802.ID et RFC 4762.
Le nombre d'adresses MAC par abonné est limité à 5 et leur « aging-time » est fixé, dans la chaine de collecte niveau 2, à 2 heures. La durée des baux DHCP (ou preferred-lifetime en DHCPvé) et des timers ARP doit y être inférieure (avec timer ARP = Bail DHCP / 2) pour assurer un service sans discontinuité et éviter la diffusion de trafic de type « Unknown » ou « Broadcast » à travers les infrastructures du Fournisseur.
Les BNGs ont pour rôle d'appliquer le profil de service des abonnés et les mettre en relation avec l'infrastructure de transport de niveau 3 (VPN IP / MPLS) pour être accessibles depuis la porte de collecte. L'infrastructure globale assure
une pleine transparence vis-à-vis du trafic échangé entre les Abonnés et le réseau de l'opérateur Client.
Les zones de collecte d'abonné sont gérées par 2 BNGs redondants en mode active/standby.
Les BNGs affectés à une zone de collecte sont choisis pour être au plus proche de celle-ci.
À noter qu'à travers les infrastructures d'accès Point-Multipoint, l'opérateur Client est en mesure d'adresser ses abonnés en [Pv4 et / ou IPvé pour le mode d'accès IPOE et uniquement en IPv4 pour le mode d'accès PPPOE.
La combinaison des 2 modes de collecte IPOE et PPPOE, est permise, mais ne l’est pas au niveau Abonné.
2.3 Classes de service réseau
La correspondance entre les classes de service du réseau du Fournisseur et les différents types de trafic associés est
basée sur la valeur présentée par les 3 bits de l'IP Precedence du champ TOS contenu dans l’entête des paquets IP. La liste de ces correspondances est présentée dans le tableau ci-dessous :
Type de trafic IP Precedence
VOIP 5, 6, 7
Business 3
Data 0,1,2,4
Tableau 1 - Correspondance Trafic et CoS Fournisseur
3. INFRASTRUCTURE DE COLLECTE
3. Collecte Point-Multipoint
3.1.1 Synoptique
Le réseau de collecte dépeint ci-après est basé sur une infrastructure GPON et reprend le schéma de principe de la Figure I.
O 7 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
DO» Figure 2 - Réseau de collecte GPON du service OPERA Office I00M M:
Les arbres PON adressent 32 voire 64 Abonnés au maximum. Toutefois, certains arbres PON peuvent être
restreints à 16 abonnés afin de servir les Points de Mutualisation les plus éloignés de leur NRO et préserver le budget optique total des lignes Abonné. Le schéma ci-après modélise différentes solutions de raccordement des abonnés sans en faire la liste exhaustive :
Figure 3 - Modélisation ODN
Les NRO peuvent prendre le rôle de PM afin de raccorder des Abonnés.
L'utilisation de coupleurs 1 :16 ou 1:32 ou 1:64 dans les points de mutualisation est fonction de la distance PM / NRO.
Avec le niveau de couplage 1:32, la distance optique maximale entre l'OLT et l'ONT avoisine 18 kms avec des modules optiques GPON de classe C+ au niveau de l'OLT.
O LE
NRO
Abonné
PM
OLT
Rep optique Rep optique
Rep optique OI PTO
Connecteur (soudé)
soudure
Abonné
P
M
Rep optique OI
PBO
PTO PBO
Coupleur 1:64
Coupleur 1:32
Abonné
PM
Rep optique Rep optique
Rep optique OI PTO PBO
Coupleur 1:32
RG ONT
(bridge)
BNG OLT
[PE]
Desserte
(Eth sur GPON)
Agrégation
(Eth sur MPLS)
VPLS axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
3.1.2 Caractéristiques des éléments actifs
3.1.2.1 ONT
L'ONT est un équipement d'intérieur pourvu d’une alimentation externe en 220v AC. L’Abonné doit fournir une prise électrique permettant son alimentation.
C'est un modèle Bridge Ethernet dont les ports ont les caractéristiques suivantes :
port optique Class B+ avec connecteur SC-APC ;
port cuivre gigabit-Ethernet par interface Abonné.
L'implémentation de la technologie GPON respecte les recommandations G.984.x de l'ITU-T :
Nombre de T-CONT = 4 minimum ;
Nombre de files d'attente associées à une interface Abonné = 8 ;
Ordonnanceur des files d'attente supporte les modes « strict-priority », Weighted Fair Queuing » ainsi que la combinaison des deux dans le sens montant. Dans la voie descendante, seul le mode « strict-priority » est supporté.
3.1.2.2 OLT
L'OLT est une plate-forme multiservices de haute capacité dont l'architecture du châssis permet de satisfaire aux besoins actuels et futurs puisqu'elle met à disposition de chaque carte de service une double connexion à 100 Gbits/s. De fait, elle est adaptée au marché des services résidentiels ou entreprises hauts débits (FTTH, FTTB, FTTO) tout en permettant de déployer simultanément plusieurs technologies d'accès basée sur la fibre optique.
En plus du mode d'accès GPON, retenu pour l'infrastructure de collecte point-multipoint, l'OLT supporte les types d'accès listés ci-après :
EPON ;
NG-PON ( 10G XG-PONI, XGS-PON : NG-POND) :
P2P Fast-Ethernet/Gigabit-Ethernet/TenGigabit-Ethernet.
3.2 Format du Circuit-ID
3.2.1 Circuit-ID
La notion de « Circuit ID » est communément employée dans les réseaux d'accès pour identifier de façon unique un Abonné en transmettant une information relative à l'équipement d'agrégation et au port d'accès, qu'il soit physique ou logique, auquel le client DHCP ou le client PPPOE est rattaché.
Mode IPoE :
Dans les transactions DHCPv4 le « Circuit-ld » est transmis par l'intermédiaire de l'option n°82 insérée par l'équipement d'agrégation des infrastructures de collecte Point-Multipoint. Elle est de taille variable et peut-être constituée d'une suite de sous options. Les codes des sous options Agent Circuit ID et Agent Remote ID sont respectivement 1 et 2.
Dans les transactions DHCPvé le « Circuit-Id » est transmis par l'intermédiaire de l'option n°18 (Interface-ID) qui peut être
complétée par l'option 37 (Relay Agent Remote-lD). L'équipement d'agrégation se comporte en relai DHCP de niveau 2 aussi appelé Lightweight DHCPvé Relay Agent (LDRA), les options 18 et 37 sont définies respectivement par les RFC3315 et RFC4649.
Par analogie avec DHCPv4, l'option DHCPv6 n°18 correspond à la sous-option 1 de l'option 82 et l'option DHCPvé6 n°37 correspond à la sous-option 2 de l'option 82.
Mode PPPoE :
O 9
LE
•
•
•
•
•
•
•
• axiIone 152 avenue Pierre Brossolette Annexe 2A - STAS OPERA Office 100M — 92240 Malakoff
Durant les échanges PPPOE, le « Circuit-Id » est transmis par l'intermédiaire d'un PPPOE Tag inséré par l'équipement d'agrégation des infrastructures de collecte Point-Multipoint en suivant les recommandations du Broadband Forum TR- 156 (Architecture de collecte Ethernet pour services Broadband sur accès GPON - Using GPON access in the context of TR-I01).
Dans ce contexte, les OLT sont appelés PPPOE Relay, ou PPPOE-Intermediate Agent. Ils insèrent les PPPOE Tag dans les messages PPPOE montants (émis par les IAD vers le réseau), c'est-à-dire durant la phases découverte et terminaison PPPOE en utilisant les messages PADI, PADR et PADT.
Le format du PPPOE Tag est défini dans le document BBF TR-I01 8 3.9.2. || se compose de plusieurs champs dont le TAG_ID (0x0105 = Vendor-Specific) et le TAG_VALUE (vendor id= Ox000DE9 = BBF) suivis d’une suite de sous options selon les besoins. Par analogie à l'option 82 DHCPv4, les codes des sous options Agent Circuit ID et Agent Remote ID sont respectivement | et 2.
3.2.2 DHCPv4
3.2.2.1 Agent Circuit-ID
Cette sous-option de l'option 82 contient la totalité des informations d'identification du circuit d'accès des Abonnés sur l'équipement d'agrégation. Elle est par conséquent systématiquement délivrée.
3.2.2.2 Agent Remote-ID
Cette sous-option de l'option 82 contient uniquement l'information du Sysname de l'équipement d'agrégation. Cette information est redondante avec celles contenues dans l’Agent Circuit-ID.
3.2.3 DHCPvé
3.2.3.1. Interface-ID
Cette option 18 à la même signification et reprend le format de l'Agent Circuit ID de l'option 82 de DHCPv4.
3.2.3.2. Relay Agent remote-ID
L'information transportée par l'option 37 est spécifique à l'équipement d'agrégation, elle peut être utilisée par exemple pour transmettre un numéro de VLAN, une description de port, …
Dans le cas du présent service, l'option 37 n'est pas ajoutée.
3.2.4 PPPOE Tag
3.24. Agent Circuit-ID
La sous-option n°1 contient la totalité des informations d'identification du circuit d'accès des Abonnés sur l'équipement d'agrégation. Elle est par conséquent systématiquement délivrée.
Elle à la même signification et reprend le format de l'Agent Circuit ID de l'option 82 de DHCPv4.
3.2.4.2. Agent Remote-ID
Cette sous-option n°2 permet d'identifier l'abonné. C'est une chaine de 63 caractères au maximum.
Dans le cas du présent service, cette sous option n'est pas ajoutée.
3.2.5 Sysname
Le Sysname correspond au nom de l'équipement auquel est raccordé l'abonné.
O 10 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
l'est contenu dans les champs circuit-id / remote-id de l'option 82 DHCPv4, dans l'option 18 DHCPvé et dans le Tag PPPOE.
Le format du sysname des OLT pour la collecte Point-MultiPoint en GPON est le suivant :
Valable pour tous | olt-xxxdd-yy
OLT Avec :
xxx = le trigramme NRO (en minuscule)
dd = le numéro du département
yy = l'identifiant OLT rattachés à un même NRO
La chaine de caractères xxxdd identifie le NRO.
3.2.6 Format du Circuit-ID spécifique aux OLTs
Dans les réseaux d'accès GPON, les options DHCP (82 ou 18) ou les PPPOE Tag sont insérés par l'OLT dans les messages DHCPv4, DHCPvé ou PPPOE des transactions initiées par l'équipement Abonné.
Pour les OLT, le format du « Circuit-ID > pourra prendre deux formes en fonction du modèle d'OLT sur lequel Abonné est raccordé :
Access_Node_ID PON Rack/Frame/Slot/PON/ONU/OnuSlit/UNI/I-VID
Access_Node_ID = Le sysname de l'équipement ;
PON = Indiquant la technologie de collecte ;
Rack = Identifiant de baie de l’'OLT toujours à la valeur |;
Frame = Identifiant de châssis OLT toujours à la valeur |;
Slot = Identifiant du Slot de l'OLT, de O1 à 16;
PON = Identifiant de port de la carte GPON, de O1 à 16. Par défaut des cartes 8 ports PON mais dans les NRO denses des cartes 16 ports PON pourront être utilisées ;
ONU = Identifiant ONT par arbre PON, de 1 à 128 (infra Fournisseur = 64 maximum) ; OnusSit = slot de l'ONT, toujours à |;
UNI — Identifiant de port sur l'ONT représentant l'interface Abonné, toujours à | ;
I-VID = Identifiant VLAN utilisé par l'équipement Abonné raccordé à l'UNI :
Celui-ci est vide si le trafic Abonné n'est pas marqué par une étiquette VLAN.
Access_Node_ID XPON Frame/Slot/Subslot/PON:ONU.gem.vlanid
Access_Node_ID = Le sysname de l'équipement ;
XPON = indiquant la technologie de collecte ;
Frame = Identifiant de châssis OLT toujours à la valeur 0 ;
Slot = Identifiant du Slot de l'OLT, del à 5;
Subslot — Identifiant de la carte fille toujours à 0 ;
PON = Identifiant de port de la carte GPON, de 0 à 15;
ONU = Identifiant ONT par arbre PON, de O à 127 (infra Fournisseur = 64 maximum) ; Gem = Identifiant du gemport de l'ONT portant l'identification de l’'Abonné, toujours à |; Vlanid = Identifiant VLAN utilisé entre l'ONT et l'OLT, toujours à 1 ;
Pour le présent service, le « Circuit-ID » qui permet d'identifier de façon unique l’Abonné dans le réseau, pourra donc prendre les formes :
« sysname pon 1/1/Slot/PON/ONU/1/Uni »
Exemple :
dans son format ascii : olt-bsn42-01 pon 1/1/01/01/4/1/1/
O (l
LE
-
-
-
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
- axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
dans son format hexadécimal correspondant aux codes ascii :
6f6c/42d62736e34322d303120706f6e20312f312f30312f30312f342#312f312f
« sysname xpon 0/Slot/0/PON:ONU.. »
Exemple :
dans son format ascii : olt-bsn42-01 xpon 0/1/0/0:4.1.
dans son format hexadécimal correspondant aux codes ascii :
6f6c/42d62736e34322d30312078706f6e20302f312f302f303a342e312e3l
À. INTERFACE D'ACCES AU SERVICE
Le service OPERA Office I00M définit deux interfaces permettant, d’une part, le raccordement de l'installation Abonné (interface Abonné), et d'autre part, l'interconnexion entre le Client Opérateur de services et celui du Fournisseur (interface de Collecte).
nl Ds 7 je+ A
Ÿ EL. D. pi Æ——— ce Ld «
Figure 5 - Interfaces de service
A. L'interface Abonné
L'interface Abonné est de type cuivre, son débit est de 1 Gbits/s.
Topologie Type | Debit Média Portée Connecteur Normes Interface interface (mètres)
Point- 1000- |Gbit/s | 4 paires de cuivre | 100m RI-45 IFEE 802.3ab Multipoint BaseT | ISO 8877
GPON mpésance 100 (support for ISO/IEC 8802.3 . ms automatic
Câble UTP 6 inversion MDI
/ MDWX)
Tableau 3 - Caractéristiques de l'interface de service Abonné
Remarque :
L'indication de portée est conforme au standard ISO/IEC 8802.53. Il conviendra de tenir compte des pertes inhérentes aux divers points de coupure (répartiteurs, catégorie des câbles et des jarretières utilisées) et de recalculer la longueur maximale admissible.
Le connecteur est de type ISO 8877 (R]J 45) femelle, il est présenté par la figure suivante :
O 12
LE
-
•
o
o
ONT
(bridge)
BNG
OLT
[PE]
Desserte L2 over MPLS network
Interface
Abonné
VPLS
Interface de
Collecte
VPN IP
Routeur
Collecte
L3 over MPLS network axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Figure 4 - Connecteur femelle RJ45
AIT Spécifications du port Ethernet de l'ONT
Les caractéristiques physiques de l'interface Ethernet sont :
Interface Cuivre ;
Connecteur RIJ-45 femelle ;
Vitesse auto : 1 Gbit/s ;
Port MDI / MDI-X avec détection automatique du câble droit ou croisé.
A.I.2 Raccordement Abonné
Appairage des paires de cuivre et le brochage du connecteur sont présentés dans les tableaux ci-dessous :
Media Paires utilisées
À paires (1:2)(3;:6)(4;5)et(7;8)
[ae] Signal Direction Description
BI_DA+ æ— | paire Bi-directionnelle À +
Bl_DA- *—— | poire Bi-directionnelle A -
BI_DB+ æ— | poire Bi-directionnelle B +
BI_DC+ *— | paire Bi-directionnelle € +
BI_DC- — |poire Bi-directionnelle C -
BI_DB- *——+ | paire Bi-directionnelle B -
BI_DD+ t—+ | paire Bi-directionnelle D +
©
|
IQ
[O1
|
©
IN
BI_DD- €——+ | paire Bi-directionnelle D -
Tableau 4 - Appairage et Brochage du connecteur pour interface 10 Base-T ou 100 Base-T
Le raccordement de l'équipement Abonné doit être réalisé avec un câble dont les caractéristiques sont équivalentes à la catégorie 6.
L'interface Ethernet de l'équipement Abonné doit être conforme à la norme IEEE 802.3ab (1000-BaseT) et configurée en mode auto-négociation avec une vitesse de transmission de 1 Gbits/s.
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
414 Spécifications IP
L’Abonné ne doit pas envoyer vers le réseau des paquets IP avec une taille supérieure à 1500 octets.
Le contenu du champ DSCP des paquets IP n'est pas modifié et peut-être utilisé par le client ISP pour faire correspondre ses flux avec les classes de services du réseau Fournisseur.
La valeur des 3 bits de poids fort du champ DSCP (ou IP Precedence) doit respecter les règles suivantes :
Precedence — 5, 6, 7 pour le trafic associé à la classe de service VolP ;
Precedence = 3 pour le trafic associé à la classe de service Business ;
Precedence = O, I, 2, 4 pour le trafic associé à la classe de service Data.
L'IAD installé chez l'abonné doit fonctionner en Ethernet « natif ». Le trafic ne doit pas être tagué avec un numéro de VLAN.
4.2 L'interface de Collecte
L'interface de Collecte livre l'ensemble du trafic montant et descendant des abonnés sur le réseau de l'opérateur client.
Elle est matérialisée par une ou plusieurs portes de livraison situées dans des points de présence du Fournisseur :
Une porte Locale collecte uniquement les flux unicast issus d’une même DSP ;
Une porte Nationale collecte les flux unicast de l'ensemble des réseaux opérés par le Fournisseur (accès issus de n'importe quel réseau de Délégation de Service).
Le client a la possibilité de souscrire au maximum 2 portes qui doivent être du même niveau (Locale ou Nationale). Lorsque le trafic est livré sur 2 portes, il ny a pas de partage de charge : une porte nominale et une porte de secours. La porte de secours peut avoir un débit inférieur à la porte nominale.
D er 7
—> < > < >
Figure 7 - Sécurisation de l'interface de Collecte
Afin d'autoriser la cohabitation des flux Unicast Abonné et les échanges radius, des interfaces logiques (VLAN) distinctes sont définies sur l'interface de collecte :
Un VLAN Data ;
Un VLAN RADIUS.
L'interface de collecte peut être composée de plusieurs ports physiques, dans ce cas le protocole LACP devra être
configuré par le client ISP.
421 Spécification des interfaces physiques
Seul l'accès fibre optique est disponible, les caractéristiques de l'interface sont les suivantes :
O 14
•
•
•
•
•
•
•
ONT
(bridge)
BNG
OLT
[PE]
Desserte L2 over MPLS network
Interface
Abonné
VPLS VPN IP
L3 over MPLS network
Interfaces de
Collecte
Routeurs
Collecte axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Debit £ Type Normes Type Interface | ;hterface Média (mtres) es Connecteur
IEEE 802.3z
1000Base-LX |1Gbit/s [Fibre Optique | Ki [Duplex |LC/PC Monomode ISO/IEC 8802.3
Fibre Optique 10GBase-LR |10 Gbits/s
Monomode 10Kms Duplex LC/PC IEEE 802.3ae
Tableau 6 - Caractéristiques de l'interface de Collecte
Remarque :
L'indication de portée est conforme au standard ISO/IEC 8802.3. Il conviendra de tenir compte des pertes inhérentes aux divers points de coupure (répartiteurs optiques, pertes liées aux connecteurs des jarretières) et de recalculer la longueur maximale admissible.
Sur ces interfaces, le client ne doit pas activer de mécanismes de spanning-tree. Il ne doit pas envoyer de paquets BPDU sur le port d'interconnexion.
A2.2 Interconnexion |P
Comme spécifié au paragraphe 4.2, deux VLANSs sont définis sur les interfaces de collecte afin de séparer les échanges RADIUS des flux Data :
Un VLAN Data pour le transport des flux data (IPOE et/ou L2TP) des abonnés ;
Un VLAN RADIUS pour les échanges RADIUS.
Les numéros de VLAN sont spécifiés dans la fiche d’interconnexion.
Deux réseaux IP d'interconnexions sont nécessaires pour acheminer les échanges RADIUS et les flux Data :
Un réseau en adressage ip publique IPv4 de type /30 ou /31 pour l’interconnexion RADIUS :
Un réseau en adressage ip publique ou privée IPv4 de type /30 ou /31, voire IPvé de type /127 pour le VLAN Data Unicast.
Pour les adressages ip publiques, le Client ISP doit disposer d’un numéro d’AS public.
Une session eBGP est établie entre le Fournisseur et le client ISP au niveau de chaque VLAN de l'interface de collecte.
Caractéristiques de la session eBGP data
Adressage IP fourni par le client ISP ;
La fonctionnalité GTSM (RFC 5082) peut être activée pour sécuriser à minima la session eBGP en contrôlant qu'elle est établie avec le premier équipement IP joignable par cette interconnexion ;
La fonctionnalité BFD peut être activée pour optimiser la durée de détection de la perte de la session eBGP.
Le Fournisseur annonce les préfixes BGP contenant les adresses IP des IADs en mode IPOE ainsi que les préfixes BGP contenant les adresses IP de ses LAC pour le mode PPPOE :
Mode IPoE : A la convenance du Client ISP, les pools IP ou les préfixes spécifiques /32 pour IPv4 ou les préfixes spécifiques lA_NA en /64 et IA_PD, de /32 à /64, pour IPv6 par lAD :
Mode PPPOoE : Les adresses de ses LAC
sur une porte nationale, le Fournisseur annonce les adresses IP des LAC des réseaux d'initiative public pour lesquels le client a opté pour une livraison nationale ;
sur une porte locale, le Fournisseur annonce uniquement les adresses IP des LAC locaux.
•
•
•
•
•
•
•
•
•
•
•
o
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Le client annonce :
Mode IPoE : Une route par défaut ;
Mode PPPoE : Les adresses de ses LNS.
Le Fournisseur appliquera un filtre sur les annonces BGP-4 du client pour autoriser :
Mode IPoE : Route par défaut uniquement ;
Mode PPPoE :
Limitation du nombre total de routes annoncées par le client sur une interface de collecte à 300 ; Seules les adresses faisant partie des blocs d'adresses LNS préalablement déclarés par le client sont
redistribués dans le réseau du Fournisseur.
Les communautés utilisées par le client seront ignorées sur le réseau du Fournisseur.
Caractéristiques de la session eBGP RADIUS
Adressage IP fourni par le Client ISP ;
La fonctionnalité GTSM (RFC 5082) peut être activée pour sécuriser à minima la session eBGP en contrôlant qu'elle est établie avec le premier équipement IP joignable par cette interconnexion ;
La fonctionnalité BFD peut être activée pour optimiser la durée de détection de la perte de la session eBGP.
Le Fournisseur annonce :
les adresses IP de ses Proxy RADIUS
Le client annonce :
les adresses IP de ses serveurs RADIUS
Le Fournisseur appliquera les filtres suivants sur les annonces BGP-4 du client :
Limitation du nombre total de routes annoncées par le client sur une interface de collecte au nombre de serveurs RADIUS du client ;
Seules ces adresses sont redistribuées dans le réseau du Fournisseur.
Les communautés utilisées par le client seront ignorées sur le réseau du Fournisseur.
Attributs BGP et gestion du mode de redondance
Les routes annoncées en BGP par le client auront l’attribut local-preference positionné de la manière suivante sur les interfaces de livraison :
Type de livraison Valeur attribut Local-Pref
Locale nominale 220
Locale secours 210
Nationale nominale 200
Nationale secours 100
Tableau 6 - Attributs BGP des préfixes échangés
•
•
•
•
o
o
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
De la même façon, le client devra marquer avec une locale préférence plus grande les routes apprises sur les interfaces de livraison nominale.
5. MODES D'ACCES ET LIVRAISON IPOE
5. Gestion IP/DHCP Abonné
Le présent service permet d'établir des sessions IP DHCP entre IAD et BNG, sans « switching » inter-abonné, routables jusqu'au réseau de l'opérateur client. Celui-ci est en mesure d'attribuer, à chacun de ses abonnés, au plus une adresse
parmi les types suivants :
IPv4 : une adresse /32 par lAD;
IA_NA (IPv6) sur infrastructure Point-Multipoint uniquement : une adresse /128 par IAD issu d’un range /64 dédié. Soit 1 range /64 par lAD;
IA_PD (IPvé) sur infrastructure Point-Multiboint uniquement : un préfixe de taille /32 à /64 par lAD.
L'opérateur client a le choix de gérer ses abonnés selon 2 méthodes ; « DHCP et RADIUS » ou « FULL RADIUS ».
Dans le mode « DHCP et RADIUS », le BNG du Fournisseur se comporte en relai DHCP entre les IAD abonnés et le
serveur DHCP du client opérateur.
Dans le mode « FULL RADIUS », le BNG du Fournisseur se comporte en serveur DHCP vis-à-vis des IAD abonnés et leurs paramètres IP sont transmis par le serveur Radius du client opérateur.
Les échanges DHCP et RADIUS des 2 méthodes sont détaillées ci-après dans cette même section du document.
5.2 Gestion profil de QoS Abonné
La gestion du profil de QoS de l'abonné se fait dynamiquement à chaque nouvel échange DHCP entre l'abonné et le serveur DHCP (DHCPv4-Discover / DHCPv4-Renew ou DHCPvé-Solicit / DHCPvé-Renew). Les échanges DHCP doivent avoir un marquage |P precedence à 0.
Quel que soit le mode de gestion des abonnés, le BNG initie une transaction Radius lui permettant de récupérer le profil de l’'abonné.
Pour cela l'opérateur client renvoie dans un message RADIUS Access-Accept l'attribut Class précisant le profil de labonné. Ce dernier est ensuite interprété par le réseau du Fournisseur et le profil de QoS associé est automatiquement activé au niveau du BNG.
5.3 Paramétrage IP et DHCP
5.31 Durée de vie des adresses IPv6
L'attribution d'une adresse IPv6 à une interface est temporaire et les différents états de sa durée de vie sont présentés par la figure suivante :
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
invalide:
Provisoire
Y
Création Allocation
Si Lrée de Préférenc
< Durée de vie »-
Figure 8 - Etats successifs d'une adresse IPv6 sur une interface
Les compteurs « Durée de vie » et « Durée de Préférence » contrôlent le cycle de vie des adresses IP sur une interface. Selon le mode d'auto-configuration, le compte à rebours démarre dès réception du message d'annonce d'un routeur ou
d'un message DHCPvé Reply.
La durée de vie (valid lifetime) indique la durée pendant laquelle l'adresse IP est associée à une interface.
La durée de préférence (preferred lifetime) est la durée pendant laquelle l'adresse IP est utilisable sans restriction dès lors que son unicité a été vérifiée. Cette durée est assimilable à la durée du bail DHCPv4.
Le cycle de vie d’une adresse IPv6 est régi par les états suivants :
Etat Provisoire (tentative) : L'adresse a été attribuée par le mécanisme d’auto-configuration mais son unicité sur le lien n'a pas encore été vérifiée par le processus de Détection d'Adresse Dupliquée (DAD). Une adresse provisoire ne peut servir dans une communication ;
Etat valide (valid) : L’unicité a été contrôlée, l'adresse est active sur une interface ; Préféré (preferred) : L'adresse peut être utilisée sans restriction ; Déprécié (deprecated) : L'adresse ne peut plus être utilisée pour de nouvelles communications mais reste active pour les connexions existantes ;
Invalide (invalid) : L'adresse ne peut plus du tout être utilisée. Elle n'est plus active sur l'interface.
5.3.2 Compteurs DHCP
En supplément de la durée du bail pour IPv4 où de la durée à l’état préféré pour IPvé, les clients DHCP gèrent 2 compteurs définis par T1 et T2 dans les RFC2131 pour DHCPv4 et RFC3315 pour DHCPvé. Ces compteurs sont à leur
valeur par défaut telle que définie dans les RFC ou configurables par les serveurs sous formes d'options.
Le premier, T1, stipule la durée à partir de laquelle le client demande à son serveur un renouvellement de la durée d'utilisation de son adresse IP. Le second, T2, entre en action lorsque la demande de renouvellement a échoué en renégociant une nouvelle adresse IP en s'adressant à tous les serveurs susceptibles de répondre.
T2 doit être compris entre TI et l'expiration du bail DHCPv4 ou de l'état préféré en DHCPvé.
Pour DHCPv4, TI et T2 ne sont pas transmis au client DHCP. Lorsque le client DHCP utilise les valeurs par défaut, les compteurs sont :
Bail = 7200 secondes (2 heures) :
TI = Renew = 0,5*Bail (valeur par défaut selon RFC2131) = 3600 secondes : T2 = Rebind = 0,875*Bail (valeur par défaut selon RFC2131) = 6300 secondes.
O 18
•
•
o
o
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Pour DHCPvé, à la différence de DHCPv4, TI et T2 sont toujours transmis au client DHCP. Les valeurs imposées par le Fournisseur sont les suivantes :
Preferred lifetime = 7200 secondes (2 heures) ;
Valid lifetime = 10800 secondes (3 heures) ;
TI = Renew = 0,5*“Bail = 3600 secondes ;
T2 = Rebind = 1,5*T1 = 5400 secondes.
5.4 Mode DHCP et RADIUS
5.4.1 Authentification et adressage IP de l’Abonné
À chaque nouvel échange IP/DHCP (DHCPv4-Discover / DHCPv4-Renew ou DHCPvé-Solicit / DHCPvé-Renew), une demande d'authentification RADIUS (RADIUS Access-Request) est envoyée au serveur RADIUS Client au travers d’un Proxy-RADIUS du Fournisseur.
Une fois la demande d'authentification validée par le serveur RADIUS client (RADIUS Access-Accept), le BNG du Fournisseur relaye la demande DHCP de l’abonné aux serveurs DHCP de l'opérateur client.
Une fois la phase d’authentification passée, le dialogue IP/DHCP client/serveur se déroule de façon standard.
L'opérateur client attribuera des adresses IP pour une durée de 2 heures (bail DHCPv4 / preferred-lifetime pour
DHCPvé = 2 heures).
5.4.2 Détail des échanges RADUIS et DHCPv4
5.4.2.1 DHCPv4-Discover
un {l
DT Serveurs RADIUS et Cr LES PTE ol + RADIU sS Routeur Backbone Routeur usager 1||: Equipement d'accès 1AD ONT (OLT) |l
|
|
!
TRES
s Comme”
ere
ne ——_—
o EEE
© ED ©
Figure 9 - Mode DHCP et RADIUS (transaction DHCPv4-Discover)
IA CO
1) L'IAD envoie un DHCP-Discover sur son port réseau.
OLT d'accès
(2) Celui-ci insère l'option 82 dans le DHCP-Discover du client en y renseignant les informations suivantes :
O 19
2e
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BNG
À réception du DHCP-Discover le BNG Nominal bloquera le DHCP-Discover de lIAD Abonné. Il générera un RADIUS Access-Request à destination du Proxy RADIUS Fournisseur (3) afin d'identifier l'abonné en recopiant certains champs du
DHCP-Discover dans sa requête (circuit-id, remote-id et vendor-dhcp).
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’'abonné sur la base de son circuit-id et proxifie l'Access- Request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access-
request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id=;
ADSL-Agent-Remote-id=.
Les attributs radius suivants seront transmis sur demande du client :
Alc-DHCP-Vendor-Class-ld = ;
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS Access-Accept (5) au proxy-RADIUS Fournisseur contenant les informations suivantes :
Class = OPERA-Office-DLmKk-ULmk-Busm : La valeur du débit HSI down max en Mbit/s
: La valeur du débit HSI up max en Mbit/s
: La valeur du débit VolP down de 1500 kbit/s
: La valeur du débit VolP up de 1500 kbit/s
: La valeur du débit Business up/down 100 Mbits/s
L'attribut Class permet de distinguer le profil de débit à appliquer à l'abonné. Il est construit en se référant aux valeurs maximales des débits descendants DATA/VOIP/BUSINESS et des débits montants DATA/VOIP/BUSINESS.
Exemple :
Ligne OPERA Office I00M avec débit symétrique Data 100Mbps, Business 100Mbps et voix de 1500Kbps.
Class = OPERA-Office-DLI00m1I500k-ULI100m1500k-Busl00m
Le proxy-Radius Fournisseur transmet le Radius Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6) :
Identifiant Service du client ;
Identifiant de l'abonné ;
O 20
LE
•
•
•
•
•
•
•
•
•
•
o
•
o
o
o
o
o
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Profile de QoS (attribut Class renvoyé par le Radius Client).
À réception de l'Access-Accept, l'abonné est instancié, au sein du BNG, dans le VPN du client avec son profil de Qos.
A ce stade l'abonné n'a toujours pas obtenu d'IP. Le BNG relaie alors le DHCP-Discover (7) de l'abonné vers le serveur
DHCP du client.
S'ensuit alors un dialogue DHCP standard, DHCP-Offer(8), DHCP-Request(9) et DHCP-Ack(10) entre l'IAD de l'abonné et le serveur DHCP du client.
Le DHCP-Ack permet au BNG Fournisseur de connaître l'adresse IP de l’abonné et la durée du bail DHCP.
5.4.2.2 DHCPv4-Renew
Chaque DHCP-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les
bases RADIUS client la procédure de renouvellement de bail entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCP et RADIUS relatifs à un renouvellement de bail :
LE aie it 1
| 1 | Arte ee l
ini I!
Serveurs RADIUS
et DHCP
l
1AD ONT Equipement d'accès BNG Proxy RADIUS Routeur Backbone Routeur usager
DHCP Request DHCP Request
RADIUS Request RADIUS Request
@ DHCP Request
Figure 10 - Mode DHCP et RADIUS (renouvellement du Bail DHCPv4)
(13) L'IAD de l'abonné envoie un message unicast de type DHCP-Request pour renouveler le bail dhcp en conservant la même adresse IP.
(14) Le DHCP- Request est intercepté et l'option 82 de l'équipement d'accès est insérée.
(15) Le DHCP- Request est bloqué au niveau du BNG qui envoie un RADIUS Access-Request.
(16) En retour, le RADIUS Client répond avec un RADIUS Access-Accept. Le BNG met à jour le profil de l'abonné sur la base des informations descendues par le serveur RADIUS.
(17) Le DHCP- Request est alors retransmis par le BNG jusqu'au serveur DHCP du client.
(18) Le serveur DHCP répond alors par un DHCP-Ack à l'abonné.
(19) Le BNG enregistre l'adresse IP de l’'abonné en analysant le DHCP-Ack pour mettre à jour sa table DHCP. Celle-ci faisant correspondre l'adresse mac et l'adresse IP de l’abonné.
5.4.3 Détail des échanges RADUIS et DHCPvé
5.4.3.1 DHCPvé-Solicit
O 21
2e
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
æ
|
_—/ æ
|
,
Sstiaser
1
Serveurs RADIUS
|
Equipement d'accès x : k (OLT) BNG Proxy RADIUS Routeur Backbone Routeur usager et DHCP
! |
l
l
l
l
O TEE @ LEE RTE ET)
LEONE 6 (TT © RADIUS Request
RADIUS Accept O RADIUS Accept
DHCPv6 Relay-Formard(Relay-F ormard (Solicit})}
| DHCPv6 Advertise © ATEN EP PE PV Ver Ô ENTRER EM EP EE NEEET Fe DHCPv6 Request @ ALL EE EI Er) @ DHCPV6 Relay-Forward (Relay-Forward(Request)) © DHCPv6 Relay-Formerd (Reply) © DHCPV6 Relay-Reply (Relay-Reply (Reply)} | il Figure 11 - Mode DHCP et RADIUS (transaction DHCPvé-Solicit) IA CO
1) LIAD envoie un DHCPvé-Solicit sur son port réseau.
Equipement d'accès (OLT)
(2) L'équipement d'accès se comporte en relai DHCPvé en encapsulant la requête Solicit dans un message DHCPvé6 Relay-Forward et y insère le circuit-id de l'abonné. Le circuit-ID étant l'option 18, Interface-ID, faisant apparaitre les informations suivantes :
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BN
Sur réception du message DHCPvé Relay-Forward (Solicit), le BNG Nominal bloque la transaction jusqu'à ce que l'abonné soit identifié. Pour cela le BNG génère un RADIUS Access-Request à destination du Proxy RADIUS Fournisseur (3) en recopiant certains champs du message DHCP dans sa requête dont le circuit-id.
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’'abonné sur la base de son circuit-id et proxifie l'Access- Request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access-
request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
O 22
LE
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id = :;
Les attributs radius suivants seront transmis sur demande du client :
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS Access-Accept (5) au proxy-RADIUS Fournisseur contenant
les informations suivantes :
Class = OPERA-Office-DLmk-ULmk-Busm : La valeur du débit HSI down max en Mbit/s
: La valeur du débit HSI up max en Mbit/s
: La valeur du débit VolP down de 1500 kbit/s
: La valeur du débit VolP up de 1500 kbit/s
: La valeur du débit Business up/down 100 Mbits/s
L'attribut Class permet de distinguer le profil de débit à appliquer à l'abonné. Il est construit en se référant aux valeurs maximales des débits descendants DATA/VOIP/BUSINESS et des débits montants DATA/VOIP/BUSINESS.
Exemple :
Ligne OPERA Office I00M avec débit symétrique Data 100Mbps, Business 100Mbps et voix de 1500Kbps. Class = OPERA-Office-DLI00m1I500k-UL100mI500k-Busi00Om
Le proxy-Radius Fournisseur transmet le Radius Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6) :
Identifiant Service du client ;
Identifiant de l'abonné ;
Profile de QoS (attribut Class renvoyé par le Radius Client).
À réception de l'Access-Accept, l'abonné est instancié, au sein du BNG, dans le VPN du client avec son profil de Qos.
À ce stade l'abonné n'a toujours pas obtenu d’IP. Le BNG relaie alors le message DHCPvé6 qui a déjà été relayé par l'OLT vers le serveur DHCP du client (7).
Ici le BNG se comporte en relai DHCPvé6 et vient ajouter une seconde encapsulation de type Relay-Forward au message Solicit de l’'abonné.
S'ensuit alors un dialogue DHCPvé standard entre l'IAD de l'abonné, les 2 relais DHCP (OLT et BNG) et le serveur DHCP du client :
DHCPvé Relay-Reply(Relay-Reply(Advertise)) (8) ;
DHCPvé Relay-Reply(Advertise) (9) :
DHCPvé Advertise (10) ;
DHCPvé Request (11) :
DHCPvé Relay-Forward (Request) (12) ;
DHCPvé Relay-Forward (Relay-Forward (Request)) (13) ;
DHCPvé Relay-Reply(Relay-Reply(Reply)) (14) :
DHCPvé Relay-Reply(Reply) (15) ;
DHCPvé Reply (16).
O 23
•
•
•
•
•
o
•
o
o
o
o
o
•
•
•
•
•
•
•
•
•
•
•
•
• axiIone 152 avenue Pierre Brossolette Annexe 2A - STAS OPERA Office 100M — 92240 Malakoff
Le DHCPvé Relay-Reply(Relay-Reply(Reply)) (14) permet au BNG Fournisseur de connaître l'adresse IP de l'abonné, la durée du preferred-lifetime et la valeur des compteurs T1/T2 (Renew/Rebind DHCP).
5.4.3.2 DHCPvé6-Renew
Chaque DHCPvé-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les bases RADIUS client la procédure de renouvellement de bail (réinitialisation du compteur preferred-lifetime) entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCPv6 et RADIUS relatifs à un renouvellement de bail :
u de ti
Equipement daccès Serveurs RADIUS ia oùT et) BNG Proxy RADIUS Routeur Backbone Routeur usager CP
1 ' ' 1 1 '
1 ' : 1 ' :
1 1 !
1 1 1 1 ï
© EE ms)
nn © ÉLTTEE © EE ETUIS ©
Figure 12 - Mode DHCP et RADIUS (renouvellement du Preferred-Lifetime DHCPvé)
(17) L'IAD de l’abonné envoie un message de type DHCPvé-Renew pour renouveler le bail dhcp en conservant la même adresse IP.
(18) DHCPvé-Renew est intercepté par l'équipement d'accès (OLT) et relayé dans un message DHCPvé6 Relay-Forward (Renew) en y insérant le circuit-id de l'abonné. Le circuit-id étant l'option 18 DHCPvé.
(19) (20) Le message DHCPv6 Relay-Forward (Renew) est bloqué au niveau du BNG qui envoie un RADIUS Access- Request à destination du serveur client via le proxy Fournisseur.
(21) (22) En retour le RADIUS Client répond avec un RADIUS Access-Accept. Le BNG met à jour le profil de l'abonné sur la base des informations descendues par le serveur RADIUS.
(23) Le message DHCPvé Relay-Forward (Renew) est alors relayé par le BNG jusqu'au serveur DHCP du client.
(24) Le serveur DHCP client répond alors par un DHCPvé Reply encapsulé par un message Relay-Reply permettant d'adresser les 2 relais DHCPvé, BNG et OLT, pour joindre l'IAD de l'abonné.
(25) Le BNG enregistre les paramètres IP de l'abonné en analysant le message DHCPv6 reçu pour mettre à jour sa table DHCP. Celle-ci faisant entre autre correspondre l'adresse mac et l'adresse IP de l'abonné.
Le BNG retransmet le message DHCPv6 après avoir supprimé l'entête Relay-Reply le concernant.
(26) L'équipement d'accès (OLT) retransmet à l'IAD de l’abonné le message DHCPvé6 après avoir supprimé l'entête Relay- Reply le concernant.
5.5 Mode full RADIUS
Dans le mode Full RADIUS, le client n'a pas à maintenir un serveur DHCP, c'est le BNG Fournisseur qui prend ce rôle.
O 24 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Le client a la possibilité :
soit, d'attribuer des adresses IP fixes à ses abonnés ;
soit, d'attribuer des adresses IP dynamiques pour une durée de 2 heures.
5.5.1 Authentification et adressage IP de l’abonné
À chaque nouvel échange IP/DHCP (DHCPv4-Discover / DHCPv4-Renew ou DHCPvé-Solicit / DHCPvé-Renew), une demande d'authentification RADIUS (RADIUS Access-Request) est envoyée au serveur RADIUS Client au travers d’un Proxy-RADIUS Fournisseur.
Une fois cette demande d'authentification validée par le serveur RADIUS client (RADIUS Access-Accept), le BNG Fournisseur joue le rôle de serveur DHCP en répondant à la demande DHCP (Discover ou Renew) de l'abonné.
Une fois la phase d’authentification passée, le dialogue IP/DHCP client/serveur se déroule de façon standard.
Le BNG Fournisseur attribuera des adresses IP pour une durée de 2 heures (bail DHCPv4 / preferred-lifetime pour
DHCPvé = 2 heures).
Pour une requête DHCPv4, le BNG servira une IPv4.
Pour une requête DHCPvé, le BNG servira un IA_NA et un IA_PD.
Dans le cas d'IAD adressés en double pile, IPv4/1Pv6, le serveur Radius Client renvoie les paramètres IPv4 et IPvé6 de l'abonné dans le même message Radius Access-Accept.
5.5.2 Détail des échanges RADIUS et DHCP
5.5.2.1 DHCPv4-Discover
FT EE
BNG |
| 1 2ristnte | Lsrinresere l Het | es SE Free !
et DHCP
'
l
l
l
14D ONT Equipement d'accès BNG Proxy RADIUS Routeur Backbone Routeur usager Serveurs RADIUS
l | l
l
l
om) 0 ax à
am ©
nou | ” ©
ms °
0
D 0
Figure 13 - Mode FULL RADIUS (transaction DHCPv4-Discover)
OÜ A
1) L'IAD envoie un DHCP Discover sur son port réseau.
Equipement FTTH d'accès
O 7
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
(2) Celui-ci insère l'option 82 dans le DHCP Discover du client en y renseignant les informations suivantes :
Slot de l'équipement d'acces ;
Port abonné ;
Hostname de l'équipement d'accès.
BNG
(3) À réception du DHCP Discover, le BNG Nominal bloquera le DHCP Discover de l'IAD Abonné. Il générera un RADIUS Access Request à destination du proxy-RADIUS Fournisseur afin d'identifier l'abonné en recopiant certains champs du DHCP Discover dans sa requête (circuit-id, remote-id et vendor-dhcp).
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’abonné sur la base de son circuit-id et proxifie l'access- request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access-
request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id=;
ADSL-Agent-Remote-id=.
Les attributs radius suivants seront transmis sur demande du client :
Alc-DHCP-Vendor-Class-ld = ;
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS access-accept (5) au proxy-RADIUS Fournisseur contenant les informations suivantes :
Class ;
Framed-IP-Address ;
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns.
Proxy-RADIUS Fournisseur
Le PROXY-RADIUS Fournisseur transmet le RADIUS Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6).
Identifiant Service du client ;
Identifiant de l'abonné ;
Profil de QoS (dérive de l'attribut Class renvoyé par le client).
O 26
LE
•
•
•
•
•
•
•
•
•
•
o
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
À réception de l'Access-Accept, l'abonné est instancié dans le VPN du client avec son profil de Qos.
Le BNG répond à l’abonné (DHCP-Offer) en proposant les paramètres réseaux qui lui ont été communiqués par le serveur RADIUS (7).
L'abonné envoie un DHCP-Request (8). Le BNG, qui joue le rôle de serveur DHCP, lui retourne un DHCP-Ack(9).
L'abonné dispose d’un bail de 2 heures.
5.5.2.2 DHCPv4-Renew
Chaque DHCP-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les bases RADIUS client la procédure de renouvellement de bail entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCP et RADIUS relatifs à un renouvellement de bail :
EE | TE
!
Serveurs RADIUS
et DHCP
l
|
|
: re
Equipement d'accès
F0 BNG Proxy RADIUS Routeur has Routeur usager |
DHCP Request DHCP Request
RADIUS Request
Figure 14 - Mode FULL RADIUS (renouvellement du Bail DHCPv4)
(10) L'IAD de l'abonné envoie un DHCP-Request.
(11) Le DHCP-Request est intercepté et l'option 82 de l'équipement d'accès est insérée.
(12) Le DHCP-Request est bloqué au niveau du BNG qui envoie un RADIUS Access-Request.
(13) En retour le RADIUS du client répond avec un RADIUS Access-Accept. Le message doit contenir les attributs suivants :
Class ;
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns.
(14) Le BNG met à jour le profil de l’abonné sur la base des informations descendues par le serveur RADIUS. Il envoie un message DHCP-ACK à l'abonné contenant les paramètres réseaux descendus par RADIUS.
5.5.3 Détail des échanges RADIUS et DHCPvé
5.5.3.1 DHCPvé-Solicit
O 27
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Proxy RADIUS
Añone
|
Serveurs RADIUS
et DHCP
!
Routeur Backbone Routeur usager
|
t
l
l
: Equipement d'accès 14D ONT (OLT)
l 1
l
1
l
O TETE @ DHCPV6 Relwy-Formard (Solicit)
au» 0 TEE
CETTE EE": Ô ENTER Er
DTA TE TUE 6 DHCPv6 Relay-Reply (Advertise)
Ill
| OX ©
@ DD ET) AUTES)0)
Figure 15 - Mode FULL RADIUS (transaction DHCPvé-Solicit)
> ©
TS 1) L'IAD envoie un DHCPvé-Solicit sur son port réseau.
Equipement d'accès (OLT)
(2) L'équipement d'accès se comporte en relai DHCPvé en encapsulant la requête Solicit dans un message DHCPvé6 Relay-Forward et y insère le circuit-id de l'abonné. Le circuit-ID étant l'option 18, Interface-ID, faisant apparaitre les
informations suivantes :
Slot de l'équipement d'accès ;
Port abonné ;
Hostname de l'équipement d'accès.
BNG
Sur réception du message DHCPvé Relay-Forward (Solicit), le BNG Nominal bloque la transaction jusqu'à ce que l’abonné soit identifié. Pour cela le BNG génère un RADIUS Access-Request à destination du Proxy RADIUS Fournisseur (3) en recopiant certains champs du message DHCP dans sa requête dont le circuit-id.
Proxy-RADIUS Fournisseur
Le Proxy-RADIUS Fournisseur identifie l'opérateur client de l’abonné sur la base de son circuit-id et proxifie l'access- request au RADIUS de l'opérateur client (4).
Le proxy-RADIUS peut si nécessaire en fonction du client opérateur rajouter et/ou supprimer des attributs de l'access- request initiale du BNG Fournisseur avant de le transmettre au RADIUS du client (cf chapitre suivant).
L’Access-Request transmis au client après traitement par le proxy-RADIUS contiendra à minima les informations suivantes
User-Name= ;
User-Password = ;
NAS-IP-Address — ;
ADSL-Agent-Circuit-id=;
O 28
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Les attributs radius suivants seront transmis sur demande du client :
Calling-Station-Id :
Pour un accès Point Multipoint = #OLT#
RADIUS Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS access-accept (5) au proxy-RADIUS Fournisseur contenant les informations suivantes :
Class ;
Paramètres IPv4 en cas d'abonné en double pile :
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns ;
Paramètres lpvé :
Alc-lpvé-Address ;
Delegated-IPv6-Prefix ;
Alc-lpvé-Primary-DNS ;
Alc-Ipvé-Secondary-DNS.
Proxy-RADIUS Fournisseur
Le PROXY-RADIUS Fournisseur transmet le RADIUS Access-Accept au BNG Fournisseur en ajoutant les attributs propriétaires nécessaires à l'activation de l'abonné (6) :
Identifiant Service du client ;
Identifiant de l'abonné ;
Profil de QoS (dérive de l'attribut Class renvoyé par le client).
À réception de l'Access-Accept, l'abonné est instancié, au sein du BNG, dans le VPN du client avec son profil de Qos.
Le BNG prend le rôle de serveur DHCP. Il renseigne les paramètres réseaux de l'abonné, qui lui ont été communiqués par
le serveur RADIUS, dans un message DHCPv6 Advertise puis l’'encapsule par un entête Relay-Reply à destination de l'équipement d'accès, l'OLT (7).
S'ensuit alors un dialogue DHCPvé6 standard entre l'IAD de l'abonné, 1 relais DHCP et le serveur DHCP du BNG :
DHCPvé Relay-Reply(Advertise) (7)
DHCPvé Advertise (8)
DHCPvé Request (9) ;
DHCPvé Relay-Forward (Request) (10) :
DHCPvé Relay-Reply(Reply) (11) :
DHCPvé Reply (12).
L'abonné dispose d’un bail (ou preferred-lifetime) de 2 heures.
5.5.3.2 DHCPvé-Renew
Chaque DHCP-Renew entraîne une nouvelle authentification de l'abonné. Si le profil de l'abonné a changé dans les bases RADIUS client la procédure de renouvellement de bail entrainera la mise à jour du profil de l'abonné.
Le schéma ci-dessous présente les échanges DHCP et RADIUS relatifs à un renouvellement de bail :
O 29
•
o
•
•
o
o
o
o
o
•
o
o
o
o
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
æmm) æ
'
Serveurs RADIUS
et DHCP
l
!
1AD ONT D Ee BNG Proxy RADIUS Routeur Backbone Routeur usager
1 l
|
l
l
1
1 ll l
fe 0 sms | © BACKBONE FOURNISSEUR
1
1
1
® DHCPv6 Renew © DHCPv6 Relay-Formard{Renew)
POELE" © EEE"
EN ERRTeE à © RADIUS Accept
o Em
Figure 16 - Mode FULL RADIUS (renouvellement du Preferred-Lifetime DHCPvé)
(13) L'IAD de l'abonné envoie Un message de type DHCPvé-Renew pour renouveler le bail dhcp en conservant la même adresse |P.
(14) DHCPvé-Renew est intercepté par l'équipement d'accès (OLT) et relayé dans un message DHCPvé Relay-Forward (Renew) en y insérant le circuit-id de l’'abonné. Le circuit-id étant l'option 18 DHCPveé.
(15) (16) Le message DHCPvé Relay-Forward (Renew) est bloqué au niveau du BNG qui envoie un RADIUS Access- Request à destination du serveur client via le proxy Fournisseur.
(17) En retour le RADIUS du client répond avec un RADIUS Access-Accept. Le message doit contenir les attributs suivants
Class ;
Paramètres IPv4 en cas d'abonné en double pile :
Framed-lP-Address ;:
Framed-IP-Netmask ;
Alc-Default-Router ;
Alc-Primary-Dns ;
Alc-Secondary-Dns.
Paramètres lpvé :
Alc-lpvé-Address ;
Delegated-IPv6-Prefix ;
Alc-lpvé-Primary-DNS ;
Alc-Ipvé-Secondary-DNS.
(18) Le BNG met à jour le profil de l'abonné sur la base des informations descendues par le serveur RADIUS.
(19) Le BNG renseigne les paramètres réseaux de l’abonné, qui lui ont été communiqués par le serveur RADIUS, dans un message DHCPvé Reply puis l'encapsule par un entête Relay-Reply à destination de l'équipement d'accès, l'OLT.
(20) L'équipement d'accès OLT désencapsule le message DHCPvé6 et le transmet à l'IAD de l'abonné.
5.5.4 Limitation connue
Dans le mode Full Radius, l'option DHCPvé n°64 « Dual-Stack Lite AFTR Name » ne peut pas être délivrée au client
DHCP. Le BNG Fournisseur est à l’origine de cette limitation car il ne reconnaît pas l’attribut RADIUS contenant le nom de domaine de l’AFTR.
O 30
LE
•
•
o
o
o
o
o
•
o
o
o
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
5.6 Adressage IP des abonnés
5.6.1 Type d'adressage
L'adressage IP des abonnés est sous la responsabilité du client. Il peut être de type public, privé ou réservé selon les besoins de ses services.
Pour rappel les ranges d'adresses IP privées définis par l'IANA sont décrits dans le RFCI918 (Address Allocation for Private Internets) :
10.0.0.0 - 10.255.255.255 (10/8 prefix) ;
172.16.0.0 - 172.31.255.255 (172.16/12 prefix) ;
192.168.0.0 - 192.168.255.255 (192.168/16 prefix).
Le range d'adresses IP globales partagées est défini dans le RFC6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) :
100.64.0.0 - 100.127.255.255 (100.64/10 prefix)
Cet espace d'adressage se rapproche, de par son utilisation, des ranges IP privés du RFCI918. Il n'est pas routé sur le réseau internet et est destiné à la numérotation des interfaces IPv4 des infrastructures mettant en relation les Carrier Grade Nat avec les équipements CPE des abonnés. Son usage permettant d'une part de contourner les éventuels
dysfonctionnements du NAT des CPE lorsque la numérotation des interfaces inside et outside est de type privée, et d'autre part pour ne pas avoir de conflit entre l'adressage du lan des abonnés et wan des CPE.
5.6.2 Gestion des pools IP des abonnés
Lorsque les abonnés sont collectés dans les plaques Point-Multipoint (technologie GPON), le client ISP à la possibilité de gérer les pools IP en mode mutualisé ou par zone.
5.6.2.1 Mutualisation des pools IP
Avec ce mode d’adressage, le client ISP est en mesure de mutualiser les pools IP de ses abonnés entre plusieurs plaques Point-Multipoint du réseau du Fournisseur où bien entre ses opérateurs de collecte.
En conséquence, les annonces de la session eBGP_Data sur l'interface de Collecte permettront de distinguer individuellement chacun des abonnés avec un préfixe spécifique /32 pour IPv4 ou les préfixes spécifiques IA_Na en /64 et IA_PD, de /32 à /64, pour IPvé6 par lAD.
Dans ce mode, il est du ressort du client ISP de garantir l’unicité des adresses IP allouées aux abonnés. C'est-à-dire que le Fournisseur n'effectuera aucun contrôle sur les réponses Radius ; par exemple si une même adresse IP est allouée à deux abonnés différents sur 2 BNG différents, le préfixe spécifique sera annoncé en doublon.
En cas de transfert d'une plaque FTTH exploitée par le Fournisseur vers un autre opérateur de collecte, et vice-versa, il sera de la responsabilité du client ISP de gérer le nouvel adressage.
5.6.2.2 Gestion des pools IP par zone dans le réseau du Fournisseur
Dans ce mode d'adressage, le client ISP déclare au Fournisseur, à travers le fichier « Fiche d’interco OPERA Office 100M »,
la liste des ranges d'adresses IPv4 et/ou IPvé des abonnés ainsi que leur zone d'affectation.
Les routes spécifiques (/32 en IPv4 ou /32 à /64 en IPv6) des IAD sont filtrées par les BNG et seuls les ranges d'adresses sont annoncés dans le VPN IP.
En conséquence, les annonces de la session eBGP_Data sur l'interface de Collecte annonceront le préfixe correspondant
à chacun des pools IP AD.
Les pools IPv4 et/ou IPv6 fournis par le client sont associés au réseau de collecte d'une plaque.
Remarque : Pour chaque plaque, le client attribue une ou plusieurs plages IPv4 dont la taille à minima est celle d’un réseau de classe C (256 adresses).
O 31
LE
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
5.6.3 Adresses IP réservées
Dans le mode « DHCP & Radius », les BNGs du Fournisseur utilisent une adresse de loopback active dans le contexte de
routage dédié à l'opérateur client pour relayer les messages DHCP vers le serveur DHCP.
Au choix du client ces adresses de loopback, IPv4 ou IPvé6 selon les besoins du service, sont :
Soit les 2 premières adresses du premier sous réseau géré par les BNGSs ;
Soit 2 adresses appartenant à des sous réseaux distincts.
5.7 Profil de QoS Abonné IPOE
Le client peut demander l'implémentation de 3 profils de QoS maximum. Chaque profil est associé à une « Class » qui est échangée lors de l'authentification RADIUS comme décrit à la section « Echange Radius en mode IPoE».
Les profils sont gérés au niveau du BNG Fournisseur.
Pour chaque profil de QosS, un maximum de 3 files d'attentes ingress et egress (sens montant et descendant) est instancié par abonné.
Le trafic de l'abonné est mappé dans l’une ou l’autre de ces files d'attentes en fonction du champ IP PRECEDENCE.
VolP : IP Precedence = 5, 6, 7:
Business : IP Precendence = 3 :
DATA : IP Precedence = 0, 1, 2, 4.
Chaque file d'attente peut disposer d’une valeur de CIR et PIR qui lui est propre.
Un PIR global est défini pour l'abonné pour l'ensemble des files d'attentes
Les valeurs de chaque classe de service sont données dans le tableau ci-dessous :
Service CIR Up PIR Up CIR Down PIR Down Remarque
VolP 1500k 1500k 1500k 1500k Pour ce service : CIR=PIR
Business 100M 100M 100M 100M Pour ce service : CIR=PIR
DATA OM 500M OM 1G
Le débit maximum total pour un abonné est : IGbps / 500Mbps.
Le débit maximum de la classe Business est : 100 Mbits/s.
Le schéma ci-dessous présente la gestion de la QoS pour un abonné OPERA Office 100M :
O 32
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Figure 17 - Profil de QoS Abonné OPERA Office I00M en mode IPOE
6. MODES D'ACCES PPP ET LIVRAISON L2TP
6. Principe et modélisation de la livraison L2TP
Figure 18 - Architecture collecte PPP livrée en L2TP
O 33
Aggregate-Scheduler = Max_Ingress
Aggregate-Scheduler Max_Egress
Ingress= trafic montant
Egress= trafic descendant
VoIP
Prec 5,6, 7
CIR=PIR=MaxVoIP
CIR-PIR Level 7
Data
Prec Default
PIR=Max_Ingress
CIR-PIR Level 1
VoIP
Prec 5,6, 7
CIR=PIR=MaxVoIP
CIR-PIR Level 7
Data
Prec Default
PIR=Max_Egress
CIR-PIR Level 1
Data Business
Prec 3
CIR=PIR
=MaxDataBusiness
CIR-PIR Level 3
Data Business
Prec 3
CIR=PIR
=MaxDataBusiness
CIR-PIR Level 3 axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Le Fournisseur transporte les sessions PPP initialisées par les IAD jusqu'à l'interface de collecte. Les sessions sont ainsi prolongées et livrées à travers des tunnels L2TP (Layer 2 Tunnelling Protocol - RFC-2661) jusqu'au réseau du client.
Le Fournisseur dispose de BNG redondant au sein des réseaux d'initiative publique qui jouent le rôle de LAC. Les tunnels
L2TP sont établis entre les BNG et un ou plusieurs LNS client.
En préalable à l'établissement des tunnels L2TP et des sessions PPP, un dialogue RADIUS est nécessaire entre le Fournisseur et le client permettant l'authentification et la configuration des IAD Abonné.
Ces deux mécanismes permettent un partage des responsabilités entre le Fournisseur et le client :
Le Fournisseur est en charge du transport des sessions PPP depuis les sites Abonné jusqu'à l'interface de collecte
Le client est responsable de l'authentification des IAD, la terminaison des sessions PPP des abonnés et leur configuration (assignation d'adresse IP, ….).
Le schéma ci-après modélise les couches protocolaires mises en œuvre :
“ IP S
| session PPP = Tunnel L2TP = .
+ Te 3 *,
< session PPPOE »
es D or rene Le VPN IP ISP FX Es EP?
ONT PPPOE-IA LAC bn sn mes ENS s \
PPPOE-IA = PPPOE Intermediate Agent Proxy-Radius . Radius-ISP L2TP = Layer 2 Tunnelng Protocol Fournisseur LAC = L2TP Access Concentrator.
LNS = L2TP Network Server
10/N*10/100GigE
Figure 19 - Transport session PPP dans tunnel L2TP
Pour chaque abonné, une session L2TP est créée à l'intérieur du tunnel. Cette session est négociée au moment de prolonger la session PPP jusqu'au LNS du Client (i.e. une fois que le BNG a authentifié l'abonné).
Une fois le tunnel et la session établis, la session PPP entre l'abonné et le client peut être initialisée de façon complètement transparente pour le Fournisseur.
L'initialisation de la session PPP se déroule comme suit :
L'IAD initie une session PPPOE pour découvrir les BNG susceptibles de le prendre en charge ; L'IAD initie une session PPP qui est interceptée par le BNG ;
Le BNG demande à l'IAD de s'authentifier ;
L'IAD envoie les paramètres d'authentification (identifiant / mot de passe) au BNG : Le BNG envoie une requête RADIUS d’authentification au Proxy RADIUS Fournisseur ; Le Proxy RADIUS Fournisseur transmet la requête au serveur RADIUS du client ;
O 34
SHEWNT
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
7. Le serveur RADIUS du client authentifie l'IAD et envoie un message d'autorisation au BNG (relayé par le Proxy RADIUS Fournisseur) ;
8. Le BNG prolonge la session PPP jusqu'au LNS du client à travers un tunnel L2TP ;
9. L'IAD s'authentifie auprès du client et récupère ses paramètres réseaux.
6.2 Tunnel L2TP
Le tunnel L2TP est créé entre deux équipements : le LAC (L2TP Access Concentrator) et le LNS (L2TP Network Server).
La fonction de LAC est assurée par un équipement Fournisseur identifié par une adresse IP publique ou privée que le client aura fournie dans la fiche d'interconnexion.
La fonction de LNS doit être assurée par un équipement sous la responsabilité du Client. Le LNS est identifié par une adresse IP publique ou privée que le client aura fournie dans la fiche d’interconnexion.
La méthode de Tunnel L2TP implique plusieurs protocoles (PPP/L2TP/UDP/IP) pour transporter les paquets IP des abonnés à travers les réseaux Fournisseur et Client. La décomposition de cette surcouche est précisée ci-après :
Entête PPP = 4 voire 8 octets max
Entête L2TP = 16 octets max
Entête UDP (port 1701) = 8 octets
Entête IP = 20 octets
La surcouche protocolaire entraine par conséquent un overhead de 52 octets maximum pour le trafic IP des abonnés et 44 octets en considérant uniquement le transport des sessions PPP pour le présent service.
Aussi, afin de se prémunir de problème MTU, l'interface du LNS ainsi que celle du LAC sur laquelle est monté le tunnel L2TP doit avoir une MTU égale à 2000. Les équipements intermédiaires (entre le LAC et le LNS) doivent avoir aussi une MTU supérieure ou égale à 2000.
Le tunnel L2TP doit être établi dynamiquement : le serveur RADIUS du Client communique les informations nécessaires à son établissement. L'établissement du tunnel suit le processus suivant :
Un IAD abonné lance une demande de connexion via une requête PPP ;
Sur réception de cette requête, le Fournisseur envoie un message RADIUS access_request au serveur RADIUS du client ;
Le serveur RADIUS du client répond par un message access_accept précisant le tunnel L2TP dans lequel transporter la session PPP de l'abonné ;
Dans le cas où le tunnel n'est pas encore créé, le LAC Fournisseur négocie l'établissement du tunnel L2TP avec le LNS du client.
Une sécurisation du LNS peut être mise en place. Pour cela, le client doit disposer d’un LNS primaire et d’un LNS de backup. Les attributs L2TP du message RADIUS « access-accept » doivent, dans ce cas, être tagués. Le Fournisseur prendra en compte l’attribut « tunnel-preference » pour identifier le LNS primaire. En cas d'échec lors de la tentative de création du tunnel sur le LNS primaire, le tunnel sera monté sur le LNS de backup.
6.3 Identification Abonné
Le client peut identifier ses abonnés sur la base des attributs Radius « User-Name (attribut standard n°1)» et/ou « ADSL- Agent-Circuit-ld (attribut ADSL-Forum 356] - n°1)».
O 35
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
6.3.1 Identification sur la base du « User-Name »
Lors de la phase d'authentification, l'abonné se présente à travers le couple [< nom_ abonné », « mot_de_passe »]
attribué par le client.
Le format du « nom_abonné » devra être avec :
est une valeur alphanumérique. La chaîne de caractère doit contenir au moins un caractère et ne doit pas dépasser 64 caractères
est une valeur alphanumérique qui identifie le client. Le client indique au moment de la commande « l'identifiant-client » à utiliser. L'identifiant du client doit respecter les règles suivantes : Le client ne doit pas utiliser un identifiant correspondant à un terme déposé à l'ICANN (Internet Corporation for Assigned Names and Numbers)
Le client ne pourra pas utiliser un s'il est déjà utilisé par un autre client L'identifiant-client doit contenir au moins 2 caractères et ne doit pas dépasser 63 caractères Le client peut demander au Fournisseur d'ajouter l’ dans le « nom_abonné » à
condition que ce dernier ne contienne que l’ lorsque l’abonné se présente
Le « mot_de_passe » utilisé par le client pour identifier un abonné devra être une valeur en alphanumérique.
Le Fournisseur définit un caractère alphanumérique comme tout caractère alphabétique de À à Z ou chiffre de O à 9. Un
même caractère en majuscule et minuscule représente deux caractères alphabétiques différents.
L'attribut « ADSL-Agent-Circuit-ld » est utilisé par le Proxy RADIUS Fournisseur pour identifier l'Abonné et le serveur
RADIUS client capable de traiter la requête.
6.3.2 Identification sur la base du « Agent-Circuit-ld »
Les équipements OLTs ajoutent le PPPOE Tag aux messages PADI/PADR/PADT avec la sous-option Ox01 (Agent-Circuit-
Id).
Le format du PPPOE Tag est défini dans le document BBF TR-I0I 8 3.9.2. Il se compose de plusieurs champs dont le
TAG_ID (0x0105 = Vendor-Specific) et le TAG_ VALUE (vendor id= 0Ox000DE9 = BBF) suivis d'une suite de sous options selon les besoins. Par analogie à l'option 82 DHCPv4, les codes des sous options Agent Circuit ID et Agent Remote ID sont respectivement | et 2.
Le BNG recopie le Circuit-ld dans l’attribut Radius ADSL-Agent-Circuit-Id échangé avec le serveur Radius client.
Le format de l’attribut Radius ADSL-Agent-Circuit-Id est précisé au paragraphe « 3.2.6.Format du Circuit-ID spécifique
aux OLTs » du présent document.
6.4 Adressage IP des abonnés
Dans le mode de collecte PPPOE, les IAD doivent être adressés en IPv4 uniquement.
Le choix des adresses IPv4 des IAD Abonné est de la responsabilité du Client. Le Fournisseur ne participe pas au routage
des adresses IPv4 du client.
6.5 Profils de QoS des Abonné PPP
Le client peut demander l'implémentation de 3 profils de QoS maximum. Chaque profil est associé à une « Class » qui est
échangée lors de l’authentification RADIUS comme décrit à la section « Echange Radius en mode PPPoP». Les profils sont gérés au niveau du BNG Fournisseur.
Pour chaque profil de QoS, un maximum de 3 files d'attentes ingress et egress (sens montant et descendant) est instancié par abonné. Chaque file d'attente peut disposer d’une valeur de CIR et PIR qui lui est propre.
O 36
LE
•
•
o
o
o
o axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Un PIR global est défini pour l'abonné pour l'ensemble des files d'attentes.
Les valeurs de chaque classe de service sont données dans le tableau ci-dessous :
Service CIR Up PIR Up CIR Down PIR Down Remarque
VolP 1500k 1500k 1500k 1500k Pour ce service : CIR=PIR
Business 100M 100M 100M 100M Pour ce service : CIR=PIR
DATA OM 500M OM 1G
Le débit maximum total pour un abonné est : IGbps / 500Mbps.
6.51 Trafic descendant
Dans le sens Client vers l’abonné, afin de différencier les différentes Classes de Service, le Client devra recopier la valeur
des 3 bits de poids fort du champ DSCP (ou IP Precedence) de l'entête IP des paquets de l’'Abonné dans l’entête IP
ajoutée et utilisée pour la session L2TP. Par défaut tout le trafic abonné sera transporté en Best Effort.
VolP : IP Precedence = 5, 6, 7:
Business : IP Precedence = 3 ;
DATA : IP Precedence = 0, 1, 2, 4.
6.5.2 Trafic montant
Dans le sens Abonné vers Client, afin de différencier les différentes Classes de Service, le CPE abonné devra marquer la
valeur des 3 bits de poids fort du champ DSCP (ou IP Precedence). Par défaut tout le trafic abonné sera transporté en
Best Effort.
VolP : IP Precedence = 5, 6, 7:
Business : IP Precedence = 3 ;
DATA : IP Precedence = 0, 1, 2, 4.
7. ECHANGES RADIUS
7. Serveurs RADIUS Fournisseur et ISP
Le Fournisseur dispose d'un proxy RADIUS qui relaye les flux RADIUS (authentification et accounting) des abonnés
jusqu'aux serveurs RADIUS du client. Le client est responsable de l’authentification et du comptage.
Le client ISP peut installer un ou plusieurs serveurs RADIUS pour l’authentification des abonnés et un ou plusieurs serveurs
pour le comptage. Le partage de charge entre les différents serveurs est possible sur le proxy RADIUS Fournisseur.
L'algorithme Round Robin permet de distribuer uniformément les requêtes sur les différents serveurs RADIUS.
Le client peut regrouper la fonction d’authentification et comptage sur les mêmes serveurs RADIUS.
Lors de la souscription au service, le client communiquera au Fournisseur :
L'adresse IP publique du ou des serveurs RADIUS d’authentification ;
L'adresse IP publique du ou des serveurs RADIUS de comptage ;
Le secret RADIUS (mot de passe partagé entre le Serveur RADIUS et le Proxy RADIUS).
O 37
•
•
•
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Le client et le Fournisseur devront convenir d’un numéro de port UDP à utiliser pour les communications RADIUS entre le
Proxy RADIUS et le serveur RADIUS. Le Fournisseur propose l'utilisation du port standard UDP 1812 pour l'authentification
et 1813 pour le comptage.
Mécanisme Status-Server :
La fonctionnalité Status-Server (RFC 5997) doit être activée sur les serveurs Radius ISP. Cette fonctionnalité est une extension du protocole RADIUS permettant à un client radius (ici les proxys RADIUS Fournisseur) de vérifier l'état opérationnel d'un serveur radius (ici les serveurs RADIUS ISP). Il faut noter que ce mécanisme n'est pas équivalent à un "Keep Alive" permanent et transmis à travers un Access-Requets (RFC2865), mais est déclenché par le client radius lorsque le serveur radius est soupçonné d'être indisponible.
Sur l'absence de réponse à un Access-Request, le client radius envoie immédiatement un message status-server et
détermine ensuite l'état opérationnel ou l'accessibilité du serveur par la réception ou l'absence de réponse de ce dernier
au message status-server.
Dans le cas d'un radius client disposant de serveurs redondants, un tel mécanisme permet de détecter l'inaccessibilité
d'un serveur et solliciter immédiatement un autre serveur sans attendre plusieurs requêtes et l'expiration d'un timeout.
Les messages status-server sont transmis au serveur radius à travers un Access-Request où un Accounting-Request.
Le radius serveur répond par un message de type Access-Accept (authentication port) ou Accounting-Response
(accounting port) aux sollicitations de type request Authenticator.
Sonde Radius :
Le Fournisseur dispose d’un serveur sonde RADIUS pour effectuer des statistiques de joignabilité RADIUS avec le serveur
RADIUS client.
Lors de la souscription au service, le client communiquera au Fournisseur :
Un couple « User-name » / « User-password » dédié à la sonde RADIUS
Le secret RADIUS (par défaut il sera identique à celui partagé entre le Serveur RADIUS et le Proxy RADIUS).
Le client devra, au même titre que pour les proxys RADIUS du Fournisseur, autoriser la sonde RADIUS à interroger son ou
ses serveurs RADIUS.
7.2 Echanges RADIUS en mode IPOE
Les sections « Détails des échanges RADIUS et DHCP » ont déjà décrit les échanges RADIUS.
Ce chapitre présente spécifiquement la médiation entre les attributs RADIUS communiqués par l'ISP et par le Fournisseur.
O 38
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
7 G
A
ON
_
Proxy-Access-Accept
À
Figure 20 - Détails des Echanges Radius
7.2.1 Access-Request envoyé au Client
Le message Access-Request, associé à un échange DHCPv4 et envoyé au client, contient les champs suivants :
User-Name : l'adresse MAC de l'IAD est envoyée dans l’attribut User-Name. Le client peut demander au
Fournisseur d'ajouter un realm (RFC 2486 83) dans le User-name ;
User-Password : mot de passe identique quel que soit l’'abonné ;
NAS-IP-Address: adresse IP du NAS (BNG) Fournisseur;
ADSL-Agent-Circuit-ID et ADSL-Agent-Remote-lD. Il s'agit de la recopie des sous options 82 Circuit-id et Remote-id. Ils sont utilisés pour identifier la ligne de l’abonné.
Ces sous options sont encodées au format TLV (Type-Length-Value) dans le datagramme DHCP. Lorsque le BNG recopie
le DHCP Circuit-ID (respectivement Remote ID) dans l'attribut Agent-Circuit-ID (respectivement Agent-Remote-lD), les 2 premiers octets (sub-option-type et length) sont retirés.
Pour un accès point multipoint :
DHCP Circuit-ID : 01216f6c/742d62736e34322d303120706f6e20312f312f30312f30312f342f312f312f
RADIUS Agent-Circuit-ID : Oxéféc/742d62736e343224303120706f6e20312f312f30312f30312f342f312f312f
Remarque :
Pour les OLTSs, la totalité de l’attribut radius Agent-Circuit-Id représente l'expression hexadécimale de codes ascii. || peut
être interprété comme une chaine de caractères ASCII comme le stipule la RFC 4679 (DSL Forum Vendor-Specific RADIUS
Attributes).
Les attributs radius suivants seront transmis sur demande du client :
O 39
Access-Request
User-Name = 00:17:33:74:ca:95
User-Password = pwd
ADSL-Agent-Circuit-Id =
0x000601f400010006010e6564672d76616c39322d30313031
ADSL-Agent-Remote-Id =
0x000e6564672d76616c39322d30313031
Alc-DHCP-Vendor-Class-Id = "ISP-BOX version x.y"
NAS-IP-Address = 10.10.10.1
Proxy-Access-Request
Class = « OPERA-Office-DLmk-
ULmk-Busm »
Access-Accept
BNG Fournisseur
Proxy-Radius
Fournisseur Radius Client
Proxy de l access-
request
Proxy de l access-
accept
User-Name = 00:17:33:74:ca:95
User-Password = pwd
ADSL-Agent-Circuit-Id =
0x000601f400010006010e6564672d76616c39322d30313031
ADSL-Agent-Remote-Id =
0x000e6564672d76616c39322d30313031
NAS-IP-Address = 10.10.10.1
•
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Alc-DHCP-Vendor-Class-ld : contenant l'option 60 DHCP (Vendor class identifier) de l'IAD. Cette option permet
de connaitre le type d’IAD installé chez l’'abonné ;
Calling-Station-Id : contenant le nom du fournisseur et le type d'équipement d’agrégation. Cette option peut
être utilisée par le client pour identifier l'opérateur de collecte et le type d'infrastructure de collecte. Exemple :
Pour un accès point multipoint Calling-Station-ld = #OLT#
7.2.2 Access-Accept du Client
Le RADIUS client authentifie l'abonné et renvoie un RADIUS Access-Accept (5) au proxy-RADIUS Fournisseur contenant
les informations suivantes :
Class = OPERA-Office-DLmk-ULmk-Busm
: La valeur du débit HSI down max en Mbit/s
: La valeur du débit HSI up max en Mbit/s
: La valeur du débit VolP down de 1500 kbit/s
: La valeur du débit VolP up de 1500 kbit/s
: La valeur du débit Business up/down 100 Mbits/s
Le champ Class, défini dans la RFC 2865, permet de différencier les profils à appliquer. Le BNG se base sur cet attribut
pour identifier le profil de QoS devant être appliqué.
Les informations complémentaires suivantes sont requises dans le mode Full RADIUS
Framed-IP-Address
Framed-IP-Netmask
Alc-Default-Router
Alc-Primary-Dns
Alc-Secondary-Dns
7.3 Echanges RADIUS en mode PPPoE
Le protocole d'authentification CHAP devra être utilisé pour l'authentification des abonnés.
Les attributs RADIUS échangés entre le Proxy RADIUS Fournisseur et le serveur RADIUS du client sont listés en annexe.
7.3.1 Etablissement des tunnels L2TP
Dans le mode dynamique, le serveur RADIUS du client envoie au BNG les paramètres nécessaires à la création ou à
identification du tunnel L2TP. Le tableau ci-dessous liste les attributs RADIUS spécifiant le tunnel L2TP à utiliser. Ces
attributs sont ajoutés au message « access_accept » envoyé par le serveur RADIUS du client.
Numéro de Nom de lattribut l'Attribut Description
Tunnel-Type 64 Type de tunnel à établir : valeur fixée à 3 pour L2TP
Tunnel-Medium-Type 65 Type de protocole de transport : valeur fixée à 1 pour IPv4
Tunnel-Server-Endpoint 67 Adresse IP du LNS terminant le tunnel L2TP
Tunnel-Assignment-ID 82 Cet attribut détermine l'identificateur du tunnel L2TP qui sera ultérieurement utilisé par le BNG pour déterminer le tunnel à utiliser pour le transport de chacun des paquets des abonnés. Ce champ doit contenir l'adresse IP du LNS.
O 40
•
•
o
•
o
o
o
o
o
•
•
•
•
• axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Le client peut envoyer la description de 2 tunnels. Les attributs doivent dans ce cas être tagués conformément à la RFC
2868. Pour chaque tunnel, le client doit renseigner l'attribut « tunnel-préférence ». Le BNG Fournisseur prend en compte
cet attribut pour identifier le tunnel L2TP primaire et le tunnel L2TP de Backup (le tunnel primaire est celui ayant la
préférence la plus faible).
Caractéristiques de l’attribut « Tunnel-Preference » :
Numéro de Nom de l’attribut
l’'Attribut Description
Tunnel-Preference 83 Préférence permettant de définir le tunnel L2TP primaire (celui qui
a la préférence la plus faible)
Remarques : Les attributs RADIUS permettant de caractériser les tunnels L2TP sont spécifiés dans la RFC 2868.
Le client ISP peut demander à ce que le LAC Fournisseur (BNG) envoie une valeur spécifique de l'Attribute Value Pairs
(AVPSs) Host Name (Attribute Type 7, RFC 3931) lors de l'établissement du tunnel L2TP. Le client ISP déclara cette valeur au Fournisseur, à travers le fichier « Fiche d'interco OPERA Office 100M ».
7.3.2 Synthèse des échanges lors de l'établissement d’une session PPP-L2TP
Le schéma ci-dessous synthétise les messages PPP, L2TP et RADIUS échangés lors de l'ouverture d'une session PPP.
A] axione 152 avenue Pierre Brossolette Annexe 2A — STAS OPERA Office 100M — 92240 Malakoff
Y Y
À
À
À
À
Y
À
Y
<<
Y
Y
À
A
A
Figure 5 - Synthèse des échanges pour la création d'une session PPP-L2TP
7.3.3 Attributs RADIUS échangés
Les échanges entre le Proxy RADIUS Fournisseur et les serveurs RADIUS du client sont détaillés ci-dessous. Les attributs RADIUS mentionnés sont définis dans les RFC 2865 et 2868 pour l'authentification et RFC 2866 et 2867 pour le comptage.
Remarque : La liste des attributs radius spécifiés dans les messages ci-après n'est pas exhaustive et peut présenter des
différences avec la réalité.
O 42
Lan
Abonné
Réseau
Ethernet / MPLS
Fournisseur
Proxy Radius
Fournisseur
Radius Client
Réseau
Transport IP/MPLS
Fournisseur
Reseau
du FAI
BNG
Fournisseur
LNS
Client
PPP (PADI)
PPP (PADO)
PPP (PADR + pppoe tag)
PPP (PADS)
LCP Config Request (option 3 = CHAP)
LCP Config Request
LCP Config Ack
PAP/CHAP Authentification Response
Radius Access Request
Radius Access Request
Détermination ISP par
analyse attribut Radius
« Agent-Circuit-Id »
Radius Access Accept
Radius Access Accept
ICRQ (Incoming Call Request)
ICRP (Incoming Call Reply)
ICCN (Incoming Call Connected)
ZBL ACK (Zero Length Body)
IPCP Config Request (adresse IP proposée = 0.0.0.0)
IPCP NAK (adresse IP propososée = IP_Abonné)
IPCP Config Request (adresse IP proposée = IP_Abonné)
IPCP ACK (adresse IP acceptée = IP_Abonné)
Session
L2TP
Transparent pour
Fournisseur
SCCRQ (Start Control Call Request)
SCCRP (Start Control Call Reply)
SCCCN (Start ControlCall Connected)
ZBL ACK (Zero Length Body)
Création du
tunnel L2TP si
L2TP en mode
dynamique
Interface
Livraison
OLT
Fourni
sseur
IAD
PPP (PADI + pppoe tag)
PPP (PADI)
PAP/CHAP Authentification Challenge
LCP Config Request (option 3 = CHAP)
LCP Config Ack (option 3 = CHAP)
PAP/CHAP Authentification Success axiIone
L'authentification RADIUS
152 avenue Pierre Brossolette
92240 Malakoff
Annexe 2A — STAS OPERA Office I00M
° Message « access-request » émis par le Proxy RADIUS Fournisseur vers le RADIUS du client
Attibuts associés au paquet RADIUS « ACCESS_REQUEST >»
re: Numéro . Nom de l’attribut PTT Description N'a
User-name ] Nom de l'abonné identifiant_abonné@identifiant_client
NAS-IP-Address 4 Adresse IP du BNG Fournisseur XXX.XXX.XXX.XXX
AA Creuit-ld ADSL Forum | Circuit Id de l'abonné Access_Node_ID PON
s-Agent-Cireuit- Na Rack/Frame/Slot/PON/ONU/OnuSit/UNI/I-VID
NAS-Port-ID 87 NAS port ID Interface logique de collecte du BNG associée à
l'abonné
-Client- - Alcatel
Alc-Client-Hardware Adresse MAC IAD Abonné XX.XX.XX.XX.XX.XX Adar N° 27
Acct-Session-ld 44 Identifiant de la session
Calling-Station-Id SI Identifiant Fournisseur et type #Nom-Fournisseur#OLT équipement d'accès
CHAP-Password 3 Mot de Passe CHAP de l'abonné Password
CHAP-Challenge 60 Challenge CHAP Challenge
° Message « access-accept » émis par le RADIUS du client vers le Proxy RADIUS Fournisseur
Nom de l’attribut Numéro PaNutgleivit Description
Attributs associés au paquet RADIUS « ACCESS_ACCEPT »
N'a
Class 25 Profil à appliquer à l’'Abonné OPERA-Office-DLmKk- ULmk-Busm
Tunnel-Typet) 64
Attribut obligatoire dans Access-Accept.
Spécifie le type de tunnel à établir : valeur
fixée à 3 pour L2TP.
Tunnel-Medium-Typet) 65
Attribut obligatoire dans Access-Accept.
Spécifie le type de protocole de
transport pour le tunnel L2TP : valeur
fixée à | pour IPv4.
Tunnel-Server-Endpoint{) 67 Adresse IP du LNS terminant le tunnel L2TP XXX.XXX.XXX.XXX
Tunnel-Assignment-ID( 82
Cet attribut détermine l’identificateur du
tunnel L2TP qui sera ultérieurement utilisé
par le BNG pour déterminer le tunnel à
utiliser pour le transport de chacun des
paquets des abonnés. L'identificateur du
tunnel doit désigner de manière unique
un EINS. Le Fournisseur recommande
d'utiliser l'adresse IP du LNS pour cet
identificateur. Dans le cas où plusieurs
tunnels doivent être créés entre un BNG
et un LNS, Le Fournisseur recommande
d'ajouter une chaîne supplémentaire à
l'adresse IP du LNS.
XXX.XXX.XXX.XXX
(1) : Envoyé uniquement lors d’un établissement dynamique du tunnel L2TP
O 43 axiIone 152 avenue Pierre Brossolette Annexe 2A - STAS OPERA Office 100M — 92240 Malakoff
. Message « access-reject » émis par le RADIUS du client vers le Proxy RADIUS Fournisseur
Aucun attribut n'est requis dans ce message.
44 axiIone
ANNEXE 1 : DICTIONNAIRE RADIUS
152 avenue Pierre Brossolette
92240 Malakoff
# Standard
#
ATTRIBUTE User-Name 1
ATTRIBUTE User- Password 2
ATTRIBUTE NAS-IP-Address 4
ATTRIBUTE NAS-Port 5
ATTRIBUTE Service-Type 6
ATTRIBUTE Framed-lP-Address 8
ATTRIBUTE Framed-IP-Netmask 9
ATTRIBUTE Class 25
ATTRIBUTE Configuration-Token 78
ATTRIBUTE Calling-Station-ld 31
ATTRIBUTE CHAP-Password
ATTRIBUTE CHAP-Challenge
ATTRIBUTE Tunnel-Type 64
ATTRIBUTE Tunnel-Medium 65
ATTRIBUTE Tunnel- Server-Endpoint 67
ATTRIBUTE Tunnel- Assignment 82
ATTRIBUTE NAS-Port-Id 87
ATTRIBUTE Delegated IPvé Prefix 123
#
# Alcatel vendor specifics
#
VENDORATTR 6527 Alc-DHCP-Vendor-Class-Id
Annexe 2A - STAS OPERA Office 100M
VENDORATTR 6527
VENDORATTR 6527
VENDORATTR 6527
VENDORATTR 6527
VENDORATTR 6527
VENDORATTR 6527
VENDORATTR 6527
#
#ADSL-Forum
#
VENDORATTR 3561
VENDORATTR 3561
Alc-Default-Router
Alc-Primary-Dns
Alc-Secondary-Dns
Alc-Client-Hardware-Addr
Alc-Ipvé-Address
Alc-1pvé-Primary-DNS
Alc-Ipvé-Secondary-DNS
ADSL-Agent-Circuit-ld
ADSL-Agent-Remote-ld
string
string
ipaddr
integer
integer
ipaddr
ipaddr
string
string
string
3 octets
60 octets
string
string
string
string
string
ipvépref
36 string
18 ipaddr
9 ipaddr
10 ipaddr
27 MAC addr
99 ipvéadar
105 ipvéadar
106 ipvéadar
1 string
2 string
45 Annexe 2A — STAS OPERA Office I00M 152 avenue Pierre Brossolette
axione 92240 Malakoff
ANNEXE 2 : GLOSSAIRE
ACL Access Control List
BGP Border Gateway Protocol
BNG Broadband Network Gateway
CIR Committed Information Rate
DHCP Dynamic Host Configuration Protocol
DSCP Differenciated Service Code Point
GPON Gigabit Passive Optical Network
HSI High Speed Internet
lAD Integrated Access Device
IGMP Internet Group Management Protocol
LAN Local Area Network
MSDP Multicast Source Discovery Protocol
NRO Nœud de Raccordement Optique
OLT Optical Line Terminal
ONT Optical Network Terminal
PIM-SM Protocol Independant Multicast - Sparse Mode
PIM-SSM Protocol Independant Multicast - Source Specific Multicast
PIR Peak Information Rate
PPP Point-to-Point Protocol
PPPOE Point-to-Point Protocol over Ethernet
RFC Request For Comment
RP Rendez-vous Point
STB Set Top Box
VLAN Virtual LAN
VoD Vidéo on Demand
VolP Voice Over IP
VPN Virtual Private Network
VPLS Virtual Private Lan Service
A6 CONTRAT OPERA Office
CONDITIONS PARTICULIERES 25.01
IL mn … “OFFICE
QXI21NE animons le monde axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
92240 Malakoff
Table des matières
1.
2
3.
À
8.
9.
10.
DÉFINITIONS un rrrnrnnrnrnennrnrennennnnnennnnnenennnnnnnnnnnnnenennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnennenennnnnnnee 4
OBJET DES CONDITIONS PARTICULIERES nee 5
DOCUMENTS CONTRACTUELS ner 5
DESCRIPTION DU SERVICE nn 6
4. Le Service... rrnrnrnnnnrnnennnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnennnnnee 6
4.1. Le Raccordement... sine 6
A2 L'ACCÈS... NL rrnrnrnenrnrnenennnnennnennnnnenennnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnennnnnenennnes 7
41.3 Garantie de Temps de Rétablissement.... inner 7
4.1.4 La Collecte... inner Erreur ! Signet non défini.
4.2 La composante Porte de Livraison... rennes 8
4.3 Spécifications Techniques d'Accès au Service (STAS).... rennes 8
COMMANDES DU SERVICE nn 8
5. Ligne OPERA OFFICE... nr 8
5.1. Eligibilité d'une adresse au Service... inner 8
5.1.2 Prise de commande... ire 8
5.2 Prévisions de COMMaANnde nine 8
5.3 Mandat de l'ABONNÉ nn 9
DELAIS ET MODALITES DE MISE EN SERVICE ner 9
6. Mise en service d’une Porte de Livraison... sise 9
6.1. Délai de mise en Service... rrnnnnnnennnnnennnnnennnnnnnnnnnnnnnennnnnnnnnnnennnnnnes 9
6.1.2 DUTÉE rm nnnnnnnnnnnnnnnnnnnnennenennnes 9
6.2 Mise en service d’une Ligne OPERA Office... nn 9
6.2. Rendez-vous d'installation... inner 9
6.2.2 Installation sur le Site Utilisateur... inner 10
6.2.3 Délai de mise à disposition... rennes 10
6.2.4 Difficultés de construction sur le Raccordement Client Final... ren (l
6.2.5 Equipements de l'Utilisateur Final... inner I]
6.2.6 Date de Début du Service... inner (l
6.2.7 Durée du Lien d'ACCÈS.... nn 12
RESILIATION DU SERVICE rennes 12
71 Résiliation d'une Ligne OPERA Office ou d’une option GTR 10H du fait du Client... rm 12
711 Résiliation d’une Ligne OPERA Office... rennes 12
71.2 Résiliation d'une option de GTR 10H rennes 13
7.2 Résiliation d'une Ligne OPERA Office pour perte d'ACCÈS...n rennes 13
7.3 Résiliation d’une Porte de Livraison... rennes 13
CESSION OÙ FIN DE LA DELEGATION DE SERVICE PUBLIC un rnrnrnnrnrnenennennenennneneennnennnes 13
MODIFICATION REGLEMENTAIRE OÙ LEGISLATIVE nn 14
DISPOSITIONS FINANCIERES un rrrrnrnnrnrennrnnrennnnennnennnnnennnnnnnenennennnnnnnnnnnnenennennennnennnnnnnnennnnnnee 14
10.1 Tarifs ner 14
10.2 Evolution tarifaire... inner 14
O 2
2e axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
10.3 Facturation... sir nee nee 14
11. LA MAINTENANCE DU CABLAGE FTTH PASSIF. nn 15
12. SERVICE APRES-VENTE.. rennes 15
12. Accueil des signalisations sine 15
12.2 Signalisation d'un dysfonctionnement.... ss 15
12.3 Domaine d'intervention du Fournisseur... ner 15
12.4 Procédure d'escalade hiérarchique... nr 16
12.5 Signalisation transmise à tort... inner 16
12.6 Maintenance programMmmMÉE nn 16
13. NIVEAU D'ENGAGEMENT DE SERVICE nn irnnnnnnnnnnnnnnenneneenennnneennenennnnes 16
13.1 Engagement du Fournisseur... nee 16
13.2 Pénalités dues par le Client... inner 19
14. EVOLUTION DU CONTRAT LL nrnrnrennnnnnnnnnennennnnnne een 19
15. OBLIGATIONS DES PARTIES... iiirnrnnmennnnnnnnenenennnennnnneeeneneeeeneeennes 20
IST rer nn nn nee nn nn ee eee 20
152 ere nee nn nn nn nn nn nn nn nee nee 20
15.8... nn eee nee ineen nnn ennnnnnnn nn eeennnennnnenenes 21
15.4 nee nee nee eee eee 21 axiIone 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01 — 92240 Malakoff
1. DEFINITIONS
En complément des définitions prévues dans les Conditions Générales, les termes suivants, utilisés dans les présentes Conditions Particulières, auront la signification qui suit :
« Abonné », « Utilisateur » ou « Utilisateur Final » désigne la personne physique ou morale souscrivant le Service auprès du Client.
« Affilié » désigne toute société qui, directement ou indirectement, (i) contrôle l'une des Parties, ou (ii) est contrôlée par l'une des Parties, ou (iii) est contrôlée par toute société visée au (i) ci-dessus. "Contrôler" une société signifie posséder, directement ou indirectement, plus de cinquante pour cent (50 %) des actions ou des parts sociales de ladite société ou détenir la majorité des droits de vote dans les conditions prévues par l'article L.233-3 du Code de commerce.
« Avis de mise à disposition du Service » désigne toute notification de la mise à disposition du Service par le Fournisseur au Client sous format papier ou électronique.
« Câblage FTTH >» désigne l'ensemble des fibres, câbles, matériels et locaux techniques entre le PM et le PTO.
« Collecte » désigne la bande passante entre le Local FTTH et la Porte de livraison.
« Collectivité Locale Délégante » désigne, dans le cadre des délégations de service public, la personne publique autorité délégante, propriétaire du réseau, support du Service.
« Commande » désigne une demande adressée par le Client au Fournisseur relative à l'exécution de Prestations désignées dans le Contrat et conforme aux Conditions Particulières et aux Conditions Générales ainsi qu'à leurs annexes.
« Desserte interne » désigne la portion du Raccordement FTTH Passif entre l'ONT et la limite de domaine privé.
« Equipement Terminal » désigne l'ensemble des matériels - propriété du Client, d'un tiers mandaté ou de l'Utilisateur Final — installé par ces derniers sur le Point de Terminaison Optique et qui, une fois connectés aux équipements informatiques de l'Utilisateur Final, lui permettent d'utiliser le Lien d'Accès.
« Equipements du Fournisseur » désigne tout équipement, mutualisé ou dédié, sous la responsabilité du Fournisseur ou de ses fournisseurs et utilisé par le Fournisseur pour rendre le Service.
« Fournisseur» désigne Axione où une Mandante, en tant qu'Opérateur d'immeuble.
« FTTH » (Fiber To The Home) désigne la liaison par fibre optique jusqu'au foyer du Client Final
« Heures Ouvrables » désigne la période de 8h à 18h les Jours Ouvrables.
« Heures Ouvrées » désigne la période de 8h à 18h les Jours Ouvrées.
«Immeuble FTTH » désigne un bâtiment ou un ensemble de bâtiments à usage d'habitation, à usage professionnel où à usage mixte et pour lequel le Fournisseur a signé une Convention avec le Gestionnaire d'Immeuble permettant l'installation, l'exploitation et la maintenance d'un Câblage FTTH.
« Incident Majeur » désigne une occurrence de panne du Réseau rendant le Service indisponible pour l'ensemble de Liens d'Accès d’un PM, d'un NRO ou d'un arbre PON.
« Jour Ouvrable » désigne tout jour à l'exception du dimanche ou de tout autre jour férié en France.
« Jour Ouvré » désigne tout jour à l'exception du samedi et du dimanche et de tout autre jour férié en France.
« Lien d'Accès » désigne la liaison établie par le Fournisseur conformément aux présentes Conditions Particulières. Les caractéristiques techniques des Liens d'Accès sont décrites dans les Spécifications Techniques d'Accès au Service. Un Lien d'Accès est réservé au raccordement d'un Utilisateur Final unique.
« Ligne FTTH » (Fiber To The Home) désigne la liaison par fibre optique jusqu'au foyer de l’Utilisateur Final.
« Ligne FTTH Passive » désigne le service fourni dans le cadre du contrat FTTH Passif.
« Local FTTH (Locaux FTTH) » désigne le logement ou le local professionnel d’un Utilisateur Final réel ou potentiel situé dans un Immeuble FTTH ou dans un Pavillon FTTH.
« Nœud de Raccordement Optique » ou « NRO » désigne le site qui héberge l'équipement d'accès actif d'un Utilisateur Final. Ce site peut être, entre autres cas, un PM-NRO.
« ONT » où « Optical Network Termination » désigne l'équipement actif convertissant les signaux optiques en signaux électriques. L'ONT correspond au Point de Terminaison.
O 4 axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
« Outil d’Eligibilité > désigne l'outil qui permet de vérifier l’éligibilité d’une adresse au Service.
« Parc » désigne l’ensemble des lignes OPERA Office souscrites par le Client.
« Pavillon FTTH >» désigne un bâtiment à usage d'habitation, à usage professionnel ou à usage mixte pour lequel le Fournisseur a installé une ligne FTTH. Un Pavillon FTTH n'est pas un Immeuble FTTH.
« Plaque » désigne tout ou partie du Réseau FTTH de la Collectivité Locale Délégante. Chaque Plaque appartient au
domaine public de la Collectivité Locale Délégante. L’occupation de ces Plaques est soumise au régime de la domanialité
publique, et en particulier aux dispositions de Code Général de la Propriété des Personnes Publiques. Les conditions
contractuelles et tarifaires peuvent varier selon la Plaque considérée.
« Point de Branchement Optique » ou « PBO » désigne le boitier auquel le logement ou le local professionnel de
l’Utilisateur Final doit être raccordé pour la mise en service des offres du Client.
« Point de Terminaison » ou « PT » désigne l'interface terminale de la Ligne OPERA Home située à l'intérieur du Site Utilisateur Final. Ce Point de Terminaison correspond à un ONT.
« Point de Mutualisation » ou « PM >» désigne le point sur lequel les liens fibres optiques de la boucle locale optique sont
concentrés pour être connectés au réseau actif FTTH.
« Point de Terminaison Optique » ou « PTO » désigne la limite de séparation entre le raccordement au PBO et
l’installation privative de l’Utilisateur Final. Le PTO est situé dans l'habitation ou le local professionnel de l'Utilisateur Final.
Il est matérialisé par un équipement comportant une ou plusieurs prises.
« Porte de Livraison » désigne l'interface physique sur laquelle le Fournisseur livre le Service au Client.
« Raccordement FTTH Passif » désigne un raccordement du Local FTTH techniquement compatible avec les
recommandations techniques du Service. Ce raccordement va de la soudure au PBO jusqu'au PTO compris. Cette
définition est valable quel que soit le mode de raccordement du Site FTTH (génie civil, appui aérien, boitier en façade).
« Réseau » ou « Réseau FTTH >» désigne l'ensemble des équipements et infrastructures exploités par le Fournisseur,
support du Service.
« Service » ou « Ligne OPERA Office » désigne le service « Ligne OPERA Office » fourni par le Fournisseur au Client au titre des présentes Conditions Particulières.
« Site Utilisateur » désigne le(s) bâtiment(s) ou espaces dans lesquels le Client ou un Utilisateur Final est situé et où l'Equipement Terminal sera installé.
2. OBJET DES CONDITIONS PARTICULIÈRES
Le service « Ligne OPERA Office » est un service de vente d'accès FTTH qui permet au Client d'offrir sous sa propre marque, aux Utilisateurs finaux, un service d'accès très haut débit à valeur ajoutée.
Les présentes Conditions Particulières ont pour objet de définir les termes et conditions dans lesquels le Fournisseur assure au titre d’une obligation de moyens renforcée, au bénéfice du Client, la fourniture du Service. Sa fourniture donne lieu à la signature des Conditions Particulières du Service.
3. DOCUMENTS CONTRACTUELS
« Li ice », désigné ci-après « » u Uiv . u Le contrat « Ligne OPERA Office », désigné ci-après « le Contrat » se compose des documents suivants. Etant entend
qu'en cas de contradiction ou de divergence entre plusieurs documents contractuels, les documents ci-dessous prévalent dans l’ordre suivant :
- les Commandes d'accès transmises au Fournisseur,
- les présentes Conditions Particulières,
- les Annexes aux Conditions Particulières.
- Les Conditions Générales de la Convention Cadre d'approvisionnement de Services de télécommunications du Fournisseur.
Les Annexes aux Conditions Particulières se décomposent comme suit :
O 5
LE axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
- L’'Annexe | - Tarifs — Ligne OPERA Office
- L'Annexe IA — Pénalités
- L’Annexe IL.B - Bordereau travaux complémentaires sur domaine privé
- L’Annexe 2.A — Spécifications Techniques d'Accès au Service Ligne OPERA Office Basic - L’'Annexe 2.B - Spécifications Techniques d'Accès au Service Ligne OPERA Office PRO - L’'Annexe 2.C - Spécifications Techniques d'Accès au Service Ligne OPERA Office 100Mbps
- L’Annexe 3 - Bon de commande Porte de Livraison
Le Contrat exprime l'intégralité des obligations des Parties, il annule et remplace tous accords écrits et verbaux, toutes correspondances où propositions entre lesdites Parties, antérieurs à sa signature et ayant le même objet.
À. DESCRIPTION DU SERVICE
Les présentes Conditions Particulières s'appliquent au service Ligne OPERA Office.
4.1 Le Service
Le Service consiste en la fourniture et la maintenance d’une prestation comprenant :
- Le raccordement d’un Site Utilisateur au réseau
- La pose du PTO chez l'abonné
- Le transport des flux du Client depuis le local FTTH de l’Abonné jusqu’à la Porte de Livraison - La Collecte
- La Porte de Livraison qui correspond à la mise en place de l'interconnexion avec le réseau du Client pour la livraison des lignes OPERA Office
- Une prestation optionnelle d'installation d'Equipement Terminal
Les Lignes FTTH sont exclusives : il ne peut y avoir qu'une seule Ligne FTTH (Active ou Passive) par Local FTTH.
Néanmoins, une seconde Ligne pourra être livrée sur un Local FTTH, selon éligibilité.
AI. Le Raccordement
Cette prestation consiste en la création d’une continuité optique entre le PTO et le PM. Deux sous-prestations techniques sont nécessaires :
- La construction d'un Raccordement FTTH Passif entre le PBO et le PTO si le Local FTTH n'en est pas déjà équipé, - Le brassage de la Ligne FTTH au PM.
La réalisation d'un Raccordement FTTH Passif est nécessaire lors de la première activation du Service commandé.
La réalisation d’un brassage au PM est nécessaire pour toute Commande d’un Accès FTTH,.
Dans le détail, le Raccordement FTTH Passif comprend :
La mobilisation/réalisation du génie civil et des autorisations associées le cas échéant, La mobilisation d'une nacelle et des autorisations associées le cas échéant, La fourniture et la pose d’un Raccordement FTTH Passif,
La demande et l'obtention d'une autorisation de syndic pour la pose d’une goulotte en parties communes le cas
échéant,
La soudure par fusion au PBO,
La fourniture et pose du PTO chez l’'Abonné,
La mise en continuité optique entre le PBO et le PTO de l'Utilisateur Final. L'envoi du Compte Rendu d'intervention (CRI)
BONT
œ
No
un
La distance maximale du Raccordement FTTH Passif en domaine privé est de 50 ml avec un objectif de 15 mil maximum
en desserte interne dès pénétration dans le local FTTH.
O 6
LE axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Le choix de l'emplacement du PTO est fait en accord avec l’'Utilisateur Final, et dans la limite des conditions de distances précisées ci-dessus. Autant que possible, le PTO sera placé dans un endroit qui favorise l'exploitation optimisée des
Equipements du Fournisseur Le Client peut passer commande auprès du Fournisseur d'une prestation d'intervention chez un Utilisateur Final pour modifier l'emplacement du PTO précédemment installé par le Fournisseur si l’'Utilisateur Final en a fait la demande auprès du Client. Dans ce cas, le Fournisseur facturera au Client cette prestation comme indiqué en Annexe I.
Lors d’un Raccordement Client Final, au-delà de la limite de prestation telle que définie dans le présent Contrat, les surcoûts seront à la charge du Client. A ce titre, le Fournisseur arrête son intervention, informe l’'Utilisateur Final et
adresse au Client un Compte Rendu d'intervention précisant autant que possible les travaux nécessaires pour d'effectuer le Raccordement Client Final
Dans le cas où la difficulté de raccordement est uniquement liée à une surlongueur de câble en domaine privé, selon la
Mandante concernée, le Fournisseur peut émettre un devis au Client en respectant la tarification précisée en Annexe I. Ce devis sera soumis à l'acceptation du Client.
Dans les autres cas nécessitant des travaux complexes en domaine privé et hors cas spécifiques chez certaines Mandantes qui sont indiqués en Annexe LB, l’'Utilisateur Final pourra:
- Soit mandater une entreprise tierce pour réaliser les travaux,
- Soit, si le Client le propose, mandater ce dernier pour réaliser les travaux ou les faire réaliser.
Dans le cas où le Client serait mandaté, celui-ci pourra faire la demande auprès du Fournisseur de réaliser lesdits travaux sur le domaine privé de l'Utilisateur Final. A ce titre, le Fournisseur émettra un devis au Client en respectant la tarification en Annexe 1.B. Ce devis sera soumis à l'acceptation du Client, ce dernier devant obtenir la validation écrite de l'Utilisateur Final. Suite à cette acceptation, le Fournisseur procède aux travaux sur le domaine privé et facture le Client du montant du devis. En cas de refus de ce devis ou de non-réponse dans un délai de quinze (15) Jours Ouvrés, le Fournisseur ne procède pas au Raccordement Client Final, la commande devra obligatoirement être annulée par le Client et le Fournisseur facture au Client une « Pénalité pour déplacement à tort - Annulation de commande après déplacement du technicien » dans les conditions tarifaires précisées en Annexe l.A.
AI.2 L'Accès
La composante Accès consiste en l'activation du Service sur la Ligne FTTH. Cette prestation comprend :
- Le transport des flux de service sur le Réseau, avec la qualité de service souscrite ; - La livraison au Client des flux sur une Porte de Livraison.
- La fourniture et la pose du PT chez l’'Abonné selon la validation faite entre les Parties, - La Collecte qui matérialise la bande passante concédée au Client pour transporter ses flux unicast depuis les Locaux FTTH de ses clients jusqu’à sa Porte de Livraison.
Le Service est limité, du côté Utilisateur Final par l'ONT et du côté Client, par la Porte de Livraison.
Le Client pourra choisir lors de sa commande le type d'Accès pour sa Ligne OPERA Office
Il existe trois (3) types d'Accès :
- Basic ;
- PRO ;
- 100 Mbps.
Les Annexes 2 décrivent les spécificités techniques de chaque type.
41.3 Garantie de Temps de Rétablissement
OPERA Office Basic
Une Ligne OPERA Office Basic est fournie sans Garantie de Temps de Rétablissement (GTR).
O 7
LE axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
OPERA Office Pro
Une option de GTR 10h peut être souscrite sur des Accès OPERA Office Pro, soit lors de la Commande de ladite Ligne, soit ultérieurement sur une Ligne OPERA Office Pro déjà en service.
OPERA Office 100 Mbps
Une Ligne OPERA Office 100 Mbps est fournie avec une Garantie de Temps de Rétablissement (GTR) de 10h.
4.2 La composante Porte de Livraison
La Porte de Livraison représente l'interface physique d'interconnexion entre le Réseau et le réseau du Client et sur laquelle le Fournisseur livre l'ensemble des Lignes OPERA Office au Client.
Plusieurs types d'interfaces sont compatibles avec ce service, les spécifications techniques de ces interfaces sont décrites en Annexe 2 du Contrat.
4.3 Spécifications Techniques d'Accès au Service (STAS)
Les STAS, jointes en Annexe 2, complètent les présentes Conditions Particulières et précisent les modalités techniques du Service.
5. COMMANDES DU SERVICE
5. Ligne OPERA Office
511 Eligibilité d'une adresse au Service
Afin de tester l’éligibilité d’une adresse au Service, le Fournisseur utilise un Outil d’Eligibilité permettant d'évaluer en temps réel l'éligibilité technique d'une adresse au Service ainsi que la présence du Raccordement FTTH Passif dans le Local FTTH.
Cette éligibilité donnera également l'information sur la catégorie du Raccordement du Local FTTH.
Les spécifications du service d'éligibilité seront détaillées par les Parties au plus tard au jour de la signature des présentes.
51.2 Prise de commande
La Commande d’une Ligne OPERA Office peut être réalisée via le Portail Client ou en Webservice.
Il est entendu que, préalablement à toute Commande de Ligne OPERA Office, le Client devra souscrire ou avoir souscrit
une Porte de Livraison.
Pour le produit OPERA Office Basic, une annulation sans frais du Fournisseur pourra survenir jusqu'à la mise en service.
5.2 Prévisions de commande
Le Client transmettra au Fournisseur des prévisions de commandes trimestrielles. Ces prévisions couvriront une période glissante de trois (3) mois.
Cette prévision devra être communiquée au format conjointement défini par les Parties.
O 8
2e axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Ces prévisions seront utilisées par le Fournisseur pour dimensionner son réseau ainsi que ses équipes de déploiement, et permettront au Fournisseur de respecter au mieux les délais de mise à disposition indiqués en 6.2.3 du présent Contrat.
Les prévisions données par le Client sont indicatives, et ne sauraient en aucun cas engager le Client à commander le
nombre de Portes de Livraison et/ou de Lignes OPERA Office ou toute autre Prestation figurant dans ses prévisions.
5.3 Mandat de l’'Abonné
Le Client s'engage expressément à obtenir de l’Utilisateur Final un mandat selon le formalisme de son choix l'autorisant à agir en son nom et pour son compte pour effectuer auprès du Fournisseur les démarches nécessaires à la mise en œuvre des services du Client sur une Ligne FTTH avec, le cas échéant, la résiliation de tout ou partie des services fournis par le Fournisseur et/ou un autre opérateur sur cette Ligne FTTH.
Le Client est seul responsable vis-à-vis du Fournisseur du respect, par les opérateurs auprès desquels il commercialise des
offres de gros, des obligations relatives au mandat.
En cas de construction de Raccordement FTTH Passif, le Client s'assure d'obtenir du propriétaire d’un Local FTTH un accord lui permettant de procéder à la construction du Raccordement FTTH Passif. Cet accord est expressément stipulé au bénéfice du Fournisseur, pour une durée de 6 mois minimum.
6. DELAIS ET MODALITES DE MISE EN SERVICE
6.1 Mise en service d'une Porte de Livraison
6.1.1 Délai de mise en service
Le délai d'activation d’une Porte de Livraison est de six (6) semaines à compter de la date de prise de la Commande concernée.
6.1.2 Durée
Une Porte de Livraison est souscrite pour une période initiale de douze (12) mois à compter de sa mise en service. Conformément aux dispositions de l’Article 9.2 de la Convention Cadre, à l'issue de la période initiale, la Porte de Livraison sera tacitement reconduite pour une durée indéterminée, le Client pouvant alors y mettre un terme sans pénalité, par lettre recommandée avec avis de réception adressée au Fournisseur en respectant un préavis de un (1) mois.
6.2 Mise en service d’une Ligne OPERA Office
6.2.1 Rendez-vous d'installation
L'installation chez l’Utilisateur Final peut entraîner un déplacement chez ce dernier notamment dans le cas où il s'agit d'un premier raccordement du Local FTTH ou dans le cas d’un local FTTH non équipé d’un ONT. Ainsi, lors de la prise de la Commande :
Lorsqu'un déplacement est nécessaire, un rendez-vous d'installation chez l’'Utilisateur final doit être organisé. Le cas échéant, le Client s'engage à utiliser lIHM ou le webservice mis à disposition par le Fournisseur afin de l’informer de la nécessité de prévoir un rendez-vous. Un ID « rendez-vous » est alors communiqué au Client. Cet
ID de rendez-vous sera rappelé par le Client lors de la transmission de la Commande au Fournisseur. Cet ID de rendez-vous fixe la date et créneau horaire d'intervention du Fournisseur ou de son prestataire chez l’Utilisateur
Final pour la Mise en Service.
Lorsqu'aucun déplacement n'est nécessaire, le Client utilisera un ID normé équivalent à une absence de rendez-
vous, convenu entre les Parties, dans la Commande. axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Le Client est responsable vis-à-vis du Fournisseur de la présence de l’'Utilisateur Final au rendez-vous d'installation. Le Client s'engage à payer au Fournisseur les pénalités libératoires décrites dans l'Annexe IA pour toute intervention non aboutie pour faute d'absence de l’Utilisateur Final au rendez-vous d'installation ou refus de raccordement de l'Utilisateur
Final (sous réserve de fournir au Client une liste lui permettant d'identifier les Utilisateurs Finaux concernés).
Réciproquement, si le Fournisseur n'est pas présent au rendez-vous, il sera redevable de pénalités au bénéfice du Client, définies en Annexe IA.
Le Fournisseur met à disposition du Client un outil permettant au Client de réserver, confirmer, modifier ou annuler des rendez-vous.
6.2.2 Installation sur le Site Utilisateur
Le Fournisseur raccorde le Local FTTH de l’Utilisateur Final à son infrastructure optique, fournit et installe chez ce dernier
un PTO et un PT. Il valide la continuité optique du Raccordement FTTH passif au Réseau.
Dans le cas où seul un PTO compatible au Service est préalablement installé, le Fournisseur fournit et installe chez l’Utilisateur Final un PT.
La validation du bon fonctionnement du Service est à la charge du Client. Il est de la responsabilité du Client de fournir, d'installer et de mettre en service son Equipement Terminal sauf si l'option d'installation de l'Equipement Terminal a été souscrite par le Client, auquel cas, le Fournisseur devra faire son affaire de cette mise en service de l'Equipement Terminal dans les conditions ci-après.
Dans le cas d'installation de l'Equipement Terminal par le Fournisseur, le Client devra transmettre l'Equipement Terminal pré-paramétré ainsi que l'ensemble du matériel permettant son raccordement à l'ONT et son utilisation (alimentation, connectique) par un moyen à sa convenance à l'Utilisateur Final et devront être mis à disposition par ce dernier au Fournisseur lors du raccordement.
Dans le cas où l'Equipement Terminal ne peut pas être mis à disposition par l'Utilisateur Final au Fournisseur, alors ce dernier ne peut pas fournir le service et ne facturera pas le Client de la prestation.
La prestation d'installation d'Equipement Terminal par le Fournisseur correspond à une durée forfaitaire de trente (30) minutes par Local FTTH sans travaux supplémentaire.
Elle comprend :
- L'installation de l'Equipement Terminal
- Un test de connectivité Internet.
La prestation ne prévoit pas de déplacement de mobilier ou d'équipement de l’Utilisateur Final. Ce dernier devra prévoir avant l'intervention du Fournisseur un accès facile et sans risque pour sa sécurité ou celle de ses biens ainsi que pour la sécurité du technicien. Si le Fournisseur juge que cette sécurité n'est pas assurée il pourra refuser de fournir le service ou ne pourra être tenu pour responsable de problème liés à l'installation de l'Equipement Terminal
6.2.3 Délai de mise à disposition
Le Fournisseur accuse réception de la Commande du Client au plus tard 2 Jours Ouvrés après envoi de la Commande par le Client. La date d'envoi de cet accusé de réception correspond à la date d'acceptation par le Fournisseur de la Commande.
Le Fournisseur s'engage à mettre à disposition chaque Commande dans les meilleurs délais.
À ce titre, le Fournisseur indique que pour 95% des Commandes passées par le Client durant un mois donné, hors OPERA
Office Basic, la mise à disposition du Service aura lieu dans un délai de 20 Jours Ouvrés à compter de l'acceptation de la Commande par le Fournisseur.
Les Parties conviennent que le non-respect de ce délai de mise à disposition du Service en raison d’une faute exclusive du Fournisseur où d’un de ses sous-traitants entrainera le paiement par ce dernier de pénalités telles que définies à l'Annexe 1.A
O 10
LE axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Les pénalités mentionnées au présent article ont un caractère forfaitaire et libératoire définitif.
Les pénalités ne seront pas dues par le Fournisseur pour cause de non-respect des délais si le retard résulte :
- D'un cas de Force Majeure tel que défini dans les Conditions Générales - De fait d’un tiers, autre que les personnes intervenant pour le compte du Fournisseur - De problématique rencontrée sur des infrastructures d’un tiers - Du non-respect du Client de ses obligations contractuelles ayant une incidence sur le Raccordement Client Final
- De difficultés de construction sur le Raccordement Client Final tels qu'indiqué à l’article 6.2.4 - De l'absence du Client Final au RDV
- D'une date de RDV tardive choisie par l’Utilisateur Final ne permettant pas au Fournisseur d'intervenir dans le délai
contractuel alors que des créneaux de rendez-vous plus tôt étaient disponibles. - De décalage de RDV à la demande du Client ou de l’'Utilisateur Final - D'un raccordement hors des limites des conditions de distances comme précisé à l’Article 4.
Le délai de mise en service est comptabilisé à partir de la réception de la Commande par le Fournisseur. || se termine par l'envoi de l’Avis de mise à disposition du Service au Client.
6.2A Difficultés de construction sur le Raccordement Client Final
Sont notamment et non exclusivement considérées comme des difficultés de construction sur le Raccordement Client
Final les cas suivants :
- L'accès règlementé ou interdiction de passage,
- Travaux nécessaires sur le domaine privé
- Le passage sur un site protégé (parcs naturels par exemple),
- Les configurations architecturales spéciales (châteaux, parkings, caves, clochers, usines ..), - Présence d'obstacles naturels (cours d'eau, ravin, etc...) où artificiels (zones souterraines, murs de soutien, points hauts, etc.…..),
- Cheminement en domaine privé saturé, inutilisable,
- Les percements de murs d’une épaisseur supérieure à 30 centimètres, - Le percement de dalles de plancher,
- Les cas de travaux au-dessus de 2,80 mètres de hauteur,
- Le passage de câbles en faux-plafonds ou coffrage,
- Le déplacement de mobilier particulièrement lourd et encombrant.
6.2.5 Equipements de l’Utilisateur Final
Il incombe exclusivement au Client de se procurer à ses frais les équipements, logiciels et installations non inclus dans le Service, que nécessite le raccordement du Réseau et/ou des équipements de l'Utilisateur Final au Réseau. De plus, le Client fera son affaire de l'installation, de l'exploitation et de la maintenance de ses équipements et logiciels.
Le Fournisseur ne prend pas en charge le paramétrage et la fourniture d'éléments actifs du réseau local du Client ou des Utilisateurs Finaux, ni la conception de l'architecture des installations du Client ou des Utilisateurs Finaux.
Le Client s'engage à ce que ses équipements n'interrompent, n'interfèrent ni ne perturbent les services acheminés via le Réseau ou ne portent pas atteinte à la confidentialité des communications acheminées via ledit Réseau, ni ne causent aucun préjudice au Fournisseur ou à tout autre utilisateur du Réseau.
Réciproquement, le Fournisseur s'engage à ce que le Réseau ne perturbe pas les équipements du Client et ne porte pas
atteinte à la confidentialité des communications qu'il achemine.
6.2.6 Date de Début du Service
La Date de Début du Service d’une Ligne OPERA Office intervient à la date d'émission de l’Avis de mise à disposition du Service envoyé sous format électronique par le Fournisseur au Client confirmant l'activation dudit Lien d'Accès.
O (l
LE axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Par dérogation expresse de l'Article 6 des Conditions Générales, cet Avis vaut également date de recette du Lien d'Accès. Cette date fait foi dans tous les échanges entre le Fournisseur et le Client.
Le Client dispose, suite à émission de cet Avis, de vingt (20) Jours Ouvrés pour contester le bon fonctionnement du Lien d'Accès. Dans ce cas, le Client motivera ce refus par écrit par l'existence d'Anomalies. Une fois ces Anomalies corrigées, un nouvel Avis sera émis par le Fournisseur au Client.
À compter de la réception par le Fournisseur de la notification d'Anomalies écrite par le Client, le Fournisseur pourra
suspendre le Lien d'Accès concerné jusqu'à sa nouvelle recette.
A défaut de réponse ou de contestation par écrit du Client dans le délai de réponse de vingt (20) Jours Ouvrés susmentionné ou en cas d'utilisation d'un Lien d'Accès à des fins d'exploitation par le Client, le Lien d'Accès de la Commande concernée sera réputé mis en service tacitement et la Date de Début du Service sera la date de l'Avis émis
par le Fournisseur.
Mise en Service de l'option GTR 10H
En cas de commande simultanée d’une Ligne OPERA Office Pro et d’une Option GTR 10H, la mise en service de l'option GTR 10H est concomitante à la mise en service de la Ligne OPERA Home . La Date de Début du Service de la Ligne OPERA Office Pro vaut également Date de Début du Service pour l'option.
En cas de rajout de l'option GTR 10H sur une Ligne OPERA Office Pro déjà en service, le délai d'activation de l'option est
de dix (10) jours ouvrés. Un Avis de mise à disposition du Service est envoyé sous format électronique par le Fournisseur au Client confirmant l'activation de ladite option.
6.2. Durée du Lien d'Accès
Par dérogation aux dispositions de l'Article 9.2 des Conditions Générales, un Lien d'Accès est souscrit pour une durée indéterminée, chaque Partie pouvant y mettre fin, selon les modalités décrites à l’article 7.
7. RESILIATION DU SERVICE
En complément des stipulations de l’article 14 des Conditions Générales de la Convention Cadre, les Parties conviennent des conditions spécifiques de résiliation suivantes.
7. Résiliation d'une Ligne OPERA Office ou d'une option GTR 10H du fait du Client
71. Résiliation d’une Ligne OPERA Office
Le Client peut résilier à tout moment une Ligne OPERA Office, sous réserve d'avoir notifié par voie électronique au Fournisseur la résiliation au moins cinq (5) jours ouvrés avant la date d'effet de la résiliation.
La résiliation d'une Ligne OPERA Office entraîne automatiquement la résiliation des options qui lui sont attachées.
Tel que précisé à l’article 10.3, si la résiliation intervient dans les trente (30) jours suivant la Date du Début du Service, le
Client est alors redevable d'un (1) mois d'abonnement tel que prévu en Annexe I.
Dans les cas listés ci-dessous, les Parties conviennent que le Client ne sera pas redevable du premier mois d'abonnement
précité :
+ _ Résiliation avant la Date de Début du Service des Liens d'Accès lié à une inéligibilité de l’Utilisateur Final, * Exercice par l’'Utilisateur Final de son droit de rétractation.
Néanmoins, dans les deux cas listés ci-dessus et dans l'hypothèse où un déplacement du Fournisseur a été réalisé, une pénalité pour « Déplacement à tort - Annulation de commande après déplacement du technicien » sera facturée au Client dans les conditions décrites à l'Annexe IA.
O 12 axiIone 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01 — 92240 Malakoff
71.2 Résiliation d'une option de GTR 10H
Le Client peut résilier à tout moment l'option de GTR 10H souscrite sur une Ligne OPERA Office Pro, sous réserve d'avoir notifié par voie électronique au Fournisseur la résiliation au moins cinq (5) Jours Ouvrés avant la date d'effet de la résiliation.
Tel que précisé à l'article 9.3, si la résiliation intervient dans les trente (30) jours suivant la date d'émission de l'Avis de mise à disposition du Service correspondant à l'activation de l'option, le Client est alors redevable d’un (1) mois d'abonnement tel que prévu en Annexe |.
7.2 Résiliation d'une Ligne OPERA Office pour perte d'accès
Sauf disponibilité de multi-accès sur certaines Mandantes, le Service étant exclusif, toute nouvelle commande de Ligne FTTH (Passive ou Active) sur un lien du Client bénéficiaire du Service entraîne automatiquement la résiliation dudit Service sur cette Ligne.
Le Client est informé de ladite résiliation dès la mise en service du nouveau lien, soit par notification électronique, soit par fichier, selon le mode d'échange convenu entre les Parties. La résiliation est effective immédiatement à compter de l'envoi de cette notification.
7.3 Résiliation d'une Porte de Livraison
Comme indiqué à l'article 6.1.2 « Durée », à l'issue de la période initiale le Client peut résilier à tout moment une Porte de Livraison, sous réserve d'avoir notifié au Fournisseur la résiliation au moins un (1) mois avant la date d'effet de la résiliation.
La résiliation d'une Porte de Livraison entraîne automatiquement et de plein droit la résiliation des Lignes OPERA Office associées à la Porte de Livraison résiliée. Les modalités financières de la résiliation des Lignes OPERA Office sont les mêmes que celles décrites à l'article 7.I.
8. CESSION OÙ FIN DE LA DELEGATION DE SERVICE PUBLIC
Sans préjudice des cas de résiliation prévus à l'article 14 des Conditions Générales de la Convention Cadre :
i. En cas de cession de la délégation de service public dont la Mandante est titulaire et au titre duquel elle commercialise le Service,
a) Dans une telle hypothèse et en cas de maintien du mandat de commercialisation au bénéfice d’Axione, le cessionnaire sera subrogé dans les droits et obligations de ladite Mandante et remplacera cette dernière dans le cadre du présent Contrat, ce que le Client accepte d'ores et déjà expressément
b) Si le mandat de commercialisation avec Axione venait à être résilié, la Mandante s'engage toutefois à ce que la cession soit conditionnée (i) à l'engagement du cessionnaire de conclure avec le Client, un contrat OPERA Office dans des conditions similaires à ceux du présent Contrat et (ii) à la reprise par le cessionnaire des Commandes en cours, sans modification substantielle, ce que le Client accepte d'ores et déjà.
ii. En cas de fin normale ou anticipée de la délégation de service public ou en cas de cession où transfert du réseau FTTH à l'initiative de la Collectivité Locale Délégante, la Mandante s'engage à informer le Client sans délai. La Mandante et la Collectivité Locale Délégante ou le cessionnaire pourront :
a) Soit reprendre le Contrat ;
b) Soit proposer un nouveau contrat de service, en tenant compte des contraintes techniques liées à la migration éventuelle des Service du Client ;
c) Soit fixer des conditions de Fermeture du Service en tenant compte des contraintes techniques liées à la migration éventuelle des Services du Client vers les offres disponibles sur le marché, ce que le Client accepte d'ores et déjà expressément.
O 13 axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
En application du principe de continuité du service public, les Commandes seront maintenues pendant une durée permettant de garantir un délai de migration raisonnable au Client. A la date de signature des présentes, les Parties considèrent qu'un délai raisonnable de migration peut être fixe à vingt-quatre (24) mois.
9. MODIFICATION REGLEMENTAIRE OÙ LEGISLATIVE
En cas :
- d'évolutions du cadre réglementaire, législatif ou jurisprudentiel, national ou communautaire, et notamment en cas d'évolution des lignes directrices de l'ARCEP (ou de toute autorité s'y substituant) ou - de décision d'une autorité administrative ou judiciaire, ou
- d'avis ou de décision de l'ARCEP (ou de toute autorité s'y substituant) sur le présent Contrat, émis en application des dispositions de l’article L.1425-1 VI du CGCT ou de tout article ou disposition le remplaçant,
ayant une incidence sur l'exécution du Contrat et pouvant notamment entrainer :
* La modification des engagements du Fournisseur,
* La modification de l'équilibre des droits et obligations des Parties tels qu'initialement prévus au Contrat, * La modification de l'équilibre économique du Contrat,
+ L'impossibilité de poursuivre tout ou partie de l'exécution du Contrat.
Les Parties reconnaissent que le Contrat devra être renégocié, en tout ou partie, en vue d'y inclure les adaptations rendues nécessaires.
10. DISPOSITIONS FINANCIERES
10.1 Tarifs
Les prix des prestations fournies dans le cadre du Contrat sont précisés dans les Annexes 1 et 1.B des présentes.
10.2 Evolution tarifaire
Les tarifs de Ligne OPERA Office peuvent être amenés à évoluer pendant la durée du Contrat.
Les délais de prévenance de toute modification de tarif sont indiqués à l’article 14 des présentes Conditions Particulières.
Toute évolution des tarifs résultant des formules d'indexations décrites en « Annexe 1 - Tarifs Offre OPERA Office » lie les Parties et ne peut en aucun cas justifier une résiliation du Contrat ou des Commandes en cours.
En dehors des modifications tarifaires liées à l'indexation prévue au contrat ou à la règlementation, le Fournisseur se réserve la possibilité de modifier ses prix, leurs structures et les modalités de facturation, moyennant le respect d’un préavis de trois (3) mois pour une hausse tarifaire et d’un (1) mois pour une baisse.
Toute évolution des tarifs :
- fera l'objet de la signature d’un nouveau Contrat entre les parties, sauf dérogation tel que décrit à l’article 13 des présentes.
- sera applicable par défaut à l’ensemble du parc du Client.
L'absence d'accord entre les Parties ne saurait justifier une résiliation des Services.
10.3 Facturation
Par dérogation aux dispositions de l'Article 5.2 des Conditions Générales, la facturation est à terme à échoir sans pro- rata temporis, étant précisé que le premier mois n’est pas facturé.
O 14
LE axiIone 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01 — 92240 Malakoff
Sauf exception prévues au présent Contrat, à compter de sa date de mise en service, une Ligne OPERA Office fait l'objet au minimum de la facturation des frais d'accès au service, des éventuels frais de raccordement, et d’un (1) mois d'abonnement au Service.
LE LA MAINTENANCE DU CABLAGE FTTH PASSIF
Le Fournisseur assure le maintien en condition opérationnelle de la Ligne FTTH depuis le PTO jusqu'à son point de livraison au Client, y compris le brassage au PM et le Raccordement FTTH Passif.
Le Fournisseur assurera où fera assurer par un tiers, dans le cadre de la maintenance, le maintien de la continuité
optique des fibres optiques utilisées par le Client jusqu'au PTO inclus. La maintenance comprend l’ensemble des opérations ayant pour objet d'assurer l'entretien courant du Câblage FTTH.
En cas de détérioration du Raccordement FTTH Passif par l’Utilisateur Final ou le Client (hors cas de dégradation classique de l'infrastructure dû à l'usage régulier, couverts par les prestations de maintenance du Câblage FTTH), le Fournisseur facturera au Client une pénalité de « Remise en Etat de la Desserte Interne » dans les conditions tarifaires indiquées à l'Annexe 1.A. Dans le cas de détérioration localisée sur le PTO uniquement, le Client peut faire la demande auprès du Fournisseur de remplacer ledit PTO. Avant chaque demande, le Client devra s'assurer avec le Client Final que la problématique est localisée uniquement sur l'équipement PTO. Dans ce cas, le Client sera facturé de frais de remplacement de PTO comme indiqué en Annexe 1. Dans le cas où, suite à une demande de remplacement de PTO, le Fournisseur diagnostiquerait une problématique différente de celle de dégradation de PTO, alors la Prestation de remplacement de PTO ne sera pas réalisée et une pénalité de signalisation transmise à tort sera facturée au Client.
12. SERVICE APRES-VENTE
12. Accueil des signalisations
Le Fournisseur met à disposition du Client une structure d'accueil des signalisations : le « Front Office Opérateurs ». Le Client peut signaler à cette structure les dysfonctionnements de lignes OPERA Office par l'intermédiaire des outils et canaux de communications prévus à cet effet. Le Fournisseur met notamment à disposition du Client une interface d'échange de ticket d'incidents dont les spécifications sont convenues par les Parties.
Les modalités d'utilisation du Front Office Opérateurs (coordonnées, horaire d'ouverture, procédure à respecter) seront détaillées au Client par le Fournisseur et feront l'objet d'une documentation écrite.
Le Client est le seul interlocuteur du Fournisseur pour le service après-vente. Il s'engage à ne pas communiquer les coordonnées de la structure d'accueil des signalisations aux Utilisateurs Finaux. Le Client assure seul et sous sa responsabilité la fourniture et la gestion des prestations qu'il fournit aux Utilisateurs Finaux, pour l'ensemble de leurs aspects matériels et logiciels. Le Fournisseur ne prendra en charge aucune demande émanant directement des Utilisateurs Finaux.
12.2 Signalisation d'un dysfonctionnement
La signalisation d'un dysfonctionnement d'une Ligne OPERA Office par le Client à la structure d'accueil des signalisations sera dénommée par la suite « Signalisation ».
Le Client s'engage à effectuer la Signalisation conformément au process SAV à établir par les Parties.
Il s'engage notamment à effectuer, avant toute Signalisation, les tests et vérifications préliminaires nécessaires, et le cas échéant grâce au moyen de diagnostic mis à disposition par le Fournisseur.
12.3 Domaine d'intervention du Fournisseur
Le Fournisseur n'assure le pilotage du rétablissement du Service que dans son propre périmètre. Le Client doit donc s'assurer que les dysfonctionnements dans son réseau ou de l'Equipement Terminal de l’Utilisateur Final sont correctement traités par les services après-vente concernés.
O 15 axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
12.4 Procédure d'escalade hiérarchique
L'activation de cette procédure peut avoir lieu quand un dysfonctionnement n'est pas rétabli conformément aux engagements de niveau de service.
Le Client doit alors respecter la Matrice des contacts ainsi que les procédures associées, qui seront définies par les Parties au plus tard au jour de la signature des présentes. Ces éléments seront renseignés dans le process SAV à établir par les Parties.
12.5 Signalisation transmise à tort
Une signalisation transmise à tort est une Signalisation transmise par le Client pour laquelle le diagnostic établi et communiqué au Client révèle que la source du dysfonctionnement est ailleurs que dans la Ligne OPERA Office (par exemple, un problème sur les installations appartenant à l'Utilisateur Final en aval du PT).
Les Parties se rencontreront de façon régulière afin d'analyser les signalisations transmises à tort par le Client. Chaque Signalisation transmise à tort pourra faire l'objet après analyse par les Parties d'une pénalité libératoire décrite dans l'annexe IA des présentes.
12.6 Maintenance programmée
Le Fournisseur pourra être amené à réaliser des opérations de maintenance programmée pour assurer le maintien de la qualité de son Réseau.
Le Fournisseur s'engage à réaliser les opérations de maintenance programmée de façon à gêner le moins possible le Client, selon les modalités définies ci-après. L'interruption de Service générée par ces opérations de maintenance programmée ne sera pas prise en compte pour la comptabilisation de l'indisponibilité des Services.
La notification de travaux programmés par le Fournisseur devra intervenir au moins sept (7) jours avant la date prévue, sous forme d'un e mail ou d'un fax contenant les indications suivantes :
- date et heure prévue de début de perturbation
- durée prévue
- impact sur le Service
- motif de la perturbation
- interlocuteur en charge
Pendant ces périodes de travaux programmés, le Fournisseur s'efforcera de limiter les conséquences des travaux sur le Service.
La plage de maintenance en heures non ouvrées (HNO) sera chaque jour de 00H00 à 6H00 du lundi soir au vendredi
matin.
13. NIVEAU D'ENGAGEMENT DE SERVICE
13.1 Engagement du Fournisseur
Les engagements du Fournisseur vis-à-vis du Client en matière de disponibilité ainsi que les pénalités en cas de non- respect de ces engagements sont définies ci-après.
L'ensemble des engagements de disponibilité et de rétablissement du Service listés ci-après ne sont pas applicables aux Accès OPERA Office Basic.
(a) Engagements de qualité de service
Engagement de qualité de service Objectif
O 16 axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Disponibilité du Service sur le Parc 99.75%
Temps de Rétablissement du Service en cas de
d'incident Majeur 4 heures 24/24 7/7
La disponibilité de 99, 75% est approximativement équivalente à 22 heures d'indisponibilité en moyenne par an sur l'ensemble du Parc pendant les heures 24/24 7/7.
(b) Définition des indicateurs de disponibilité du service
Pour une ligne donnée, le Service est réputé disponible si l'Equipement Terminal peut recevoir et envoyer des données selon les spécifications techniques à l'exclusion des points suivants :
1. d'un incident sur un équipement sous la responsabilité du Client ou de l’Utilisateur Final,
2. d'un cas de force majeure,
3. des périodes de maintenance programmée.
La disponibilité du Service est calculée sur l'ensemble du Parc de lignes souscrites par le Client et sur les heures 24/24 7/7 sur une base annuelle en utilisant la formule suivante :
Avec :
Disponibilité Pourcentage de disponibilité du Service
Somme sur l'ensemble du Parc de lignes souscrites par
le Client du nombre total en minutes pendant lequel le
Dispo_total Service a été disponible pendant la période de
référence
Somme sur l'ensemble du Parc de lignes souscrites par
Periode_de_ref le Client du nombre total de minutes dans une année
calendaire
En cas d'incident Majeur :
- Le Fournisseur s'engage à rétablir le Service dans un délai maximal de 4 heures pour les incidents rendant le Service indisponible pour l'ensemble de Liens d'Accès d’un NRO.
- Le Fournisseur s'engage à rétablir le Service dans un délai maximal de 5 Jours Ouvrés pour les incidents rendant le Service indisponible pour l'ensemble de Liens d'Accès d’un PM où d'un arbre PON.
L'Indisponibilité du Service est calculée à partir de l'ouverture du ticket d'incident jusqu'au rétablissement du Service.
(c) Pénalité en cas de non-respect de l'engagement du Fournisseur en matière de disponibilité
Au titre du Niveau de Disponibilité Parc :
Au cas où, pour des raisons imputables au Fournisseur, la disponibilité du service de Ligne OPERA Office serait inférieure à celle définie dans l'objectif, le Client pourra réclamer au Fournisseur une pénalité qui sera créditée sur les factures à venir du Client et calculée chaque fin d'année calendaire comme suit :
Niveau de Disponibilité Parc Pénalité
Disponibilité strictement inférieure à 99,25% P=5%xA
Disponibilité comprise entre 99,25 % et 99,50% P=3% x A
Disponibilité comprise entre 99,50% et 99,75% P=I%xA
100 _ _ _ _ = ref de Periode total Dispo service Dispo axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
| Disponibilité est supérieure ou égale à 99,75% P=0
Où :
P est la pénalité due pour l'année concernée au titre de l'engagement de disponibilité.
À est le montant de la redevance annuelle pour la composante Accès du Service.
Au titre de l'interruption de Service en cas d’Incident Majeur :
Au cas où, pour des raisons imputables au Fournisseur, le Temps de Rétablissement du Service suite à un Incident Majeur serait supérieur à la Garantie de Temps de Rétablissement du Service définie dans l'objectif, le Client pourra réclamer au Fournisseur une pénalité qui sera créditée sur les factures à venir du Client au titre de la Commande concernée et calculée à chaque période de facturation comme suit :
Incident rendant le Service indisponible pour l'ensemble de Liens d'Accès d'un NRO :
Durée de l'interruption de Service en cas Pénalité
d'incident Majeur
Inférieure à 4 heures P=0€
Comprise entre 4 et 10 heures P=10%xm
Comprise entre 10 et 20 heures P=20%xm
Supérieure à 20 heures P=40%xm
Où :
« P » est la pénalité due pour l'incident Majeur sur NRO.
« m » est le montant de la redevance mensuelle pour les Lignes FTTH concernées par l'incident Majeur sur NRO.
Incident rendant le Service indisponible pour l'ensemble de Liens d'Accès d'un PM ou d'un arbre PON :
Durée de l'interruption de Service en cas
d'incident Majeur sur un PM ou un arbre Pénalité
PON
Inférieure à 5 jours P=0<€
Comprise entre 5 et 10 jours P= 30%xm
Comprise entre 10 et 20 jours P= 75%xm
Supérieure à 20 jours P= 100%xm
Où :
« P » est la pénalité due pour l'Incident Majeur sur PM ou arbre PON.
« m » est le montant de la redevance mensuelle pour les Lignes FTTH concernées par l'incident Majeur sur PM ou arbre
PON.
Il est entendu que les pénalités pour incident rendant le Service indisponible pour l'ensemble de Liens d'Accès d’un NRO ne sont pas cumulatives des pénalités pour incident rendant le Service indisponible pour l'ensemble de Liens d'Accès d’un PM ou d'un arbre PON. Ni inversement, les pénalités pour incident rendant le Service indisponible pour l’ensemble de
O 18
2e axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
Liens d'Accès d’un PM où d'un arbre PON ne sont pas cumulables aux pénalités pour incident rendant le Service indisponible pour l'ensemble de Liens d'Accès d'un NRO.
Au titre de l'interruption de Service en cas d’Incident sur une Ligne OPERA Office 100Mbps ou d'une ligne OPERA Office
Pro bénéficiant de l'option GTR 10H :
Au cas où, pour des raisons imputables au Fournisseur, sur une Ligne OPERA Office 100Mbps ou d’une ligne OPERA
Office Pro bénéficiant de l'option GTR 10H, le Temps de Rétablissement du Service suite à une interruption totale du Service sur la Ligne concernée serait supérieure à la Garantie de Temps de Rétablissement du Service définie à l'Article 4.1.2, le Client pourra réclamer au Fournisseur une pénalité qui sera créditée sur les factures à venir du Client au titre de la Commande concernée et calculée, à chaque période de facturation comme suit :
Durée de l'interruption de Service en cas d'incident sur Pénalité
une Ligne OPERA Office bénéficiant d’une GTR 10h
Inférieure à 10 heures ouvrables P=0€
Comprise entre 10 et 20 heures P=25%xm
Comprise entre 20 et 30 heures P=50%xm
Supérieure à 30 heures P=100%xm
Où :
« P » est la pénalité due pour l'interruption du Service
« M » est le montant de la redevance mensuelle pour la Ligne OPERA Office concernée par l'interruption de Service.
En aucun cas, le montant total des pénalités dues au titre de l'ensemble des engagements de qualité service (GTR et taux de disponibilité) pour une année civile ne pourra excéder 8% de la redevance annuelle du Service concerné.
13.2 Pénalités dues par le Client
Des pénalités peuvent être facturées au Client pour les cas suivants :
* En cas d'envoi par le Client de commandes non conformes avec les spécifications du présent Contrat, sous réserve que ces spécifications aient été transmises au Client par le Fournisseur, * En cas de signalisation d’un incident pour lequel il s'avère finalement que la responsabilité du Fournisseur n'est pas engagée (dite « Signalisation à tort »).
* En cas d'absence de l’Abonné lors d’un rendez-vous fixé par le Client. * En cas d'annulation, à l'initiative du Client d'une installation d'Abonné avec un délai d'anticipation insuffisant (délai précisé en Annexe IA).
Les pénalités sont facturées aux tarifs précisés en Annexe IA. Elles ont un caractère forfaitaire et libératoire.
14. EVOLUTION DU CONTRAT
En cas de modification des termes et conditions du Service ou du Contrat, pour quelque raison que ce soit, les Parties signeront un nouveau Contrat.
Par exception, les Parties conviennent que sont réalisées uniquement par voie de notification écrite par, le Fournisseur au Client, sans qu'il soit besoin de procéder à la signature d'un nouveau Contrat, les modifications suivantes :
Sous réserve d’un préavis de 6 mois pour :
O 2e axione 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01
— 92240 Malakoff
- toute modification de l'Annexe 2 impactant les équipements actifs ou passifs du Client, ou le Service fourni au Client. Le Client conserve cependant la possibilité de refuser ces modifications et le cas échéant, au choix du Client, soit de résilier le présent Contrat et les Commandes en cours de plein droit et avec effet immédiat, soit de
résilier le présent Contrat de plein droit et avec effet immédiat avec poursuite des Commandes en cours jusqu’à leur terme initial sans possibilité de renouvellement ;
Sous réserve d'un préavis de 3 mois pour :
* toute modification de l'Annexe 2 n'impactant pas les équipements actifs ou passifs du Client, ou le Service fourni au Client;
* toute modification à la hausse des tarifs de l'Annexe 1 ou de l'Annexe 1.B résultant de l'application de l'indexation
prévue au contrat
Sous réserve d'un préavis de 1 mois pour :
* toute modification à la baisse des tarifs de l'Annexe 1 ou de l'Annexe 1.B sans modification de la structure tarifaire
ou des pénalités.
Toutefois, lorsque les modifications du Contrat sont imposées par la règlementation, y compris par toute décision d'une autorité administrative ou judiciaire prise en application de cette dernière, dans des délais qui sont incompatibles avec les
délais contractuels de préavis de modification unilatérale du Contrat, les Parties conviennent que les modifications du Contrat en cause prendront effet à la date imposée par ladite règlementation. Dans ce cas, la date d'effet applicable sera mentionnée dans la notification envoyée par le Fournisseur au Client.
15. OBLIGATIONS DES PARTIES
15.1
Les Parties conviennent expressément que le Fournisseur ou ses fournisseurs ou la Collectivité Locale Délégante demeureront de manière permanente pleinement propriétaires de leurs Equipements et qu'aucun droit de propriété n'est transféré au Client sur l'un quelconque des éléments mis à sa disposition au titre d'une Commande, y compris les éléments d'accès au Service, leurs logiciels et leurs documentation, livrets et instructions techniques fournis au Client. Par conséquent, le Client s'engage à ce que ni lui-même ni un Utilisateur Final ne procède à tout acte de disposition ou permette tout acte, quel que soit, contraire aux droits de propriété ou de licence du Fournisseur, de ses fournisseurs et de la Collectivité Locale Délégante.
Lorsque des logiciels sont nécessaires à l'utilisation par l’'Utilisateur Final des Equipements du Fournisseur ou de la Collectivité Locale Délégante, le Fournisseur concède aux Utilisateurs Finaux, un droit d'usage personnel, non exclusif et non transférable sur ces logiciels pour ses seuls besoins propres. Ce droit est consenti pour la durée de chaque Commande. Le Client s'interdit d'effectuer toute adaptation, modification, duplication ou reproduction de ces logiciels, quelle qu'en soit la nature, de les installer sur d'autres équipements et, de manière générale, s'interdit tout acte qui contreviendrait aux droits du Fournisseur, de ses fournisseurs et/ou de la Collectivité Locale Délégante.
En cas de saisie ou de toute autre prétention d'un tiers à des droits sur les Equipements du Fournisseur où de la Collectivité Locale Délégante, y compris les éventuels logiciels, le Client est tenu, dès qu'il en a connaissance, de s'y opposer et d'en aviser immédiatement le Fournisseur afin de lui permettre de sauvegarder les droits du Fournisseur ou de la Collectivité Locale Délégante. De la même manière, en cas de procédure collective du Client, le Client avisera immédiatement le Fournisseur.
15.2
À tout moment et sans devoir indemniser le Client, le Fournisseur pourra modifier le Réseau (i) pour respecter un ordre,
une instruction ou une exigence dûment justifiée du Gouvernement, de la Collectivité Locale Délégante, d'une autorité de régulation, ou de toute autorité administrative compétente, ou (ii) si la modification n'affecte pas les niveaux de Service.
O 20
LE axiIone 152 avenue Pierre Brossolette Conditions Particulières - OPERA Office 25.01 — 92240 Malakoff
En cas de réalisation d'une hypothèse prévue en (i) ci avant, le Fournisseur informera le Client aussi rapidement que possible s'il a besoin de suspendre la fourniture du Service, et les Parties se rapprocheront pour envisager la mise en place d’une solution de remplacement.
15.3
Les Parties s'engagent à respecter et à faire respecter à toute personne sous leur contrôle, toutes dispositions légales ou toutes décisions des autorités réglementaires compétentes susceptibles de s'appliquer aux présentes, et notamment la loi du 10 juillet 1991 en matière de secret et de neutralité des correspondances émises par voie des télécommunications, et la réglementation applicable au traitement des données à caractère personnel.
Le Client étant propriétaire et gestionnaire des adresses IP attribuées aux Utilisateurs Finaux, il fera son affaire de toutes demandes d'informations, réclamations ou responsabilités afférent à l'utilisation des adresses IP.
15.4
Le Client déclare souscrire le Service en relation directe avec son activité professionnelle et commercialiser, auprès de ses propres clients finaux, une prestation de service qui lui est propre. Il fera son affaire de l'utilisation du Service et des Utilisateurs Finaux.
Le Client reconnaît en conséquence qu'il reçoit et prend directement à sa charge toute action ou réclamation émanant des Utilisateurs Finaux, considérés comme des tiers aux Commandes.
Fait à le ;
en deux exemplaires originaux,
Pour Axione
Pour le Client 1 D]
I[@1e]! (@1lI@1IIIe
ONHONOMHNOO!
Ile1e]| I @]lI@iII
lee] IeliIe |
161110] (01e
DO] [e)||16
œ]10]||[0][e
elle]! [e
DHOINOC
DONIONONIO
JII[@]I(@]|I [010]!
DHOIHOOI
ONIOINONOC
pie] [0] [0] (1
animons le monde