Internet Draft Document Michael Mroz
draft-mroz-ppvpn-inter-as-lsps-00.txt Olen Stokes
Venkatesh Kanagasabapathy
Vijay Bhagavath
Extreme Networks
Giles Heron
PacketExchange, Ltd.
Pierre Lin
Yipes Communications, Inc.
Yetik Serbest
SBC Communications
Expires August 2002 February 2002
Tunnel LSPs Extended Across Autonomous System Boundaries
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the usage of the Border Gateway Protocol
(BGP) to establish Transparent LAN Services (TLS) tunnels across
Autonomous System (AS) boundaries. TLS is described in [MARTINI-
SIG] and [LASSERRE-TLS]. The focus of this document is to explain
how to achieve the tunnel LSP between Provider Edge (PE) routers in
different ASes. The method described herein may also be used in
[BGP-VPN] implementations.
Mroz, et al. [Page 1]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
Placement of this Memo in Sub-IP Area
RELATED DOCUMENTS
http://search.ietf.org/internet-drafts/draft-martini-l2circuit-
trans-mpls-06.txt
http://search.ietf.org/internet-drafts/draft-lasserre-vkompella-
ppvpn-vpls-00.txt
http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-
00.txt
WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
PPVPN
WHY IS IT TARGETTED AT THIS WG
The charter of the PPVPN WG includes L2 VPN services and this draft
specifies a method for extending Ethernet L2 VPN services over MPLS
across AS boundaries.
JUSTIFICATION
There is no Internet document that fully provides a method of
establishing inter-AS LSPs, which are necessary for the purpose of
allowing multiple carriers to be involved in a single L2VPN.
Mroz, et al. [Page 2]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
Table of Contents
1 Overview .
. . . . . . . . . . . . . . . . . 4
1.1 Labeled Route Known Within the AS.
. . . . . . . . . 5
1.2 Labeled Route Not Known Within the AS
. . . . . . . . 5
1.3 Terminology .
. . . . . . . . . . . . . . . . 6
. . . . . . . . . . . . . . 6
2.1 MP_REACH_NLRI Next Hop Field
. . . . . . . . . . . 6
2.2 Multiple Routes to a Destination .
. . . . . . . . . 7
2.3 Usage of Labeled Routes .
. . . . . . . . . . . . 7
2.4 LSP Between BGP Peers.
. . . . . . . . . . . . . 7
2.5 Label Stack Depth .
. . . . . . . . . . . . . . 8
. . . . . . . . . . . . . . 8
3.1 Usage of Sub Network Point of Attachment
. . . . . . . 8
4 Establishing the LSP Between PEs .
. . . . . . . . . 8
4.1 BGP Next Hop Reachability
. . . . . . . . . . . . 9
4.2 PE Reachability.
. . . . . . . . . . . . . . . 9
5 Security Considerations .
. . . . . . . . . . . . 9
6 Scalability Issues.
. . . . . . . . . . . . . . 9
7 Intellectual Property Considerations.
. . . . . . . .10
8 Full Copyright Statement.
. . . . . . . . . . . .10
9 References
. . . . . . . . . . . . . . . . .11
10 Authors' Addresses.
. . . . . . . . . . . . . .12
11 Appendix A: Example of Establishment of Inter-AS LSP
. . .13
12 Appendix B: Example of an Update Message Containing MP REACH
NLRI . . . . . . . . . . . . . . . . .16
Mroz, et al. [Page 3]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
1 Overview
This document describes a method of establishing Label Switched
Paths (LSP, see [MPLS]) between Provider Edge (PE) devices that are
located in different Autonomous Systems (AS). This document also
resolves some ambiguities with respect to [SDP] when carrying
labeled IPv4 routes. The intent is to enable VPN services to be
delivered over multiple provider networks. For example, multipoint
metro Ethernet (VPLS [L2VPN]) services can be offered on a global
scale, over multiple metro and wide-area networks. VPLS
capabilities support applications such as enterprise LAN
interconnection, distance peering, Internet access and virtual co-
location.
There is currently one other IETF document ([INTER-CITY]) that
provides a method of establishing inter-AS LSPs. [INTER-CITY] does
not address the ambiguities with respect to [SDP] that are
mentioned above.
Other documents have suggested methods of establishing inter-AS
LSPs. For example, [BGP-VPN] briefly describes three methods of
setting up LSPs on inter-provider backbones. Also, [L2VPN]
recommends using the most scalable method described in [BGP-VPN].
This method will be the focus herein.
[MARTINI-SIG] uses targeted Label Distribution Protocol (LDP, see
[MPLS-LDP]) sessions to distribute Virtual Circuit (VC) labels
between the PE. Similarly, a [BGP-VPN] or [L2VPN] implementation
may use multi-hop EBGP sessions to distribute labeled VPN-IPv4
routes between the PEs. The labels in the above cases are referred
to as "VPN labels". In data packets, the MPLS label stack above the
related VPN label is used to "tunnel" these packets through the
MPLS network between the PEs. The simplest case is where the
related tunnel LSP is set up within an AS by LDP. When multiple
ASes are involved, LDP does not normally distribute labels across
AS boundaries. Instead, BGP is used to distribute "labeled /32 IPv4
routes to the PE routers" as specified in [SDP].
This document focuses on the use of [MPLS-LDP] for establishment of
LSPs that are interior to an AS. It is, however, reasonable that
other protocols such as that described in [RSVP-TE] could be used.
There are two cases for inter-AS tunnel LSP construction. In the
first case, the AS Border Router (ASBR) that receives the "labeled
/32 IPv4 route to the PE" imports it into its own AS, which implies
that the PEs need not run BGP at all. In the second case, the
routes are not available in the Interior Gateway Protocol (IGP)
running within the AS.
Mroz, et al. [Page 4]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
1.1 Labeled Route Known Within the AS
When the "labeled /32 routes to the PE" are known internally to all
ASes through which the tunnel LSP must pass, a "single label" stack
is sufficient to transport packets from one PE to another. Assume
that PE1 and PE2 wish to exchange VPN labels. In the first AS (AS1)
containing PE1, a route to PE1 and an LSP to follow that route
would be available to an ASBR. That ASBR (call it ASBR1) would be
configured to use BGP to export a "labeled /32 IPv4 route to PE1"
to its EBGP neighbor. The neighbor ASBR would be configured to
import the route into its own AS. This would continue until the AS
that contained PE2 received the route, at which time PE2 would be
able to use VPN labels distributed by PE1.
The route to PE1 exported by ASBR1 has an association to an LSP
that was formed by LDP within AS1. Since LDP does not operate
between AS1 and other ASes, ASBR1's BGP must allocate a label to
assign to the route to get to PE1 and distribute the related
"labeled /32 IPv4 route to PE1" to its neighbor. Within its
forwarding database, ASBR1 will arrange for a label swap from the
label assigned by BGP for the "labeled /32 IPv4 route to PE1" to
the label received via LDP for the route. Connecting LDP-
distributed LSPs to consequently generated LSPs formed by BGP is
known as an "export splice". Similarly, the neighboring ASBR will
receive the "labeled /32 IPv4 route to PE1" and will import this
route into its own AS, causing LDP to distribute a label for the
route. Within its forwarding database, that ASBR will arrange for a
label swap from the label received in the "labeled /32 IPv4 route
to PE1" to the label assigned by LDP for the route. Connecting BGP-
distributed LSPs to consequently generated LSPs formed by LDP is
known as an "import splice".
1.2 Labeled Route Not Known Within the AS
When the BGP labeled /32 routes to the PEs are not imported into
the ASes, the tunnel LSP between the PEs must be set up using a
"two label" stack. The top label, distributed by LDP, is used to
get a packet to the BGP Next Hop of the route. The bottom label is
assigned and distributed by the BGP Next Hop in the related
"labeled /32 IPv4 route to the PE". Label swaps are performed on
the top label by Label Switching Routers (LSR) internal to the AS.
The penultimate LSR (the ASBR in the AS) may swap this label for
the Implicit Null label before sending the packet to its exterior
neighboring ASBR. The exterior ASBR, having assigned the bottom
label, can now recognize the need to swap this label for the one
assigned by the next BGP Next Hop, and to push a label associated
to an LSP used within the AS to get to that BGP Next Hop.
Mroz, et al. [Page 5]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
1.3 Terminology
The phrase "labeled IPv4 route to x" is used when referring to BGP
routes sent or received in MP REACH NLRI attributes.
The phrase "distribute a route to X and a label" is used to mean
that the IGP will distribute the route and LDP will distribute a
label for that route.
The use of the term "import" means "to accept external information
into a domain", and is consistent with its usage in [OSPF]. The
term "export" means "to provide information to the exterior of a
domain".
[SDP] describes the format used by BGP that allows it to distribute
labeled routes. The following sections specify some usages of the
formats in [SDP] for distributing labeled IPv4 routes.
2.1 MP_REACH_NLRI Next Hop Field
When used in the context of [SDP], the format of the MP_REACH_NLRI
Next Hop field (see [MEXT-BGP4]) does not contain a field for an
MPLS label. Consequently, in this application, the MP_REACH_NLRI
Next Hop contains an unlabeled IPv4 address, as does the NEXT HOP
attribute (see [BGP-4}).
The formats given in [SDP] allow multiple routes to the same
destination to be carried in a single Update message. The format
restricts all of the labeled prefixes to have the same BGP Next
Hop, but does not restrict an unlabeled route from carrying a
different BGP Next Hop (in the NEXT_HOP attribute). This would be
expected since [SDP] does not restrict the address family to IPv4.
However, [BGP-4] states that an Update message carries a single
route, yet allows multiple prefixes to share the route's
attributes. When the MP REACH NLRI carries labeled IPv4 addresses,
the NEXT_HOP attribute, if present, SHALL contain the same prefix
as the Next Hop field of the MP_REACH_NLRI attribute (note,
although the NEXT HOP attribute is a mandatory attribute,
[MEXT-BGP4] allows it to be excluded when the NLRI field of the
Update is empty).
An example BGP Update message that contains labeled IPv4 routes is
given in Appendix B.
Mroz, et al. [Page 6]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
2.2 Multiple Routes to a Destination
It can be inferred from [SDP] that a single Update message can
carry multiple routes to the same destination as long as each route
carries a different label. However, doing so assigns the same BGP
attribute values to all such routes. Furthermore, there is no tie-
breaking procedure defined among such routes. Therefore, a single
Update message SHALL carry a particular address prefix only once,
either in the NLRI field (without a label) or in the MP REACH NLRI
field (with a label). Each route to a particular destination and
from the same BGP speaker SHALL be delivered in a separate Update
message.
Withdrawal of routes to a prefix is done either using the standard
Withdrawn Routes field when unlabeled IPv4 routes are to be
withdrawn, or by using the MP UNREACH NLRI attribute when labeled
IPv4 routes are to be withdrawn. In the latter case, a specific
labeled IPv4 route is withdrawn by specifying the label originally
provided. All labeled IPv4 routes with the same prefix and from the
same BGP speaker are withdrawn when the specified label value is
0x800000 (the unlabeled route, if any, is not affected).
This document does not require that an implementation support the
Multiple Routes to a Destination feature.
2.3 Usage of Labeled Routes
A labeled IPv4 route can only be used to forward traffic via MPLS.
A router MUST NOT install this route in such a way that forwarding
takes place without using the related label switched path.
2.4 LSP Between BGP Peers
[SDP] indicates that a BGP speaker should not advertise the
capability to exchange labeled routes to its peer unless there is
an LSP between them. However, if the speakers are directly
adjacent, the LSP could be established by exchanging labeled IPv4
routes once the capability has been advertised.
Mroz, et al. [Page 7]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
2.5 Label Stack Depth
An MP REACH NLRI attribute can carry labeled IPv4 routes that
contain more than one label, with the final label in the stack
terminated using the "bottom-of-stack" bit (see [MPLS-ENCAPS]). The
format of the NLRI field of the MP REACH NLRI attribute limits the
depth of the label stack associated to an address prefix (to nine
labels for labeled IPv4). However, it may be reasonable for an
implementation to further limit this depth.
An implementation that receives a labeled IPv4 route whose label
stack depth exceeds the maximum depth tolerated by that
implementation SHALL reject the route, sending a Notify containing
the Optional Attribute Error subcode to the peer that sent the
route (see [BGP-4]).
3.1 Usage of Sub Network Point of Attachment
Usage of the SNPA field of the MP REACH NLRI attribute is not
specified herein. The "Number of SNPAs" field may be set to zero.
4 Establishing the LSP Between PEs
If routes to the PE routers are to be known within those ASes
across which an LSP must be set up, ASBRs will have to be
configured to import and export "labeled /32 IPv4 routes to PEs" to
and from their respective IGP. It should be noted that not all ASes
need to be configured the same way. For example, a transit AS may
be configured not to import routes to the PEs, while the AS
containing the PE devices may be configured otherwise.
The remaining subsections are devoted to the case where routes to
PE routers are not known to AS-internal routers that do not run
BGP. It is assumed that the PE routers are running BGP and are
exchanging labeled IPv4 routes with their peers. Appendix A gives
an example of an inter-AS LSP setup.
Mroz, et al. [Page 8]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
4.1 BGP Next Hop Reachability
In order to reach inter-AS destinations of routes distributed with
labels, there must be an LSP to get to the BGP Next Hop of the
route. The BGP Next Hop of a route would normally be either the
exterior ASBR that has a non-multihop EBGP session with the
interior ASBR, or the interior ASBR itself.
When the BGP Next Hop is the exterior ASBR, the exterior ASBR could
advertise a "labeled /32 IPv4 route to itself" to the interior
ASBR, and the interior ASBR could be configured to import that
route into its AS routing domain. Alternatively, the interior ASBR
could proxy-advertise a /32 route and a label to its interior AS,
and arrange for a label swap to the Implicit Null label.
When the BGP Next Hop is the interior ASBR (known as "next hop
self"), the ASBR advertises into its interior a /32 route to
itself, and also distributes a label for that route into its
interior.
4.2 PE Reachability
Because routes to the PEs are not advertised into the interior of
some ASes along the tunnel LSP, a PE will need to advertise a
"labeled /32 IPv4 route to itself" (with the next hop of the route
being the PE itself) to its peers. As with the "next hop self" case
described above, the PE must also advertise a route to itself and
distribute a label for that route into its interior.
The advantage of having the PE advertise the "labeled /32 IPv4
route to itself" is that the ASBR will not have to be configured to
export the route to the PE from its interior.
Alternatively, the interior ASBR could be configured as such. If
the interior ASBR were also configured to imported a route and a
label to the remote PE, the local PE would not have to run BGP.
5 Security Considerations
No new security issues result from this document.
6 Scalability Issues
In [MARTINI-SIG], targeted LDP sessions are used to distribute VPN
labels. Because the related TCP sessions will now be established
between ASes, the same scalability problems faced by BGP (addressed
using Route Reflectors [BGP-RR] and/or Confederations [BGP-CONFED])
could arise. Since the focus of this document is to provide a
method for establishing inter-AS LSPs, this issue will not be
addressed further.
Mroz, et al. [Page 9]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
7 Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
8 Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Mroz, et al. [Page 10]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
9 References
[BGP-VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-00.txt (Work
In Progress)
[L2VPN] "Layer 2 VPNs Over Tunnels", draft-kompella-ppvpn-l2vpn-
01.txt (Work In Progress)
[SDP] Rekhter & Rosen, "Carrying Label Information in BGP-4", RFC
3107, May 2001
[LASSERRE-TLS] "Transparent VLAN Services over MPLS", draft-
lasserre-vkompella-ppvpn-vpls-00.txt, May 2002 (Work In Progress)
[MARTINI-SIG] "Transport of Layer 2 Frames Over MPLS", draft-
martini-l2circuit-trans-mpls-08.txt, November 2001 (Work IN
Progress)
[BGP-4] Rekhter & Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995
[MEXT-BGP4] Bates, et al., "Multiprotocol Extensions for BGP-4",
RFC 2858, June 2000
[MPLS] Rosen, et al., "Multiprotocol Label Switching Architecture",
RFC 3031, January 2001
[MPLS-LDP] Andersson, et al., "LDP Specification", RFC 3036,
January 2001
[RSVP-TE] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001
[OSPF] Moy, "OSPF Version 2", RFC 2328, April 1998
[BGP-RR] Bates, et al., "BGP Route Reflection - An Alternative to
Full Mesh IBGP", RFC 2796, April 2000
[BGP-CONFED] Traina, et al., "Autonomous System Confederations for
BGP", RFC 3065, February 2001
[MPLS-ENCAPS] Rosen, et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001
[INTER-CITY] Menezes, et al., "Inter-City MAN Services Using MPLS",
draft-menezes-inter-city-man-mpls-00.txt, November 2001
Mroz, et al. [Page 11]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
10 Authors' Addresses
Mike Mroz
Extreme Networks
630 Davis Drive, Suite 250
Morrisville, NC 27560
Email: mroz@extremenetworks.com
Olen Stokes
Extreme Networks
630 Davis Drive, Suite 250
Morrisville, NC 27560
Email: ostokes@extremenetworks.com
Venkatesh Kanagasabapathy
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
Email: vkanagasabapathy@extremenetworks.com
Vijay Bhagavath
Extreme Networks
3583 Monroe Street
Santa Clara, CA 95051
Email: vbhagavath@extremenetworks.com
Giles Heron
PacketExchange, Ltd.
91 Brick Lane
London E1 6QL
U.K.
Email: giles@packetexchange.net
Pierre Lin
Yipes Communications, Inc.
114 Sansome St.
San Francisco CA 94104
Email: pierre.lin@yipes.com
Yetik Serbest
SBC Communications
Austin, TX
Email: serbest@tri.sbc.com
512-372-5666
Mroz, et al. [Page 12]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
11 Appendix A: Example of Establishment of Inter-AS LSP
The following example refers to Figure A.1.
<-------------
------------ L32' --------- L32 ------------
| ASBR31 |-------------| P3 |-------------| ASBR32 |
------------ L31 --------- L31' ------------
| L12 | L22
| ------------> |
| AS3 |
------------+--------------------------------------------------+-------
| NULL | | | NULL
NULL | | | NULL |
------------ | | ------------
L22' | ASBR1 | | | L12' | ASBR2 |
------------ | | ------------
| L11' | | | L21'
L23 | | | L13 |
------------ | | ------------
| P1 | | | | P2 |
------------ | | ------------
| L11 | | | L21
L23' | | | L13' |
L22'' ------------ | | L12'' ------------
L24 | PE1 | | | L14 | PE2 |
------------ | | ------------
| | | |
| AS1 | | AS2 |
| | | |
------------+---------------------| |---------------------+-------
| | | |
| | | |
------- | | -------
/ CE1 \ | | / CE2 \
| VLAN1 | | | | VLAN2 |
\ / | | \ /
------- | | -------
Figure A.1: Establishment of Inter-AS LSP Between PE1 and PE2
Mroz, et al. [Page 13]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
In the figure, AS1 and AS2 contain PE devices, and AS3 is a transit
network. Labels inside the "horseshoe" are used for data flow from
CE1 to CE2, and labels outside the horseshoe are used for dataflow
from CE2 to CE1 (arrows indicate these directions). All ASes are
running [OSPF] as their IGP, and are running LDP. All devices
except the Provider (Pn) internal devices are running BGP. PE1 and
PE2 are running the protocol described in [MARTINI-SIG]. It is
assumed that the EBGP sessions may advertise the multiprotocol
capability for labeled IPv4 routes before an LSP is established
between the related ASBRs. An LSP establishment sequence follows:
1. ASBR1 proxy advertises into AS1 (via OSPF) a /32 route to get to
ASBR31. LDP running in ASBR1 advertises a label (L11') into AS1
for that route. P1's LDP advertises label L11 for the route.
Similarly, ASBR2 proxy advertises a route and label (L21') for
ASBR32 into AS2 and P2's LDP advertises label L21 for the route;
ASBR32 advertises L31' for ASBR2 into AS3 and P3 advertises L31;
and ASBR31 advertises L32' for ASBR1 into AS3 and P3 advertises
L32. In this way, LSPs to the BGP Next Hops are known in the
relevant AS interior. When doing this advertisement, each device
arranges for a label swap to the Implicit Null label.
2. PE1 advertises (via OSPF) a /32 route to itself into AS1. LDP
distributes a label L23' for that route. P1 consequently
advertises label L23 to ASBR1 for that route. Similarly, PE2
advertises label L13' and P2 advertises L13.
3. PE1 uses BGP to advertise a "labeled /32 IPv4 route to PE1"
(L22'') to ASBR1. Similarly, PE2 advertises a "labeled /32 IPv4
route to PE2" (L12'') to ASBR2.
4. ASBR1 advertises the "labeled /32 IPv4 route to PE1 (L22')" to
ASBR31 with ASBR1 as the next hop. Similarly, ASBR2 advertises
the "labeled /32 IPv4 route to PE2 (L12')" to ASBR32 with ASBR2
as the next hop.
5. ASBR31 advertises the "labeled /32 IPv4 route to PE1 (L22')" to
ASBR32. Similarly, ASBR32 advertises the "labeled /32 IPv4 route
to PE2 (L12')" to ASBR31.
6. ASBR32 advertises the "labeled /32 IPv4 route to PE1 (L22)" to
ASBR2 with ASBR32 as the next hop. Similarly, ASBR31 advertises
the "labeled /32 IPv4 route to PE2 (L12)" to ASBR1 with ASBR31
as the next hop.
7. ASBR1 advertises the "labeled /32 IPv4 route to PE2 (L12)" to
PE1. Similarly, ASBR2 advertises the "labeled /32 IPv4 route to
PE1 (L22)" to PE2.
8. PE1 and PE2 establish their targeted LDP session. PE1 advertises
VC Label L24 for VLAN1 to PE2. PE2 advertises VC Label L14 for
VLAN2 to PE1.
Mroz, et al. [Page 14]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
Summary of the elemental LSPs formed above:
LSP Created From To Purpose
--- ------- ---- -- -------
L11-L11'-NULL LDP PE1 ASBR31 BGP Next Hop
L31-L31'-NULL LDP ASBR31 ASBR2 BGP Next Hop
L13-L13' LDP ASBR2 PE2 BGP Next Hop
L12-L12'-L12'' BGP PE1 PE2 Identifies Next Hop LSP
L14 LDP PE1 PE2 Identifies VLAN2
L21-L21'-NULL LDP PE2 ASBR32 BGP Next Hop
L32-L32'-NULL LDP ASBR32 ASBR1 BGP Next Hop
L23-L23' LDP ASBR1 PE1 BGP Next Hop
L22-L22'-L22'' BGP PE2 PE1 Identifies Next Hop LSP
L24 LDP PE2 PE1 Identifies VLAN1
Label Stacks Formed for Figure A.1 are read from (left) top of
stack to (right) bottom of stack (i.e., Top/Middle/Bottom). The
stacks are shown as they exist on the links between network
devices.
Packet From CE1 to CE2 Packet From CE2 to CE1
---------------------- ----------------------
CE1-PE1 None CE2-PE2 None
PE1-P1 L11/L12/L14 PE2-P2 L21/L22/L24
P1-ASBR1 L11'/L12/L14 P2-ASBR2 L21'/L22/L24
ASBR1-ASBR31 L12/L14 ASBR2-ASBR32 L22/L24
ASBR31-P3 L31/L12'/L14 ASBR32-P3 L32/L22'/L24
P3-ASBR32 L31'/L12'/L14 P3-ASBR31 L32'/L22'/L24
ASBR32-ASBR2 L12'/L14 ASBR31-ASBR1 L22'/L24
ASBR2-P2 L13/L12''/L14 ASBR1-P1 L23/L22''/L24
P2-PE2 L13'/L12''/L14 P1-PE1 L23'/L22''/L24
PE2-CE2 None PE1-CE1 None
In the forwarding of the packet from ASBR31 to P3 that ASBR31
performs a swap of label L12 for label L12', and then pushes label
L31 to get to next hop ASBR2.
Mroz, et al. [Page 15]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
12 Appendix B: Example of an Update Message Containing MP REACH NLRI
The example message carries both the NLRI / NEXT HOP fields and the
MP REACH NLRI field.
Octets Data Description
------ ---- -----------
0-15 FF...FF Marker (all ones)
16-17 0052 Length (82 octets)
18 02 Type (UPDATE)
19-20 0000 Unfeasible routes (length)
21-22 0033 Path Attribute Length, 51 octets
23-24 4001 ORIGIN Attribute
25 01 Length of ORIGIN attribute value
26 01 NLRI learned via EGP
27-28 4002 AS PATH Attribute
29 04 Length of AS PATH
30 01 AS_SET
31 01 One AS is present
32-33 FC00 Private AS number
34-35 4003 NEXT HOP Attribute
36 04 Length of Next Hop
37-38 0A320101 Next hop is 10.50.1.1
39-40 4005 LOCAL PREF Attribute
41 04 Length of local preference
42-43 00000005 Local Preference Metric
Labeled IPv4 routes are contained in MP REACH NLRI attribute:
44-45 800E MP REACH NLRI Attribute
46 1B MP REACH NLRI Attribute length 27
47-48 0800 Address Family is IP
49 04 SAFI is RFC3107, label present
50 04 Length in octets of Next Hop
51-54 0A320101 Next hop is 10.50.1.1
55 00 No SNPAs are present
56 38 Length of label/prefix (56 bits)
57-59 CEC001 Label CEC00 (Bottom-of-stack)
60-63 0A3C0101 IP network 10.60.1.1/32
64 48 Length of label/prefix (72 bits)
65-67 473200 Label 47320
68-70 473211 Label 47321 (Bottom-of-stack)
71-73 0A4601 IP network 10.70.1.0/24
Unlabeled routes are contained in the normal Update NLRI field:
74 18 Length of 1st NLRI (24 bits)
75-77 0A5001 Prefix 10.80.1/24
78 14 Length of last NLRI (20 bits)
79-81 0A2810 Prefix 10.40.16/20
Mroz, et al. [Page 16]
Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt February 2002
Some notes on the Example Update message:
1. Four address prefixes are present, two with labels, and two
without. No withdrawn routes are present, and for simplicity,
a minimal set of attributes is present. IP addresses were
selected from the private address space for the example.
2. There is a two-deep label stack associated to the prefix
10.70.1.0/24. The reason for this is beyond the scope of this
document. However, an implementation that normally associates
only a single label to a prefix and which is to become the
Next Hop for the advertised route could assign and distribute
a single label, and arrange to swap this label for the two
label stack.
3. The "labeled /32 IPv4 route to 10.60.1.1" could be a route to
get to PE1 in Figure A.1. The Update message could be one
sent from ASBR31 to ASBR32 via IBGP as described in bullet 5
of Appendix A.
Mroz, et al. [Page 17]