Zum Hauptinhalt springen

7. Änderungen gegenüber RFC 3036

Hier ist eine Liste der Änderungen gegenüber RFC 3036

1. Das Host Address FEC und Verweise darauf wurden entfernt, da es von keiner Implementierung verwendet wird.

2. Die Referenzliste wurde in normative und informative Referenzen aufgeteilt

3. "MPLS using ATM VP Switching" wurde aus der Liste der normativen Referenzen und die Verweise darauf entfernt.

4. Der Verweis auf RFC 1700 wurde entfernt und durch einen Link auf http://www.iana.org/assignments/address-family-numbers ersetzt.

5. Der Verweis auf RFC 1771 wurde entfernt und durch einen Verweis auf RFC 4271 ersetzt.

6. Die Verwendung des F-Bits wurde klargestellt.

7. Eine Option wurde hinzugefügt, die Split Horizon bei geordneter Steuerung (Ordered Control) erlaubt.

8. Die Verarbeitung von Nachrichten mit gesetztem U-bit während der Sitzungsinitialisierungsverfahren wurde klargestellt.

9. Die Verarbeitung des E-Bits während der Sitzungsinitialisierungsverfahren wurde klargestellt.

10. Ein Text wurde hinzugefügt, der erklärt, dass die Shutdown-Nachricht im Zustandsübergangsdiagramm als Notification-Nachricht mit einem Status TLV implementiert wird, das einen schwerwiegenden Fehler anzeigt.

  1. Ein Fall für eine zu kurze TLV-Länge wurde in die Spezifikation zur Behandlung fehlerhafter TLVs aufgenommen.

  2. Die durch Hello-Spoofing entstehende Sicherheitsbedrohung wurde erläutert.

  3. Verweise auf 4271 und 4278 sowie ein Text zur Abweichung der Standardsreife bezüglich der MD5-Option wurden hinzugefügt.

  4. Ein Text aus 3031 zur Behandlung des Implicit NULL-Labels wurde hinzugefügt.

  5. Die Kodierung von DLCIs wurde aufgenommen, um den normativen Verweis auf 3034 zu entfernen.

  6. Die Verweise auf 3031, 3032 und 3034 wurden in informative Verweise verschoben.

  7. In dem Abschnitt, der die Behandlung unbekannter TLVs beschreibt, wurde der Verweis auf einen nicht existierenden Abschnitt entfernt (Erratum im ursprünglichen Dokument).

  8. Ein Text wurde hinzugefügt, der klärt, wie Interoperabilität beim Senden herstellereigener TLVs und Nachrichten erreicht wird.

  9. In den Verfahren "receive label request" wurde das Verfahren für den Fall, dass eine Schleife erkannt wird, so geändert, dass eine Benachrichtigung gesendet wird, bevor der Rest der Verarbeitung abgebrochen wird.

  10. In den Verfahren "receive label release" wurde das Verhalten für merge-fähige LSRs klargestellt.

  11. In den Verfahren "receive label release" wurde das Verhalten beim Empfang einer unbekannten FEC klargestellt.

  12. In Anmerkung 4 zu "Detect Change in FEC Next Hop" wurde der Text geändert, um auf die richtige Menge von Bedingungen für das Senden eines Labelanforderungsverfahrens zu verweisen (Tippfehler im ursprünglichen Dokument).

  13. In den Verfahren für "LSR decides to no longer label switch a FEC" wurde die Tatsache klargestellt, dass das Label nicht wiederverwendet werden darf, bis eine Label Release empfangen wurde.

  14. In der Routine "Prepare_Label_Mapping_Attributes" wurde eine Anmerkung zur Behandlung unbekannter TLVs gemäß ihren U- und F-Bits hinzugefügt.

  15. In den Verfahren zur Verarbeitung der Address-Nachricht wurde das Verhalten für den Fall klargestellt, dass ein LSR die erneute Ankündigung einer Adresse empfängt, die er zuvor selbst angekündigt hat, oder den Entzug einer Adresse von einem LSR, der diese Adresse zuvor nicht angekündigt hat.

  16. In der Routine "Receive Label Mapping" wurde die Bedeutung von PrevAdvLabel klargestellt, wenn zuvor keine Label-Ankündigungsnachricht gesendet wurde.

  17. In den Verfahren "Receive Label Mapping" wurde das Verfahren für den Fall, dass eine Schleife erkannt wird, so geändert, dass eine Benachrichtigung gesendet wird, bevor der Rest der Verarbeitung abgebrochen wird.

  18. In den Verfahren "Receive Label Mapping" wurde Schritt LMp.10 korrigiert, um Label Mapping-Nachrichten für zusätzliche (nicht zusammengeführte) LSPs für die FEC zu behandeln.

  19. In den Verfahren "Receive Label Mapping" wurde das Verhalten beim Empfang eines doppelten Labels für dieselbe FEC klargestellt.

  20. In der Routine "Receive Label Abort Request" wurde das Verhalten für nicht merge-fähige LSRs klargestellt.

  21. Die folgenden Punkte wurden in den Abschnitt aufgenommen, der Bereiche für zukünftige Studien erörtert:

  o  Erweiterungen zur Übermittlung der maximalen Übertragungseinheit
  o  grundlegende Peer-Discovery auf NBMA-Medien
o Option zum Herunterfahren einer Adjazenz
o Mechanismen zur Absicherung von Hello-Nachrichten
o Erkennung eines zustandslosen schnellen Neustarts der Steuerungsebene
o Unterstützung der "End of LIB"-Nachricht

o Mechanismen für den Umgang mit dem Fall, dass verschiedene LSRs dieselbe Adresse ankündigen