Ethernet longue portée (LRE) et ligne numérique d'abonné (xDSL) : Ligne d'abonné numérique à débit asymétrique (ADSL)

Architecture de référence RBE (encapsulation du type pont routeur)

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu

CPE

Introduction

Ce document décrit une architecture de bout en bout de Ligne d'abonné numérique à débit asymétrique (ADSL) qui utilise la caractéristique traversière conduite de l'encapsulation (RBE) pour le concentrateur d'accès universel de Cisco 6400 (UAC). RBE a été développé pour adresser le RFC1483 connu jetant un pont sur des questions, y compris des saturations de diffusion et la Sécurité. Excepté le fait qu'elle fonctionne exclusivement au-dessus de l'atmosphère, la caractéristique RBE fonctionne identiquement à la moitié-transition. L'évolutivité, la représentation, et la Sécurité supplémentaires peuvent être réalisées à l'aide des seules caractéristiques des abonnés de xDSL.

Supposition

L'architecture de référence est conçue utilisant le modèle d'architecture de référence de forum ADSL. L'architecture couvre différentes offres de services par le fournisseur d'accès au réseau (PETIT SOMME) et différents scénarios de la façon dont le trafic d'abonné est expédié au fournisseur de service réseau (NSP). En cette architecture, RBE est la méthode d'encapsulation assumée utilisée par le Cisco 6400. Le contenu du document est basé sur des déploiements existants, aussi bien que quelques essais en interne est réalisés sur l'architecture. Pour des fonctions améliorées et des modifications, référez-vous aux notes de mise à jour pour la dernière release du logiciel de ½ du ¿  de Cisco IOSïÂ. Actuellement, RBE est pris en charge sur les Plateformes de Cisco 6400, de Cisco 7200 et de Cisco 7500. Ce document est limité aux discussions du Cisco 6400.

Brief technique

Du point de vue de réseau, la connexion atmosphère ressemble à une connexion conduite. Le trafic de données est reçu en tant que paquets RFC1483, mais ils sont des trames des Ethernets RFC1483 ou de l'IEEE 802.3. Au lieu de jeter un pont sur les Ethernets ou la trame d'IEEE 802.3, comme dans le cas du militaire de carrière RFC1483 jetant un pont sur, les artères de routeur sur l'en-tête de la couche 3. Excepté quelques contrôles superficiels, l'en-tête de passerelle est ignorée. Ceci est expliqué en détail dans la section suivante.

Description opérationnelle

/image/gif/paws/12917/routed_bridged_encap_1.gif

D'un point de vue opérationnel, le routeur fonctionne comme si l'interface du pont routé ont été connectées à un LAN Ethernet. L'exécution est décrite ci-dessous de deux manières : paquets provenant des sites du client et paquets destinés pour les sites du client.

Pour des paquets provenant des sites du client, l'en-tête Ethernet est ignorée et l'adresse IP de destination est examinée. Si l'adresse IP de destination est dans le cache d'artère, le paquet fastswitched à l'interface sortante. Si l'adresse IP de destination n'est pas dans le cache d'artère, le paquet est aligné pour la commutation de processus. Dans le mode de commutation de processus, l'interface sortante par laquelle le paquet doit être conduit est trouvée par le regard dans la table de routage. Après que l'interface sortante soit identifiée, le paquet est conduit par l'intermédiaire de cette interface. Ceci se produit sans condition requise pour un groupe de passerelle ou un Bridge Group Virtual Interface (BVI).

Pour des paquets destinés pour les sites du client, l'adresse IP de destination du paquet est examinée d'abord. L'interface de destination est déterminée de la table de Routage IP. Ensuite, le routeur vérifie la table de Protocole ARP (Address Resolution Protocol) associée avec cette interface pour qu'une adresse MAC de destination place dans l'en-tête Ethernet. Si aucun n'est trouvé, le routeur génère une demande d'ARP de l'adresse IP de destination. La demande d'ARP est expédiée à l'interface de destination seulement. Ce contraste avec la transition, dans laquelle la demande d'ARP est envoyée à toutes les interfaces dans le groupe de passerelle.

Pour un scénario utilisant des interfaces non numérotées (où vous pouvez trouver deux abonnés sur le même sous-réseau), l'interface du pont routé utilise le proxy ARP. Par exemple, 192.168.1.2 (l'hôte A) veut communiquer avec 192.168.1.3 (hôte B). Cependant, hébergez A est sur le même sous-réseau que l'hôte B.

Hébergez A doit apprendre l'adresse MAC d'hôte B en envoyant une diffusion ARP à l'hôte B. Quand l'interface du pont routé au périphérique d'agrégation reçoit cette émission, elle enverra une réponse de proxy ARP avec l'adresse MAC de 192.168.1.1, hôte A. Il prendra cette adresse MAC, la placera dans son en-tête Ethernet, et enverra le paquet. Quand le routeur reçoit le paquet, il jette l'en-tête et regarde l'adresse IP de destination, alors la conduit sur l'interface appropriée.

Avantages RBE

RBE a été développé avec l'intention d'aborder certaines des questions faites face par l'architecture de pontage RFC1483. RBE retient les principaux avantages de l'architecture de pontage RFC1483, tout en éliminant la plupart de ses inconvénients.

  • Configuration minimale à la CPE (CPE).

    Le fournisseur de services considère ceci important parce qu'il n'exige plus un grand nombre de déplacements entre sites et plus de besoins d'investir fortement dans le personnel pour le support des protocoles de plus haut niveau. Le CPE en mode de passerelle agit en tant que périphérique très simple. Le dépannage minimal est impliqué au CPE puisque tout qui entre des Ethernets passe directement plus d'au côté WAN.

  • Facile à migrer des architectures de pontage pures vers RBE. Il n'y a aucune modification exigée à l'extrémité d'abonné.

  • Évite les défis de détournement IP et de mystification d'ARP relevés en architectures de pontage pures typiques. RBE empêche également des saturations de diffusion à l'aide des connexions point-à-point. La Sécurité est le principal inconvénient en architectures de pontage pures.

  • Comparé aux architectures de pontage pures, RBE fournit la performance supérieure en raison de l'implémentation de routage au périphérique d'agrégation. En outre, RBE est plus extensible parce qu'il n'a pas des limites de groupe de passerelle.

  • Sélection Web de la couche 3 de supports utilisant la passerelle de sélection de Cisco Service (SSG).

Considérations d'implémentation

Certains des points clé à considérer avant de mettre en application cette architecture sont identiques que mentionnés dans le papier de l'architecture de référence de pontage RFC1483.

RBE est recommandé quand :

  • Les scénarios sont identiques qu'en architectures de pontage existantes.

  • Le PETIT SOMME veut exécuter seulement la Gestion minimale de CPEs. Le concept d'un CPE simple n'exige minimal ou aucune configuration après que le CPE soit déployé à l'emplacement de l'abonné.

  • Le PETIT SOMME ne veut pas installer et mettre à jour des clients d'hôte sur les hôtes derrière le CPE ponté. Ces les tâches d'installation et de maintenance augmentent des coûts et la maintenance de déploiement, y compris la fourniture de personnel d'assistance avec la connaissance du logiciel client et du système d'exploitation sur lesquels le client s'exécute.

  • Le PETIT SOMME veut déployer un réseau traversier extensible et sécurisé utilisant CPEs existant (qui peut seulement fonctionner dans RFC1483 jetant un pont sur le mode) et veut offrir des capacités de sélection de service.

La prochaine discussion explique comment des adaptations et des échelles d'architecture RBE à différents modèles professionnels.

Network Architecture

/image/gif/paws/12917/routed_bridged_encap_2.gif

L'architecture de réseau RBE est semblable à l'architecture de pontage RFC1483. Comme spécifié en cette architecture, le périphérique d'agrégation a pu être dans le PETIT SOMME ou au NSP. Si une architecture de bout en bout du circuit virtuel permanent (PVC) est utilisée, le NSP termine les abonnés et configure RBE au périphérique d'agrégation. Si le PETIT SOMME préfère fournir des services en gros plus la sélection de service, il peut choisir de terminer ces abonnés et d'obtenir des adresses IP d'un serveur local du protocole DHCP (DHCP). Dans le cas des services en gros, le PETIT SOMME peut choisir d'obtenir les adresses IP du NSP. Ces scénarios sont couverts en détail dans la section Gestion IP de ce document.

Considérations de conception pour l'architecture RBE

RBE élimine les principaux risques de sécurité impliqués de l'architecture de pontage RFC1483. Supplémentaire, RBE fournit une meilleure représentation et est plus extensible parce que les sous-interfaces sont traitées en tant qu'interfaces conduites.

Cette section explique certains des points clé qui doivent être considérés avant de concevoir l'architecture RBE. Pour le côté des abonnés, les conceptions de bases demeurent les mêmes qu'en architecture de pontage RFC1483.

Dans RBE, un circuit virtuel simple (circuit virtuel) est alloué une artère, un ensemble d'artères, ou un sous-réseau de Routage interdomaine sans classe (CIDR). Ainsi, l'environnement de confiance est réduit seulement aux sites du client simples représentés par les adresses IP dans l'ensemble d'artères ou le bloc CIDR. L'ISP contrôle également les adresses assignées à l'utilisateur. Ceci est fait en configurant un sous-réseau sur la sous-interface à cet utilisateur. Par conséquent, si un utilisateur misconfigures le matériel avec une adresse IP en dehors de la plage d'adresses allouée (faisant probablement circuler des paquets d'ARP jusqu'au routeur), le routeur génère une erreur « de câble faux » et refuse d'écrire l'IP erroné au mappage d'adresse MAC dans sa table ARP.

RBE peut être déployé utilisant seulement des sous-interfaces point par point atmosphère. Il ne peut pas être déployé sur des sous-interfaces multipoints. Quoique le côté des abonnés pont, vous n'avez pas besoin de définir des groupes ou des interfaces BVI de passerelle parce que les sous-interfaces sont traitées en tant qu'interfaces conduites.

Les sous-interfaces point par point atmosphère peuvent être numérotées des interfaces ou non-numérotées à quelques autres interfaces.

Par définition, une interface numérotée est une interface qui a une adresse IP spécifique assignée à elle avec un masque de sous-réseau fixe. Exemple :

Interface atm0/0/0.132 point-to-point
ip address 192.168.1.1 255.255.255.252

Suivant les indications de cet exemple, quand RBE est déployé avec une interface numérotée, il devrait y a un sous-réseau distinct pour chaque abonné. L'hôte à l'extrémité d'abonné devrait être configuré pour 192.168.1.2. Il y a seulement un hôte à l'extrémité d'abonné. Si la condition requise est de prendre en charge plus d'un hôte, le masque de sous-réseau choisi devrait faciliter plus d'hôtes.

Les interfaces numérotées donnent le contrôle de PETIT SOMME du nombre d'hôtes que l'abonné a connectés derrière le CPE. Comme expliqué ci-dessus, ce manque de contrôle était un problème grave en architecture de pontage RFC1483.

Cependant, cette méthodologie consomme trop d'adresses IP. Vous devrez allouer un sous-réseau par abonné, utiliser une adresse IP pour la sous-interface atmosphère, et laisser l'adresse d'émission et toutes les adresses zéro inutilisées. Ainsi, pour avoir un hôte derrière le CPE, vous devez au moins définir un masque de sous-réseau de 255.255.255.252. Vu la pénurie des adresses IP, ceci peut ne pas être une option faisable à moins que le NAP/NSP utilise l'espace d'adressage privé et exécute le Traduction d'adresses de réseau (NAT) pour atteindre le monde extérieur.

Afin d'économiser des adresses IP, une alternative serait d'utiliser des interfaces non numérotées. Par définition, une interface non numérotée est une interface qui utilise l'adresse IP d'une autre interface à l'aide de la commande d'ip unnumbered. Exemple :

!
interface loopback 0
ip address 192.168.1.1 255.255.255.0
!
interface atm0/0/0.132 point-to-point
ip unnumbered loopback 0
!
interface atm0/0/0.133 point-to-point
ip unnumbered loopback 0

Suivant les indications de l'exemple ci-dessus, une adresse IP et un sous-réseau sont seulement appliqués à l'interface de bouclage. Toutes les sous-interfaces atmosphère seraient non-numérotées à cette interface de bouclage. Dans ce scénario, tous les abonnés étant terminé sur des sous-interfaces atmosphère (non-numérotées à bouclage 0) seraient sur le même sous-réseau que celui du bouclage 0. Ceci implique que les abonnés seraient sur le même sous-réseau, mais serait livré dedans par différentes interfaces conduites. Dans cette situation, ce devient un problème pour que le routeur identifie quel abonné est derrière quelle sous-interface atmosphère. Pour le Cisco IOS, 192.168.1.0 (dans le diagramme de Gestion IP) est directement connecté par l'intermédiaire du bouclage 0 d'interface, et de lui ne va jamais envoyer le trafic destiné aux adresses l'unes des d'hôte sur ce sous-réseau par l'intermédiaire de n'importe quelle autre interface. Afin de résoudre ce problème, vous devez configurer explicitement les routes hôte statiques. Exemple :

ip route 192.168.1.2 255.255.255.255 atm0/0/0.132
ip route 192.168.1.3 255.255.255.255 atm0/0/0.133

Comme spécifié dans cet exemple, quand le routeur doit prendre une décision de routage et doit expédier le trafic destiné pour 192.168.1.2, il choisira l'atmosphère 0/0/0.132 comme interface sortante, et ainsi de suite. Sans spécifier ces routes hôte statiques, le routeur choisirait l'interface sortante comme bouclage 0 et relâcherait le paquet.

Quoique l'interface non numérotée économise des adresses IP, elle exige une tâche supplémentaire de configurer les routes hôte statiques sur le processeur d'artère de noeud (NRP) pour chaque abonné. Notez que si un abonné a, par exemple, 14 hôtes derrière le CPE, on ne l'exige pas pour avoir les routes hôte statiques pour chaque hôte. Un récapitulatif de routage peut être défini pour la sous-interface atmosphère.

Jusqu'ici, cette explication a supposé que les hôtes derrière le CPE seront configurés pour des adresses IP statiques. Cette supposition n'est pas vraie dans des conceptions de vie réelle. Dans le monde pratique, le PETIT SOMME veut exécuter la configuration minimale et la maintenance pour le CPE et les hôtes reliés à lui. Afin de réaliser cela, les hôtes devraient obtenir leurs adresses dynamiquement utilisant un serveur DHCP.

Afin d'obtenir leurs adresses IP dynamiquement, des hôtes doivent être configurés pour obtenir des adresses IP d'un serveur DHCP. Quand l'hôte initialise, il envoie des requêtes DHCP. Ces demandes sont alors transmises par relais au serveur DHCP compétent, qui assigne une adresse IP à l'hôte d'un dans sa portée précédemment définie.

Afin d'expédier les requêtes DHCP initiales de l'hôte au serveur DHCP compétent, vous devriez s'appliquer la commande de helper-address d'IP à l'interface qui reçoit les émissions. Après que les émissions soient reçues, le Cisco IOS regarde la configuration du helper-address d'IP pour cette interface et en avant de ces demandes dans un paquet monodiffusion au serveur DHCP compétent dont l'adresse IP est spécifiée dans le helper-address d'IP. Après que le serveur DHCP réponde avec l'adresse IP, il envoie la réponse à l'interface sur le routeur qui a initialement expédié la demande. Ceci est utilisé car l'interface sortante pour envoyer la réponse de serveur DHCP à l'hôte qui a initialement demandé le service. Le routeur installe également automatiquement une route hôte pour cette adresse.

Si RBE est activé sur une sous-interface et est un Protocol Data Unit traversier par IEEE 802.3 (PDU), l'encapsulation Ethernet est examinée après l'encapsulation de passerelle atmosphère. Si c'est un paquet IP/ARP, il est manipulé comme n'importe quel autre paquet IP/ARP. Le paquet IP fastswitched. S'il échoue, il est aligné pour la commutation de processus.

La représentation pour RBE est une grande victoire. Le code traversier standard d'aujourd'hui a le problème inhérent d'exiger deux classifications distinctes pour un paquet avant qu'une décision d'expédition puisse être prise. Une classification est définie comme processus d'examiner (sur l'en amont) et de modifier (sur l'en aval) l'en-tête de paquet pour expédier les informations, qui sont relativement chères. Une consultation de la couche 2 est nécessaire pour déterminer si le paquet doit être conduit ou jeté un pont sur. Puis, à la couche 3, une consultation est nécessaire pour identifier l'emplacement auquel le paquet devrait être conduit. Cette classification est faite dans les directions en amont aussi bien qu'en aval, qui a une incidence sur la représentation.

Pour RBE, on le prédétermine par configuration que le paquet doit être conduit dans la direction en amont. Par conséquent, il n'est pas nécessaire de passer par le chemin de transfert traversier, qui était nécessaire dans le cas de la transition standard.

Points clé de RBE

CPE

La configuration CPE demeure la même que dans la transition standard. Aucune modification au CPE n'est exigée pour déployer RBE.

Gestion IP

routed_bridged_encap_3.gif

Tout en déployant les interfaces numérotées pour RBE, l'allocation d'adresse IP à l'hôte derrière le CPE ponté est habituellement manipulée par l'intermédiaire d'un serveur DHCP. Comme cité précédemment, le serveur DHCP peut résider dans le PETIT SOMME ou dans le NSP. Pour l'un ou l'autre de cas, la sous-interface numérotée atmosphère devrait être configurée avec la commande de helper-address d'IP. Si le serveur DHCP va trouvez-vous au NSP, le périphérique d'agrégation de PETIT SOMME doit avoir une artère pour atteindre ce serveur. Le seul scénario dans lequel un PETIT SOMME utiliserait son propre serveur DHCP et la plage d'adresses IP est quand elle veut offrir des capacités de sélection de service aux abonnés, et ces abonnés sont RÉSEAU LOCAL relié au PETIT SOMME.

Si le PETIT SOMME veut utiliser l'espace d'adresse IP du NSP, une des adresses IP pour chaque sous-réseau devrait être allouée à la sous-interface atmosphère. Également, il devrait y avoir un certain accord mutuel entre le PETIT SOMME et le NSP de sorte que le PETIT SOMME configure l'adresse exacte. Quand le serveur DHCP du NSP assigne des adresses IP, cet accord devrait être en place pour s'assurer que le serveur fournit les informations de passerelle par défaut correcte à l'hôte. Le PETIT SOMME peut alors ou récapituler une artère statique pour toutes ces adresses assignées aux abonnés, ou il peut choisir d'exécuter un protocole de routage avec le NSP pour annoncer ces artères. Dans la plupart des scénarios, le PETIT SOMME et le NSP préféreraient ne pas utiliser un protocole de routage. La fourniture d'une artère statique est une bonne option.

C'est la configuration de base exigée sur le NRP pour déployer RBE avec les interfaces numérotées :

!
interface ATM0/0/0.132 point-to-point
ip address 192.168.1.1 255.255.255.0
ip helper-address 192.168.3.1
no ip directed-broadcast
atm route-bridged ip
pvc 1/32
encapsulation aal5snap
!
interface ATM0/0/0.133 point-to-point
ip address 192.168.2.1 255.255.255.0
ip helper-address 192.168.3.1
no ip directed-broadcast
atm route-bridged ip
pvc 1/33
encapsulation aal5snap

Utilisant des interfaces non numérotées est la meilleure manière d'économiser des adresses IP. Comme expliqué plus tôt, quand des interfaces non numérotées sont utilisées avec le DHCP, des routes hôte sont dynamiquement installées. Ceci peut être la meilleure approche à déployer RBE. Le serveur DHCP peut se trouvent alors au PETIT SOMME ou au NSP, quant aux interfaces numérotées.

C'est la configuration de base exigée sur le NRP pour déployer RBE avec des interfaces non numérotées :

interface Loopback0
ip address 192.168.1.1 255.255.255.0
no ip directed-broadcast
!
interface ATM0/0/0.132 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
ATM route-bridged ip
pvc 1/32
encapsulation aal5snap
!
interface ATM0/0/0.133 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
ATM route-bridged ip
pvc 1/33
encapsulation aal5snap

Comment une destination de service est atteinte

Jusqu'ici, ce document a discuté la technologie de base d'accès utilisant RBE comme méthode d'encapsulation. Cependant, utilisant cette architecture, le NAP/NSP peut également offrir de divers services et différentes options pour où le PETIT SOMME peut expédier le trafic d'abonné au NSP. Ces concepts sont expliqués dans les sections suivantes.

Fourniture de l'accès Internet

Dans ce scénario, la fonction primaire pour le NSP est de permettre d'accéder l'accès Internet à grande vitesse aux abonnés finaux. Puisque le NSP va fournir le service final, la gestion d'adresse IP devient la responsabilité du NSP. Il peut assigner des adresses IP publique à ses abonnés finaux à l'aide d'un serveur DHCP, ou il peut choisir de fournir des adresses IP privées aux abonnés et puis de les exécuter NAT pour atteindre le monde extérieur.

Services en gros

Si le PETIT SOMME veut offrir des services en gros à d'autres ISP, il peut faire ainsi. Dans ce scénario, le PETIT SOMME habituellement ne préfère pas manipuler des adresses IP pour tous les abonnés pour NSPs différent. Le PETIT SOMME incite une certaine organisation avec l'ISP pour fournir des adresses IP à ces abonnés. Ceci peut être réalisé par le PETIT SOMME expédiant les requêtes DHCP provenant les abonnés aux serveurs DHCP chez le NSPs. Le PETIT SOMME doit configurer ses sous-interfaces atmosphère avec une des adresses IP de cette plage, et il doit annoncer ces artères au NSP. L'annonce de route a pu être sous forme de l'un ou l'autre une artère statique ou un certain protocole de routage entre le PETIT SOMME et le NSP. L'artère statique est la méthode préférable pour le PETIT SOMME, aussi bien que le NSP.

Accès d'entreprise

L'accès d'entreprise exige habituellement des services du réseau privé virtuel (VPN). Ceci signifie que la société ne fournira aucune adresse IP au PETIT SOMME et ne permet pas au PETIT SOMME pour annoncer l'espace d'adresse IP entreprise dans le noyau IP du PETIT SOMME, car elle pourrait avoir comme conséquence une brèche dans la sécurité. Les sociétés préfèrent habituellement appliquer leurs propres adresses IP à leurs clients, ou elles permettront l'accès par l'intermédiaire de certains sécurisés signifie comme la commutation par étiquette multiprotocole/réseau privé virtuel (MPLS/VPN) ou le Layer 2 Tunneling Protocol (L2TP).

L'autre approche à fournir l'accès sécurisé à l'entreprise est où le PETIT SOMME fournit les adresses IP initiales à ces abonnés. Par conséquent, les abonnés devient Réseau local-relié au PETIT SOMME. Après que les abonnés aient les adresses IP initiales, ils peuvent initier un tunnel à la société par l'exécution de logiciel client L2TP sur l'hôte. Consécutivement, la société authentifiera cet abonné et fournira une adresse IP de son espace d'adresse IP. Cette adresse IP est utilisée par l'adaptateur L2TP VPN. De cette façon, les abonnés font accéder l'option à se connecter à leur ISP pour la connexion Internet ou à leur société par un accès sécurisé de tunnel L2TP. Cependant, ceci exige de la société de fournir l'adresse IP de destination de tunnel à l'abonné, qui devrait être routable par le noyau IP du PETIT SOMME.

Entretenez les capacités de sélection

Le PETIT SOMME a pu offrir de diverses capacités de sélection de service utilisant la fonctionnalité de Cisco SSG. Le SSG offre deux méthodes pour fournir la sélection de service : par l'intermédiaire de la couche 2 (qui est connue comme PTA-MD) et posez la sélection Web 3. Avec RBE, seulement la méthode de sélection Web de la couche 3 peut être utilisée. Ceci exige des abonnés Réseau local-d'être reliés au PETIT SOMME ; c'est-à-dire, le PETIT SOMME fournit l'adresse IP initiale à l'abonné et permet d'accéder au tableau de bord de sélection de Cisco Service (disque transistorisé).

Dans le cas de l'architecture RBE, la méthode de sélection Web de Cisco le SSG est une bonne manière d'expliquer le trafic d'abonné.

Conclusion

RBE fournit une meilleure représentation et est plus extensible que la transition standard. Il surmonte également tous les problèmes de sécurité faits face dans la transition standard. RBE élimine les problèmes de saturation de diffusion de la transition standard. RBE fournit une architecture robuste pour le PETIT SOMME qui veut éviter la maintenance du logiciel d'hôte de client, les questions liées jeter un pont sur, et veut des coûts inférieurs de déploiement. Avec RBE, tout c'est possible tout en utilisant l'architecture de pontage existante.


Informations connexes


Document ID: 12917