Groupe de travail Réseau	M. Chen, Huawei
Request for Comments : 5392	R. Zhang, Huawei
Catégorie : Sur la voie de la normalisation	X. Duan, China Mobile
Traduction Claude Brière de L'Isle	janvier 2009

Extensions à OSPF pour la prise en charge de l'ingénierie de trafic MPLS et GMPLS entre systèmes autonomes (AS)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Résumé
Le présent document décrit des extensions aux protocoles OSPF version 2 et 3 pour la prise en charge de l’ingénierie de trafic (TE, Traffic Engineering) de commutation d’étiquettes multiprotocoles (MPLS, Multiprotocol Label Switching) et MPLS généralisé (GMPLS, Generalized MPLS) pour plusieurs systèmes autonomes (AS, Autonomous System). Les extensions à OSPF-TE v2 et v3 sont définies pour l’arrosage des informations de TE sur les liaisons inter AS qui peuvent être utilisées pour effectuer le calcul de chemin TE inter-AS.

Aucune prise en charge des informations d’arrosage de l’intérieur d’un AS à un autre AS n’est proposée ni définie dans ce document.
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans le document	2
2. Position du problème	2
2.1 Note sur les non objectifs	2
2.2 Détermination du chemin par domaine	3
2.3 Calcul de chemin rétro récurrent	4
3. Extensions à OSPF	4
3.1 Définitions de LSA	5
3.2 Charge utile de LSA	5
3.3 Détails de sous TLV	6
4. Procédure pour les liaisons TE inter-AS	7
4.1 Origine des informations de TE par un mandataire	8
5. Considérations sur la sécurité	8
6. Considérations relatives à l’IANA	9
6.1 LSA OSPF TE inter AS	9
6.2 OSPF LSA Sub-TLVs Type	9
7. Remerciements	9
8. Références	9
8.1 Références normatives	9
8.2 Références pour information	10
Adresse des auteurs	10

 	1.	Introduction

La [RFC3630] définit des extensions au protocole OSPF [RFC2328] pour prendre en charge l’ingénierie de trafic (TE, Traffic Engineering) intra-zone. Les extensions fournissent le moyen de coder les informations de TE pour les liaisons à capacité TE dans le réseau et arroser ces informations au sein d’une zone. Les avis d’état de liaison (LSA, Link State Advertisement) opaques de type 10 [RFC5250] sont utilisés pour porter de telles informations de TE. Deux Type-Longueur-Valeur (TLV) de niveau supérieur sont définis dans la [RFC3630] : Adresse de routeur et Liaison. Le TLV Liaison a plusieurs sous TLV incorporés qui décrivent les attributs du TLV pour un TLV Liaison.

La [RFC5329] définit des extensions similaires à OSPFv3 [RFC5340]. Elle définit un nouveau LSA, qui est appelé LSA TE intra-zone, pour annoncer les informations de TE. La [RFC5329] utilise les "extensions d’ingénierie du trafic à OSPF" [RFC3630] comme base des définitions de TLV et définit des nouveaux TLV et sous TLV pour étendre les capacités de TE aux réseaux IPv6.

Les exigences pour établir des chemins de commutation d’étiquette (LSP, Label Switched Path) d’ingénierie du trafic de commutation d’étiquette multi protocoles (MPLS-TE, Multiprotocol Label Switching Traffic Engineering) qui traversent plusieurs systèmes autonomes (AS, Autonomous System) sont décrites dans la [RFC4216]. Comme décrit dans la [RFC4216], une méthode DEVRAIT procurer la capacité de calculer un chemin s’étendant sur plusieurs AS. Ainsi une entité de calcul de chemin qui peut être l’extrémité de tête d’un routeur de commutation d’étiquettes (LSR, Label Switching Router) un routeur de bordure d’AS (ASBR, AS Border Router) ou un élément de calcul de chemin [RFC4655] a besoin de savoir les informations de TE non seulement des liaisons au sein d’un AS, mais aussi des liaisons qui connectent aux autres AS.

Dans le présent document, deux nouveaux LSA séparés sont définis pour annoncer les informations TE inter-AS pour respectivement OSPFv2 et OSPFv3, et trois nouveaux sous-TLV sont ajoutés au TLV Liaison existant pour étendre les capacités TE pour l’ingénierie de trafic inter-AS. Les définitions et procédures détaillées sont discutées dans les sections suivantes.

Le présent document ne propose pas ni ne définit de mécanismes pour annoncer d’autres informations TE extra-AS au sein de OSPF. Voir au paragarphe 2.1 la liste complète des non objectifs de ce travail.

 	1.1	Conventions utilisées dans le document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Position du problème

Comme décrit dans la [RFC4216], dans le cas de l’établissement d’un LSP TE inter-AS traversant plusieurs AS, le message Path [RFC3209] peut inclure les éléments suivants dans l’objet Chemin explicite (ERO, Explicit Route Object) afin de décrire le chemin du LSP :
- un ensemble de numéros d’AS comme des bonds lâches ; et/ou
- un ensemble de LSR incluant des ASBR comme bonds lâches.

Deux méthodes pour déterminer les chemins inter-AS sont actuellement discutées. La méthode par domaine [RFC5152] détermine le chemin d’un domaine à la fois. La méthode rétro récurrente [RFC5441] utilise la coopération entre les PCE pour déterminer un chemin inter-domaines optimal.

Les paragraphes qui suivent examinent comment les informations de liaison TE inter-AS pourraient être utiles dans les deux cas.

 	2.1	Note sur les non objectifs
Il est important de noter que le présent document ne fait aucun changement aux hypothèses de confidentialité et d’adaptabilité entourant l’utilisation des AS dans l’Internet. En particulier, ce document est conforme aux exigences établies dans la [RFC4216].

Les caractéristiques suivantes sont explicitement exclues :
o	on ne tente pas de distribuer les informations de TE d’un AS à un autre AS  ;
o	il n’y a pas de mécanisme proposé pour distribuer une forme quelconque d’informations TE d’accessibilité pour les destinations extérieures à l’AS  ;
o	il n’y a pas de changement proposé à l’architecture ou usage de PCE  ;
o	l’agrégation de TE n’est pas prise en charge ni recommandée  ;
o	il n’y a pas d’échange d’informations privées entre les AS  ;
o	aucune adjacence OSPF n’est formée sur la liaison inter-AS.

Noter aussi que les extensions proposées dans ce document sont utilisées seulement pour annoncer des information sur les liaisons TE inter-AS. À ce titre, ces extensions visent un problème entièrement différent de l’auto découverte de L1VPN [RFC5252], qui définit comment les informations de TE sur les liaisons entre équipement de côté consommateur (CE, Customer Edge ) et équipement de côté fournisseur (PE, Provider Edge) peuvent être annoncées dans OSPF-TE à côté des informations d’auto-découverte pour les liaisons CE-PE. Il n’y a pas de chevauchement entre ce document et la [RFC5252].

 	2.2	Détermination du chemin par domaine
Dans la méthode par domaine de détermination d’un chemin inter-AS pour un LSP MPLS-TE, quand un LSR qui est un point d’entrée d’un AS reçoit un message Path d’un AS en amont avec un ERO contenant un prochain bond qui est un numéro d'AS, il a besoin de trouver quels LSR (ASBR) au sein de l’AS local sont connectés à l’AS en aval afin qu’il puisse calculer un segment de LSP TE à travers l’AS local vers un de ces LSR et lui transmettre le message Path et donc dans l’AS suivant. Voir un exemple à la Figure 1 :

            R1------R3----R5-----R7------R9-----R11
                    |     | \    |      / |
                    |     |  \   |  ----  |
                    |     |   \  | /      |
            R2------R4----R6   --R8------R10----R12
                       :              :
            <-- AS1 -->:<---- AS2 --->:<--- AS3 --->

Figure 1 :Modèle de référence inter-AS

La figure montre trois AS (AS1, AS2, et AS3) et douze LSR (R1 à R12). R3 et R4 sont des ASBR dans AS1. R5, R6, R7, et R8 sont des ASBR dans AS2. R9 et R10 sont des ASBR dans AS3.

Si il est prévu d’établir un LSP TE inter-AS TE de R1 à R12, la séquence d’AS va être : AS1, AS2, AS3.

Supposons que le message Path entre dans AS2 à partir de R3. Le prochain bond dans le ERO montre AS3, et R5 doit déterminer un segment de chemin à travers AS2 pour atteindre AS3. Il a un choix entre trois points de sortie de AS2 (R6, R7, et R8) et il a besoin de savoir lequel des trois fournit la connexité TE à AS3, et si la connexité TE (par exemple, la bande pasante disponible) est adéquate pour le LSP demandé.

Autrement, si le prochain bond dans l’ERO est l’entrée d’ASBR pour AS3 (disons R9) R5 a besoin de savoir lequel de ses ASBR de sortie a une liaison TE qui connecte à R9. Comme il peut y avoit plusieurs ASBR qui sont connectés à R9 (les deux R7 et R8 dans cet exemple) R5 a aussi besoin de savoir les propriétés TE des liaisons TE inter-AS afin qu’il puisse choisir l’ASBR de sortie correct.

Une fois que le message Path atteint l’ASBR de sortie, tout choix de liaison TE inter-AS peut être fait par l’ASBR si il n’est pas déjà fait par l’ASBR d’entrée qui a calculé le segment.

On trouvera plus de détails à la Section 4 de la [RFC5152], qui explique clairement pourquoi l’annonce des liaisons inter-AS est désirée.

Pour permettre à R5 de faire le choix correct de l’ASBR de sortie, les informations suivantes sont nécessaires :
o	Liste de toutes les liaisons TE inter-AS pour l’AS local.
o	Propriétés TE de chaque liaison TE inter-AS.
o	Numéro d'AS de l’AS voisin auquel chaque liaison TE inter-AS est connectée.
o	Identité (identifiant de routeur TE) de l’ASBR voisin auquel chaque liaison TE inter-AS est connectée.

Dans les réseaux GMPLS, plus d’informations peuvent aussi être requises pour choisir les liaisons TE correctes comme défini dans la [RFC4203].

L’exemple ci-dessus montre comment ces informations sont nécessaires aux ASBR points d’entrée pour chaque AS (ou les PCE qui fournissent les services de calcul pour les ASBR) mais ces informations sont aussi nécessaires dans tout l’AS local si la fonction de calcul de chemin est pleinement répartie entre les LSR dans l’AS local, par exemple, pour prendre en charge les LSP qui ont des points de départ (nœuds d’entrée) au sein de l’AS.

 	2.3	Calcul de chemin rétro récurrent
Un autre scénario qui utilise les techniques de PCE a le même problème. La [RFC5441] définit une méthode de calcul de LSP TE fondée sur le PCE (appelée calcul de chemin rétro récurrent (BRPC, Backward Recursive Path Computation) pour calculer les LSP MPLS-TE ou GMPLS inter-domaines contraints optimaux. Dans cette méthode de calcul de chemin, un ensemble spécifique de domaines traversés (des AS) sont supposés être choisis avant le début du calcul. Chaque PCE en aval dans un domaine(i) retourne à son PCE voisin en amont dans le domaine(i-1) une arborescence de multipoint à point de chemins potentiels. Chaque arborescence consiste en l’ensemble de chemins provenant de tous les nœuds de bordure situés dans le domaine(i) pour la destination où chaque chemin satisfait l’ensemble des contraintes exigées pour le LSP TE (bande passante, affinités, etc.).

Donc un PCE a besoin de choisir des nœuds de bordure (c’est-à-dire, des ASBR) qui fournissent la connexité avec l’AS en amont. Afin que l’arborescence des chemins fournis par un PCE à son voisin puisse être corrélée, les identités des ASBR pour chaque chemin doivent être référencées, de sorte que le PCE doit connaître les identités des ASBR dans l’AS distant atteint par toute liaison TE inter-AS, et, afin qu’il donne seulement les chemins convenables dans l’arborescence, le PCE doit connaître les propriétesTE des liaisons TE inter-AS. La figure suivant en donne un exemple :

                   PCE1<------>PCE2<-------->PCE3
                   /       :             :
                  /        :             :
                R1------R3----R5-----R7------R9-----R11
                        |     | \    |      / |
                        |     |  \   |  ----  |
                        |     |   \  | /      |
                R2------R4----R6   --R8------R10----R12
                           :              :
                <-- AS1 -->:<---- AS2 --->:<--- AS3 --->

Figure 2 : Modèle de référence BRPC pour inter-AS

La figure montre trois AS (AS1, AS2, et AS3) trois PCE (PCE1, PCE2, et PCE3) et douze LSR (R1 à R12). R3 et R4 sont des ASBR dans AS1. R5, R6, R7, et R8 sont des ASBR dans AS2. R9 et R10 sont des ASBR dans AS3. PCE1, PCE2, et PCE3 coopèrent pour effectuer un calcul de chemin inter-AS et sont responsables du calcul du segment de chemin au sein de leur propre domaine.

Si iI est prévu d’établir un LSP TE inter-AS TE de R1 à R12, les domaines traversés sont supposés être choisis : AS1->AS2->AS3, et la chaîne de PCE est : PCE1->PCE2->PCE3. D’abord, la demande de calcul de chemin générée par le client de calcul de chemin (R1) est relayée par PCE1 et PCE2 le long de la chaîne de PCE à PCE3, puis PCE3 commence à calculer les segments de chemin à partir des nœuds frontières d'entrée qui fournissent la connexion de AS2 à la destination (R12). Mais, pour fournir des segments de chemin convenables, PCE3 doit déterminer quels nœuds frontières d'entrée fournissent la connexité à son AS voisin en amont (identifié par son numéro d'AS) et doit connaître les propriétés TE des liaisons TE inter-AS. De la même façon, PCE2 a aussi besoin de déterminer les nœuds frontières d'entrée en accord avec son AS voisin en amont et les capacités de la liaison TE inter-AS.

Donc, pour prendre en charge le calcul de chemin rétro récurrent, les mêmes informations que mentionnées au paragraphe  2.2 sont nécessaires. Le numéro d'AS de l’AS voisin auquel chaque liaison TE inter-AS est connectée est particulièrement important.

 	3.	Extensions à OSPF

Noter que le présent document ne définit pas de mécanisme pour la distribution des informations de TE d’un AS à un autre, ni ne distribue aucune forme d’informations TE d’accessibilité pour les destinations en dehors de l’AS, ne change pas l’architecture ou usage de PCE, ne suggère ni ne recommande aucune forme d’agrégation de TE, et ne fournit pas d’informations privées  entre les AS. Voir le paragraphe 2.1.

Les extensions définies dans ce document permettent qu’une annonce de liaison TE inter-AS soit facilement identifiée comme telle par l’utilisation de deux nouveaux types de LSA, qui sont appelés LSA Inter-AS-TE-v2 et LSA Inter-AS-TE-v3. Trois nouveaux sous-TLV sont ajoutés au TLV Liaison pour porter les informations sur l’AS voisin et l’ASBR distant.

Bien que certaines des informations de TE d’une liaison TE inter-AS puissent être disponibles dans l’AS à partir d’autres protocoles, afin d’éviter toute dépendance à l’endroit où de tels protocoles sont traités, ce mécanisme porte toutes les informations nécessaires pour les opérations TE requises.

 	3.1	Définitions de LSA
 	3.1.1	LSA inter-AS-TE-v2
Pour l’annonce de liaisons TE OSPFv2 inter-AS, un nouveau LSA opaque, le LSA Inter-AS-TE-v2, est défini dans ce document. Le LSA Inter-AS-TE-v2 a le même format que le "LSA Ingénierie du trafic", qui est défini dans la [RFC3630].

L’annonce de liaison TE inter-AS DEVRAIT être portée dans un LSA opaque de type 10 [RFC5250] si la portée d’arrosage est limitée à l’intérieur d’une seule zone IGP à laquelle appartient l’ASBR, ou PEUT être portée dans un LSA opaque de type 11 [RFC5250] si les informations sont destinées à atteindre tous les routeurs (y compris les routeurs de bordure de zone, les ASBR, et les PCE) dans l’AS. Le choix entre l’utilisation d’un LSA opaque de type 10 (portée de zone) ou de type 11 (portée d’AS) est un choix de politique au niveau de l’AS, et son contrôle de configuration DEVRAIT être fourni dans les mises en œuvre d’ASBR qui prennent en charge l’annonce de liaisons TE inter-AS.

L’identifiant d’état de liaison d’un LSA opaque comme défini dans la [RFC5250] est divisé en deux parties. Une d’elles est le type Opaque (8 bits) l’autre est l’identifiant opaque (24 bits). La valeur pour le type Opaque de LSA Inter-AS-TE-v2 est 6 et a été alloué par l’IANA (voir le paragraphe 6.1). L’identifiant opaque du LSA Inter-AS-TE-v2 est une valeur arbitraire utilisée pour identifier de façon univoque les LSA d’ingénierie du trafic. L’identifiant d’état de liaison n’a pas de signification topologique.

Les TLV au sein du corps d’un LSA Inter-AS-TE-v2 ont le même format qu’utilisé dans OSPF-TE. La charge utile des TLV consiste en un ou plusieurs triplets Type/Longueur/Valeur incorporés. De nouveaux sous-TLV spécifiques de l’annonce de liaison TE inter-AS sont décrits au paragraphe 3.2.

 	3.1.2	LSA inter-AS-TE-v3
Dans ce document, un nouveau type de LS est défini pour l’annonce OSPFv3 de liaison TE inter-AS. Le code de fonction du nouveau type de LS est 13 (voir le paragraphe 6.1).

Le format d’un LSA Inter-AS-TE-v3 suit la définition standard d’un LSA OSPFv3 comme défini dans la [RFC5340].

Les trois bits de poids fort du champ Type de LS de l’en-tête de LSA OSPFv3 codent les propriétés génériques du LSA et sont appelés le bit U, le bit S2, et le bit S1 [RFC5340]. Le reste du type de LS porte le code de fonction de LSA.

Pour le LSA Inter-AS-TE-v3, les bits sont réglés comme suit :

Le bit U est toujours réglé à 1 pour indiquer qu’un routeur OSPFv3 DOIT arroser le LSA à sa portée d’arrosage définie même si il ne reconnaît pas le type de LS.

Les bits S2 et S1 indiquent la portée d’arrosage d’un LSA. Pour le LSA Inter-AS-TE-v3, les bits S2 et S1 DEVRAIENT être réglés à 01 pour indiquer que la portée d’arrosage doit être limitée à la seule zone IGP à laquelle appartient l’ASBR, mais PEUVENT être réglés à 10 si les informations devraient atteindre tous les routeurs (y compris les routeurs de bordure de zone, les ASBR, et les PCE) dans l’AS. Le choix entre l’utilisation de 01 ou 10 relève de la politique à l’échelle du réseau, et le contrôle de configuration DEVRAIT être fourni dans les mises en œuvre d’ASBR qui prennent en charge l’annonce des liaisons de TE inter-AS.

L’identifiant d’état de liaison du LSA Inter-AS-TE-v3 est une valeur arbitraire utilisée pour identifier de manière univoque les LSA d’ingénierie du trafic. L’identifiant de LSA n’a pas de signification topologique.
Les TLV au sein du corps d’un LSA Inter-AS-TE-v3 ont le même format et sémantique que ceux définis dans la [RFC5329]. Les nouveaux sous-TLV spécifiques de l’annonce de liaison TE inter-AS sont décrits au paragraphe 3.2.

 	3.2	Charge utile de LSA
Les LSA Inter-AS-TE-v2 LSA et Inter-AS-TE-v3 contiennent tous deux un TLV de niveau supérieur :

2 : TLV Liaison

Pour le LSA Inter-AS-TE-v2, ce TLV est défini dans la [RFC3630], et pour le LSA Inter-AS-TE-v3, ce TLV est défini dans la [RFC5329]. Les sous-TLV portés dans ce TLV sont décrits dans les paragraphes qui suivent.

 	3.2.1	TLV Liaison
Le TLV Liaison décrit une seule liaison et consiste en un ensemble de sous-TLV. Les sous-TLV à inclure dans le TLV Liaison du LSA Inter-AS-TE-v2 et LSA Inter-AS-TE-v3 sont définis, respectivement, dans la [RFC3630] et la [RFC5329], et la liste des sous-TLV peut être étendue par d’autres documents. Cependant, le présent document définit les exceptions suivantes.

Le sous-TLV Identifiant de liaison [RFC3630] NE DOIT PAS être utilisé dans le TLV Liaison d’un LSA Inter-AS-TE-v2, et le sous-TLV Identifiant de voisin [RFC5329] NE DOIT PAS être utilisé dans le TLV Liaison d’un LSA Inter-AS-TE-v3. Étant donné que OSPF est un IGP et devrait seulement être utilisé entre routeurs dans le même domaine d’acheminement, les sous-TLV Identifiant de liaison et Identifiant de voisin spécifique d’OSPF ne sont pas applicables aux liaisons inter-AS.

À la place, l’ASBR distant est identifié en incluant les nouveaux sous-TLV suivants définis dans ce document et décrits dans les paragraphes qui suivent  :
21 – sous-TLV Numéro d’AS distant
22 – sous-TLV Identifiant IPv4 d’ASBR distant
23 – sous-TLV Identifiant IPv6 d’ASBR distant

Le sous-TLV Numéro d’AS distant DOIT être inclus dans le TLV Liaison des deux LSA Inter-AS-TE-v2 et Inter-AS-TE-v3. Au moins un des sous-TLV Identifiant IPv4 d’ASBR distant et Identifiant IPv6 d’ASBR distant DEVRAIT être inclus dans le TLV Liaison du LSA Inter-AS-TE-v2 et du LSA Inter-AS-TE-v3. Noter qu’il est possible d’inclure le sous-TLV Identifiant IPv6 d’ASBR distant dans le TLV Liaison de la LSA Inter-AS-TE-v2, et d’inclure le sous-TLV Identifiant IPv4 d’ASBR distant dans le TLV Liaison du LSA Inter-AS-TE-v3 parce que les sous-TLV se réfèrent aux ASBR qui sont dans une portée d’adressage différente (c’est-à-dire, un AS différent) de où le LSA OSPF est utilisé.

 	3.3	Détails de sous TLV
 	3.3.1	Sous TLV Numéro d’AS distant
Un nouveau sous-TLV, Numéro d’AS distant est défini pour inclusion dans le TLV Liaison quand on annonce des liaisons inter-AS. Le sous-TLV Numéro d’AS distant spécifie le numéro d'AS de l’AS voisin auquel connecte la liaison annoncée. Le sous-TLV Numéro d’AS distant est EXIGÉ dans un TLV Liaison qui annonce une liaison TE inter-AS.

Le sous-TLV Numéro d’AS distant est un TLV de type 21 (voir le paragraphe 6.2), et fait quatre octets. Son format est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Longueur          |
+---------------+---------------+---------------+---------------+
|                    Numéro d’AS distant                        |
+---------------+---------------+---------------+---------------+

Le champ Identifiant d’AS distant fait 4 octets. Quand seuls deux octets sont utilisés pour le numéro d'AS, comme dans les déploiements courants, les deux octets de gauche (de poids fort) DOIVENT être réglés à zéro.

 	3.3.2	Sous TLV Identifiant IPv4 d’ASBR distant
Un nouveau sous-TLV, appelé Identifiant IPv4 d’ASBR distant, peut être inclus dans le TLV Liaison quand on annonce des liaisons inter-AS. Le sous-TLV Identifiant IPv4 d’ASBR distant spécifie l’identifiant IPv4 de l’ASBR distant auquel la liaison inter-AS annoncée connecte. Ce pourrait être toute adresse IPv4 stable et acheminable de l’ASBR distant. L’utilisation de l’identifiant d’adresse de routeur TE telle que spécifiée dans le TLV Adresse de routeur [RFC3630] est RECOMMANDÉE.

Le sous-TLV Identifiant IPv4 d’ASBR distant est un TLV de type 22 (voir le paragraphe 6.2) et fait quatre octets. Son format est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Longueur          |
+---------------+---------------+---------------+---------------+
|                    Identifiant d’ASBR distant                 |
+---------------+---------------+---------------+---------------+

Dans les annonces OSPFv2, le sous-TLV Identifiant IPv4 d’ASBR distant DOIT être inclus si l’ASBR voisin a une adresse IPv4. Si l’ASBR voisin n’a pas une adresse IPv4 (pas même un identifiant de routeur TE IPv4) le sous-TLV Identifiant IPv6 d’ASBR distant DOIT être inclus à la place. Un sous-TLV Identifiant IPv4 d’ASBR distant et un sous-TLV Identifiant IPv6 d’ASBR distant PEUVENT les deux être présents dans un TLV Liaison dans OSPFv2 ou OSPFv3.

 	3.3.3	Sous TLV Identifiant IPv6 d’ASBR distant
Un nouveau sous-TLV, appelé Identifiant IPv6 d’ASBR distant, peut être inclus dans le TLV Liaison quand on annonce des liaisons inter-AS. Le sous-TLV Identifiant IPv6 d’ASBR distant spécifie l’identifiant de l’ASBR distant auquel connecte la liaison inter-AS annoncée. Ce pourrait être toute adresse IPv6 stable, acheminable, et mondiale de l’ASBR distant. L’utilisation de l’identifiant de routeur TE IPv6 d’adresse IPv6 de routeur TE comme spécifiée dans l’adresse de routeur IPv6, qui est spécifiée dans le TLV Adresse de routeur IPv6 [RFC5329], est RECOMMANDÉE.

Le sous-TLV Identifiant IPv6 d’ASBR distant est un TLV de type 24 (voir le paragraphe 6.2) et fait seize octets. Son format est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Longueur          |
+---------------+---------------+---------------+---------------+
|                       Identifiant d’ASBR distant              |
+---------------+---------------+---------------+---------------+
|                    Identifiant d’ASBR distant (suite)         |
+---------------+---------------+---------------+---------------+
|                    Identifiant d’ASBR distant (suite)         |
+---------------+---------------+---------------+---------------+
|                    Identifiant d’ASBR distant (suite)         |
+---------------+---------------+---------------+---------------+

Dans les annonces OSPFv3, le sous-TLV Identifiant IPv6 d’ASBR distant DOIT être inclus si l’ASBR voisin a une adresse IPv6. Si l’ASBR voisin n’a pas d’adresse IPv6, le sous-TLV Identifiant IPv4 d’ASBR distant DOIT être inclus à la place. Un sous-TLV Identifiant IPv4 d’ASBR distant et un sous-TLV Identifiant IPv6 d’ASBR distant PEUVENT tous les deux être présents dans un TLV Liaison dans OSPFv2 ou OSPFv3.

 	4.	Procédure pour les liaisons TE inter-AS

Quand TE est activé sur une liaison inter-AS et que la liaison est ouverte, l’ASBR DEVRAIT annoncer cette liaison en utilisant les procédures normales pour OSPF-TE [RFC3630]. Quand la liaison est fermée ou quand TE est désactivé sur la liaison, l’ASBR DEVRAIT retirer l’annonce. Quand il y a des changements aux paramètres de TE pour la liaison (par exemple, quand la bande passante disponible change) l’ASBR DEVRAIT ré-annoncer la liaison, mais l’ASBR DOIT prendre des précautions contre des réannonces excessives, comme décrit dans la [RFC3630].

Les Hellos NE DOIVENT PAS être échangés sur la liaison inter-AS, et par conséquent, une adjacence OSPF NE DOIT PAS être formée.

Les informations annoncées viennent de la connaissance de l’ASBR des capacités TE de la liaison, de l’état et usage actuel de la liaison, et de la configuration à l’ASBR du numéro d'AS distant et de l’identifiant de routeur TE de l’ASBR distant.

Les routeurs traditionnels qui reçoivent une annonce pour une liaison TE inter-AS sont capables de l’ignorer parce que le type de liaison porte une valeur inconnue. Ils vont continuer d’arroser la LSA, mais ne vont pas tenter d’utiliser les informations reçues comme si la liaison était une liaison TE intra-AS.

Dans le fonctionnement actuel de OSPF TE, les LSR à chaque extrémité d’une liaison TE émettent des LSA qui décrivent la liaison. Les bases de données dans les LSR ont alors deux entrées (une générée en local, l’autre provenant de l'homologue) qui décrivent les différentes "directions" de la liaison. Cela permet que le plus court chemin ouvert en premier obligé (CSPF, Constrained Shortest Path First) fasse une vérification bidirectionnelle sur la liaison quand on effectue le calcul de chemin et qu’on l’élimine du calcul sauf si les deux directions de  la liaison satisfont les contraintes requises.

Dans le cas qu’on considère ici (c'est-à-dire, d’une liaison TE à un autre AS) il n’y a, par définition, pas d’échange de trafic IGP et donc pas d’informations TE de liaison bidirectionnelle. Afin que l’entité de calcul de chemin CSPF inclue la liaison comme chemin candidat, on doit trouver un moyen d’obtenir des LSA qui décrivent ses propriétés TE (bidirectionnelles) dans la base de données TE.

C’est réalisé par l’annonce de l’ASBR, à l’intérieur de son AS, des informations sur les deux directions de la liaison TE au prochain AS. L’ASBR va normalement générer un LSA décrivant son propre côté d’une liaison ; il joue ici un rôle de "mandataire" pour l’ASBR à la bordure de l’autre AS et génère un LSA supplémentaire qui décrit la "vue" de cet appareil de la liaison.

Seules des informations de TE essentielles pour la liaison ont besoin d’être annoncées ; c'est-à-dire, le type de liaison, le numéro d'AS distant, et l’identifiant d’ASBR distant. Les routeurs ou PCE qui sont capables de traiter les annonces de liaisons TE inter-AS NE DEVRAIENT PAS utiliser de telles liaisons pour calculer des chemins qui sortent d’un AS vers un ASBR distant et rentrer ensuite immédiatement dans l’AS par une autre liaison TE. De tels chemins constitueraienr des occurrences très rares et NE DEVRAIENT PAS être permises sauf par suite de configurations de politiques spécifiques au routeur ou PCE qui calcule le chemin.

 	4.1	Origine des informations de TE par un mandataire
La Section 4 décrit comment un ASBR annonce les informations de liaison TE comme un mandataire pour son ASBR voisin, mais ne décrit pas d’où ces informations viennent.

Bien que la source de ces informations sorte du domaine d’application de ce document, il est possible qu’il y ait une exigence de configuration à l’ASBR, comme le sont d’autres propriétés locales de la liaison TE. De plus, lorsque BGP est utilisé pour échanger des informations d’acheminement IP entre les ASBR, une certaine quantité de configuration locale supplémentaire sur la liaison et l’ASBR distant va probablement être disponible.

On note de plus qu’il est possible, et peut être opérationnellement avantageux, d’obtenir une partie des informations de configuration requises de BGP. Si et comment utiliser ces possibilities est une affaire de mise en œuvre.

 	5.	Considérations sur la sécurité

Les extensions de protocole définies dans ce document sont relativement mineures et peuvent être sécurisées au sein de l’AS dans lequel elles sont utilisées par les mécanismes existants de sécurité d’OSPF.

Il n’y a pas d’échange d’informations entre les AS, et pas de changement aux relations de sécurité OSPF entre les AS. En particulier, comme aucune adjacence OSPF n’est formée sur les liaisons inter-AS, il n’y a pas d’exigence de sécurité OSPF entre les AS.

Certaines des informations incluses dans ces nouvelles annonces (par exemple, le numéro d'AS distant et l’identifiant d’ASBR distant) sont obtenues manuellement d’une administration voisine au titre des relations commerciales. La source et le contenu de ces informations devrait être vérifié avec attention avant de les rentrer comme informations de configuration à l’ASBR responsable d’annoncer les liaisons TE inter-AS.

On notera que, dans le scénario qu’on examine, un échange de trafic de protocole de passerelle frontière (BGP, Border Gateway Protocol) peut exister entre les deux ASBR, et cela pourrait être utilisé pour détecter des incohérences de configuration (par exemple, l’administration qui a à l’origine fourni les informations peut mentir, ou des mauvaises configurations ou fautes manuelles sont faites par les opérateurs). Par exemple, si un numéro d'AS distant différent est reçu dans un BGP OPEN [RFC4271] de celui configuré en local dans OSPF-TE, comme on le décrit ici, la politique locale DEVRAIT alors être appliquée pour déterminer si il faut alerter l’opérateur d’une potentielle mauvaise configuration ou supprimer l’annonce OSPF de la liaison TE inter-AS. Noter de plus que si BGP est utilisé pour échanger des informations de TE comme décrit au paragraphe 4.1, la session BGP inter-AS DEVRAIT être sécurisée en utilisant des mécanismes comme décrits dans la [RFC4271] pour fournir des vérifications d’authentification et d’intégrité.

 	6.	Considérations relatives à l’IANA

L’IANA a fait les allocations suivantes à partir des registres qu’elle tient.

 	6.1	LSA OSPF TE inter AS
 	6.1.1	Inter-AS-TE-v2 LSA
L’IANA a alloué un nouveau type de LSA opaque (6) au LSA Inter-AS-TE-v2.

 	6.1.2	Inter-AS-TE-v3 LSA
L’IANA a alloué un nouveau code de fonction de type de LSA OSPFv3 (13) au LSA Inter-AS-TE-v3.

 	6.2	OSPF LSA Sub-TLVs Type
L’IANA tient le registre "TLV d’ingénierie du trafic de plus court chemin ouvert en premier (OSPF)" avec le sous registre "Types de sous TLV dans un TLV Liaison TE". L’IANA a alloué trois nouveaux sous TLV comme suit (voir les détails au paragraphe 3.3) :

Valeur	Signification
   21	sous TLV Numéro d’AS distant
   22	sous TLV Identifiant IPv4 d’ASBR distant
   24	sous TLV Identifiant IPv6 d’ASBR distant

 	7.	Remerciements

Les auteurs tiennent à remercier Adrian Farrel, Acee Lindem, JP Vasseur, Dean Cheng, et Jean-Louis Le Roux de leur relecture et de leurs commentaires sur ce document.

 	8.	Références
 	8.1	Références normatives

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

[RFC2328]	J. Moy, "OSPF version 2", STD 54, avril 1998. (MàJ par la RFC6549, RFC8042, 9355)

[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

[RFC3630]	D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", septembre 2003.

[RFC4203]	K. Kompella et autres, "Extensions OSPF pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (MàJ RFC3630) (P.S.)

[RFC5250]	L. Berger et autres, "Option OSPF de LSA opaque", juillet 2008. (Remplace RFC2370) (P.S.)

[RFC5329]	K. Ishiguro et autres, "Extensions d'ingénierie du trafic à OSPF version 3", septembre 2008. (P.S.)

[RFC5340]	R. Coltun et autres, "OSPF pour IPv6", juillet 2008. (P.S. ; Remplace RFC2740  ; MàJ par RFC8362)

 	8.2	Références pour information

[RFC4216]	R. Zhang et J.-P. Vasseur, "Exigences pour l'ingénierie de trafic MPLS entre systèmes autonomes (AS)", novembre  2005. (Information)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212, 9072)

[RFC4655]	A. Farrel, J.-P. Vasseur et J. Ash, "Architecture fondée sur l'élément de calcul de chemin (PCE)", août 2006.

[RFC5152]	JP. Vasseur et autres, "Méthode de calcul de chemin par domaine pour établir des chemins de commutation d'étiquettes (LSP) à ingénierie du trafic inter domaine", février 2008. (P.S.)

[RFC5252]	I. Bryskin, L. Berger, "Auto découverte de VPN de couche 1 fondé sur OSPF", juillet 2008. (P.S.)

[RFC5441]	JP. Vasseur, éd., R. Zhang, N. Bitar, JL. Le Roux "Procédure de calcul rétro récurrent fondée sur PCE (BRPC) pour calculer le plus court chemin obligé de commutation d'étiquette à ingénierie du trafic inter-domaine", avril 2009. (P. S.)

 	Adresse des auteurs

Mach(Guoyi) Chen	Renhai Zhang	Xiaodong Duan	
Huawei Technologies Co., Ltd.	Huawei Technologies Co., Ltd.	China Mobile	
KuiKe Building, No.9 Xinxi Rd.	KuiKe Building, No.9 Xinxi Rd.	53A,Xibianmennei Ave,Xunwu District	
Hai-Dian District	Hai-Dian District	Beijing,	
Beijing, 100085	Beijing, 100085	China	
P.R. China	P.R. China	mél : duanxiaodong@chinamobile.com	
mél : mach@huawei.com	mél : zhangrenhai@huawei.com