idnits 2.17.1 draft-hu-nvo3-vxlan-gpe-extension-for-vbng-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 13, 2018) is 2141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7348' is defined on line 374, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 nvo3 S. Hu 3 Internet-Draft F. Qin 4 Intended status: Informational Z. Li 5 Expires: December 15, 2018 China Mobile 6 Z. Wang 7 Huawei 8 T. Ao 9 ZTE 10 June 13, 2018 12 VXLAN GPE Extension for Packets Exchange Between Control and User Plane 13 of vBNG 14 draft-hu-nvo3-vxlan-gpe-extension-for-vbng-00 16 Abstract 18 This document briefly describes the architecture of control plane and 19 user plane separated vBNG and define the extension of VXLAN-GPE for 20 PPPoE/IPoE dialup packets exchange between control plane and user 21 plane. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 15, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 2 59 3. CU separated BNG Requirements . . . . . . . . . . . . . . . . 2 60 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. vBNG service header . . . . . . . . . . . . . . . . . . . 4 62 4.2. Optional solution for vBNG service header . . . . . . . . 5 63 4.3. Inner packets encapsulation and decapsulation . . . . . . 6 64 4.4. User dialup process . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 For migration of vBNG, one way is separating the control plane(CP) 73 and user plane(UP) of traditional BNG. CP is deployed in centrolized 74 cloud DC and UP is fulfilled by high performance hardware device, 75 e.g. router, switch, etc. VXLAN-GPE is used to transfer PPPoE/IPoE 76 dialup packets between CP and UP. This document describes how to 77 extend VXLAN-GPE to carry necessary information of access user in 78 VXLAN packets. 80 2. Terminology and Abbreviations 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 BNG: Broadband Network Gateway. It is usually the layer 3 edge node 87 of ISP's core network and provides users access control for broadband 88 service. It's also known as BRAS(Broadband Remote Access Server) or 89 BAS(Broadband Access Server). 91 3. CU separated BNG Requirements 93 The architecture of C/U separated BNG is shown as the following 94 figure. 96 +----------------------------------+ 97 | BNG-CP | 98 +--+--------------+--------------+-+ 99 | | | 100 Service | Control | Management| 101 Interface | Interface | Interface | 102 | | | | | | 103 VXLAN-GPE | CUSP | NETCONF | 104 | | | 105 +--+--------------+--------------+-+ 106 | BNG-UPs | 107 +-----------------+----------------+ 108 | 109 | 110 +--------+--------+ 111 | Access Network | 112 +--------+--------+ 113 | 114 +----+----+ 115 | User | 116 +---------+ 118 In this architecture, CP is responsible for user access 119 authentication and setting forwarding entries of UP if authentication 120 is successful. UP need to relay PPPoE/IPoE dialup packets between 121 users and CP and forward PPPoE/IPoE data packets to Internet based on 122 the forwarding entries set by CP. CP should do some basic 123 configurations on UP, e.g. user profile configuration. 125 There are three interfaces between CP and UP. Management interface 126 is used by CP to carry out basic configurations of UP through 127 NETCONF. Control interface is used for seting forwarding entries on 128 UP through OpenFlow. Service interface is used to transmitting 129 PPPoE/IPoE dialup packets between user plane and control plane. 130 VXLAN-GPE is chosen for service interface since it's a relatively 131 mature technology and can carry L2 packets through L3 network. For 132 user access authentication, CP need to know which port of UP the user 133 is connected to for the authentication of access location because a 134 specfic user is only permitted to access on specific port/location. 135 The necessary information include: node ID, slot ID, subcard ID, port 136 ID and so on. The access port information should be carried in VXLAN 137 packets encapsulated by UP. The next section describes how to extend 138 VXLAN-GPE this requirement. 140 4. Mechanism 142 In order to extend VXLAN-GPE for carrying user access port 143 information, a new next protocol value will be requested from IANA 144 based on Generic Protocol Extension for VXLAN [I-D.ietf-nvo3-vxlan- 145 gpe], see section IANA Considerations. The new next protocol is 146 called vBNG service header. 148 4.1. vBNG service header 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |R|R|R|F|R|R|Ver| Next Protocol | Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Node ID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Slot ID | Subcard ID | Port ID | Port Type | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 2: vBNG service header 162 Flag (8 bits): The first 8 bits are the flag field. "R" bits are 163 reserved bits which MUST be set to zero and ignored. 165 F (1 bit): The F bit is set to indicated the inner packet following 166 the vBNG service header SHOULD be forwarded based on the routing 167 table by UP instead of forwarded to users. F bit is set only in the 168 packets from CP to UP for some specific scenarios, e.g. DHCP relay, 169 L2TP. 171 Ver (2 bits): Version of vBNG service header. In this document the 172 version is 0. 174 Next protocol (8 bit): This field indicates the protocol immediatly 175 following the vBNG service header. This doocument defines two next 176 protocol value, 0x00 for PPPoE and 0x01 for IPoE. 178 Node ID (32 bit): This field indicates which UP node is processing 179 the user access. It COULD be one of the UP's IP addresses which MUST 180 be unique in all related UPs. 182 Slot ID (8 bit): This field indicates which slot of the indicated UP 183 is processing the user access. If there is no different slots on the 184 indicated UP this field MUST be set to 0x00. 186 Subcard ID (8 bit): This field indicates which subcard of the 187 indicated slot is processing the user access. If there is no 188 different subcards on the indicated slot this field MUST be set to 189 0x00. 191 Port ID (8 bit): This field indicates which port of the indicated 192 subcard is processing the user access. 194 Port Type (8 bit): This field indicates the type of the user access 195 port. This document defines the following types: 197 +-------------------+----------+ 198 | Port Type | Value | 199 +-------------------+----------+ 200 | GE | 0x01 | 201 +-------------------+----------+ 202 | 10GE | 0x02 | 203 +-------------------+----------+ 204 | 40GE | 0x03 | 205 +-------------------+----------+ 206 | 100GE | 0x04 | 207 +-------------------+----------+ 208 | LAG | 0x05 | 209 +-------------------+----------+ 210 | Virtual Interface | 0x06 | 211 +-------------------+----------+ 213 Figure 3: vBNG service header 215 4.2. Optional solution for vBNG service header 217 One optional solution is using ifIndex to indicate the port 218 information. 220 The ifIndex of the interface MAY be included. This is the 32-bit 221 ifIndex assigned to the interface by the device as specified by the 222 Interfaces Group MIB [RFC2863]. 224 The ifIndex can be utilized within a management domain to map to an 225 actual interface, but it is also valuable in public applications. 226 The ifIndex can be used as an opaque token to discern which interface 227 of UP is processing the user access. And based on this index, the 228 information binding with the interface of UP, such as the Slot ID, 229 subcard ID, Port ID, etc, can be retrieved by the CP. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |R|R|R|F|R|R|Ver| Next Protocol | Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Node ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | IfIndex | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 4: Optional vBNG service header 243 IfIndex (32 bit): This field indicates which interface of UP is 244 processing the user access. And based on this index, the information 245 which binding with the interface of UP, such as the Slot ID, subcard 246 ID, Port ID, etc, can be retrieved by the CP. 248 4.3. Inner packets encapsulation and decapsulation 250 Following the vBNG service header it's the original PPPoE/IPoE dialup 251 packet which SHOULD includes MAC, C-VLAN, S-VLAN, PPPoE/IPoE header, 252 PPPoE/IPoE payload and so on. UP SHOULD NOT modify the original 253 PPPoE/IPoE dialup packets when encapsulating them into VXLAN-GPE 254 packets or decapsulating them from VXLAN-GPE packets. 256 4.4. User dialup process 258 When UP receives PPPoE/IPoE dialup packets from users, it 259 encapsulates the original dialup packets in VXLAN-GPE with the user 260 access port information and sends to CP. CP decapsulates VXLAN-GPE 261 packets and processes PPPoE/IPoE related things, including AAA 262 authentication and addresses allocation. CP encapsulates the PPPoE/ 263 IPoE response packets in VXLAN-GPE and sends to UP. UP decapsulates 264 VXLAN-GPE packets and sends PPPoE/IPoE response packets to users. 265 The following two diagrams show the PPPoE and IPoE process by UP and 266 CP. 268 +----+ +---+ +---+ +------+ 269 |User| |UP | |CP | |Radius| 270 +-+--+ +-+-+ +-+-+ +---+--+ 271 | | PPPoE PADI | | 272 | PPPoE PADI | in VXLAN-GPE | | 273 |------------------->|------------------->| | 274 | | PPPoE PADO | | 275 | PPPoE PADO | in VXLAN-GPE | | 276 |<-------------------|<-------------------| | 277 | | PPPoE PADR | | 278 | PPPoE PADR | in VXLAN-GPE | | 279 |------------------->|------------------->| | 280 | | PPPoE PADS | | 281 | PPPoE PADS | in VXLAN-GPE | | 282 |<-------------------|<-------------------| | 283 | | CHAP_Challenge | | 284 | CHAP_Challenge | in VXLAN-GPE | | 285 |<-------------------|<-------------------| | 286 | | CHAP_Response | | 287 | CHAP_Response | in VXLAN-GPE | | 288 |------------------->|------------------->| | 289 | | | Access-request | 290 | | |----------------->| 291 | | | Access-accept | 292 | | |<-----------------| 293 | | CHAP_Success | | 294 | CHAP_Success | in VXLAN-GPE | | 295 |<-------------------|<-------------------| | 296 | | IPCP | | 297 | IPCP | in VXLAN-GPE | | 298 |<==================>|<==================>| | 299 | | Set Forwarding | | 300 | | Entries on UP | | 301 | |<-------------------| | 302 | | 303 | User Data in PPPoE | User Data +--------------------+ 304 |<==================>|<==============>| Internet | 305 | | +--------------------+ 307 Figure 5: PPPoE Process 309 +----+ +---+ +---+ +------+ 310 |User| |UP | |CP | |Radius| 311 +-+--+ +-+-+ +-+-+ +---+--+ 312 | | DHCP Discovery | | 313 | DHCP Discovery | in VXLAN-GPE | | 314 |------------------->|------------------->| | 315 | | | Access-request | 316 | | |----------------->| 317 | | | Access-accept | 318 | | |<-----------------| 319 | | DHCP Offer | | 320 | DHCP Offer | in VXLAN-GPE | | 321 |<-------------------|<-------------------| | 322 | | DHCP Request | | 323 | DHCP Request | in VXLAN-GPE | | 324 |------------------->|------------------->| | 325 | | DHCP ACK | | 326 | DHCP ACK | in VXLAN-GPE | | 327 |<-------------------|<-------------------| | 328 | | Set Forwarding | | 329 | | Entries on UP | | 330 | |<-------------------| | 331 | | 332 | User Data in IPoE | User Data +--------------------+ 333 |<==================>|<==============>| Internet | 334 | | +--------------------+ 336 Figure 6: IPoE Process 338 5. Security Considerations 340 This document only defines new "Next Protocol" for C/U seperated 341 vBNG. So, this document itself does not directly introduce more 342 security issues. The same security considerations as Generic 343 Protocol Extension for VXLAN [I-D.ietf-nvo3-vxlan-gpe]. 345 6. IANA Considerations 347 IANA is requested to assign a new next protocol value in VXLAN-GPE 348 header as the following: 350 +---------------+---------------------+----------------+ 351 | Next Protocol | Description | Reference | 352 +---------------+---------------------+----------------+ 353 | TBD | vBNG service header | This Document | 354 +---------------+---------------------+----------------+ 356 Figure 7: Requested new next protocol 358 7. Normative References 360 [I-D.ietf-nvo3-vxlan-gpe] 361 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 362 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 363 in progress), April 2018. 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 371 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 372 . 374 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 375 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 376 eXtensible Local Area Network (VXLAN): A Framework for 377 Overlaying Virtualized Layer 2 Networks over Layer 3 378 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 379 . 381 Authors' Addresses 383 Shujun Hu 384 China Mobile 385 32 Xuanwumen West Ave, Xicheng District 386 Beijing, Beijing 100053 387 China 389 Email: hushujun@chinamobile.com 390 Fengwei Qin 391 China Mobile 392 32 Xuanwumen West Ave, Xicheng District 393 Beijing, Beijing 100053 394 China 396 Email: qinfengwei@chinamobile.com 398 Zhenqiang Li 399 China Mobile 400 32 Xuanwumen West Ave, Xicheng District 401 Beijing, Beijing 100053 402 China 404 Email: lizhenqiang@chinamobile.com 406 Zitao Wang 407 Huawei 408 101 Software Avenue, Yuhua District 409 Nanjing, Jiangsu 210012 410 China 412 Email: wangzitao@huawei.com 414 Ting Ao 415 ZTE