idnits 2.17.1 draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.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 (November 30, 2018) is 1974 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) ** Downref: Normative reference to an Informational draft: draft-cuspdt-rtgwg-cu-separation-infor-model (ref. 'InforModel') Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Hu 2 Intended status: Proposed Standard China Mobile 3 D. Eastlake 4 Z. Wang 5 Huawei 6 F. Qin 7 Z. Li 8 China Mobile 9 J. Song 10 Huawei 11 T. Chua 12 Singapore Telecommunications Ltd 13 Expires: May 29, 2018 November 30, 2018 15 Control-Plane and User-Plane Separation BNG Control Channel Protocol 16 draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.txt 18 Abstract 20 This document specifies the CU Separation Broadband Network Gateway 21 (BNG) control channel Protocol (CUSP) for communications between a 22 Control Plane (CP) and a set of User Planes (UPs). CUSP is designed 23 to be flexible and extensible so as to easily allow for the addition 24 of further messages and objects, should further requirements be 25 expressed in the future. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Distribution of this document is unlimited. Comments should be sent 33 to the authors or the RGTWG working group mailing list: 34 rtgwg@ietf.org. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Table of Contents 53 1. Introduction............................................3 55 2. Concept and Terminology.................................4 56 2.1 Terminology............................................4 58 3. Protocol Overview.......................................5 59 3.1 Initialization Phase...................................5 60 3.2 Network Resource Report................................5 61 3.3 IPoE Session Establishment.............................6 62 3.4 PPPoE Session Establishment............................7 63 3.5 Setting the User's QoS Information.....................9 64 3.6 CUSP Session Statistics...............................10 66 4. CUSP Common Header.....................................11 68 5. Objective Message Formats..............................12 69 5.1 Objective TLV Format..................................12 71 6. Control Message Format.................................14 72 6.1 Control TLV Format....................................14 73 6.2 Hello Message.........................................15 74 6.3 Statistics Message....................................15 76 7. Event TLV Format.......................................17 77 7.1 Event TLV Format......................................17 78 7.2 USER_TRAFFIC_INFORMATION Message......................18 79 7.3 USER_DETECT_RESULT_INFORMATION Message................18 81 8. Resource Report TLV Format.............................20 82 8.1 Resource Report TLV Format............................20 84 9. Error Message Format..................................21 86 10. Security Considerations...............................22 88 11. IANA Considerations...................................22 89 11.1 Message Types........................................22 90 11.2 TLV Types Values.....................................22 91 11.3 ERRID Codes..........................................22 93 Normative References......................................23 94 Informative References....................................23 96 Authors' Addresses........................................24 98 1. Introduction 100 A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge 101 router, and the aggregation point for user traffic. To provide 102 centralized session management, flexible address allocation, high 103 scalability for subscriber management capacity, and cost-efficient 104 redundancy, the Control/User (CU) separated BNG is descried in 105 [TR-384]. The CU separated Service Control Plane, which is 106 responsible for user access authentication and setting forwarding 107 entries in User Planes, can be virtualized and centralized. The 108 routing control and forwarding plane, i.e. the BNG user plane 109 (local), can be distributed across the infrastructure. 111 This document specifies the CU Separation BNG control channel 112 Protocol (CUSP) for communications between a BNG Control Plane (CP) 113 and a set of User Planes (UPs). CUSP is designed to be flexible and 114 extensible so as to easily allow for additional messages and objects, 115 should further requirements be expressed in the future. 117 2. Concept and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2.1 Terminology 127 BNG: Broadband Network Gateway. A broadband remote access server 128 (BRAS, B-RAS or BBRAS) routes traffic to and from broadband 129 remote access devices such as digital subscriber line access 130 multiplexers (DSLAM) on an Internet service provider's (ISP) 131 network. BRAS can also be referred to as a Broadband Network 132 Gateway (BNG). 134 CP: Control Plane. CP is a user control management component which 135 supports the management of the UP's resources such as the user 136 entry and forwarding policy. 138 CU: Control / User. 140 CUSP: Control and User Separate Protocol. 142 UP: User Plane. UP is a network edge and user policy implementation 143 component. The traditional router's Control Plane and Forwarding 144 Plane are both preserved on BNG devices in the form of a user 145 plane. 147 3. Protocol Overview 149 3.1 Initialization Phase 151 UP CP 152 | | 153 | TCP Session Establishment | 154 |<----------------------------->| 155 | | 156 | | 157 | HELLO (version) | 158 |------------------------------>| 159 | | 160 | | 161 | HELLO (version) | 162 |<----------------------------- | 163 | | 164 | | 166 The initialization phase consists of two successive steps: 168 1) Establishment of a TCP connection (3-way handshake) between the CP 169 and the UP using port tbd1. 171 2) Establishment of a CUSP session over the TCP connection. 173 Once the TCP connection is established, the CP and the UP initialize 174 the CUSP session during which the version negotiation is performed. 175 The version information is carried within Hello messages (see Section 176 6.2). If the CUSP session establishment phase fails because the CP 177 or UP disagree on the version parameters or one of the CP or UP does 178 not answer after the expiration of the establishment timer, the TCP 179 connection is immediately closed. 181 3.2 Network Resource Report 183 The CP configures the BNG's access interface via NETCONF, and UPs 184 report the attributes of their interfaces and slots. 186 UP CP 187 | | 188 | slot attributes report | 189 | via CUSP | 190 |----------------------------->| 191 | | 192 | port attributes report | 193 | via CUSP | 194 |----------------------------->| 195 | | 196 | Configure BNG access | 197 | interface via NETCONF | 198 |<---------------------------->| 199 | | 200 | | 202 Details of the Resource Report Message can be found in Sections 8. 204 3.3 IPoE Session Establishment 206 UP CP 207 | | 208 | UP reports its resources | 209 |----via CUSP------------------->| 210 | | 211 | Configure BNG access | 212 |<---interface via NETCONF-------| 213 | | 214 | CP sends ACCESS_IF_INFO | 215 |<---to UPs via CUSP-------------| 216 | | 217 | User dialup via VXLAN | 218 |<------------------------------>| 219 | | 220 | CP sends USER_BASEC_INFO | 221 |<---to UPs via CUSP-------------| 222 | | 223 | CP sends USER_IPV4_INFO | 224 |<---to UPs via CUSP-------------| 225 | | 226 | CP sends ROUTEV4 INFO | 227 |<---to UPs via CUSP-------------| 228 | | 229 | UP reports the USER_DETECT_RESULT_INFO 230 |----to CP via CUSP------------->| 231 | | 232 | UP reports the USER_TRAFFIC_INFO 233 |----to CP via CUSP------------->| 234 | | 236 Once a CUSP session has been established, if an IPoE session is 237 required, the UPs report attributes of the interfaces and slots to be 238 used for the IPoE session via CUSP, and the CP initiate a NETCONF 239 session to configure the requested access interface of BNG. 241 Once the above process has been accomplished, the CP sends to the UP 242 the ACCESS_IF_INFO (Access Interface Information) message that 243 contains a variety of objects that specify the set of constrains and 244 attributes for the BNG access interface. For example, ifname = 0001 245 [RFC2863], BNG service enable, IPv4 connection trigger enable, 246 neighbor detection enable, etc. 248 Then the user dials up via VXLAN, the CP sends to the UP the 249 USER_BASIC_INFOR message USER_IPV4_INFOR, and USER_ROUTEV4_INFO that 250 contains a variety of objects that specify the attributes for the 251 user's basic information, user's ipv4 information, and routing 252 information. 254 Upon receiving the above messages from a CP, the UPs reports the user 255 detection results and user's traffic status via the 256 USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, message. 258 3.4 PPPoE Session Establishment 259 UP CP 260 | | 261 | UP reports the resources | 262 |----via CUSP------------------->| 263 | | 264 | Configure BNG access | 265 |<-------interface via NETCONF-->| 266 | | 267 | CP sends ACCESS_IF_INFO | 268 |<---to UPs via CUSP-------------| 269 | | 270 | User dialup via VXLAN | 271 |<------------------------------>| 272 | | 273 | CP sends USER_BASEC_INFO | 274 |<---to UPs via CUSP-------------| 275 | | 276 | CP sends USER_IPV4_INFO | 277 |<---to UPs via CUSP-------------| 278 | | 279 | CP sends ROUTEV4 INFO | 280 |<---to UPs via CUSP-------------| 281 | | 282 | CP sends USER_PPP_INFO | 283 |<---to UPs via CUSP-------------| 284 | | 285 | UP reports the USER_DETECT_RESULT_INFO 286 |----to CP via CUSP------------->| 287 | | 288 | UP reports the USER_TRAFFIC_INFO 289 |----to CP via CUSP------------->| 290 | | 292 Once a CUSP session has been established, if an PPPoE session is 293 required, the UPs report attributes of the corresponding interfaces 294 and slots to be used for the PPPoE session via CUSP, and the CP 295 initiate a NETCONF session to configure requested access interface of 296 the BNG. 298 Once the above process has been accomplished, the CP sends to the UP 299 the ACCESS_IF_INFO (Access Interface Information) message that 300 contains a variety of objects that specify the set of constrains and 301 attributes for the BNG access interface. For example, ifname = 0001 302 [RFC2863], BNG service enable, IPv4 connection trigger enable, 303 neighbor detection enable, etc. 305 Then the user dials up via VXLAN, the CP sends to the UP the 306 USER_BASIC_INFOR message, the USER_PPP_INFO message, USER_IPV4_INFOR 307 message, and USER_ROUTEV4_INFO message that contains a variety of 308 objects that specify the attributes of the user's basic information, 309 user's PPP information, user's ipv4 information, and routing 310 information. 312 Upon receiving the above messages from a CP, the UPs reports the user 313 detection results and user's traffic status via 314 USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, etc. 316 3.5 Setting the User's QoS Information 318 UP CP 319 | | 320 | UP reports the resources | 321 |----via CUSP------------------->| 322 | | 323 | Configure BNG Access interface 324 |<-----via NETCONF---------------| 325 | | 326 | Configure QOS template | 327 |<-----via NETCONF---------------| 328 | | 329 | User dials up via VXLAN | 330 |<---CP sends objective TLV/Event| 331 | report, etc. | 332 | | 333 | CP sends USER_QOS_INFO | 334 |<---to UPs via CUSP-------------| 335 | | 337 Once a CUSP session has been established, if a user's Quality of 338 Service (QoS) needs to be set dynamically, then the UPs report 339 attributes of the relevant interfaces and slots via CUSP, and the CP 340 initiate a NETCONF session to configure the requested access 341 interfaces of the BNG and User's configuration template. Then the 342 user dials up via VXLAN, the CP sends the USER_BASIC_INFOR message, 343 USER_IPV4_INFOR message, and USER_ROUTEV4_INFO message to the UP, the 344 UPs reports the user detection results and user's traffic status. 346 Once above process has been accomplished, the CP sends the 347 USER_QOS_AUTH_INFO message to the UPs; this message contains a 348 variety of objects that specify the set of constrains and attributes 349 for the user's required QoS. (The format of these QoS attributes 350 should be parallel to the QoS configuration templates.) 352 3.6 CUSP Session Statistics 354 UP CP 355 | | 356 | | 357 |<-----statistic_REQUEST ------------| 358 | | 359 |------statistic_REQUEST (ACK)------>| 360 | | 361 |------statistic_BEGIN-------------->| 362 | | 363 |<-----statistic_BEGIN (ACK)---------| 364 | | 365 |------statistic_DATA--------------->| 366 | | 367 |------statistic_END---------------->| 368 | | 369 |<-----statistic_END (ACK)-----------| 370 | | 371 | | 373 If the CUSP session goes down, the CU separation BNG is required to 374 save the users' information. And if the CUSP session restarts, the 375 CP may request that the UP send the previous session's statistics to 376 synchronize user information. The above figure shows this process, 377 and the details of the session statistic message can be found in 378 Sections 6.3. 380 4. CUSP Common Header 382 A CUSP message consists of a common header followed by a variable- 383 length body made of a set of objects. Receiving a CUSP message with 384 a missing mandatory object MUST trigger an Error message (see Section 385 5.6). Conversely, if an object is optional, the object may or may 386 not be present. 388 Common header: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Message-Type |F| Resv | Message-Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Transaction id | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 CUSP Message Common Header 399 Message-Type (8 bits): The following message types are defined in 400 this document: 402 Value Meaning 403 ----- ------------------ 404 1 Update objective 405 2 Hello 406 3 statistics Request 407 4 statistics Begin 408 5 statistics Data 409 6 statistics End 410 7 Source Report 411 8 Event Report 412 9 Error 414 F (1 bit): Setting the F bit to one enables the control message ACK 415 mode and setting the F bit to zero disables that mode. 417 Resv (7 bits): Reserved bits. They MUST be set to zero on 418 transmission and MUST be ignored on receipt. 420 Message-Length (16 bits): Total length of the CUSP message including 421 the common header, expressed in bytes as an unsigned 422 integer. 424 Transaction ID (32 bits): This field is used to identify requests. It 425 is echoed back in the corresponding ACK / response / Error 426 message. 428 5. Objective Message Formats 430 CUSP objects have a common format. They begin with a CUSP common 431 header (see Section 4). This is followed by object-specific fields 432 defined for each different object. The object may also include one 433 or more type-length-value (TLV) encoded data sets. Each TLV has the 434 same structure as described in Section 5.1. 436 5.1 Objective TLV Format 438 A CUSP object may include a set of one or more optional TLVs. All 439 CUSP objective TLVs have the following format: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | TLV-Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Value | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Type: 2 bytes 450 TLV-Length: 2 bytes 451 Value: variable 453 A CUSP objective TLV is comprised of 2 bytes for the type, 2 bytes 454 specifying the TLV-Length, and a value field. The Type and TLV-Length 455 fields are unsigned integers. 457 The first 4 bits of Type field indicate the operation of this TLV, 458 currently, there are two types: 0 - update the objectives; 1 - delete 459 the object. Updating a non-existent object creates it. 461 The remaining bits of the Type field indicate the TLV's type (4-15 462 bits) which is the object to which it applies. The following objects 463 / types are currently defined: 465 Value Meaning 466 ----- -------------- 467 0 USER_BASIC_INFO 468 1 USER_PPP_INFO 469 2 ACCESS_IFSRV_INFO 470 3 USER_IPV4_INFO 471 4 USER_IPV6_INFO 472 5 USER_QOS_AUTH_INFO 473 6 ROUTEV4_INFO 474 7 ROUTEV6_INFO 475 8 STATIC_USER_INFO 477 The TLV-Length field defines the length of the value portion in 478 bytes. The TLV is padded to 4-bytes alignment; padding is not 479 included in the Length field (so a 3-byte value would have a length 480 of 3, but the total size of the TLV would be 8 bytes). 482 Unrecognized TLVs MUST be ignored. 484 IANA management of the CUSP Object TLV type identifier codespace is 485 described in Section 11. 487 The details of the attributes of the Objective TLV are specified in 488 Section 4.1 of [InforModel]. 490 6. Control Message Format 492 CUSP Control messages have a common format. They begin with the CUSP 493 common header (see Section 4) followed by control TLVs fields for the 494 different control operations. It may also include one or more type- 495 length-value (TLV) encoded control data sets. Each TLV has the same 496 structure as described in Section 6.1. 498 For each CUSP message type, rules are defined that specify the set of 499 objects that the message can carry. We use the Backus-Naur Form 500 (BNF) (see [RFC5511]) to specify such rules. Square brackets refer 501 to optional sub-sequences. An implementation MUST form the CUSP 502 messages using the object ordering specified in this document. 504 6.1 Control TLV Format 506 A CUSP control may include a set of one or more optional TLVs. All 507 CUSP control TLVs have the following format: 509 Type: 2 bytes 510 TLV-Length: 2 bytes 511 Value: variable 513 A CUSP control TLV consists of 2 bytes for the type, 2 bytes 514 specifying the TLV length, and a value field. 516 Control Type (8 bits): The following message types are currently 517 defined: 519 Value Meaning 520 ----- ---------- 521 0 Hello 522 1 Statistics 524 The Length field defines the length of the value portion in bytes. 525 The TLV is padded to 4-bytes alignment; padding is not included in 526 the Length field (so a 3-byte value would have a length of 3, but the 527 total size of the TLV would be 8 bytes). 529 Unrecognized TLVs MUST be ignored. 531 IANA management of the CUSP Object TLV type identifier codespace is 532 described in Section 11. 534 6.2 Hello Message 536 The Hello message is a CUSP message sent by a UP to a CP and by a CP 537 to a UP in order to establish a CUSP session. The Type field of the 538 CUSP common header for the Hello message is set to 2. 540 Once the TCP connection has been successfully established, the first 541 message sent by the UP to the CP or by the CP to the UP MUST be a 542 Hello message. 544 Any message received prior to a Hello message MUST trigger a protocol 545 error condition causing an ERROR message to be sent with Error-Type 546 Version_ Negotiation_Failed and the CUSP session establishment 547 attempt MUST be terminated by closing the TCP connection. 549 The Hello message is used to establish a CUSP session between the 550 CUSP peers. During the establishment phase, the CUSP peers exchange 551 version information. If both parties agree on such version 552 negotiation, the CUSP session is successfully established. 554 The format of a Hello message is as follows: 556 ::= 557 558 :: = 560 Version (4 bytes): specifies the CP/UP supported CUSP's version, 561 currently, the version is 1. 563 6.3 Statistics Message 565 If the CUSP session goes down, the CU separation BNG is required to 566 preserve the users' information. If the CUSP session restarts, the 567 CP may request the UP to report the previous session's statistics to 568 synchronize user information. 570 The Type field of the CUSP common header for the Statistics messages 571 is set to 3, 4, 5, or 6. 573 The format of a Statistics message is as follows: 575 ::= 576 577 ::= 579 ClassID (2 bytes): This field specifies the statistics type of CUS 580 session, the following statistics types are currently defined: 582 Value Meaning 583 ----- ------------------------------- 584 0 objective message statistic 585 1 Source report message statistic 586 2 Event report message statistic 588 Event (2 bytes): specified the Statistics message's subtypes, the 589 following subtypes are currently defined: 591 Value Meaning 592 ----- ------- 593 0 request Statistics message 594 1 begin Statistics message 595 2 Statistics data message 596 3 End Statistics message 598 Note that, the event value MUST be synchronized with the type of 599 comment header. 601 7. Event TLV Format 603 CUSP Event TLVs have a common format. They begin with a CUSP common 604 header (see Section 4). It is followed by Event TLV fields defined 605 for each different Events. It may also include one or more type- 606 length-value (TLV) encoded Event data sets. Each TLV has the same 607 structure as described in Section 7.1. 609 For each CUSP message type, rules are defined that specify the set of 610 objects that the message can carry. We use the Backus-Naur Form 611 (BNF) (see [RFC5511]) to specify such rules. Square brackets refer 612 to optional sub-sequences. An implementation MUST form the CUSP 613 messages using the object ordering specified in this document. 615 7.1 Event TLV Format 617 A CUSP Event may include a set of one or more optional TLVs. All 618 CUSP Event TLVs have the following format: 620 Type: 2 bytes 621 Length: 2 bytes 622 Value: variable 624 A CUSP Event TLV consists of 2 bytes for the type, 2 bytes specifying 625 the TLV length, and a value field. 627 Event Type (8 bits): The following message types are currently 628 defined: 630 Type Meaning 631 ----- ------------------------------ 632 0 USER_TRAFFIC_INFORMATION 633 1 USER_DETECT_RESULT_INFORMATION 635 The Length field defines the length of the value portion in bytes. 636 The TLV is padded to 4-bytes alignment; padding is not included in 637 the Length field (so a 3-byte value would have a length of 3, but the 638 total size of the TLV would be 8 bytes). 640 Unrecognized TLVs MUST be ignored. 642 IANA management of the CUSP Object TLV type identifier codespace is 643 described in Section 11. 645 7.2 USER_TRAFFIC_INFORMATION Message 647 The USER_TRAFFIC_INFORMATION Message be used by the UP to reported 648 the user's traffic statistics. 650 The format of a USER_TRAFFIC_INFORMATION message is as follows: 652 ::= 653 654 ::= 655 656 658 USER_ID (4 bytes): is the identifier of user. This parameter is 659 unique and mandatory. This attribute is used to distinguish 660 different users. 662 StatisticsType (4 bytes): be used to indicate the Statistics type, 663 the following types are currently defined: 665 Value Meaning 666 ----- ----------------------- 667 0 IPv4 traffic statistics 668 1 IPv6 traffic statistics 670 IngressPackets (8 bytes): be used to present the ingress packets. 672 IngressBytes (8 bytes): be used to present the ingress bytes. 674 EgressPackets (8 bytes): be used to present the egress packets. 676 EgressBytes (8 bytes): be used to present the egress bytes. 678 7.3 USER_DETECT_RESULT_INFORMATION Message 680 The USER_TRAFFIC_INFORMATION Message is used to reported the failure 681 of user detection by the UP. 683 The format of a USER_DETECT_RESULT_INFORMATION message is as follows: 685 ::= 686 687 ::= 689 USER_ID (4 bytes): is the identifier of user. This parameter is 690 unique and mandatory. This attribute is used to distinguish different 691 users. 693 DetectFail (2 bytes): be used to indicate that the user detect fail. 695 8. Resource Report TLV Format 697 CUSP Resource Report TLVs have a common format. They begin with a 698 CUSP common header (see Section 4). It is followed by Event TLV 699 fields defined for each different Resource. It may also include one 700 or more type-length-value (TLV) encoded Resource Report data sets. 701 Each TLV has the same structure as described in Section 7.1. 703 8.1 Resource Report TLV Format 705 A CUSP Resource Report may include a set of one or more optional 706 TLVs. All CUSP Resource Report TLVs have the following format: 708 Type: 2 bytes 709 Length: 2 bytes 710 Value: variable 712 A CUSP Resource Report TLV is comprised of 2 bytes for the type, 2 713 bytes specifying the TLV length, and a value field. 715 Resource Type (8 bits): The following message types are currently 716 defined: 718 Value Meaning 719 ----- ------- 720 0 RESOURCE_IF_INFO 721 1 RESOURCE_SLOT_INFO 723 The Length field defines the length of the value portion in bytes. 724 The TLV is padded to 4-bytes alignment; padding is not included in 725 the Length field (so a 3-byte value would have a length of 3, but the 726 total size of the TLV would be 8 bytes). 728 Unrecognized TLVs MUST be ignored. 730 IANA management of the CUSP Object TLV type identifier codespace is 731 described in Section 11. 733 The details about the attributes of Resource Report TLV are specified 734 in Section 4.2 of [InforModel] 736 9. Error Message Format 738 Error messages are used by the CP or UPs to notify the other side of 739 the connection of problems. They are mostly used by the UPs to 740 indicate a failure of a request initiated by the CP. 742 The format of an Error message is as follows: 744 ::= 745 747 ERRID (4 bytes): Used to indicate the error type. The following types 748 are currently defined: 750 Value Meaning 751 ------- -------------------------------- 752 00~1000 Reserved 753 1001 version negotiation failed 754 1002 TLV type cannot be recognized 755 1003 TLV length Anomaly 756 1004 TLV objective Anomaly 757 1005 Statistics failed 758 1006 Statistics request not supported 760 10. Security Considerations 762 TBD. 764 11. IANA Considerations 766 IANA is registered to assign a port for CUSP as follows: 768 Service Port Transport 769 Name Number Protocol Description Reference 770 ------- ------ --------- ------------ --------------- 771 cusp tbd1 tcp Control User [this document] 772 Separation 773 Protocol 775 IANA is requested to create a "CUSP Parameters" web page and include 776 there of the registries set up below in this Section. 778 11.1 Message Types 780 TBD. 782 11.2 TLV Types Values 784 TBD. 786 11.3 ERRID Codes 788 TBD. 790 Normative References 792 [cuspdt-rtgwg-cu-separation-bng-deployment] Gu, R., Hu, S., and Z. 793 Wang, "Deployment Model of Control Plane and User Plane 794 Separation BNG", draft-cuspdt-rtgwg-cu-separation-bng- 795 deployment (work in progress), October 2017. 797 [InforModel] Wang, Z., Gu, R., Lopezalvarez, V., and S. Hu, 798 "Information Model of Control-Plane and User-Plane 799 separation BNG", draft-cuspdt-rtgwg-cu-separation-infor- 800 model (work in progress), October 2018. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, DOI 804 10.17487/RFC2119, March 1997, . 807 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 808 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 809 . 811 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used 812 to Form Encoding Rules in Various Routing Protocol 813 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 814 2009, . 816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 817 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 818 2017, . 820 Informative References 822 [cuspdt-rtgwg-cusp-requirements] Hu, S., Gu, R., Lopezalvarez, V., 823 Song, J., and Z. Wang, "Requirements for Control Plane and 824 User Plane Separated BNG Protocol", draft-cuspdt-rtgwg- 825 cusp-requirements (work in progress), October 2018. 827 [TR-384] Broadband Forum, "Cloud Central Office Reference 828 Architectural Framework", BBF TR-384, 2018. 830 Authors' Addresses 832 Shujun Hu 833 China Mobile 834 32 Xuanwumen West Ave, Xicheng District 835 Beijing, Beijing 100053 836 China 838 Email: hushujun@chinamobile.com 840 Donald Eastlake, 3rd 841 Huawei 842 1424 Pro Shop Court 843 Davenport, FL 33896 844 USA 846 Phone: +1-508-333-2270 847 Email: d3e3e3@gmail.com 849 Zitao Wang 850 Huawei 851 101 Software Avenue, Yuhua District 852 Nanjing, Jiangsu 210012 853 China 855 Email: wangzitao@huawei.com 857 Fengwei Qin 858 China Mobile 859 32 Xuanwumen West Ave, Xicheng District 860 Beijing, Beijing 100053 861 China 863 Email: qinfengwei@chinamobile.com 865 Zhenqiang Li 866 China Mobile 867 32 Xuanwumen West Ave, Xicheng District 868 Beijing, Beijing 100053 869 China 871 Email: lizhenqiang@chinamobile.com 873 Jun Song 874 Huawei 875 101 Software Avenue, Yuhua District 876 Nanjing, Jiangsu 210012 877 China 879 Email: song.jun@huawei.com 881 Tee Mong Chua 882 Singapore Telecommunications Limited 883 31 Exeter Road, #05-04 Comcentre Podium Block 884 Singapore City 239732 885 Singapore 887 Email: teemong@singtel.com 889 Copyright, Disclaimer, and Additional IPR Provisions 891 Copyright (c) 2018 IETF Trust and the persons identified as the 892 document authors. All rights reserved. 894 This document is subject to BCP 78 and the IETF Trust's Legal 895 Provisions Relating to IETF Documents 896 (http://trustee.ietf.org/license-info) in effect on the date of 897 publication of this document. Please review these documents 898 carefully, as they describe your rights and restrictions with respect 899 to this document. Code Components extracted from this document must 900 include Simplified BSD License text as described in Section 4.e of 901 the Trust Legal Provisions and are provided without warranty as 902 described in the Simplified BSD License.