Zum Hauptinhalt springen

RFC 8277 - Using BGP to Bind MPLS Labels to Address Prefixes

  • Status: Proposed Standard
  • Veröffentlicht: October 2017
  • Stream: IETF
  • Ersetzt: RFC3107
  • Errata: Keine Errata

Document Information​

  • RFC Number: 8277
  • Title: Using BGP to Bind MPLS Labels to Address Prefixes
  • Author: E. Rosen
  • Date: October 2017
  • Category: Standards Track
  • ISSN: 2070-1721
  • Obsoletes: RFC 3107

Abstract​

This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.

Dieses Dokument spezifiziert eine Reihe von Verfahren zur Verwendung von BGP, um bekannt zu geben, dass ein bestimmter Router ein bestimmtes MPLS-Label (oder eine bestimmte Sequenz von MPLS-Labels, die als zusammenhängender Teil eines Label-Stacks organisiert sind) an ein bestimmtes Adresspräfix gebunden hat. Dies kann durch Senden einer BGP UPDATE-Nachricht erfolgen, deren Feld Network Layer Reachability Information sowohl das Präfix als auch das/die MPLS-Label(s) enthält und deren Next Hop-Feld den Knoten identifiziert, an dem das besagte Präfix an das/die besagte(n) Label(s) gebunden ist. Dieses Dokument macht RFC 3107 obsolet.

Status of This Memo​

This is an Internet Standards Track document.

Dies ist ein Internet Standards Track-Dokument.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Community. Es wurde einer öffentlichen Prüfung unterzogen und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung genehmigt. Weitere Informationen zu Internet-Standards finden Sie in Abschnitt 2 von RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8277.

Informationen zum aktuellen Status dieses Dokuments, etwaige Errata und Möglichkeiten zur Rückmeldung finden Sie unter https://www.rfc-editor.org/info/rfc8277.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2017 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

Table of Contents​

  1. Introduction
  2. Using BGP to Bind an Address Prefix to One or More MPLS Labels
  3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes
  4. Data Plane
  5. Relationship between SAFI-4 and SAFI-1 Routes
  6. IANA Considerations
  7. Security Considerations
  8. References

1. Introduction​

[RFC3107] specifies encodings and procedures for using BGP to indicate that a particular router has bound either a single MPLS label or a sequence of MPLS labels to a particular address prefix. (A sequence of labels would be organized as a contiguous part of an MPLS label stack as specified in [RFC3031] and [RFC3032].) This is done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). Each such UPDATE also advertises a path to the specified prefix via the specified next hop.

[RFC3107] spezifiziert Kodierungen und Verfahren für die Verwendung von BGP, um anzuzeigen, dass ein bestimmter Router entweder ein einzelnes MPLS-Label oder eine Sequenz von MPLS-Labels an ein bestimmtes Adresspräfix gebunden hat. (Eine Sequenz von Labels würde als zusammenhängender Teil eines MPLS-Label-Stacks organisiert sein, wie in [RFC3031] und [RFC3032] spezifiziert.) Dies erfolgt durch Senden einer BGP UPDATE-Nachricht, deren Feld Network Layer Reachability Information sowohl das Präfix als auch das/die MPLS-Label(s) enthält und deren Next Hop-Feld den Knoten identifiziert, an dem das besagte Präfix an das/die besagte(n) Label(s) gebunden ist. Jedes solche UPDATE kündigt auch einen Pfad zum angegebenen Präfix über den angegebenen Next Hop an.

Although there are many implementations and deployments of [RFC3107], there are a number of issues with it that have impeded interoperability in the past and may potentially impede interoperability in the future:

Obwohl es viele Implementierungen und Einsätze von [RFC3107] gibt, gibt es eine Reihe von Problemen damit, die die Interoperabilität in der Vergangenheit behindert haben und die Interoperabilität in der Zukunft möglicherweise behindern könnten:

  • Although [RFC3107] specifies an encoding that allows a sequence of MPLS labels (rather than just a single label) to be bound to a prefix, it does not specify the semantics of binding a sequence of labels to a prefix.

  • Obwohl [RFC3107] eine Kodierung spezifiziert, die es erlaubt, eine Sequenz von MPLS-Labels (statt nur eines einzelnen Labels) an ein Präfix zu binden, spezifiziert es nicht die Semantik der Bindung einer Sequenz von Labels an ein Präfix.

  • Many implementations of [RFC3107] do not support the binding of a sequence of labels to a prefix.

  • Viele Implementierungen von [RFC3107] unterstützen die Bindung einer Sequenz von Labels an ein Präfix nicht.

  • [RFC3107] specifies that if a BGP UPDATE message binds a sequence of labels to a prefix, the BGP speaker MUST include a BGP Capability [RFC5492] in its OPEN message indicating that it can process such UPDATE messages. However, [RFC3107] does not define a Capability Code for this purpose.

  • [RFC3107] spezifiziert, dass, wenn eine BGP UPDATE-Nachricht eine Sequenz von Labels an ein Präfix bindet, der BGP-Sprecher eine BGP Capability [RFC5492] in seiner OPEN-Nachricht einschließen MUSS, die anzeigt, dass er solche UPDATE-Nachrichten verarbeiten kann. [RFC3107] definiert jedoch keinen Capability Code für diesen Zweck.

This document replaces and obsoletes [RFC3107]. It defines a new BGP Capability to be used when binding a sequence of labels to a prefix; by using this Capability, the interoperability problems alluded to above can be avoided. This document also removes the unimplemented "Advertising Multiple Routes to a Destination" feature (see Section 4 of [RFC3107]), while specifying how to use [RFC7911] to provide the same functionality.

Dieses Dokument ersetzt und macht [RFC3107] obsolet. Es definiert eine neue BGP Capability, die verwendet werden soll, wenn eine Sequenz von Labels an ein Präfix gebunden wird; durch Verwendung dieser Capability können die oben genannten Interoperabilitätsprobleme vermieden werden. Dieses Dokument entfernt auch die nicht implementierte Funktion "Advertising Multiple Routes to a Destination" (siehe Abschnitt 4 von [RFC3107]), während es spezifiziert, wie [RFC7911] verwendet wird, um dieselbe Funktionalität bereitzustellen.

2. Using BGP to Bind an Address Prefix to One or More MPLS Labels​

This is done by sending a Multiprotocol BGP UPDATE message, i.e., an UPDATE message with an MP_REACH_NLRI attribute as specified in [RFC4760]. The Network Address of Next Hop field of that attribute contains an IP address of node N. The label(s) and the prefix are encoded in the Network Layer Reachability Information (NLRI) field of the MP_REACH_NLRI. The encoding of the NLRI field is specified in Sections 2.2 and 2.3.

Dies geschieht durch Senden einer Multiprotocol BGP UPDATE-Nachricht, d. h. einer UPDATE-Nachricht mit einem MP_REACH_NLRI-Attribut, wie in [RFC4760] spezifiziert. Das Feld Network Address of Next Hop dieses Attributs enthält eine IP-Adresse von Knoten N. Das/die Label(s) und das Präfix werden im Feld Network Layer Reachability Information (NLRI) des MP_REACH_NLRI kodiert. Die Kodierung des NLRI-Feldes ist in den Abschnitten 2.2 und 2.3 spezifiziert.

If the prefix is an IPv4 address prefix or a VPN-IPv4 ([RFC4364]) address prefix, the Address Family Identifier (AFI) of the MP_REACH_NLRI attribute is set to 1. If the prefix is an IPv6 address prefix or a VPN-IPv6 prefix ([RFC4659]), the AFI is set to 2. If the prefix is an IPv4 address prefix or an IPv6 address prefix, the Subsequent Address Family Identifier (SAFI) field is set to 4.

Wenn das Präfix ein IPv4-Adresspräfix oder ein VPN-IPv4-Adresspräfix ([RFC4364]) ist, wird der Address Family Identifier (AFI) des MP_REACH_NLRI-Attributs auf 1 gesetzt. Wenn das Präfix ein IPv6-Adresspräfix oder ein VPN-IPv6-Präfix ([RFC4659]) ist, wird der AFI auf 2 gesetzt. Wenn das Präfix ein IPv4-Adresspräfix oder ein IPv6-Adresspräfix ist, wird das Feld Subsequent Address Family Identifier (SAFI) auf 4 gesetzt.

In the remainder of this document, we will use the term "SAFI-x UPDATE" to refer to a BGP UPDATE message containing an MP_REACH_NLRI attribute or an MP_UNREACH_NLRI attribute ([RFC4760]) whose SAFI field contains the value x.

Im Rest dieses Dokuments verwenden wir den Begriff "SAFI-x UPDATE", um auf eine BGP UPDATE-Nachricht zu verweisen, die ein MP_REACH_NLRI-Attribut oder ein MP_UNREACH_NLRI-Attribut ([RFC4760]) enthält, dessen SAFI-Feld den Wert x enthält.

2.1. Multiple Labels Capability​

[RFC5492] defines the "Capabilities Optional Parameter". A BGP speaker can include a Capabilities Optional Parameter in a BGP OPEN message. The Capabilities Optional Parameter is a triple that includes a one-octet Capability Code, a one-octet Capability length, and a variable-length Capability Value.

[RFC5492] definiert den "Capabilities Optional Parameter". Ein BGP-Sprecher kann einen Capabilities Optional Parameter in eine BGP OPEN-Nachricht aufnehmen. Der Capabilities Optional Parameter ist ein Tripel, das einen ein Oktett langen Capability Code, eine ein Oktett lange Capability Length und einen variabel langen Capability Value enthält.

This document defines a BGP Optional Capabilities parameter ([RFC5492]) known as the Multiple Labels Capability.

Dieses Dokument definiert einen BGP Optional Capabilities Parameter ([RFC5492]), der als Multiple Labels Capability bekannt ist.

  • Unless this Capability is sent on a given BGP session by both of that session's BGP speakers, a SAFI-4 or SAFI-128 UPDATE message sent on that session from either speaker MUST bind a prefix to only a single label and MUST use the encoding of Section 2.2.

  • Sofern diese Capability nicht auf einer bestimmten BGP-Sitzung von beiden BGP-Sprechern dieser Sitzung gesendet wird, MUSS eine SAFI-4 oder SAFI-128 UPDATE-Nachricht, die auf dieser Sitzung von einem der beiden Sprecher gesendet wird, ein Präfix nur an ein einzelnes Label binden und MUSS die Kodierung von Abschnitt 2.2 verwenden.

2.2. NLRI Encoding When the Multiple Labels Capability Is Not Used​

If the Multiple Labels Capability has not been both sent and received on a given BGP session, then in a BGP UPDATE on that session whose MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations specified in Section 2, the NLRI field is encoded as shown in Figure 2:

Wenn die Multiple Labels Capability auf einer bestimmten BGP-Sitzung nicht sowohl gesendet als auch empfangen wurde, dann wird in einem BGP UPDATE auf dieser Sitzung, dessen MP_REACH_NLRI-Attribut eine der in Abschnitt 2 spezifizierten AFI/SAFI-Kombinationen enthält, das NLRI-Feld wie in Abbildung 2 gezeigt kodiert:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |                 Label                 |Rsrv |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Prefix                               ~
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: NLRI with One Label

  • Length: The Length field consists of a single octet.

  • Length: Das Length-Feld besteht aus einem einzelnen Oktett.

2.3. NLRI Encoding When the Multiple Labels Capability Is Used​

If (a) a BGP speaker has sent the Multiple Labels Capability in its BGP OPEN message for a particular BGP session, (b) it has received the Multiple Labels Capability in its peer's BGP OPEN message for that session, and (c) both Capabilities specify AFI/SAFI x/y, then when using an UPDATE of AFI x and SAFI y to advertise the binding of a label or sequence of labels to a given prefix, the BGP speaker MUST use the encoding of Section 2.3. This encoding MUST be used even if only one label is being bound to a given prefix.

Wenn (a) ein BGP-Sprecher die Multiple Labels Capability in seiner BGP OPEN-Nachricht für eine bestimmte BGP-Sitzung gesendet hat, (b) er die Multiple Labels Capability in der BGP OPEN-Nachricht seines Peers für diese Sitzung empfangen hat und (c) beide Capabilities AFI/SAFI x/y spezifizieren, dann MUSS der BGP-Sprecher bei Verwendung eines UPDATE von AFI x und SAFI y, um die Bindung eines Labels oder einer Sequenz von Labels an ein bestimmtes Präfix anzukündigen, die Kodierung von Abschnitt 2.3 verwenden. Diese Kodierung MUSS verwendet werden, auch wenn nur ein einzelnes Label an ein bestimmtes Präfix gebunden wird.

If the Multiple Labels Capability has been both sent and received on a given BGP session, then in a BGP UPDATE on that session whose MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations specified in Section 2, the NLRI field is encoded as shown in Figure 3:

Wenn die Multiple Labels Capability auf einer bestimmten BGP-Sitzung sowohl gesendet als auch empfangen wurde, dann wird in einem BGP UPDATE auf dieser Sitzung, dessen MP_REACH_NLRI-Attribut eine der in Abschnitt 2 spezifizierten AFI/SAFI-Kombinationen enthält, das NLRI-Feld wie in Abbildung 3 gezeigt kodiert:

    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
   +-+-+-+-+-+-+-+-+
   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Label                 |Rsrv |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                               ~
   ~                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Label                 |Rsrv |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Prefix                               ~
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.4. How to Explicitly Withdraw the Binding of a Label to a Prefix​

Suppose a BGP speaker has announced, on a given BGP session, the binding of a given label or sequence of labels to a given prefix. Suppose it now wishes to withdraw that binding. To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute. The NLRI field of this attribute is encoded as follows:

Angenommen, ein BGP-Sprecher hat auf einer bestimmten BGP-Sitzung die Bindung eines bestimmten Labels oder einer Sequenz von Labels an ein bestimmtes Präfix angekündigt. Angenommen, er möchte diese Bindung nun zurückziehen. Dazu kann er eine BGP UPDATE-Nachricht mit einem MP_UNREACH_NLRI-Attribut senden. Das NLRI-Feld dieses Attributs wird wie folgt kodiert:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     | Compatibility |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Prefix                               ~
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: NLRI for Withdrawal

Upon transmission, the Compatibility field SHOULD be set to 0x800000.

Bei der Übertragung SOLLTE das Compatibility-Feld auf 0x800000 gesetzt werden.

2.5. Changing the Label That Is Bound to a Prefix​

Procedures for changing the label(s) bound to a given prefix by a given node are given in Section 2.5.

Verfahren zum Ändern des/der Labels, das/die von einem bestimmten Knoten an ein bestimmtes Präfix gebunden ist/sind, werden in Abschnitt 2.5 angegeben.

3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes​

Procedures for propagating SAFI-4 and SAFI-128 UPDATEs are discussed in Section 3.

Verfahren zur Verbreitung von SAFI-4 und SAFI-128 UPDATEs werden in Abschnitt 3 diskutiert.

3.1. Comparability of Routes​

3.2. Modification of Label(s) Field When Propagating​

3.2.1. When the Next Hop Field Is Unchanged​

3.2.2. When the Next Hop Field Is Changed​

4. Data Plane​

When a BGP speaker installs and propagates a SAFI-4 or SAFI-128 UPDATE, and if it changes the value of the Network Address of Next Hop field, it must program its data plane appropriately. This is discussed in Section 4.

Wenn ein BGP-Sprecher ein SAFI-4 oder SAFI-128 UPDATE installiert und weitergibt und wenn er den Wert des Feldes Network Address of Next Hop ändert, muss er seine Datenebene entsprechend programmieren. Dies wird in Abschnitt 4 diskutiert.

5. Relationship between SAFI-4 and SAFI-1 Routes​

6. IANA Considerations​

This document defines a new SAFI value (128) for the VPN-IPv6 address family.

Dieses Dokument definiert einen neuen SAFI-Wert (128) für die VPN-IPv6-Adressfamilie.

7. Security Considerations​

8. References​

8.1. Normative References​

  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
  • [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
  • [RFC4659] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
  • [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
  • [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.
  • [RFC7841] Halpern, J., Ed., Resnick, P., Ed., and A. Farrel, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, May 2016.
  • [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, July 2016.

8.2. Informative References​

  • [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.

Acknowledgements​

Author's Address​

E. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America

Email: [email protected]

Letztes Update am