idnits 2.17.00 (12 Aug 2021) /tmp/idnits64256/draft-ietf-ppvpn-hiervpn-corevpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 73 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 21 has weird spacing: '...d is in full ...' == Line 22 has weird spacing: '... all provis...' == Line 23 has weird spacing: '...), its areas...' == Line 24 has weird spacing: '... and its w...' == Line 28 has weird spacing: '... and may be...' == (68 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Callon' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'Fox' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'Rosen2' is defined on line 301, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Callon' -- Possible downref: Non-RFC (?) normative reference: ref. 'Rosen2' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Chandrasekar Kathirvelu 3 INTERNET-DRAFT Karthik Muthukrishnan 4 Tom Walsh 5 Expires January 2002 Lucent Technologies 7 Andrew Malis 8 Vivace Networks, Inc. 10 Fred Ammann 11 COMMCARE telecommunications 13 July 2001 15 Hierarchical VPN over MPLS Transport 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are Working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 34 Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This memo presents an approach for building hierarchical Virtual 40 Private Network (VPN) services. This approach uses Multiprotocol 41 Label Switching (MPLS). The central vision is for the service 42 provider to provide a virtual router service to other SPs without 43 participating in VPNs of those SPs. 45 1.0. Acronyms 46 ARP Address Resolution Protocol 47 CE Customer Edge router 48 LSP Label Switched Path 49 PNA Private Network Administrator 50 SLA Service Level Agreement 51 SP Service Provider 52 PE Service Provider Edge Device 53 SPNA SP Network Administrator 54 VPNID VPN Identifier 55 VR Virtual Router 56 VRL Virtual Router Link 57 VRC Virtual Router Console 58 P Provider Device 60 2. Introduction 62 This draft describes an approach for building Hierarchical IP VPN 63 services out of the backbone of the SP's network. We use the VR 64 model to describe the relationship among the VPNs, and MPLS Label 65 stacking to explain how the data is transported in the 66 hierarchical VPNs.An application of this technique enables the 67 aggregration of many regional or local service Provider VPN 68 networks across a Hierarchical VPN tunneling architecture. 70 The approach presented here does not require modification of any 71 existing routing protocols. 73 3. Hierarchical Relationship between VPNs 75 A simplified example that shows a hierarchical relationship 76 between Virtual Routed VPNs is shown in Figure 1. NOTE: 77 Hierarchies can be extended to more than two levels. 79 Hierarchical levels are designated numerically with the highest 80 level designated as 0. Lower hierarchical levels are designated 81 as Level 1, 2, etc. Higher level VPNs transport lower level VPNs. 82 So: 84 - LEVEL 0 represents the highest hierarchical level. A Level 0 85 VPN transports lower level VPNs but is not itself transported by 86 any other VPN; 88 - LEVEL 1 represents a VPN that is transported by a LEVEL 0 VPN 89 but is not itself transported across any lower or equal level VPN. 91 Level 1 VPNs | Level 0 VPN | Level 1 VPNs 92 | | 93 VPN x | | VPN x 94 ------------| |------------- 95 VPN y | VPN A | VPN y 96 ------------|======================|------------- 97 VPN z | | VPN z 98 ------------| |-------------- 99 | | 101 Figure 1. Hierarchical VPN Levels. 103 By assigning the VPNs depicted in this figure to different hierarchical 104 levels, a hierarchical relationship between the VPNs is created. For 105 example, the highest hierarchical level is designated as "Level 0". In 106 this example, VPN A is a level 0 VPN. Similarly, VPNs' X, Y and Z are 107 part of the next lowest hierarchical level, designated "Level 1". Data 108 within a Level 1 VPN is transported transparently across the Level 0 109 VPN. 111 A possible realization of a Hierarchical VPN (similar to that depicted 112 in Figure 1) can now be described using the VR model. This realization 113 does not assume a single Service Provider only is involved. 114 Specificically, in the examples which follow, SP1 and SP2 do not have to 115 be the same Service Provider. MPLS Label stacking techniques are used 116 to create the hierarchical levels and explain how the data is 117 transported. 119 Figure 2. shows an example of a Hierarchical VPN involving two Service 120 Providers. This example assumes that SP1 provides an international 121 backbone network that is utilized by SP2 to connect its geographically 122 isolated regional (or local) networks. In this example, SP2 is 123 providing two customer VPNs, X and Y. A two level Hierarchical VPN is 124 created to allow VPN X and VPN Y (i.e., level 1 VPNs in this hierarchy) 125 to be transported (at level 0) across VPN A. 127 +-+ 128 +---| | VPN x 129 +-+ VPN x | +-+ 130 | | ( ) A ( ) +-+ 131 +-+-- ( ) ( )-----(SP2)---| | 132 ( ) A ( ) (G) +-+ VPN y 133 ( SP2 )-----( SP1 ) 134 ( B ) ( ) A ( ) +-+ 135 ( ) ( )------(SP2)---| | VPN y 136 +-+ | ( ) (F) +-+ 137 | |-------+ | +-+ 138 +-+ VPN y +--------------| | VPN x 139 +-+ 141 Figure 2 Hierarchical VPN 143 Figure 3 expands the diagram to show the relationship between SP2 and 144 SP1. From this Figure 3. we can see that SP2 provides both end customer 145 VPNs (i.e., VPN x and VPN y) and SP2 must also know about the backbone 146 (i.e., VPN A) that it uses for transporting the hierarchy. On the other 147 hand, SP1 needs to be concerned with just the Level 0 VPN A. 149 VPN x 150 +---+ VRL ( VPN x=>VPN A) 151 ---| |-----------+ 152 | | | 153 +---+ +-+--+ 154 | |==========> SP1 PE (B) 155 | | VPN A 156 +---+ +-+--+ 157 | | | 158 ----| |-----------+ 159 +---+ VRL ( VPN y=>VPN A) 160 VPN y 162 Figure 3 Hierarchical Relationship of a VRL 164 Figure 3. also shows a relationship between a level 1 VPN (e.g., VPN X) 165 and a level 0 VPN (e.g., VPN A). A Virtual Router Link (VRL) is used 166 between the Level 1 and Level 0 VPNs. The VRL is explained in more 167 detail in the next section. In Figure 3. the hierarchical relationship 168 is shown by the directional arrow indication (i.e., VPN X => VPN A). 169 The lower level VPN X has an arrow pointing to the higher level VPN A, 170 as indicated by VPN X => VPN A. 172 4. Virtual Router Link 174 A VR can be connected to other VRs by a Virtual Router Link (VRL). Each 175 end of VRL is logically bound to a VR. From the perspective of the VR, 176 the VRL looks like one of its many links, some of which could be 177 physical links. The user can define a set of rules on this VRL to 178 control the relationship between two VPNs. This relationship could 179 be hierarchical or peering. 181 In the case of hierarchical VPNs, VRLs are configured between VRs with 182 one end as the upper end of the hierarchy and the other as the lower 183 end. 185 NOTE: investigation into whether VRLs can be extended to cover point- 186 to-point connections between VRs for control information exchange is for 187 further study. 189 5. Label Distribution 191 VPNs can use any label distribution protocol. The only restriction is, 192 within a specific VPN, the same protocol should be used in all its PE 193 devices, so that they can interwork. This is restricted by the nature of 194 the distribution protocol not by the VPNs. 196 Referring to Figure 2, SP1 provides the Level 0 VPN service (called VPN 197 A) to SP2(B/G/F). The label distribution operates independently in each 198 level of the VPN Hierarchy. Labels are distributed for the Level 0 VPN 199 separately from the labels that are distributed for the Level 1 VPN. 200 The following text describes the label distribution for each level of 201 the hierarchical VPN. 203 Level 0 (VPN A) Label Distribution: 205 The PEs of SP1 share the VPN A routing information between each other. 206 In other words, the reachability information of SP2 edge routers is 207 exchanged. LSP tunnels are set up in VPN A between the edge routers of 208 SP2. For example, an LSP tunnel from SP2 (edge router B) is created to 209 SP2 (edge router G). 211 Level 1 (VPN X) Label Distribution: 213 The PEs of SP2 share the VPN x routing information with each other. In 214 other words, the reachability information of the CE routers of VPN x is 215 exchanged. LSP tunnels are set up in VPN X between the CE routers in 216 SP2. 218 Usage of Penultimate Hop Popping (PHP) requires penultimate and top-most 219 labels to be allocated from the same label space (e.g., in this case the 220 allocation is from VPN A's label space). This implies in the case of 221 Hierarchical VPNs, that an additional label (i.e., the penultimate 222 label) will be necessary between the IGP label (i.e., top-most label) 223 for the PE and VPN destination label. This is shown in the next section 224 on Forwarding. 226 In this example, it is indicated that A2 is the label for SP2-CE(G) in 227 SP2-CE(B) and it is shown in the Forwarding section (Section 6.) how A2 228 is used. (see Figure 4.). This label is chosen from the VPN A Label 229 space. 231 Architecturally, Level 1 VPN Y and Y are connected to Level 0 VPN A by 232 a Virtual Router Link. Note that the edge routers of SP2 must have 233 knowledge of all three VPNs (i.e., VPN X, VPN Y, and VPN A). When the 234 VRL is configured for a hierarchical relationship , then the top 235 level VPN will allocate a label for each VRL, i.e., to each VPNs, from 236 its label space. 238 6. Forwarding 240 User data from the lower level VPNs (e.g. Level 1 in Figure 4) are 241 forwarded by the LSP tunnels of the upper level VPN (e.g. Level 0 in 242 Figure 4). The label encoding shown in Figure 4. is explained below. 244 VPN x/y/z Data 245 +-----+ +----+----+ 246 |Data | | Lx2|Data| 247 +-----+ +----+----+ 249 +----+----+-----+ 250 | Ax2|Lx2 | Data| 251 +----+----+-----+ 252 +----+----+-----+-----+ 253 | A2 |Ax2 | Lx2 |Data | 254 +----+----+-----+-----+ 256 Figure 4 Label Encoding 258 1. Customer data arrives at the VPN X CE router in SP2 (B) and is 259 encapsulated in a MPLS frame. 261 2. Label Lx2 is pushed on to the Label Stack. Lx2 is the peer VPN x CE 262 label used to forward VPN X data to VPN X CE router in SP2 (G). 264 3. Next Label Ax2 is pushed on to the Label Stack. Ax2 is the peer VPN 265 X attachment label with VPN A taken from VPN A's label space. This 266 label is used by VPN A to forward data on the SP2 (G) VRL between VPN A 267 and VPN X. 269 4. Finally Label A2 is pushed on to the Label Stack. This is the peer 270 VPN A label used to forward data from the VPN A SP2 (B) PE router to the 271 VPN A SP2 (G) PE router. 273 In summary, the complete LSP path therefore to move customer data on VPN 274 X from the SP2 (B) CE to the SP2 (G) CE is as follows: a) Transport 275 data across Level 0 (VPN A) using label A2; b) Transport data across the 276 VRL from Level 0 to Level 1 in SP2 (G) using label Ax2 c) Transport data 277 across Level 1 (VPN x) from SP2 (B) to SP2(G) using label Lx2 279 7. Security Considerations 281 Security as available in MPLS networks will be available and extended to 282 hierarchical VPNs. 284 8. Intellectual Property Considerations 286 Lucent technologies may seek patent or other intellectual property 287 protection for some of all of the technologies disclosed in this 288 document. If any standards arising from this document are or become 289 protected by one or more patents assigned to Lucent Technologies. Lucent 290 Technologies intends to disclose those patents and license them on 291 reasonable and non-discriminatory terms. 293 9. References 295 [Callon] Callon R., et al., "A Framework for Multiprotocol Label 296 Switching", work in Progress 298 [Fox] Fox, B. and B. Gleeson,"Virtual Private Networks 299 Identifier", RFC 2685, September 1999. 301 [Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol 302 Label Switching Architecture", work in progress 304 [muthuk] K.Muthukrishnan, A.Malis "A Core MPLS IP VPN Architecture", 305 RFC 2917 September 2000. 307 10. Authors' Addresses 309 Karthik Muthukrishnan 310 Lucent Technologies 311 1 Robbins Road 312 Westford, MA 01886 313 Phone: (978) 952-1368 314 EMail: mkarthik@lucent.com 316 Andrew Malis 317 Vivace Networks, Inc. 318 2730 Orchard Parkway 319 San Jose, CA 95134 320 Phone: (408) 383-7223 321 EMail: Andy.Malis@vivacenetworks.com 323 Chandrasekar Kathirvelu 324 Lucent Technologies 325 1 Robbins Road 326 Westford, MA 01886 327 Phone: (978) 952-7116 328 EMail: ck32@lucent.com 330 Tom Walsh 331 Lucent Technologies 332 10 Lyberty Way 333 Westford, MA 01886 334 Phone: (978) 392-2311 335 EMail: tdwalsh@lucent.com 336 Fred Ammann 337 COMMCARE Telecommunications 338 Turmstrasse 8 339 CH-8952 Schlieren 340 Switzerland 341 Phone: +41 1 738 61 11 342 Email: fa@commcare.ch 344 11. Full Copyright Statement 346 Copyright (C) The Internet Society (2001). All Rights Reserved. 348 This document and translations of it may be copied and furnished to 349 others, and derivative works that comment on or otherwise explain it 350 or assist in its implementation may be prepared, copied, published 351 and distributed, in whole or in part, without restriction of any 352 kind, provided that the above copyright notice and this paragraph are 353 included on all such copies and derivative works. However, this 354 document itself may not be modified in any way, such as by removing 355 the copyright notice or references to the Internet Society or other 356 Internet organizations, except as needed for the purpose of 357 developing Internet standards in which case the procedures for 358 copyrights defined in the Internet Standards process must be 359 followed, or as required to translate it into languages other than 360 English. 362 The limited permissions granted above are perpetual and will not be 363 revoked by the Internet Society or its successors or assigns. 365 This document and the information contained herein is provided on an 366 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 367 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 368 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 369 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 370 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Acknowledgement 374 Funding for the RFC Editor function is currently provided by the 375 Internet Society.