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 2 Usage of RFC 3107 . . . . . . . . . . . . . . . 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 3 Usage of RFC 2858 . . . . . . . . . . . . . . . 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". 2 Usage of RFC 3107 [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 Usage of RFC 2858 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]