draft-ietf-mpls-bgp4-mpls-00.txt   draft-ietf-mpls-bgp4-mpls-01.txt 
Network Working Group Yakov Rekhter Network Working Group Yakov Rekhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: October 1998 Eric Rosen Expiration Date: February 1999 Eric Rosen
Cisco Systems Cisco Systems
Carrying Label Information in BGP-4 Carrying Label Information in BGP-4
draft-ietf-mpls-bgp4-mpls-00.txt draft-ietf-mpls-bgp4-mpls-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. Such NLRI is identified by using Sub-AFI TBD. attributes. Such NLRI is identified by using Sub-AFI TBD.
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 <label, length, prefix>, whose fields are triples of the form <label, length, prefix>, whose fields are
described below: described below:
+---------------------------+ +---------------------------+
| Length (1 octet) |
+---------------------------+
| Label (3 octets) | | Label (3 octets) |
+---------------------------+ +---------------------------+
............................. .............................
+---------------------------+ +---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) | | Prefix (variable) |
+---------------------------+ +---------------------------+
The use and the meaning of these fields are as follows: The use and the meaning of these fields are as follows:
a) Label: a) Length:
The Length field indicates the length in bits of the address
prefix plus the label(s).
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 bit contains "Bottom of Stack" (as octets, where the high-order bit contains "Bottom of Stack" (as
defined in [MPLS-ENCAPS]). The following high-order three bits defined in [MPLS-ENCAPS]). The following high-order three bits
must be zero. The remaining 20 bits contain the label value. must be zero. The remaining 20 bits contain the label value.
b) Length:
The Length field indicates the length in bits of the address
prefix. A length of zero indicates a prefix that matches all
(as specified by the address family) addresses (with prefix,
itself, of zero octets).
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.
The encoding described above allows a single BGP Update message to
carry multiple routes, each with its own label(s).
The label(s) specified for a particular route (and associated with it The label(s) specified for a particular route (and associated with it
address prefix) must be assigned by the LSR which is identified by address prefix) must be assigned by the LSR which is identified by
the value of the Next Hop attribute of the route. the value of the Next Hop attribute of the route.
When a BGP speaker redistributes a route, the label(s) assigned to When a BGP speaker redistributes a route, the label(s) assigned to
that route must not be changed (except by omission), unless the that route must not be changed (except by omission), unless the
speaker changes the value of the Next Hop attribute of the route. speaker changes the value of the Next Hop attribute of the route.
If a route is withdrawn, and a label(s) is specified at the time of A BGP speaker can withdraw a previously advertised route (as well as
withdrawal, only the corresponding route with the corresponding the binding between this route and a label) by either (a) advertising
label is withdrawn. If a route is withdrawn, and no label is a new route (and a label) with the same NLRI as the previously
specified at the time of withdrawal, then only the corresponding advertised route, or (b) listing the NLRI of the previously
unlabeled route is withdrawn; the labeled routes are left in advertised route in the Withdrawn Routes field of an Update message.
place. The label information carried (as part of NLRI) in the Withdrawn
Routes field should be set to 0x800000.
5. Advertising Multiple Routes to a Destination
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).
5. Capability Negotiation The encoding described above allows a single BGP Update message to
carry multiple routes, each with its own label(s).
BGP-4 speakers using Multiprotocol Extensions to carry label mapping In the case where a BGP speaker advertises multiple routes to a
information should use the Capabilities Optional Parameter as defined destination, if a route is withdrawn, and a label(s) is specified at
in [BGP-CAP]. The MP_EXT Capability Code, as defined in [CAP-MP], is the time of withdrawal, only the corresponding route with the
used to negotiate the (AFI, SAFI) pairs available on a particular corresponding label is withdrawn. If a route is withdrawn, and no
connection. label is specified at the time of withdrawal, then only the
corresponding unlabeled route is withdrawn; the labeled routes are
left in place.
6. Capability Negotiation
A BGP speaker that uses Multiprotocol Extensions to carry label
mapping information should use the Capabilities Optional Parameter,
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
negotiate 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.
6. Security Considerations A BGP speaker that is capable of handling multiple routes to a
destination (as described above) should use the Capabilities Optional
Paramter, as defined in [BGP-CAP], to inform its peers about this
capability. The value of this capability is TBD.
7. Security Considerations
Security issues are not discussed in this document. Security issues are not discussed in this document.
7. Acknowledgements 8. Acknowledgements
To be supplied. To be supplied.
8. References 9. References
[BGP-4] "A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li (RFC [BGP-4] "A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li (RFC
1771) http://ds.internic.net/rfc/rfc1771.txt 1771) http://ds.internic.net/rfc/rfc1771.txt
[BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, et al, [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, et al,
Work in progress, http://www.internic.net/internet-drafts/draft- Work in progress, http://www.internic.net/internet-drafts/draft-
ietf-idr-bgp4-cap-neg-00.txt ietf-idr-bgp4-cap-neg-00.txt
[BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, et al (RFC [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, et al (RFC
2283) http://ds.internic.net/rfc/rfc2283.txt 2283) http://ds.internic.net/rfc/rfc2283.txt
[CAP-MP] "BGP-4 Capabilities Negotiation for BGP Multiprotocol
Extensions", P. Marques, Work in progress,
http://ds.internic.net/internet-drafts/draft-marques-bgp4-cap-mp-
00.txt
[LDP] "LDP Specification", N. Feldman, et al, Work in progress
[MPLS-ARCH], "A Proposed Architecture for MPLS", E. Rosen, et al, [MPLS-ARCH], "A Proposed Architecture for MPLS", E. Rosen, et al,
Work in progress, http://www.internic.net/internet-drafts/draft- Work in progress, http://www.internic.net/internet-drafts/draft-
ietf-mpls-arch-00.txt ietf-mpls-arch-00.txt
[MPLS-ENCAPS], "MPLS Label Stack Encoding", E. Rosen, et al, Work in [MPLS-ENCAPS], "MPLS Label Stack Encoding", E. Rosen, et al, Work in
progress, http://www.internic.net/internet-drafts/draft-ietf-mpls- progress, http://www.internic.net/internet-drafts/draft-ietf-mpls-
label-encaps-00.txt label-encaps-00.txt
9. Author Information 10. Author Information
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
email: yakov@cisco.com email: yakov@cisco.com
Eric Rosen Eric Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/