draft-ietf-mpls-bgp4-mpls-05.txt   rfc3107.txt 
Network Working Group Yakov Rekhter Network Working Group Y. Rekhter
Internet Draft Juniper Networks Request for Comments: 3107 Juniper Networks
Expiration Date: July 2001 Category: Standards Track E. Rosen
Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
May 2001
January 2001
Carrying Label Information in BGP-4 Carrying Label Information in BGP-4
draft-ietf-mpls-bgp4-mpls-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
When BGP is used to distribute a particular route, it can be also be This document specifies the way in which the label mapping
used to distribute an MPLS label which is mapped to that route information for a particular route is piggybacked in the same Border
[MPLS-ARCH]. This document specifies the way in which this is done. Gateway Protocol (BGP) Update message that is used to distribute the
The label mapping information for a particular route is piggybacked route itself. When BGP is used to distribute a particular route, it
in the same BGP Update message that is used to distribute the route can be also be used to distribute a Multiprotocol Label Switching
itself. (MPLS) label which is mapped to that route.
Table of Contents Table of Contents
1 Specification of Requirements .......................... 2 1 Specification of Requirements .......................... 2
2 Overview ............................................... 2 2 Overview ............................................... 2
3 Carrying Label Mapping Information ..................... 3 3 Carrying Label Mapping Information ..................... 3
4 Advertising Multiple Routes to a Destination ........... 4 4 Advertising Multiple Routes to a Destination ........... 4
5 Capability Negotiation ................................. 5 5 Capability Advertisement ............................... 4
6 When the BGP Peers are not Directly Adjacent ........... 5 6 When the BGP Peers are not Directly Adjacent ........... 5
7 Security Considerations ................................ 6 7 Security Considerations ................................ 5
8 Acknowledgments ........................................ 7 8 Acknowledgments ........................................ 6
9 References ............................................. 7 9 References ............................................. 6
10 Author Information ..................................... 7 10 Authors' Addresses ..................................... 7
11 Full Copyright Statement ............................... 8
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Overview 2. Overview
When BGP is used to distribute a particular route, it can also be When BGP is used to distribute a particular route, it can also be
used to distribute an MPLS label that is mapped to that route [MPLS- used to distribute an MPLS label that is mapped to that route [MPLS-
ARCH]. This document specifies the way in which this is done. The ARCH]. This document specifies the way in which this is done. The
label mapping information for a particular route is piggybacked in label mapping information for a particular route is piggybacked in
the same BGP Update message that is used to distribute the route the same BGP Update message that is used to distribute the route
itself. itself.
This can be useful in the following situations: This can be useful in the following situations:
- If two immediately adjacent Label Switched Routers (LSRs) are - If two immediately adjacent Label Switched Routers (LSRs) are
also BGP peers, then label distribution can be done without the also BGP peers, then label distribution can be done without the
need for any other label distribution protocol. need for any other label distribution protocol.
- Suppose one's network consists of two "classes" of LSR: exterior - Suppose one's network consists of two "classes" of LSR:
LSRs, which interface to other networks, and interior LSRs, which exterior LSRs, which interface to other networks, and interior
serve only to carry traffic between exterior LSRs. Suppose that LSRs, which serve only to carry traffic between exterior LSRs.
the exterior LSRs are BGP speakers. If the BGP speakers Suppose that the exterior LSRs are BGP speakers. If the BGP
distribute MPLS labels to each other along with each route they speakers distribute MPLS labels to each other along with each
distribute, then as long as the interior routers support MPLS, route they distribute, then as long as the interior routers
they need not receive any of the BGP routes from the BGP support MPLS, they need not receive any of the BGP routes from
speakers. the BGP speakers.
If exterior router A needs to send a packet to destination D, and If exterior router A needs to send a packet to destination D,
A's BGP next hop for D is exterior router B, and B has mapped and A's BGP next hop for D is exterior router B, and B has
label L to D, then A first pushes L onto the packet's label mapped label L to D, then A first pushes L onto the packet's
stack. A then consults its IGP to find the next hop to B, call label stack. A then consults its IGP to find the next hop to
it C. If C has distributed to A an MPLS label for the route to B, call it C. If C has distributed to A an MPLS label for the
B, A can push this label on the packet's label stack, and then route to B, A can push this label on the packet's label stack,
send the packet to C. and then send the packet to C.
If a set of BGP speakers are exchanging routes via a Route Reflector If a set of BGP speakers are exchanging routes via a Route Reflector
[BGP-RR], then by piggybacking the label distribution on the route [BGP-RR], then by piggybacking the label distribution on the route
distribution, one is able to use the Route Reflector to distribute distribution, one is able to use the Route Reflector to distribute
the labels as well. This improves scalability quite significantly. the labels as well. This improves scalability quite significantly.
Note that if the Route Reflector is not in the forwarding path, it Note that if the Route Reflector is not in the forwarding path, it
need not even be capable of forwarding MPLS packets. need not even be capable of forwarding MPLS packets.
Label distribution can be piggybacked in the BGP Update message by Label distribution can be piggybacked in the BGP Update message by
using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The
label is encoded into the NLRI field of the attribute, and the SAFI label is encoded into the NLRI field of the attribute, and the SAFI
("Subsequent Address Family Identifier") field is used to indicate ("Subsequent Address Family Identifier") field is used to indicate
that the NLRI contains a label. A BGP speaker may not use BGP to 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, send labels to a particular BGP peer unless that peer indicates,
through BGP Capability Negotiation, that it can process Update through BGP Capability Advertisement, that it can process Update
messages with the specified SAFI field. messages with the specified SAFI field.
3. Carrying Label Mapping Information 3. Carrying Label Mapping Information
Label mapping information is carried as part of the Network Layer Label mapping information is carried as part of the Network Layer
Reachability Information (NLRI) in the Multiprotocol Extensions Reachability Information (NLRI) in the Multiprotocol Extensions
attributes. The AFI indicates, as usual, the address family of the attributes. The AFI indicates, as usual, the address family of the
associated route. The fact that the NLRI contains a label is associated route. The fact that the NLRI contains a label is
indicated by using SAFI value 4 [assignment to be confirmed by IANA]. indicated by using SAFI value 4.
The Network Layer Reachability information is encoded as one or more The Network Layer Reachability information is encoded as one or more
triples of the form <length, label, prefix>, whose fields are triples of the form <length, label, prefix>, whose fields are
described below: described below:
+---------------------------+ +---------------------------+
| Length (1 octet) | | Length (1 octet) |
+---------------------------+ +---------------------------+
| Label (3 octets) | | Label (3 octets) |
+---------------------------+ +---------------------------+
skipping to change at page 4, line 15 skipping to change at page 3, line 42
The use and the meaning of these fields are as follows: The use and the meaning of these fields are as follows:
a) Length: a) Length:
The Length field indicates the length in bits of the address The Length field indicates the length in bits of the address
prefix plus the label(s). prefix plus the label(s).
b) Label: b) Label:
The Label field carries one or more labels (that corresponds to The Label field carries one or more labels (that corresponds to
the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3
octets, where the high-order 20 bits contain the label value, octets, where the high-order 20 bits contain the label value,
and the low order bit contains "Bottom of Stack" (as defined in and the low order bit contains "Bottom of Stack" (as defined in
[MPLS-ENCAPS]). [MPLS-ENCAPS]).
c) Prefix: c) Prefix:
The Prefix field contains address prefixes followed by enough The Prefix field contains address prefixes followed by enough
trailing bits to make the end of the field fall on an octet trailing bits to make the end of the field fall on an octet
boundary. Note that the value of trailing bits is irrelevant. boundary. Note that the value of trailing bits is irrelevant.
skipping to change at page 5, line 8 skipping to change at page 4, line 34
A BGP speaker may maintain (and advertise to its peers) more than one A BGP speaker may maintain (and advertise to its peers) more than one
route to a given destination, as long as each such route has its own route to a given destination, as long as each such route has its own
label(s). label(s).
The encoding described above allows a single BGP Update message to The encoding described above allows a single BGP Update message to
carry multiple routes, each with its own label(s). carry multiple routes, each with its own label(s).
In the case where a BGP speaker advertises multiple routes to a In the case where a BGP speaker advertises multiple routes to a
destination, if a route is withdrawn, and a label(s) is specified at destination, if a route is withdrawn, and a label(s) is specified at
the time of withdrawal, only the corresponding route with the the time of withdrawal, only the corresponding route with the
corresponding label is withdrawn. If a route is withdrawn, and no corresponding label is withdrawn. If a route is withdrawn, and no
label is specified at the time of withdrawal, then only the label is specified at the time of withdrawal, then only the
corresponding unlabeled route is withdrawn; the labeled routes are corresponding unlabeled route is withdrawn; the labeled routes are
left in place. left in place.
5. Capability Negotiation 5. Capability Advertisement
A BGP speaker that uses Multiprotocol Extensions to carry label A BGP speaker that uses Multiprotocol Extensions to carry label
mapping information should use the Capabilities Optional Parameter, mapping information should use the Capabilities Optional Parameter,
as defined in [BGP-CAP], to inform its peers about this capability. as defined in [BGP-CAP], to inform its peers about this capability.
The MP_EXT Capability Code, as defined in [BGP-MP], is used to The MP_EXT Capability Code, as defined in [BGP-MP], is used to
negotiate the (AFI, SAFI) pairs available on a particular connection. advertise the (AFI, SAFI) pairs available on a particular connection.
A BGP speaker should not advertise this capability to another BGP A BGP speaker should not advertise this capability to another BGP
speaker unless there is a Label Switched Path (LSP) between the two speaker unless there is a Label Switched Path (LSP) between the two
speakers. speakers.
A BGP speaker that is capable of handling multiple routes to a A BGP speaker that is capable of handling multiple routes to a
destination (as described above) should use the Capabilities Optional destination (as described above) should use the Capabilities Optional
Parameter, as defined in [BGP-CAP], to inform its peers about this Parameter, as defined in [BGP-CAP], to inform its peers about this
capability. The value of this capability is TBD. capability. The value of this capability is 4.
6. When the BGP Peers are not Directly Adjacent 6. When the BGP Peers are not Directly Adjacent
Consider the following LSR topology: A--B--C--D. Suppose that D Consider the following LSR topology: A--B--C--D. Suppose that D
distributes a label L to A. In this topology, A cannot simply push L distributes a label L to A. In this topology, A cannot simply push L
onto a packet's label stack, and then send the resulting packet to B. onto a packet's label stack, and then send the resulting packet to B.
D must be the only LSR that sees L at the top of the stack. Before A D must be the only LSR that sees L at the top of the stack. Before A
sends the packet to B, it must push on another label, which was sends the packet to B, it must push on another label, which was
distributed by B. B must replace this label with yet another label, distributed by B. B must replace this label with yet another label,
which was distributed by C. In other words, there must be an LSP which was distributed by C. In other words, there must be an LSP
skipping to change at page 6, line 19 skipping to change at page 5, line 45
that they come from B. This makes it easy for A to discard any that they come from B. This makes it easy for A to discard any
packets from B whose top labels are not among the labels that A packets from B whose top labels are not among the labels that A
distributed to B. That is, A can easily ensure that B only uses distributed to B. That is, A can easily ensure that B only uses
those labels which it is entitled to use. This technique can be used those labels which it is entitled to use. This technique can be used
to prevent "label spoofing", i.e., the situation in which an LSR to prevent "label spoofing", i.e., the situation in which an LSR
imposes a label which has not been properly distributed to it. imposes a label which has not been properly distributed to it.
The procedures discussed in this document would commonly be used when The procedures discussed in this document would commonly be used when
the label distribution peers are separated not merely by a point-to- the label distribution peers are separated not merely by a point-to-
point link, but by an MPLS network. This means that when an LSR A point link, but by an MPLS network. This means that when an LSR A
processes a labelled packet, it really has no way to determine which processes a labeled packet, it really has no way to determine which
other LSR B pushed on the top label. Hence it cannot tell whether other LSR B pushed on the top label. Hence it cannot tell whether
the label is one which B is entitled to use. In fact, when Route the label is one which B is entitled to use. In fact, when Route
Reflectors are in use, A may not even know the set of LSRs which Reflectors are in use, A may not even know the set of LSRs which
receive its label mappings. So the previous paragraph's technique receive its label mappings. So the previous paragraph's technique
for preventing label spoofing does not apply. for preventing label spoofing does not apply.
It is possible though to use other techniques to avoid label spoofing It is possible though to use other techniques to avoid label spoofing
problems. If, for example, one never accepts labeled packets from problems. If, for example, one never accepts labeled packets from
the network's "external" interfaces, and all the BGP-distributed the network's "external" interfaces, and all the BGP-distributed
labels are advertised via IBGP, then there is no way for an untrusted labels are advertised via IBGP, then there is no way for an untrusted
skipping to change at page 7, line 12 skipping to change at page 6, line 31
trusted and untrusted systems out the same interface. One way to trusted and untrusted systems out the same interface. One way to
avoid this problem is simply to avoid this situation. avoid this problem is simply to avoid this situation.
8. Acknowledgments 8. Acknowledgments
Thanks to Ravi Chandra, Enke Chen, Srihari Ramachandra, Eric Gray and Thanks to Ravi Chandra, Enke Chen, Srihari Ramachandra, Eric Gray and
Liam Casey for their comments. Liam Casey for their comments.
9. References 9. References
[BGP-4] RFC 1771, "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
T. Li, 3/95 (BGP-4)", RFC 1771, March 1995.
[BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J. [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement
Scudder, draft-ietf-idr-bgp4-cap-neg-04.txt, 9/99 with BGP-4", RFC 2842, May 2000.
[BGP-MP] RFC 2283, "Multiprotocol Extensions for BGP-4", T. Bates, R. [BGP-MP] Bates, T., Rekhter, Y, Chandra, R. and D. Katz,
Chandra, D.Katz, Y. Rekhter, 2/98 "Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[BGP-RR] RFC 1966, "BGP Route Reflection: An alternative to full mesh [BGP-RR] Bates, T. and R. Chandra, "BGP Route Reflection: An
IBGP", T. Bates, R. Chandra, 6/96. alternative to full mesh IBGP", RFC 1966, June 1996.
[MPLS-ARCH] "Multiprotocol Label Switching Architecture"A Proposed [MPLS-ARCH] Rosen, E., Vishwanathan, A. and R. Callon,
Architecture for MPLS", E. Rosen, A. Vishwanathan, R. Callon, draft- "Multiprotocol Label Switching Architecture" RFC 3031,
ietf-mpls-arch-06.txt, 8/99. January 2001.
[MPLS-ENCAPS] "MPLS Label Stack Encoding", E. Rosen, et al, draft- [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
ietf-mpls-label-encaps-07.txt, 9/99 Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
10. Author Information 10. Authors' Addresses
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
email: yakov@juniper.net
EMail: yakov@juniper.net
Eric Rosen Eric Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
email: erosen@cisco.com
EMail: erosen@cisco.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 29 change blocks. 
76 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/