L3VPN Working Group Yiqun Cai Internet Draft Eric C. Rosen (Editor) Intended Status: Proposed Standard Rajesh Sharma Expires: August 6, 2012 IJsbrand Wijnands Cisco Systems, Inc. February 6, 2012 MVPN: Extranets, Anycast-Sources, 'Hub & Spoke', with PIM Control Plane draft-rosen-l3vpn-mvpn-extranet-04.txt Abstract This document provides the specification for using the PIM control plane of to provide Multicast Virtual Private Network support for extranets, for anycast sources, and for "hub and spoke" configurations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. Rosen, et al. [Page 1] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 3 3 Extranets using PIM as the MVPN Control Plane ......... 3 3.1 Default PMSI .......................................... 4 3.2 Red method ............................................ 4 3.2.1 Control Plane RPF Check ............................... 5 3.2.2 Data Plane RPF Check .................................. 5 3.3 Blue method ........................................... 5 3.4 Binding Specific Extranet C-Flows to S-PMSIs .......... 6 3.5 Two VRFs on One PE .................................... 7 4 Supporting Anycast Sources with PIM Control Plane ..... 7 5 Hub and Spoke MVPNs ................................... 8 5.1 Unicast Hub and Spoke VPNs ............................ 8 5.2 Multicast Hub and Spoke VPNs .......................... 10 6 IANA Considerations ................................... 13 7 Security Considerations ............................... 13 8 Acknowledgments ....................................... 13 9 Authors' Addresses .................................... 13 10 Normative References .................................. 14 Rosen, et al. [Page 2] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 1. Specification of requirements 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 [RFC2119]. 2. Introduction This document extends the PIM control plane of [MVPN] to provide support for the following features: - MVPN Extranets In an MVPN "extranet", the transmitter of a multicast traffic flow is in a different VPN than the receivers. Additional procedures are defined to determine how the traffic is associated with a particular MI-PMSI [MVPN]or MS-PMSI [MVPN_MSPMSI], and how the RPF checks are done. - Support for Anycast Sources - Support for "Hub and Spoke" VPNs 3. Extranets using PIM as the MVPN Control Plane Suppose there are two VPNs. VPN1 consists of a set of VRFs, each of which has been configured with RT1 as it export and import Route Target. VPN2 consists of a set of VRFs, each of which has been configured with RT2 as it export and import Route Target. For convenience, we will use the term "blue" instead of "RT1" and the term "red" instead of "RT2". Thus we will call VPN1 the "blue VPN" and VPN2 the "red VPN". Similarly, the blue VPN consists of a number of "blue sites" containing "blue systems"; these sites are attached to PEs via VRF interfaces that are associated with "blue VRFs". We want to create an MVPN extranet in which blue receivers can join multicast groups whose sources and/or RPs are red. The first step is to ensure that the blue VRFs (or the subset of blue VRFs whose attached sites are allowed to receive multicasts from red sources) import routes to the red sources. This is done as follows: - The red VRFs are configured so that the subset of red routes that are to be part of the extranet are exported with a seconds RT value (call it RT3), as well as with RT2. For convenience, we will call RT3 "violet". Rosen, et al. [Page 3] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 - The blue VRFs are configured so that they import violet routes as well as blue routes. There are two different methods of providing the extranets, which will shall call the "red method" and the "blue method". (Remember that the red VPN contains the transmitter, and the blue VPN contains the receivers.) This document assumes that in the case of non-SSM extranet multicast groups, the mapping between a group address and an RP is pre-configured in the PEs. This document does not provide support for bidirectional C-trees in extranets. 3.1. Default PMSI Some of the procedures subsequently specified in this section are largely independent of whether PIM is used with (a) an MI-PMSI or (b) with an MS-PMSI that has been bound to the double wildcard. We will use the term "default PMSI" as a general term to mean either (a) or (b), depending upon which technique is actually being used in a given network. 3.2. Red method In the "red method", extranet multicasts are carried by default in the default PMSI of the red VPN, which we will of course call the "red PMSI". To use this method, blue VRFs must be configured to import "red" I-PMSI A-D routes and red S-PMSI A-D routes. If MI-PMSIs are being used, the blue VRFs must immediately join the P-tunnels specified in the red I-PMSI A-D routes. If MS-PMSIs are being used, a blue VRF need not join the MS-PMSI P-tunnel rooted at a particular PE unless a PIM Join needs to be sent to that PE. The PIM C-instance associated with a blue VRF will treat the red and blue default PMSIs as two different PIM interfaces. The blue VRFs must also be configured to "associate" violet unicast routes with the red default PMSI. What this means is that the red default PMSI will be considered to be the RPF interface for the violet unicast routes. The RPF interface for the blue unicast routes remains, as usual, the blue default PMSI. Rosen, et al. [Page 4] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 All that remains to be specified is how the control plane and data plane RPF checks are done. Apart from these MVPN-specific procedures for the RPF check, ordinary PIM procedures are used. 3.2.1. Control Plane RPF Check Suppose a PE receives a PIM Join(S,G) from a CE, over a VRF interface that is associated with a blue VRF. The PE does the RPF check for S by looking up S in the blue VRF. If the route matching S is a blue route (i.e., carries the blue RT but not the violet RT), then a Join is sent over the blue default PMSI. However, if the route matching S is a violet route (i.e., carries the violet RT), a Join is sent over the red default PMSI. If the PE receives a PIM Join(*,G) from a CE, the RPF check is done against the address of the corresponding RP; otherwise the procedure is the same. 3.2.2. Data Plane RPF Check Suppose a red default PMSI has been associated with a blue VRF, as specified above, and an (S,G) multicast data packet is received from the red default PMSI. Then S is looked up in the (blue) VRF. If it matches a violet route, the packet is forwarded normally. However, if it matches a blue route, the packet is discarded as having failed the RPF check. This prevents the blue sites from receiving packets from red transmitters, except in the case where routes to the red receivers have been explicitly imported into the blue VRF. 3.3. Blue method In the "blue method", extranet multicasts are carried by default in the default PMSI of the blue VPN. In the blue method, the red VRFs must be configured to import "blue" I-PMSI and S-PMSI A-D routes. If MI-PMSIs are being used the P-tunnels specified therein must be joined immediately. If MS-PMSIs are being used, the P-tunnels need not be joined unless and until it is necessary to send a PIM Join to the root of the P-tunnel. The PIM C-instance associated with a red VRF will treat the red default PMSI and the blue default PMSI as two different PIM interfaces. Rosen, et al. [Page 5] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 PIM Joins from blue receivers are then received at the red VRF over the blue PMSI, whereas PIM Joins from red receivers are received at the red VRF over the red PMSI. As a result, PIM may add one or the other or both PMSIs to a particular multicast tree's olist. In this method, the blue VRFs are associated with only one default PMSI, so the RPF check for both blue and violet sources (and RPs) always resolves to that PMSI. Hence the special RPF check procedures of the red method are not necessary. However, a PE with a red VRF may need to transmit multicast traffic on more than one MI-PMSI. Note that since the data plane RPF check of section 3.2.2 is not needed, one does not really need a "violet" RT value. Rather, one may simply configure certain routes from the red VRF to be exported with both the red and the blue RTs. 3.4. Binding Specific Extranet C-Flows to S-PMSIs If the procedure of [MVPN] section 7.4.2 is used, the S-PMSI Join message MUST be sent on whatever default PMSI or default PMSIs are used to carry the C-flow identified in the message. If the procedure of [MVPN]section 7.4.1 is used, then procedures differ slightly depending upon whether the red method or the blue method is in use. If the red method is in use, and if a C-flow whose target source is exported from a red VRF is bound to an S-PMSI, then the S-PMSI A-D route that specifies the binding must carry both the red RT and the violet RT. Blue VRFs must be configured to import the violet S-PMSI A-D routes. If the blue method is in use, and if a C-flow whose target source is exported from a red VRF is bound to an S-PMSI, then the S-PMSI A-D route that specifies the binding: - must carry the red RT if the C-flow has any receivers on the red default PMSI, and - must carry the blue RT if the C-flow has any receivers on the blue default PMSI. Rosen, et al. [Page 6] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 3.5. Two VRFs on One PE It is possible that a red VRF and a blue VRF will exist on the same PE. Then by the above procedures, one of these VRFs will need to join a PMSI that it can use for sending control packets to and receiving data packets from the other. However, the protocol used to construct the P-tunnels instantiating the PMSI may not provide a mechanism by which a given PE can join a P-tunnel of which it is the root. In this case, the PE implementation MUST support a local function whereby a given VRF, say VRF1, can "join" a P-tunnel whose root is another VRF, say VRF2, on the same PE. The PE MUST also support a local function whereby packets can be transmitted from one VRF to another just as if the VRFs had been on separate PEs. 4. Supporting Anycast Sources with PIM Control Plane Suppose that some customer site contains router C-R1 and some other customer site in the same VPN contains router C-R2. And that each sends a PIM Join(C-S,C-G) messages towards C-S. Ordinarily, the result will be to create a single C-tree whose root is C-S and whose leaves include C-R1 and C-R2. However, in some deployment scenarios, C-S may be an anycast address that belongs to two or more different sources, say C-S1 and C-S2. Let's suppose that these two sources attach to the VPN backbone through two different PEs, and let's further suppose that C-S1 is "close" to C-R1, and C-S2 is "close" to C-R2. Then even though both C-R1 and C-R2 send Join(S,G) messages, what is really desired is to create two C-trees, one rooted at C-S1 (with C-R1 as a leaf) and one rooted at C-S2 (with C-R2 as a leaf). If the data traffic traveling along both C-trees is carried on a single MI-PMSI, it is important that a (C-S,C-G) data packet is forwarded towards C-R1 only if the packet is actually traveling on the C-tree rooted at C-S1, and not on the C-tree rooted as C-S2. To ensure this, if a particular MVPN is providing anycast service, its PEs MUST use the procedure described in section 9.1.1 of [MVPN], and MUST NOT use the procedures described in sections 9.1.2 and 9.1.3 of [MVPN]. This also enables the use of C-RPs that have anycast addresses. Furthermore, if anycast source support is provided for a particular multicast group C-G, all PEs MUST execute the procedure described in section 4.2.1 of [PIM], and MUST act as if SwitchToSPTDesired(S,G) (defined in [PIM] section 4.2.1) is true when the first (S,G) packet Rosen, et al. [Page 7] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 (from any PE) is received. (This procedure MUST be executed by each PE even if the PE is not the "last hop" of the C-tree.) This will ensure that each PE receives and forwards (C-S,C-G) traffic from the appropriate source C-tree, even if PE has received only Join(C-*,C-G) messages but not Join(C-S,C-G) messages from its directly attached CEs. 5. Hub and Spoke MVPNs The Layer 3 Virtual Private Network (L3VPN) technology of [RFC4364] generally provides an "any-to-any" network service, where any system at one site of a VPN can send traffic to and receive traffic from a system at any other site. Or more precisely, nothing in the procedures governing the distribution of routing information in the VPN prevents any-to-any communication. In some deployments, however, it has been convenient to distinguish between two kinds of VPN site, the "hub site" and the "spoke sites". In this section, we first describe how the "hub and spoke" configuration affects the distribution of unicast routing. We then specify a means of providing multicast VPN service in the hub and spoke configuration. 5.1. Unicast Hub and Spoke VPNs In a unicast hub and spoke VPN: - any system in a hub site can send traffic to and receive traffic from any other system in a hub site; - any system in a hub site can send traffic to and receive traffic from any system in a spoke site; - any system in a spoke site can send traffic to and receive traffic from any system in a hub site; - a system in one spoke site cannot send traffic to and cannot receive traffic from a system in a different spoke site. Using the technology of [RFC4364], it is possible to create this sort of "hub and spoke" VPN by suitable restricting the flow of routing information among the sites. One way to construct a hub and spoke VPN is as follows: Rosen, et al. [Page 8] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 - Within a given VPN, every site is denoted as either a hub site or a spoke site. - On a given PE, every spoke site is attached to a distinct VRF (i.e., all interfaces of that VRF lead to the same spoke site). We will call these "Spoke VRFs". - On a given PE, any number of hub sites can be attached to a single "Hub VRF". - Each Hub VRF is configured with an export-RT that we shall call "Hub_Route", and with a pair of import-RTs, one of which is "Hub_Route", and the other of which we shall call "Spoke_Route". (Of course, each hub and spoke VPN has its unique Hub_Route RT and its unique Spoke_Route RT.) - Each Spoke VRF is configured with export-RT "Spoke_Route" and import-RT "Hub_Route". With this configuration, the Spoke VRFs will contain only routes to systems at hub sites, whereas the Hub VRFs will contain routes to systems at both hub and spoke sites. Even if two spoke sites attach to the same PE, they cannot communicate directly, because they are associated with different VRFs, and their respective VRFs do not import each others' routes. (There are implementation techniques that can eliminate the need to configure a separate VRF for each spoke site on a PE, but these are out of scope of this document.) There are several different variations on this theme. For example, in a particular VPN, spoke-to-spoke communication may be allowed, but only if the spoke-to-spoke traffic first enters a hub site. Some system at the hub site would be responsible for "turning the traffic around", i.e., sending it back to VPN backbone for delivery to the target spoke site. This can be useful if the "turnaround system" at the hub site performs some sort of inspection of the spoke-to-spoke traffic and then applies authorization policies of some sort. To provide this sort of Hub and Spoke VPN: - The total set of routes exported by the Hub VRFs must include routes that "summarize" all the routes exported by the Spoke VRFs. For example, one or more Hub VRFs may export a default route. In the Hub VRFs, each of these summary routes will have one of the VRF interfaces as its next hop interface. - When such a summary route is exported as a VPN-IP route, it MUST be advertised with a label for which the Next Hop Label Forwarding Entry (see section 3.10 of [RFC3031]) specifies on of the VRF interfaces as the next hop interface. Rosen, et al. [Page 9] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 In this scenario, if a PE receives traffic from a spoke site, and the IP destination address of that traffic is a system in another spoke site, the traffic will be tunneled to a PE that attaches to a hub, and then sent over one of the Hub VRF's "VRF interfaces", i.e., sent to a Hub CE router. The Hub PE, when it receives the tunneled packet, does not look up the packet's IP destination address in the Hub VRF, but rather forwards based on the MPLS label. If the Hub CE decides (possibly after inspecting the packet and authorizing the transmission) to "turn the packet around", sending it back to the PE, the PE will look up the IP destination address in the Hub VRF, find that it matches one of the routes imported from a spoke VRF, and tunnel the packet to the PE attaches to the corresponding spoke site. Note that setting up a hub and spoke VPN is just a matter of proper configuration. There are no protocol differences between a Hub and Spoke VPN and any other kind of RFC 4364 VPN. 5.2. Multicast Hub and Spoke VPNs Sometimes it is necessary to support multicast service over a Hub and Spoke VPN. In this scenario, it is generally desired to provide an MVPN service with the following properties: - A receiver at a hub site may receive multicast traffic from a transmitter at a spoke site (including the case where the RP is at a spoke site) - A receiver at a spoke site may receive multicast traffic from a transmitter at a hub site (including the case where the RP is at a hub site) - A receiver at a spoke site must not be allowed to join a shared tree (i.e., a (C-*,C-G) tree whose root (i.e., the RP) is at a different spoke site. - A receiver at a spoke site must not be allowed to receive multicast traffic from a transmitter at a different spoke site, except possibly in the case where the traffic traverses a hub site on its path from one spoke site to the other. This type of MVPN service can be provided by using a variation of the "PIM over MS-PMSI" model described in [MVPN_MSPMSI]. In this model, each PE advertises an MS-PMSI for each VRF. If these advertisements are made using BGP S-PMSI A-D routes, the A-D route originating at a Hub VRF carries the "Hub_Route" RT; an A-D route originating at a spoke VRF carries the "Spoke_Route" RT. That is, the S-PMSI A-D routes originating at a given VRF carry the same RT as the unicast Rosen, et al. [Page 10] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 routes originating at that VRF. To support Hub and Spoke functionality, the MS-PMSIs originating at the spoke VRFs may all specify the same P-tunnel identifier. Similarly, the MS-PMSIs originating at the hub VRFs may all specify the same P-tunnel identifier, but this must be a different P-tunnel identifier than the one specified for the MS-PMSIs originating from the spoke VRFs. In this case, it is convenient to speak of the Hub and Spoke infrastructure as consisting of two MS-PMSIs, a "spoke-rooted" MS-PMSI and a "hub-rooted" MS-PMSI. As discussed in [MVPN_MSPMSI], it is possible to instantiate an MS-PMSI as a set of PIM-SM trees. This means of instantiation can be useful in Hub and Spoke scenarios when GRE/PIM tunneling is used. In this case, for a given VPN, there MAY be a single sparse mode group address associated with the MS-PMSIs rooted at the spoke VRFs, and a second sparse mode group address associated with the MS-PMSIs rooted at the hub VRFs. The result is the creation of two distinct sets of P-tunnels for the VPN, one set used to carry data traffic fromspoke sites to hub sites (and PIM control traffic in the opposite direction), and the other set used to carry data traffic from hub sites to spoke sites (and PIM control traffic in the opposite direction). Suppose that a spoke VRF and a hub VRF are on the same PE, and that an MS-PMSI advertisement exported by one of those VRFs is imported by the other. The PE implementation MUST support a local function whereby the importing VRF can "join" the MS-PMSI exported by the other VRF, and MUST support a local function whereby packets transmitted from one VRF onto the MS-PMSI are received by the other VRF (if and only if the latter VRF has joined the MS-PMSI exported by the former). Since spoke VRFs do not import each others' S-PMSI A-D routes, and do not import each other's unicast routes, and since there is no MI-PMSI, there is no way for a C-Join to be transmitted directly from one spoke VRF to another. If a CE at a spoke site sends a Join(S,G) to its PE, the PE will forward it on the hub-rooted MS-PMSI advertised by the hub site that is the BGP next hop for S; no spoke VRF can receive PIM control packets on that MS-PMSI. In this scheme, each hub VRF joins two MS-PMSIs, the one spoke-rooted MS-PMSI and the hub-rooted MS-PMSI. Normal PIM procedures would see these as two PIM interfaces. If a hub VRF at PE1 receives a Join(S,G) from the hub-rooted MS-PMSI, where S is at a spoke site, normal PIM/MVPN procedures would cause PE1 to send a Join(S,G) over the spoke-rooted PMSI towards a PE that attaches to S's site. If these procedures are followed, a receiver at a spoke site could get Rosen, et al. [Page 11] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 multicast data from a different spoke site; the data would get "turned around" at a PE that attaches to a hub site. Since this violates the requirements as stated above, a PE providing Hub and Spoke MVPN service MUST NOT send a Join message on one MS-PMSI as a result of having received a Join message over another. Note that this does not completely prevent a receiver in a spoke site from being able to receive multicast data from a transmitter in a different spoke site. This can happen in the following situation: - A receiver R1 at a hub site, Site1, joins a (C-*,C-G) tree, - The RP for (C-*,C-G) is at a different hub site, Site2, - A system S1 at a spoke site, Site3, transmits multicast traffic to group C-G. In this situation, the PE attached to Site 2 may need to turn the (S1,G) data around and transmit it on the hub-rooted PMSI, so that R1 can receive it. This also allows spoke sites to receive it. However, turnaround at a PE is never a desirable traffic pattern, and implementations are NOT required to support it. An alternative procedure which enables R1 to receive the (S1,G) traffic is for the PE at Site3 to generate a BGP Source Active A-D route, carrying the "spoke route" RT, when it receives a Join(S1,G) on the spoke-rooted MS-PMSI. This route would be withdrawn when the PE no longer has the corresponding (S1,G) state. The PE attached to Site1 will see this SA route, and if it has (*,G) state, will then generate (S1,G) state and expect to receive (S1,G) traffic from the spoke-rooted MS-PMSI. Another situation in which a receiver in a spoke site may be able to receive multicast data from a transmitter in a different spoke site is the following: - A receiver R1 at a spoke site, Site1, joins a (C-*,C-G) tree, - The RP for (C-*,C-G) is at a hub site - A system S2 at a different spoke site, Site2, transmits multicast traffic to group C-G, - The hub site containing the RP is multiply connected to the SP backbone, - The best path from R1 to the RP enters the RP's hub site via a particular PE-CE link, link1, Rosen, et al. [Page 12] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 - The best path from S2 to the RP enters the RP's hub site via a different PE-CE link, link2. In this case, it is possible for multicast data traffic to travel from S2 to link1 to the RP to link2 to R1. In some situations, a SP and its customer may wish to explicitly set up this scenario in order to allow spoke sites to receive selected multicast traffic from other spoke sites. The procedures described in this section are compatible with the procedures of section 4. 6. IANA Considerations This document does not specify any actions for IANA. 7. Security Considerations There are no additional security considerations beyond those of [MVPN] and [MVPN-BGP]. 8. Acknowledgments The authors wish to thank DP Ayyadevara, Rayen Mohanty, Maria Napierala, and Karthik Subramanian. 9. Authors' Addresses Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ycai@cisco.com Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com Rosen, et al. [Page 13] Internet Draft draft-rosen-l3vpn-mvpn-extranet-04.txt February 2012 Rajesh Sharma Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: rajshr@cisco.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium E-mail: ice@cisco.com 10. Normative References [MVPN_MSPMSI] "MVPN: Optimized Use of PIM via MS-PMSIs", Cai, Rosen, Wijnands, draft-rosen-l3vpn-mvpn-mspmsi-10.txt, February 2012 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakhov Rekhter, draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Fenner, Handley, Holbrook, Kouvelas, RFC 4601, August 2006 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 [RFC3031] "MPLS Architecture", Rosen, Viswanathan, Callon, January 2001 [RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 Rosen, et al. [Page 14]