idnits 2.17.1 draft-huang-nvo3-vxlan-gpe-extension-for-vbng-01.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 (October 29, 2017) is 2364 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) == 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-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-vxlan-gpe (ref. 'I-D.ietf-nvo3-vxlan-gpe') ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 L. Huang, Ed. 3 Internet-Draft S. Hu 4 Intended status: Standards Track China Mobile 5 Expires: May 2, 2018 M. Wang 6 Huawei 7 T. Ao 8 ZTE Corporation 9 October 29, 2017 11 VXLAN GPE Extension for Packets Exchange Between Control and User Plane 12 of vBNG 13 draft-huang-nvo3-vxlan-gpe-extension-for-vbng-01 15 Abstract 17 This document briefly describes the architecture of control plane and 18 user plane separated vBNG and define the extension of VXLAN-GPE for 19 PPPoE/IPoE dialup packets exchange between control plane and user 20 plane. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 2, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 2 55 3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. vBNG service header . . . . . . . . . . . . . . . . . . . 4 58 4.2. Optional solution for vBNG service header . . . . . . . . 5 59 4.3. Inner packets encapsulation and decapsulation . . . . . . 6 60 4.4. User dialup process . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 For migration of vBNG, one way is separating the control plane(CP) 69 and user plane(UP) of traditional BNG. CP is deployed in centrolized 70 cloud DC and UP is fulfilled by high performance hardware device, 71 e.g. router, switch, etc. VXLAN-GPE is used to transfer PPPoE/IPoE 72 dialup packets between CP and UP. This document describes how to 73 extend VXLAN-GPE to carry necessary information of access user in 74 VXLAN packets. 76 2. Terminology and Abbreviations 78 BNG: Broadband Network Gateway. It is usually the layer 3 edge node 79 of ISP's core network and provides users access control for broadband 80 service. It's also known as BRAS(Broadband Remote Access Server) or 81 BAS(Broadband Access Server). 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Requirement 89 The architecture of C/U separated BNG is shown as the following 90 figure. 92 +----------------------------------+ 93 | BNG-CP | 94 +--+--------------+--------------+-+ 95 | | | 96 Service | Control | Management| 97 Interface | Interface | Interface | 98 | | | | | | 99 VXLAN-GPE | OpenFlow | NETCONF | 100 | | | 101 +--+--------------+--------------+-+ 102 | BNG-UP | 103 +-----------------+----------------+ 104 | 105 | 106 +--------+--------+ 107 | Access Network | 108 +--------+--------+ 109 | 110 +----+----+ 111 | User | 112 +---------+ 114 Figure 1: Architecture of C/U separated vBNG 116 In this architecture, CP is responsible for user access 117 authentication and setting forwarding entries of UP if authentication 118 is successful. UP need to relay PPPoE/IPoE dialup packets between 119 users and CP and forward PPPoE/IPoE data packets to Internet based on 120 the forwarding entries set by CP. CP should do some basic 121 configurations on UP, e.g. user profile configuration. 123 There are three interfaces between CP and UP. Management interface 124 is used by CP to carry out basic configurations of UP through 125 NETCONF. Control interface is used for seting forwarding entries on 126 UP through OpenFlow. Service interface is used to transmitting 127 PPPoE/IPoE dialup packets between user plane and control plane. 128 VXLAN-GPE is chosen for service interface since it's a relatively 129 mature technology and can carry L2 packets through L3 network. For 130 user access authentication, CP need to know which port of UP the user 131 is connected to for the authentication of access location because a 132 specfic user is only permitted to access on specific port/location. 133 The necessary information include: node ID, slot ID, subcard ID, port 134 ID and so on. The access port information should be carried in VXLAN 135 packets encapsulated by UP. The next section describes how to extend 136 VXLAN-GPE this requirement. 138 4. Mechanism 140 In order to extend VXLAN-GPE for carrying user access port 141 information, a new next protocol value will be requested from IANA 142 based on Generic Protocol Extension for VXLAN 143 [I-D.ietf-nvo3-vxlan-gpe], see section IANA Considerations. The new 144 next protocol is called vBNG service header. 146 4.1. vBNG service header 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |R|R|R|F|R|R|Ver| Next Protocol | Reserved | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Node ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Slot ID | Subcard ID | Port ID | Port Type | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 2: vBNG service header 160 Flag (8 bits): The first 8 bits are the flag field. "R" bits are 161 reserved bits which MUST be set to zero and ignored. 163 F (1 bit): The F bit is set to indicated the inner packet following 164 the vBNG service header SHOULD be forwarded based on the routing 165 table by UP instead of forwarded to users. F bit is set only in the 166 packets from CP to UP for some specific scenarios, e.g. DHCP relay, 167 L2TP. 169 Ver (2 bits): Version of vBNG service header. In this document the 170 version is 0. 172 Next protocol (8 bit): This field indicates the protocol immediatly 173 following the vBNG service header. This doocument defines two next 174 protocol value, 0x00 for PPPoE and 0x01 for IPoE. 176 Node ID (32 bit): This field indicates which UP node is processing 177 the user access. It COULD be one of the UP's IP addresses which MUST 178 be unique in all related UPs. 180 Slot ID (8 bit): This field indicates which slot of the indicated UP 181 is processing the user access. If there is no different slots on the 182 indicated UP this field MUST be set to 0x00. 184 Subcard ID (8 bit): This field indicates which subcard of the 185 indicated slot is processing the user access. If there is no 186 different subcards on the indicated slot this field MUST be set to 187 0x00. 189 Port ID (8 bit): This field indicates which port of the indicated 190 subcard is processing the user access. 192 Port Type (8 bit): This field indicates the type of the user access 193 port. This document defines the following types: 195 +-------------------+----------+ 196 | Port Type | Value | 197 +-------------------+----------+ 198 | GE | 0x01 | 199 +-------------------+----------+ 200 | 10GE | 0x02 | 201 +-------------------+----------+ 202 | 40GE | 0x03 | 203 +-------------------+----------+ 204 | 100GE | 0x04 | 205 +-------------------+----------+ 206 | LAG | 0x05 | 207 +-------------------+----------+ 208 | Virtual Interface | 0x06 | 209 +-------------------+----------+ 211 Figure 3: User Access Port Types 213 4.2. Optional solution for vBNG service header 215 One optional solution is using ifIndex to indicate the port 216 information. 218 The ifIndex of the interface MAY be included. This is the 32-bit 219 ifIndex assigned to the interface by the device as specified by the 220 Interfaces Group MIB [RFC2863]. 222 The ifIndex can be utilized within a management domain to map to an 223 actual interface, but it is also valuable in public applications. 224 The ifIndex can be used as an opaque token to discern which interface 225 of UP is processing the user access. And based on this index, the 226 information binding with the interface of UP, such as the Slot ID, 227 subcard ID, Port ID, etc, can be retrieved by the CP. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |R|R|R|F|R|R|Ver| Next Protocol | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Node ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | IfIndex | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 4: Optional vBNG service header 241 IfIndex (32 bit): This field indicates which interface of UP is 242 processing the user access. And based on this index, the information 243 which binding with the interface of UP, such as the Slot ID, subcard 244 ID, Port ID, etc, can be retrieved by the CP. 246 Other fields have the same definition as the previous section. 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-04 (work 363 in progress), April 2017. 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 Lu Huang (editor) 384 China Mobile 385 32 Xuanwumen West Ave, Xicheng District 386 Beijing 100053 387 China 389 Email: hlisname@yahoo.com 390 Shujun Hu 391 China Mobile 392 32 Xuanwumen West Ave, Xicheng District 393 Beijing 100053 394 China 396 Email: shujun_hu@outlook.com 398 Michael Wang 399 Huawei 400 101 Software Avenue, Yuhua District 401 Nanjing, Jiangsu 210012 402 China 404 Email: wangzitao@huawei.com 406 Ting Ao 407 ZTE Corporation 408 No.889, BiBo Road 409 Shanghai 201203 410 China 412 Email: ao.ting@zte.com.cn