idnits 2.17.00 (12 Aug 2021) /tmp/idnits18500/draft-kathirvelu-hiervpn-corevpn-01.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 19 has weird spacing: '...d is in full ...' == Line 20 has weird spacing: '... all provis...' == Line 21 has weird spacing: '...), its areas...' == Line 22 has weird spacing: '... and its w...' == Line 26 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 293, but no explicit reference was found in the text == Unused Reference: 'Fox' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'Rosen2' is defined on line 299, 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 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are Working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 32 Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo presents an approach for building hierarchical Virtual 38 Private Network (VPN) services. This approach uses Multiprotocol 39 Label Switching (MPLS). The central vision is for the service 40 provider to provide a virtual router service to other SPs without 41 participating in VPNs of those SPs. 43 1.0. Acronyms 44 ARP Address Resolution Protocol 45 CE Customer Edge router 46 LSP Label Switched Path 47 PNA Private Network Administrator 48 SLA Service Level Agreement 49 SP Service Provider 50 PE Service Provider Edge Device 51 SPNA SP Network Administrator 52 VPNID VPN Identifier 53 VR Virtual Router 54 VRL Virtual Router Link 55 VRC Virtual Router Console 56 P Provider Device 58 2. Introduction 60 This draft describes an approach for building Hierarchical IP VPN 61 services out of the backbone of the SP's network. We use the VR 62 model to describe the relationship among the VPNs, and MPLS Label 63 stacking to explain how the data is transported in the 64 hierarchical VPNs.An application of this technique enables the 65 aggregration of many regional or local service Provider VPN 66 networks across a Hierarchical VPN tunneling architecture. 68 The approach presented here does not require modification of any 69 existing routing protocols. 71 3. Hierarchical Relationship between VPNs 73 A simplified example that shows a hierarchical relationship 74 between Virtual Routed VPNs is shown in Figure 1. NOTE: 75 Hierarchies can be extended to more than two levels. 77 Hierarchical levels are designated numerically with the highest 78 level designated as 0. Lower hierarchical levels are designated 79 as Level 1, 2, etc. Higher level VPNs transport lower level VPNs. 80 So: 82 - LEVEL 0 represents the highest hierarchical level. A Level 0 83 VPN transports lower level VPNs but is not itself transported by 84 any other VPN; 86 - LEVEL 1 represents a VPN that is transported by a LEVEL 0 VPN 87 but is not itself transported across any lower or equal level VPN. 89 Level 1 VPNs | Level 0 VPN | Level 1 VPNs 90 | | 91 VPN x | | VPN x 92 ------------| |------------- 93 VPN y | VPN A | VPN y 94 ------------|======================|------------- 95 VPN z | | VPN z 96 ------------| |-------------- 97 | | 99 Figure 1. Hierarchical VPN Levels. 101 By assigning the VPNs depicted in this figure to different hierarchical 102 levels, a hierarchical relationship between the VPNs is created. For 103 example, the highest hierarchical level is designated as "Level 0". In 104 this example, VPN A is a level 0 VPN. Similarly, VPNs' X, Y and Z are 105 part of the next lowest hierarchical level, designated "Level 1". Data 106 within a Level 1 VPN is transported transparently across the Level 0 107 VPN. 109 A possible realization of a Hierarchical VPN (similar to that depicted 110 in Figure 1) can now be described using the VR model. This realization 111 does not assume a single Service Provider only is involved. 112 Specificically, in the examples which follow, SP1 and SP2 do not have to 113 be the same Service Provider. MPLS Label stacking techniques are used 114 to create the hierarchical levels and explain how the data is 115 transported. 117 Figure 2. shows an example of a Hierarchical VPN involving two Service 118 Providers. This example assumes that SP1 provides an international 119 backbone network that is utilized by SP2 to connect its geographically 120 isolated regional (or local) networks. In this example, SP2 is 121 providing two customer VPNs, X and Y. A two level Hierarchical VPN is 122 created to allow VPN X and VPN Y (i.e., level 1 VPNs in this hierarchy) 123 to be transported (at level 0) across VPN A. 125 +-+ 126 +---| | VPN x 127 +-+ VPN x | +-+ 128 | | ( ) A ( ) +-+ 129 +-+-- ( ) ( )-----(SP2)---| | 130 ( ) A ( ) (G) +-+ VPN y 131 ( SP2 )-----( SP1 ) 132 ( B ) ( ) A ( ) +-+ 133 ( ) ( )------(SP2)---| | VPN y 134 +-+ | ( ) (F) +-+ 135 | |-------+ | +-+ 136 +-+ VPN y +--------------| | VPN x 137 +-+ 139 Figure 2 Hierarchical VPN 141 Figure 3 expands the diagram to show the relationship between SP2 and 142 SP1. From this Figure 3. we can see that SP2 provides both end customer 143 VPNs (i.e., VPN x and VPN y) and SP2 must also know about the backbone 144 (i.e., VPN A) that it uses for transporting the hierarchy. On the other 145 hand, SP1 needs to be concerned with just the Level 0 VPN A. 147 VPN x 148 +---+ VRL ( VPN x=>VPN A) 149 ---| |-----------+ 150 | | | 151 +---+ +-+--+ 152 | |==========> SP1 PE (B) 153 | | VPN A 154 +---+ +-+--+ 155 | | | 156 ----| |-----------+ 157 +---+ VRL ( VPN y=>VPN A) 158 VPN y 160 Figure 3 Hierarchical Relationship of a VRL 162 Figure 3. also shows a relationship between a level 1 VPN (e.g., VPN X) 163 and a level 0 VPN (e.g., VPN A). A Virtual Router Link (VRL) is used 164 between the Level 1 and Level 0 VPNs. The VRL is explained in more 165 detail in the next section. In Figure 3. the hierarchical relationship 166 is shown by the directional arrow indication (i.e., VPN X => VPN A). 167 The lower level VPN X has an arrow pointing to the higher level VPN A, 168 as indicated by VPN X => VPN A. 170 4. Virtual Router Link 172 A VR can be connected to other VRs by a Virtual Router Link (VRL). Each 173 end of VRL is logically bound to a VR. From the perspective of the VR, 174 the VRL looks like one of its many links, some of which could be 175 physical links. The user can define a set of rules on this VRL to 176 control the relationship between two VPNs. This relationship could 177 be hierarchical or peering. 179 In the case of hierarchical VPNs, VRLs are configured between VRs with 180 one end as the upper end of the hierarchy and the other as the lower 181 end. 183 NOTE: investigation into whether VRLs can be extended to cover point- 184 to-point connections between VRs for control information exchange is for 185 further study. 187 5. Label Distribution 189 VPNs can use any label distribution protocol. The only restriction is, 190 within a specific VPN, the same protocol should be used in all its PE 191 devices, so that they can interwork. This is restricted by the nature of 192 the distribution protocol not by the VPNs. 194 Referring to Figure 2, SP1 provides the Level 0 VPN service (called VPN 195 A) to SP2(B/G/F). The label distribution operates independently in each 196 level of the VPN Hierarchy. Labels are distributed for the Level 0 VPN 197 separately from the labels that are distributed for the Level 1 VPN. 198 The following text describes the label distribution for each level of 199 the hierarchical VPN. 201 Level 0 (VPN A) Label Distribution: 203 The PEs of SP1 share the VPN A routing information between each other. 204 In other words, the reachability information of SP2 edge routers is 205 exchanged. LSP tunnels are set up in VPN A between the edge routers of 206 SP2. For example, an LSP tunnel from SP2 (edge router B) is created to 207 SP2 (edge router G). 209 Level 1 (VPN X) Label Distribution: 211 The PEs of SP2 share the VPN x routing information with each other. In 212 other words, the reachability information of the CE routers of VPN x is 213 exchanged. LSP tunnels are set up in VPN X between the CE routers in 214 SP2. 216 Usage of Penultimate Hop Popping (PHP) requires penultimate and top-most 217 labels to be allocated from the same label space (e.g., in this case the 218 allocation is from VPN A's label space). This implies in the case of 219 Hierarchical VPNs, that an additional label (i.e., the penultimate 220 label) will be necessary between the IGP label (i.e., top-most label) 221 for the PE and VPN destination label. This is shown in the next section 222 on Forwarding. 224 In this example, it is indicated that A2 is the label for SP2-CE(G) in 225 SP2-CE(B) and it is shown in the Forwarding section (Section 6.) how A2 226 is used. (see Figure 4.). This label is chosen from the VPN A Label 227 space. 229 Architecturally, Level 1 VPN Y and Y are connected to Level 0 VPN A by 230 a Virtual Router Link. Note that the edge routers of SP2 must have 231 knowledge of all three VPNs (i.e., VPN X, VPN Y, and VPN A). When the 232 VRL is configured for a hierarchical relationship , then the top 233 level VPN will allocate a label for each VRL, i.e., to each VPNs, from 234 its label space. 236 6. Forwarding 238 User data from the lower level VPNs (e.g. Level 1 in Figure 4) are 239 forwarded by the LSP tunnels of the upper level VPN (e.g. Level 0 in 240 Figure 4). The label encoding shown in Figure 4. is explained below. 242 VPN x/y/z Data 243 +-----+ +----+----+ 244 |Data | | Lx2|Data| 245 +-----+ +----+----+ 247 +----+----+-----+ 248 | Ax2|Lx2 | Data| 249 +----+----+-----+ 250 +----+----+-----+-----+ 251 | A2 |Ax2 | Lx2 |Data | 252 +----+----+-----+-----+ 254 Figure 4 Label Encoding 256 1. Customer data arrives at the VPN X CE router in SP2 (B) and is 257 encapsulated in a MPLS frame. 259 2. Label Lx2 is pushed on to the Label Stack. Lx2 is the peer VPN x CE 260 label used to forward VPN X data to VPN X CE router in SP2 (G). 262 3. Next Label Ax2 is pushed on to the Label Stack. Ax2 is the peer VPN 263 X attachment label with VPN A taken from VPN A's label space. This 264 label is used by VPN A to forward data on the SP2 (G) VRL between VPN A 265 and VPN X. 267 4. Finally Label A2 is pushed on to the Label Stack. This is the peer 268 VPN A label used to forward data from the VPN A SP2 (B) PE router to the 269 VPN A SP2 (G) PE router. 271 In summary, the complete LSP path therefore to move customer data on VPN 272 X from the SP2 (B) CE to the SP2 (G) CE is as follows: a) Transport 273 data across Level 0 (VPN A) using label A2; b) Transport data across the 274 VRL from Level 0 to Level 1 in SP2 (G) using label Ax2 c) Transport data 275 across Level 1 (VPN x) from SP2 (B) to SP2(G) using label Lx2 277 7. Security Considerations 279 Security as available in MPLS networks will be available and extended to 280 hierarchical VPNs. 282 8. Intellectual Property Considerations 284 Lucent technologies may seek patent or other intellectual property 285 protection for some of all of the technologies disclosed in this 286 document. If any standards arising from this document are or become 287 protected by one or more patents assigned to Lucent Technologies. Lucent 288 Technologies intends to disclose those patents and license them on 289 reasonable and non-discriminatory terms. 291 9. References 293 [Callon] Callon R., et al., "A Framework for Multiprotocol Label 294 Switching", work in Progress 296 [Fox] Fox, B. and B. Gleeson,"Virtual Private Networks 297 Identifier", RFC 2685, September 1999. 299 [Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol 300 Label Switching Architecture", work in progress 302 [muthuk] K.Muthukrishnan, A.Malis "A Core MPLS IP VPN Architecture", 303 RFC 2917 September 2000. 305 10. Authors' Addresses 307 Karthik Muthukrishnan 308 Lucent Technologies 309 1 Robbins Road 310 Westford, MA 01886 311 Phone: (978) 952-1368 312 EMail: mkarthik@lucent.com 314 Andrew Malis 315 Vivace Networks, Inc. 316 2730 Orchard Parkway 317 San Jose, CA 95134 318 Phone: (408) 383-7223 319 EMail: Andy.Malis@vivacenetworks.com 321 Chandrasekar Kathirvelu 322 Lucent Technologies 323 1 Robbins Road 324 Westford, MA 01886 325 Phone: (978) 952-7116 326 EMail: ck32@lucent.com 328 Tom Walsh 329 Lucent Technologies 330 10 Lyberty Way 331 Westford, MA 01886 332 Phone: (978) 392-2311 333 EMail: tdwalsh@lucent.com 334 Fred Ammann 335 COMMCARE Telecommunications 336 Turmstrasse 8 337 CH-8952 Schlieren 338 Switzerland 339 Phone: +41 1 738 61 11 340 Email: fa@commcare.ch 342 11. Full Copyright Statement 344 Copyright (C) The Internet Society (2001). All Rights Reserved. 346 This document and translations of it may be copied and furnished to 347 others, and derivative works that comment on or otherwise explain it 348 or assist in its implementation may be prepared, copied, published 349 and distributed, in whole or in part, without restriction of any 350 kind, provided that the above copyright notice and this paragraph are 351 included on all such copies and derivative works. However, this 352 document itself may not be modified in any way, such as by removing 353 the copyright notice or references to the Internet Society or other 354 Internet organizations, except as needed for the purpose of 355 developing Internet standards in which case the procedures for 356 copyrights defined in the Internet Standards process must be 357 followed, or as required to translate it into languages other than 358 English. 360 The limited permissions granted above are perpetual and will not be 361 revoked by the Internet Society or its successors or assigns. 363 This document and the information contained herein is provided on an 364 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 365 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 366 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 367 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 368 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 370 Acknowledgement 372 Funding for the RFC Editor function is currently provided by the 373 Internet Society.