idnits 2.17.00 (12 Aug 2021) /tmp/idnits4876/draft-vasavada-ppvpn-es-l3vpn-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2547bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (July 2001) is 7615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '6' on line 43 ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'ES' -- Possible downref: Normative reference to a draft: ref. 'L2TPES' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nishit Vasavada 2 INTERNET DRAFT Amber Networks, Inc. 4 July 2001 6 Layer 3 VPNs using Encapsulation Services Protocol 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 [RFC2547bis] defines a way to implement Layer 3 VPNs using BGP and 33 MPLS. [GRE_IP_MPLS] shows a method to implement RFC 2547 style VPNs 34 across a non-MPLS network. This document shows an alternative way 35 of implementing Layer 3 VPNs in a non-MPLS network. Unlike 36 [RFC2547bis], it does not require BGP either to be running on the PE. 38 3. Specification of Requirements 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [6]. 44 4. Introduction 46 [RFC2547bis] discusses in great detail the motivation and 47 requirements for a Layer 3 Virtual Private Network (VPN). The goal 48 of this document is to accomplish the same as that of [RFC2547bis], 49 and therefore the common details are not repeated here. 51 [RFC2547bis] requires that the Service Provider(SP)'s network be 52 MPLS-enabled. This means all the routers in the SP's core network 53 MUST be able to support MPLS. [RFC2547bis] uses BGP for route 54 distribution, which requires BGP to be running in the SP's core 55 network at least with an overlay topology. While this may be the 56 case in fair number of networks, a technology not requiring to run 57 BGP for route distribution may be more suitable for networks not 58 running BGP. 60 [ES] defines a generic protocol to emulate and encapsulate Layer 1 61 and Layer 2 circuits over a core network. We extend [ES] to carry 62 VPN Discovery Protocol (VDP) and Route Distribution Protocol (RDP). 63 VDP is an auto-discovery mechanism for discovering other Provider 64 Edge (PE) routers which are connected to a site belonging to a VPN 65 that has a site connected to the PE router running VDP. RDP is an 66 extensible mechanism to distribute route information for each VPN 67 to all other PEs with sites belonging to that specific VPN. 69 A special ES tunnel is set up between two PEs to carry L3 VPN 70 traffic. It carries control and data traffic for all VPNs which are 71 common to the two PEs. Inside each tunnel, each ES session 72 represents a specific VPN. 74 -------- -------- 75 | | ES/L2TP Tunnel | | 76 | |_______________________________________________| | 77 | | | | 78 | | Control Channel: VDP | | 79 | |<--------------------------------------------->| | 80 | | | | 81 | | Session 1: VPN A: RDP + data | | 82 | PE 1 |<--------------------------------------------->| PE 2 | 83 | | : | | 84 | | : | | 85 | | : | | 86 | | Session n: VPN N: RDP + data | | 87 | |<--------------------------------------------->| | 88 | | | | 89 | |_______________________________________________| | 90 | | | | 91 -------- -------- 93 Figure 1. Two PEs running ES based L3 VPNs 95 The ES tunnel is set up by following the process outlined in [ES]. 96 The access link type is "L3VPN". Service attributes are chosen 97 according to the tunnel guiding parameters - e.g. it may indicate 98 the remote PE. The service type capability negotiated is ES, again 99 as specified in [ES]. Session 0 is reserved for carrying VDP 100 traffic and will be referred to as control session in rest of the 101 document. The control session is set up as soon as the tunnel comes 102 up. The numerically lower IP address initiates and numerically 103 higher IP address passively awaits for the session. VPN related 104 route information (through RDP) and data traffic is carried in 105 individual sessions - one session per VPN. Thus, one session of VPD 106 runs once per pair of PE (one per tunnel), while one session of RDP 107 runs once per VPN per tunnel. 109 The sessions map VPNs to ES tunnel/session with the use of VPN-IDs. 110 Each VPN is assigned an 8-byte ID known as VPN-ID. The VPN-ID is 111 passed to the remote PE during L2TP session set up through the 112 end-identifier AVP specified in [L2TPES]. VPN-ID with all zeros is 113 reserved, while all 1's is used for the control session. Rest of 114 the sessions carry a specific VPN-ID during session set-up, and all 115 the traffic through that session is mapped to the VPN represented 116 by that VPN-ID. 118 5. VPN Discovery Protocol (VDP) 119 The aim of VPN Discovery Protocol is to dynamically determine VPN 120 membership at the remote end of IP-VPN tunnels. The protocol 121 communicates with its remote peer using the VPN control session (a 122 special session) inside a VPN tunnel. 124 The protocol is a simple, reasonably state-less Query-Response 125 based protocol. It makes the following assumptions: 127 - It runs over an unreliable transport (an ES/L2TP session in this 128 case). 129 - Fragmentation of protocol PDUs are handled at underlying IP layer 130 - L2TP signaling is asymmetric in nature. VPN Discovery protocol 131 assumes that the PE with numerically lower IP address will always 132 initiate the establishment of underlying tunnels and sessions. The 133 other end (with numerically higher IP address) will passively wait 134 for the incoming tunnel/session requests. 136 5.1. VDP Operation 138 - The protocol gets triggered as soon as the VPN control session 139 becomes active between two PEs. 140 - For each remote PE, the local PE maintains a state for each 141 configured VPN on the system. The state of the VPN for the remote 142 PE changes through the operation of the VDP (the state transition 143 is described in the next section). 144 - Initially, all the VPNs on all remote PEs are in a "Dirty" state. 145 This state means that the membership information has not been 146 conveyed to the remote PE. 147 - A periodic timer, with a configurable timeout value, is used to 148 send the list of dirty VPNs to the remote PE, as a 149 VPN-Query-Request PDU. 150 - The remote PE, upon receipt of the query request, sends back a 151 VPN-Query-Response indicating against each VPN listed, whether it 152 has been configured on the remote PE end or not. 153 - When the query response comes back to the local PE, each of the VPN 154 contained in the response message go to a "Clean" state (from a 155 previous Dirty state). A Clean state means that its VPN membership 156 has been conveyed to the remote PE. 157 - All the VPNs in the query response, which are not configured on 158 the remote system remain in the clean state, until the VPN 159 membership is removed from the local PE. 160 - For each VPN in the query response which is configured on the 161 remote PE, either a VPN session request is initiated or is 162 passively awaited, depending upon the relative numerical 163 relationship between the IP addresses of the two PEs. 164 - As stated earlier, it is assumed that the underlying transport does 165 not guarantee any reliable delivery. Hence, every time a new query 166 request is sent, a (4-byte) sequence number is incremented and is 167 included in the PDU message. 168 - The receiver end copies the sequence number in the query request to 169 the query response. The sender of the query request does not 170 accept any query response which has a sequence number different 171 from the one that was included in the last query request sent. 172 - A checksum is included to protect the integrity of the PDU. 174 At the end of initial run of VDP, both PEs know whether each of the 175 VPN on the local side has a member VPN site on the remote PE as well. 176 The idea is to have a mechanism where VPN memberships of a specific 177 PE need not be configured at all other PEs in the network. 179 5.2. Message format 181 The VDP message format is as shown below: 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Version | Message Type | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Sequence Number | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | VPN Membership Entries (variable number) 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Checksum | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Version (one byte): Set to 1 198 Message Type (one byte): 199 0 for VDP Request 200 1 for VDP Response 201 Length (two bytes): length of the entire PDU beginning version 202 through the checksum field 203 Sequence Number (four bytes): Starts from 0 and wraps over after 204 reaching the maximum value. The sender of VDP Request MUST 205 increment the number by one every time it sends a new request. 206 The sender of VDP Response MUST copy the Sequence number from the 207 Request it is responding to. 208 VPN Membership Entries (nine bytes per entry): There can be multiple 209 entries in this field. Each entry consists of two parts: 210 - An 8-byte VPN ID 211 - A 1-byte value that shows whether the VPN is present or not: 1 212 denotes Present, 0 denotes Not Present. This field SHOULD be 213 ignored on receiving the Request. The sender of Response MUST 214 set it to proper value based on whether the VPN represented by 215 the corresponding VPN ID is present or not. 216 Checksum (two bytes): This is an IP-style checksum over the VDP 217 message beginning the Version field through the Checksum field. 219 5.3. Example 221 For example, suppose PE1 in Figure 1 has member VPNs A, B, C and D, 222 and PE2 has member VPNs B, D, E and F. The following exchange will 223 take place, assuming PE2 receives PE1's query before it sends its own 224 query: 225 - PE1 sends a request with VPNs A, B, C and D in the VPN 226 Membership Entries. 227 - PE2 sends a response with VPNs A, B, C and D in the VPN 228 Membership Entries. The Present/Not Present field will reflect 229 the membership status of the corresponding VPN at PE2. This means 230 VPNs B and D will be marked Present, while VPNs A and C will be 231 marked as Not Present. The sequence number will be the same as in 232 the request received from PE1. Checksum is recomputed. 233 - PE2 sends a request for VPNs E and F to PE1. 234 - PE1 sends a response showing VPNs E and F Not Present. 235 - PE1 and PE2 have one ES session set up for each of the VPNs B and 236 D. 238 VDP does not retransmit a PDU if no response is received. However, 239 it periodically scans the database for "Dirty" entries, and sends a 240 new VDP Request message if one or more such entries are found. These 241 may be older entries which were never acknowledged through VDP 242 Response by the peer PE, or they may newly configured VPNs since the 243 last scan. 245 If a VPN membership is removed from a PE, the PE tears down the 246 ES/L2TP sessions corresponding to the VPN from each PE which had 247 that VPN as a member. Thus, there is no need for an explicit VDP 248 message for informing VPN membership removal. 250 6. Route Distribution Protocol (RDP) 252 RDP is used to distribute subscriber addresses to other sites in the 253 VPN. RDP is VPN specific, and therefore is carried in the session 254 created for the specific VPN. In the case of ES over L2TP, the 255 RDP for VPN A is sent to PE X via the L2TP tunnel set up with PE X 256 inside the ES/L2TP session set up for VPN A. This is shown in 257 Figure 1. 259 6.1. Message format 261 The RDP message format is as shown below: 263 0 1 2 3 264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Version | Message Type | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sequence Number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Route Entries (variable number) 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Checksum | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Version (one byte): Set to 1 278 Message Type (one byte): 279 0 for Route Advertise 280 1 for Route Advertise Response 281 Length (two bytes): length of the entire PDU beginning version 282 through checksum 283 Sequence Number (four bytes): Starts from 0 and wraps over after 284 reaching the maximum value. The sender of Route Advertise message 285 MUST increment the number by one every time it sends a new 286 message. The sender of Route Advertise Response MUST copy the 287 Sequence number from the Advertise message it is responding to. 288 Route Entries (five bytes per entry): Each route entry is a 3-tuple: 289 - A 32-bit prefix 290 - A 4-bit mask-length, and 291 - A 4-bit field that shows whether the route is being Added 292 or Withdrawn. 0 denotes ### and 1 denotes ### 293 Checksum (two bytes): This is an IP-style checksum over the RDP 294 message beginning the Version field through the Checksum field. 296 6.2. RDP Operation 298 RDP maintains a "dirty" list of routes for each VRF. The list is 299 maintained per peer PE, and tells the local PE that the status of 300 that specific route has not been confirmed by the peer PE. 302 A route is added in the dirty list and put in Dirty/Add state when 303 the route was recently added. The route is sent to the peer PE in 304 an RDP Advertise message with the add/withdraw value set to Add. 305 When the peer PE acknowledges the message after processing the routes 306 in the Advertise message, it includes the route in its Route Entries 307 list. The local PE at this point removes the route from the dirty 308 list. 310 Similarly, when a route is deleted from the VRF for the VPN, it is 311 added to the dirty list and put in Dirty/Withdraw state. It retained 312 in the list till the peer PE acknowledges the Route Advertise message 313 that announced the withdrawal of the route. 315 When a PE receives an RDP Advertise message, it identifies the 316 corresponding VRF by the ES tunnel/session. This ensures that the 317 routes belonging to a specific VPN are injected only into the VRF 318 corresponding to that VPN. This is essential for an L3 VPN, since it 319 allows SP's customers to have overlapping private address space 320 without causing any confusion in the core. 322 Once a VRF is identified by the receiving PE, the routes are added or 323 deleted based on the Add/Withdraw field. When the PE is done 324 processing the Route Advertise message, it sends the packet back to 325 the PE which sent the Route Advertise message. This serves as an 326 acknowledgement of Route Advertise. The Message Type field is set to 327 Route Advertise Response, and the checksum is recomputed. 329 The PE receiving the Route Advertise Response compares the sequence 330 number of the Response message with the last Route Advertise 331 message sent to the peer PE. If the sequence numbers do not match, 332 the Route Advertise Response is silently discarded. If the sequence 333 numbers match, the receiving PE finds all the routes listed in the 334 Route Advertise Response and removes them from the dirty list. 336 7. Data plane operation 338 When L3 VPN data is received from a CE, the VRF is chosen based on 339 the interface. The Destination IP address in the VRF tells the PE 340 the peer PE, as well as the ES tunnel/session corresponding to the 341 peer PE and the VPN. The customer data packet is encapsulated in 342 ES (and the lower transport protocol such as L2TP) and sent to the 343 peer PE. 345 The peer PE identifies the outbound interface based on the ES tunnel/ 346 session information in the packet from the sending PE. The ES 347 encapsulation is removed and the packet is sent out on the outbound 348 interface. 350 8. Interface with ES 352 VDP, RDP and data plane traffic is encapsulated in ES [ES]. If ES 353 runs over L2TP as shown in [ES], all the sessions inside each tunnel 354 between the PEs will need to negotiate ES as the L2TP service type, 355 as defined in [L2TPES]. 357 8. Future Work 359 Modify ES header to accommodate multiple types of traffic inside ES. 360 Assigning unique VPN-ID for inter-SP VPNs. 362 9. Security Considerations 364 All the underlying ES Security considerations remain, though no new 365 ones are introduced. 367 10. IANA Considerations 369 None at present. 371 11. Intellectual Property Considerations 373 Amber Networks may seek patent or other intellectual property 374 protection for some of all of the technologies disclosed in this 375 document. If any standards arising from this document are or become 376 protected by one or more patents assigned to Amber Networks, Amber 377 intends to disclose those patents and license them on reasonable and 378 non-discriminatory terms. 380 12. Acknowledgments 382 Many thanks to Himansu Sahu, Danny McPherson, Stanley Fong and Indira 383 Mitchell for their help in reviewing this draft. 385 13. References 387 [RFC2547bis] Rosen, et. al., "BGP/MPLS VPNs", Work in Progress, 388 February 2001 390 [GRE_IP_MPLS] Rekhter, et. al., "Use of PE-PE GRE or IP in RFC2547 391 VPNs", Work in Progress, June 2001 393 [ES] Vasavada, N., "ESP: Encapsulation Services Protocol", Work in 394 Progress, July 2001 396 [L2TPES] Vasavada N., "Encapsulation Services Protocol Service Type 397 for L2TP", draft-vasavada-l2tpext-es-svctype-00.txt, Work in 398 Progress, July 2001 400 14. Author's Address 402 Nishit Vasavada 403 Amber Networks, Inc. 404 48664 Milmont Drive 405 Fremont, CA 94538 406 Phone: +1 510.687.5200 407 Email: nishit@ambernetworks.com