Network Working Group Y. Rekhter Request for Comments: 3107 Juniper Networks Category: Standards Track E. Rosen Cisco Systems, Inc. May 2001 Carrying Label Information in BGP-4 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching (MPLS) label which is mapped to that route. 1 Specification of Requirements .......................... 2 2 Overview ............................................... 2 3 Carrying Label Mapping Information ..................... 3 4 Advertising Multiple Routes to a Destination ........... 4 5 Capability Advertisement ............................... 4 6 When the BGP Peers are not Directly Adjacent ........... 5 7 Security Considerations ................................ 5 8 Acknowledgments ........................................ 6 9 References ............................................. 6 10 Authors' Addresses ..................................... 7 11 Full Copyright Statement ............................... 8
RFC 2119. MPLS- ARCH]. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. This can be useful in the following situations: - If two immediately adjacent Label Switched Routers (LSRs) are also BGP peers, then label distribution can be done without the need for any other label distribution protocol. - Suppose one's network consists of two "classes" of LSR: exterior LSRs, which interface to other networks, and interior LSRs, which serve only to carry traffic between exterior LSRs. Suppose that the exterior LSRs are BGP speakers. If the BGP speakers distribute MPLS labels to each other along with each route they distribute, then as long as the interior routers support MPLS, they need not receive any of the BGP routes from the BGP speakers. If exterior router A needs to send a packet to destination D, and A's BGP next hop for D is exterior router B, and B has mapped label L to D, then A first pushes L onto the packet's label stack. A then consults its IGP to find the next hop to B, call it C. If C has distributed to A an MPLS label for the route to B, A can push this label on the packet's label stack, and then send the packet to C. If a set of BGP speakers are exchanging routes via a Route Reflector [BGP-RR], then by piggybacking the label distribution on the route distribution, one is able to use the Route Reflector to distribute the labels as well. This improves scalability quite significantly. Note that if the Route Reflector is not in the forwarding path, it need not even be capable of forwarding MPLS packets. Label distribution can be piggybacked in the BGP Update message by using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The label is encoded into the NLRI field of the attribute, and the SAFI
("Subsequent Address Family Identifier") field is used to indicate that the NLRI contains a label. A BGP speaker may not use BGP to send labels to a particular BGP peer unless that peer indicates, through BGP Capability Advertisement, that it can process Update messages with the specified SAFI field. MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, and the low order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). c) Prefix: The Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant.
The label(s) specified for a particular route (and associated with its address prefix) must be assigned by the LSR which is identified by the value of the Next Hop attribute of the route. When a BGP speaker redistributes a route, the label(s) assigned to that route must not be changed (except by omission), unless the speaker changes the value of the Next Hop attribute of the route. A BGP speaker can withdraw a previously advertised route (as well as the binding between this route and a label) by either (a) advertising a new route (and a label) with the same NLRI as the previously advertised route, or (b) listing the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. The label information carried (as part of NLRI) in the Withdrawn Routes field should be set to 0x800000. (Of course, terminating the BGP session also withdraws all the previously advertised routes.) BGP-CAP], to inform its peers about this capability. The MP_EXT Capability Code, as defined in [BGP-MP], is used to advertise the (AFI, SAFI) pairs available on a particular connection. A BGP speaker should not advertise this capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers.
A BGP speaker that is capable of handling multiple routes to a destination (as described above) should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The value of this capability is 4.
It is possible though to use other techniques to avoid label spoofing problems. If, for example, one never accepts labeled packets from the network's "external" interfaces, and all the BGP-distributed labels are advertised via IBGP, then there is no way for an untrusted router to put a labeled packet into the network. One can generally assume that one's IBGP peers (or the IBGP peers of one's Route Reflector) will not attempt label spoofing, since they are all under the control of a single administration. This condition can actually be weakened significantly. One doesn't need to refuse to accept all labeled packets from external interfaces. One just needs to make sure that any labeled packet received on an external interface has a top label which was actually distributed out that interface. Then a label spoofing problem would only exist if there are both trusted and untrusted systems out the same interface. One way to avoid this problem is simply to avoid this situation. [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [BGP-MP] Bates, T., Rekhter, Y, Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [BGP-RR] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996. [MPLS-ARCH] Rosen, E., Vishwanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture" RFC 3031, January 2001. [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.