Aller au contenu principal

2. Détails de la modification

Les trois RFC 3032, 3270 et 5129 sont maintenant mises à jour selon ce qui suit.

2.1. RFC 3032​

RFC 3032 indique à la page 4:

  1. Experimental Use This three-bit field is reserved for experimental use.

Le présent paragraphe est maintenant modifié en:

  1. Traffic Class (TC) field This three-bit field is used to carry traffic class information, and the change of the name is applicable to all places it occurs in IETF RFCs and other IETF documents. RFC 3270 and RFC 5129 update the definition of the TC field and describe how to use the field.

Dans la figure 1 de la page 3 de la RFC 3032, le format d'une entrée de pile d'étiquettes est spécifié comme suit:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
 |                Label                  | Exp |S|       TTL     | Stack
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                     Label:  Label Value, 20 bits
                     Exp:    Experimental Use, 3 bits
                     S:      Bottom of Stack, 1 bit
                     TTL:    Time to Live, 8 bits

                              Figure 1

La figure 1 de la RFC 3032 est maintenant modifiée pour correspondre au changement de nom du champ TC:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
 |                Label                  | TC  |S|       TTL     | Stack
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                     Label:  Label Value, 20 bits
                     TC:     Traffic Class field, 3 bits
                     S:      Bottom of Stack, 1 bit
                     TTL:    Time to Live, 8 bits

                               Figure 1 (new)

Note: La désignation « Figure 1 (new) » sert à distinguer les deux figures dans le présent document. Dans la RFC 3032, elle reste « Figure 1 ».

2.2. RFC 3270​

RFC 3270 dit à la page 6:

1.2. EXP-Inferred-PSC LSP (E-LSP)​

Un seul LSP peut servir à prendre en charge un ou plusieurs Ordered Aggregates (OA). Un tel LSP peut prendre en charge jusqu'à huit Behavior Aggregates (BA) d'une même FEC, quel que soit le nombre d'OA couverts par ces BA. Avec ces LSP, le LSR utilise le champ EXP de l'en-tête shim MPLS pour déterminer le PHB à appliquer au paquet, notamment la PSC et la préférence d'abandon.

Nous nous référons à ces LSP comme "LSP EXP-inferred-PSC" (E-LSP), puisque le PSC d'un paquet transporté sur ce LSP dépend de la valeur du champ EXP pour ce paquet.

L'association entre le champ EXP et le PHB (c'est-à-dire la PSC et la priorité d'abandon) pour un tel LSP est soit signalée explicitement lors de l'établissement de l'étiquette, soit fondée sur une association préconfigurée.

Les opérations détaillées des E-LSP sont précisées à la section 3 ci-dessous.

RFC 3270 est maintenant mis à jour comme suit:

a. Un nouveau paragraphe est ajouté à la fin de la section 1 "Introduction":

Le champ EXP a été rebaptisé champ TC, et donc toutes les références dans la RFC 3270 au champ EXP se réfèrent maintenant au champ TC.

b. Un nouveau terme est ajouté à la section 1.1 « Terminology »:

TC Traffic Class (replaces the term EXP)

c. Dans la section 1.1 "Terminologie", l'acronyme E-LSP est désormais compris comme signifiant:

E-LSP Explicitly TC-encoded-PSC LSP

La section 1.2 de la page 6 de la RFC 3270 est maintenant modifiée en:

1.2. LSP à PSC explicitement codée dans le champ TC (E-LSP)​

Le champ EXP a été rebaptisé champ TC, et donc toutes les références dans RFC 3270 au champ EXP se réfèrent maintenant au champ TC. Cependant, nous conservons l'acronyme E-LSP (Explicitly TC-encoded-PSC LSP) car l'acronyme est largement utilisé.

Un seul LSP peut servir à prendre en charge un ou plusieurs OA. Un tel LSP peut prendre en charge jusqu'à huit BA d'une même FEC, quel que soit le nombre d'OA couverts par ces BA. Avec ces LSP, le LSR utilise le champ TC de l'en-tête shim MPLS pour déterminer le PHB à appliquer au paquet, notamment la PSC et la préférence d'abandon.

Nous nous référons à ces LSP comme "LSP explicitement codés TC-PSC" (E-LSP), puisque le PSC d'un paquet transporté sur ce LSP dépend de la valeur du champ TC (anciennement appelé champ EXP) pour ce paquet.

L'association entre le champ TC et le PHB (c'est-à-dire la PSC et la priorité d'abandon) pour un tel LSP est soit signalée explicitement lors de l'établissement de l'étiquette, soit fondée sur une association préconfigurée.

Il s'agit d'une mise à jour de la RFC 3032 [RFC3032], conforme à l'intention initiale d'utiliser ce champ de l'en-tête shim MPLS comme champ TC. La RFC 3270 a elle-même été mise à jour par la RFC 5129 [RFC5129].

Les opérations détaillées des E-LSP sont spécifiées à la section 3 de la RFC 3270.

2.3. RFC 5129​

RFC 5129 est maintenant mis à jour comme suit:

Un nouveau paragraphe est ajouté à la fin de la section 1.1 « Background »:

Le champ EXP a été rebaptisé champ TC, et donc toutes les références dans la RFC 5129 au champ EXP se réfèrent maintenant au champ TC.

La section 2 (cinquième puce), page 7 de la RFC 5129, indique:

Une troisième approche possible a été proposée par [Shayman]. Dans ce mécanisme, les LSR internes supposent que les extrémités prennent en charge ECN, mais cette hypothèse est vérifiée lors du retrait de la dernière étiquette. Si un LSR interne a marqué ECN dans le champ EXP de l'en-tête shim alors que l'en-tête IP indique que les extrémités ne prennent pas en charge ECN, le routeur de bord (ou l'avant-dernier routeur en cas de penultimate hop popping) abandonne le paquet. Nous recommandons ce mécanisme, appelé per-domain ECT checking, et le définissons plus précisément dans la section suivante. Son principal inconvénient est que des paquets peuvent continuer à être transmis après avoir rencontré une congestion, pour n'être abandonnés qu'à la sortie du domaine MPLS. La justification de cette décision figure à la section 8.1.

La section 2 (bullet 5) de la RFC 5129 est maintenant mise à jour en:

Une troisième approche possible a été proposée par [Shayman]. Dans ce mécanisme, les LSR internes supposent que les extrémités prennent en charge ECN, mais cette hypothèse est vérifiée lors du retrait de la dernière étiquette. Si un LSR interne a marqué ECN dans le champ TC de l'en-tête shim alors que l'en-tête IP indique que les extrémités ne prennent pas en charge ECN, le routeur de bord (ou l'avant-dernier routeur en cas de penultimate hop popping) abandonne le paquet. Nous recommandons ce mécanisme, appelé per-domain ECT checking, et le définissons plus précisément dans la section suivante. Son principal inconvénient est que des paquets peuvent continuer à être transmis après avoir rencontré une congestion, pour n'être abandonnés qu'à la sortie du domaine MPLS. La justification de cette décision figure à la section 8.1. Ce mécanisme met à jour les RFC 3032 [RFC3032] et RFC 3270 [RFC3270].

2.4. Portée de cette modification​

Il y a plusieurs endroits dans les RFC qui sont explicitement mis à jour par ce document qui font référence au " champ Exp ", parfois ils font référence au champ comme " bits Exp ", " bits EXP " ou " EXP ". Dans tous ces cas, les références font maintenant référence au champ TC.

Il existe également d'autres RFC (par exemple, RFC 3272 [RFC3272], RFC 3443 [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 [RFC4379], RFC 4448 [RFC4448], et RFC 4761 [RFC4761]) qui font référence au " champ Exp "; ils font parfois référence au champ comme " bits Exp ", " bits EXP " et " EXP ". Pour tous les RFC, y compris, mais sans s'y limiter, ceux mentionnés dans ce paragraphe, ces références font maintenant référence au champ TC.