Internet DRAFT - draft-rekhter-bgp4-mpls
draft-rekhter-bgp4-mpls
Network Working Group Yakov Rekhter
Internet Draft Cisco Systems
Expiration Date: August 1998 Eric Rosen
Cisco Systems
Carrying Label Information in BGP-4
draft-rekhter-bgp4-mpls-00.txt
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
When a pair of Label Switch Routers (LSRs) that maintain BGP peering
with each other exchange routes, the LSRs also need to exchange label
mapping information for these routes. The exchange is accomplished by
piggybacking the label mapping information for a route in the same
BGP Update message that is used to exchange the route. This document
specifies the way in which this is done.
draft-rekhter-bgp4-mpls-00.txt [Page 1]
Internet Draft draft-rekhter-bgp4-mpls-00.txt February 1998
3. Overview
The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH]
identifies situations in which the mapping between a label and a
route must be distributed between BGP peers. This document specifies
how this label mapping information is distributed. The label mapping
information is included in the BGP Update message that is used to
distribute the route. This is done by utilizing BGP-4 Multiprotocol
Extensions attribute [BGP-MP].
4. Carrying Label Mapping Information
Label mapping information is carried as part of the Network Layer
Reachability Information (NLRI) in the Multiprotocol Extensions
attributes. Such NLRI is identified by using Sub-AFI TBD.
The Network Layer Reachability information is encoded as one or more
triples of the form <label, length, prefix>, whose fields are
described below:
+---------------------------+
| Label (3 octets) |
+---------------------------+
.............................
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use and the meaning of these fields are as follows:
a) Label:
The Label field carries one or more labels (that corresponds to
the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3
octets, where the high-order bit contains "Bottom of Stack" (as
defined in [MPLS-ENCAPS]). The following high-order three bits
must be zero. The remaining 20 bits contain the label value.
b) Length:
The Length field indicates the length in bits of the address
draft-rekhter-bgp4-mpls-00.txt [Page 2]
Internet Draft draft-rekhter-bgp4-mpls-00.txt February 1998
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:
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 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
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.
If a route is withdrawn, and a label(s) is specified at the time of
withdrawal, only the corresponding route with the corresponding
label is withdrawn. If a route is withdrawn, and no label is
specified at the time of withdrawal, then only the corresponding
unlabeled route is withdrawn; the labeled routes are left in
place.
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
label(s).
5. Capability Negotiation
BGP-4 speakers using Multiprotocol Extensions to carry label mapping
information should use the Capabilities Optional Parameter as defined
in [BGP-CAP]. The MP_EXT Capability Code, as defined in [CAP-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
speaker unless there is a Label Switched Path (LSP) between the two
speakers.
draft-rekhter-bgp4-mpls-00.txt [Page 3]
Internet Draft draft-rekhter-bgp4-mpls-00.txt February 1998
6. Security Considerations
Security issues are not discussed in this document.
7. Acknowledgements
To be supplied.
8. References
[BGP-4]
[BGP-CAP]
[BGP-MP], RFC2283
[CAP-MP]
[LDP]
[MPLS-ARCH], draft-ietf-mpls-arch-00.txt
[MPLS-ENCAPS], draft-ietf-mpls-label-encaps-00.txt
9. Author Information
Yakov Rekhter
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
email: yakov@cisco.com
Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
email: erosen@cisco.com
draft-rekhter-bgp4-mpls-00.txt [Page 4]
