idnits 2.17.1 draft-cuspdt-rtgwg-cu-separation-bng-protocol-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TR-384' is mentioned on line 96, but not defined == Missing Reference: 'RBNF' is mentioned on line 579, but not defined == Unused Reference: 'I-D.cuspdt-rtgwg-cu-separation-bng-deployment' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'I-D.cuspdt-rtgwg-cu-separation-infor-model' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'I-D.cuspdt-rtgwg-cusp-requirements' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC5511' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC5837' is defined on line 767, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-cuspdt-rtgwg-cu-separation-bng-deployment-00 == Outdated reference: A later version (-03) exists of draft-cuspdt-rtgwg-cu-separation-infor-model-00 == Outdated reference: A later version (-03) exists of draft-cuspdt-rtgwg-cusp-requirements-01 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg S. Hu 3 Internet-Draft China Mobile 4 Intended status: Informational Donald. Eastlake 5 Expires: April 25, 2019 Z. Wang 6 Huawei 7 F. Qin 8 Z. Li 9 China Mobile 10 J. Song 11 Huawei 12 T. Chua 13 Singapore Telecommunications Limited 14 October 22, 2018 16 Control-Plane and User-Plane separation BNG control channel Protocol 17 draft-cuspdt-rtgwg-cu-separation-bng-protocol-02 19 Abstract 21 This document specifies the CU Separation BNG control channel 22 Protocol (CUSP) for communications between a Control Plane (CP) and a 23 set of User Planes (UPs). CUSP is designed to be flexible and 24 extensible so as to easily allow for the addition of further messages 25 and objects, should further requirements be expressed in the future. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 3 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Initialization Phase . . . . . . . . . . . . . . . . . . 3 66 3.2. Network Resource Report . . . . . . . . . . . . . . . . . 4 67 3.3. IPoE Session Establishment . . . . . . . . . . . . . . . 5 68 3.4. PPPoE Session Establishment . . . . . . . . . . . . . . . 7 69 3.5. Set User's QoS Information . . . . . . . . . . . . . . . 8 70 3.6. CUSP session statistic . . . . . . . . . . . . . . . . . 9 71 4. CUSP common header . . . . . . . . . . . . . . . . . . . . . 9 72 5. Objective Message Formats . . . . . . . . . . . . . . . . . . 10 73 5.1. Objective TLV Format . . . . . . . . . . . . . . . . . . 11 74 6. Control Message Format . . . . . . . . . . . . . . . . . . . 12 75 6.1. Control TLV Format . . . . . . . . . . . . . . . . . . . 12 76 6.2. Hello Message . . . . . . . . . . . . . . . . . . . . . . 13 77 6.3. Statistics Message . . . . . . . . . . . . . . . . . . . 13 78 7. Event TLV Format . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Event TLV Format . . . . . . . . . . . . . . . . . . . . 15 80 7.2. USER_TRAFFIC_INFORMATION Message . . . . . . . . . . . . 15 81 7.3. USER_DETECT_RESULT_ INFORMATION Message . . . . . . . . . 16 82 8. Resource Report TLV Format . . . . . . . . . . . . . . . . . 16 83 8.1. Resource Report TLV Format . . . . . . . . . . . . . . . 17 84 9. Error Message Format . . . . . . . . . . . . . . . . . . . . 17 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 12. Normative References . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 BNG is an Ethernet-centric IP edge router, and the aggregation point 93 for the user traffic. To provide centralized session management, 94 flexible address allocation, high scalability for subscriber 95 management capacity, and cost-efficient redundancy, the CU separated 96 BNG is introduced [TR-384]. The CU separated Service Control Plane 97 could be virtualized and centralized, which is responsible for user 98 access authentication and setting forwarding entries to user planes. 99 The routing control and forwarding plane, i.e. BNG user plane 100 (local), could be distributed across the infrastructure. 102 This document specifies the CU Separation BNG control channel 103 Protocol (CUSP) for communications between a Control Plane (CP) and a 104 set of User Planes (UPs). CUSP is designed to be flexible and 105 extensible so as to easily allow for the addition of further messages 106 and objects, should further requirements be expressed in the future. 108 2. Concept and Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2.1. Terminology 116 BNG: Broadband Network Gateway. A broadband remote access server 117 (BRAS, B-RAS or BBRAS) routes traffic to and from broadband remote 118 access devices such as digital subscriber line access multiplexers 119 (DSLAM) on an Internet service provider's (ISP) network. BRAS can 120 also be referred to as a Broadband Network Gateway (BNG). 122 CP: Control Plane. CP is a user control management component which 123 supports the management of UP's resources such as the user entry and 124 forwarding policy 126 UP: User Plane. UP is a network edge and user policy implementation 127 component. The traditional router's Control Plane and Forwarding 128 Plane are both preserved on BNG devices in the form of a user plane. 130 3. Protocol Overview 132 3.1. Initialization Phase 133 UP CP 134 | | 135 | | 136 | | 137 | HELLO (version) | 138 |------------------------------>| 139 | | 140 | | 141 | | 142 | HELLO (version) | 143 |<----------------------------- | 144 | | 145 | | 146 | | 148 The initialization phase consists of two successive steps: 150 1) Establishment of a TCP connection (3-way handshake) between the CP 151 and the UP. 153 2) Establishment of a CUSP session over the TCP connection. 155 Once the TCP connection is established, the CP and the UP initiate 156 CUSP session establishment during which the version negotiation are 157 performed. The version's information are carried within Hello 158 messages. If the CUSP session establishment phase fails because the 159 CP or UP disagree on the version parameters or one of the CP or UP 160 does not answer after the expiration of the establishment timer, the 161 TCP connection is immediately closed. 163 Details about the Hello message can be found in Sections 6.2 164 respectively. 166 3.2. Network Resource Report 168 The CP configures the BNG's access interface via NETCONF, and UPs 169 report attributes of according interfaces and slots. 171 UP CP 172 | | 173 | slot attributes report | 174 |------------------------------>| 175 | | 176 | port attributes report | 177 |------------------------------>| 178 | Configure BNG access | 179 |<-------interface via netconf->| 180 | | 181 | | 182 | | 184 Details about the Resource Report Message can be found in Sections 8 185 respectively. 187 3.3. IPoE Session Establishment 188 UP CP 189 | UP report the resources | 190 |----via CUSP------------------>| 191 | | 192 | Configur BNG access | 193 |<--------interface via netconf-| 194 | | 195 | CP sends ACCESS_IF_INFO | 196 |<---to UPs via CUSP------------| 197 | | 198 | User dialup via VXLAN | 199 |<----------------------------->| 200 | | 201 | CP sends USER_BASEC_INFO | 202 |<---to UPs via CUSP------------| 203 | | 204 | CP sends USER_IPV4_INFO | 205 |<---to UPs via CUSP------------| 206 | | 207 | CP sends ROUTEV4 INFO | 208 |<---to UPs via CUSP------------| 209 | | 210 | UP report the USER_DETECT_RESULT_INFO 211 |----to CP via CUSP------------>| 212 | | 213 | | 214 | UP report the USER_TRAFFIC_INFO 215 |----to CP via CUSP------------>| 216 | | 218 Once a CUSP session has been established, if an IPoE session be 219 required that the UPs report attributes of corresponding interfaces 220 and slots via CUSP, and the CP initiate a NETCONF session to 221 configure requested access interface of BNG. 223 Once above process has been accomplished, the CP sends the 224 ACCESS_IF_INFO (Access Interface Information) message to UPs that 225 contains a variety of objects that specify the set of constrains and 226 attributes for the BNG access interface. For example, ifname = 0001, 227 BNG service enable, IPv4 connection trigger enable, neighbor 228 detection enable, etc. 230 And then the user dialup via VXLAN, the CP sends the USER_BASIC_INFOR 231 message USER_IPV4_INFOR, and USER_ROUTEV4_INFO to UPs that contains a 232 variety of objects that specify the attributes for the user's basic 233 information, user's ipv4 information, and routing information. 235 Upon receiving above messages from a CP, the UPs reports the user 236 detection results and user's traffic status via 237 USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, etc. 239 3.4. PPPoE Session Establishment 241 UP CP 242 | | 243 | UP report the resources | 244 |----via CUSP------------------>| 245 | Configur BNG access | 246 |<-------interface via netconf->| 247 | | 248 | CP sends ACCESS_IF_INFO | 249 |<---to UPs via CUSP------------| 250 | | 251 | User dialup via VXLAN | 252 |<----------------------------->| 253 | | 254 | CP sends USER_BASEC_INFO | 255 |<---to UPs via CUSP------------| 256 | | 257 | CP sends USER_IPV4_INFO | 258 |<---to UPs via CUSP------------| 259 | | 260 | CP sends ROUTEV4 INFO | 261 |<---to UPs via CUSP------------| 262 | | 263 | CP sends USER_PPP_INFO | 264 |<---to UPs via CUSP------------| 265 | | 266 | UP report the USER_DETECT_RESULT_INFO 267 |----to CP via CUSP------------>| 268 | | 269 | UP report the USER_TRAFFIC_INFO 270 |----to CP via CUSP------------>| 271 | | 273 Once a CUSP session has been established, if an PPPoE session be 274 required that the UPs report attributes of corresponding interfaces 275 and slots via CUSP, and the CP initiate a NETCONF session to 276 configure requested access interface of BNG. 278 Once above process has been accomplished, the CP sends the 279 ACCESS_IF_INFO (Access Interface Information) message to UPs that 280 contains a variety of objects that specify the set of constrains and 281 attributes for the BNG access interface. For example, ifname = 0001, 282 BNG service enable, IPv4 connection trigger enable, neighbor 283 detection enable, etc. 285 And then the user dialup via VXLAN, the CP sends the USER_BASIC_INFOR 286 message, USER_PPP_INFO message, USER_IPV4_INFOR message, and 287 USER_ROUTEV4_INFO message to UPs that contains a variety of objects 288 that specify the attributes for the user's basic information, user's 289 PPP information, user's ipv4 information, and routing information. 291 Upon receiving above messages from a CP, the UPs reports the user 292 detection results and user's traffic status via 293 USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, etc. 295 3.5. Set User's QoS Information 297 UP CP 298 | | 299 | UP report the resources | 300 |----via CUSP------------------>| 301 | | 302 | Configure BNG Access interface 303 |<-----via netconf--------------| 304 | | 305 | Configure QOS template | 306 |<-----via netconf--------------| 307 | | 308 | User dialup via VXLAN/ | 309 |<---CP sends objecitve tlv/event 310 | report,etc. | 311 | | 312 | CP sends USER_QOS_INFO | 313 |<---to UPs via CUSP------------| 314 | | 316 Once a CUSP session has been established, if a user's QoS needs to be 317 set dynamically that the UPs report attributes of according 318 interfaces and slots via CUSP, and the CP initiate a NETCONF session 319 to configure requested access interface of BNG and User's 320 configuration template. And then the user dialup via VXLAN, the CP 321 sends the USER_BASIC_INFOR message, USER_IPV4_INFOR message, and 322 USER_ROUTEV4_INFO message to UP, the UPs reports the user detection 323 results and user's traffic status. 325 Once above process has been accomplished, the CP sends the 326 USER_QOS_AUTH_INFO message to UPs that contains a variety of objects 327 that specify the set of constrains and attributes for the user's 328 required QoS.(Note that the format of these QoS attributes should 329 synchronize with QoS configuration templates.) 331 3.6. CUSP session statistic 333 UP CP 334 | | 335 | | 336 |<-----statistic REQUEST ------------| 337 | | 338 |------statistic_REQUEST (ACK)------>| 339 | | 340 |------statistic_BEGIN-------------->| 341 | | 342 |<-----statistic_BEGIN (ACK)---------| 343 | | 344 |------statistic_DATA--------------->| 345 | | 346 |------statistic_END---------------->| 347 | | 348 |<-----statistic_END (ACK)-----------| 349 | | 350 | | 352 If the CUSP session down, the CU separation BNG required that the 353 users' information should be reserved. And if the CUSP session 354 restart, the CP may request the UP to report the previous session's 355 statistics to synchronize user information. Above figure describe 356 this process, and the details about the session statistic message can 357 be found in Sections 6.3 respectively. 359 4. CUSP common header 361 A CUSP message consists of a common header followed by a variable- 362 length body made of a set of objects. A CUSP message with a missing 363 mandatory object MUST trigger an Error message (see Section 5.6). 364 Conversely, if an object is optional, the object may or may not be 365 present. 367 Common header: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Message-Type |F| Resv | Message-Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Transaction id | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 CUSP Message Common Header 379 Message-Type (8 bits): The following message types are currently 380 defined: 382 Value Meaning 383 1 Update objective 384 2 Hello 385 3 statistics Request 386 4 statistics Begin 387 5 statistics Data 388 6 statistics End 389 7 Source Report 390 8 Event Report 391 9 Error 393 Flags (1 bits): The control message ACK mode be enabled by setting it 394 to one. 396 Resv (7 bits): Unassigned bits are considered as reserved. They MUST 397 be set to zero on transmission and MUST be ignored on receipt. 399 Message-Length (16 bits): total length of the CUSP message including 400 the common header, expressed in bytes. 402 5. Objective Message Formats 404 CUSP objects have a common format. They begin with a CUSP common 405 header (see Section 4). This is followed by object-specific fields 406 defined for each different object. The object may also include one 407 or more type-length-value (TLV) encoded data sets. Each TLV has the 408 same structure as described in Section 5.1. 410 5.1. Objective TLV Format 412 A CUSP object may include a set of one or more optional TLVs. All 413 CUSP objective TLVs have the following format: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | type | Message-Length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Value | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Type: 2 bytes 424 Length: 2 bytes 425 Value: variable 427 A CUSP object TLV is comprised of 2 bytes for the type, 2 bytes 428 specifying the TLV length, and a value field. 430 The first 4 bits of Type field indicate the operation of this TLV, 431 currently, there are two types: 0 - update the objectives; 1 - delete 432 the objectives. 434 The other bits of Type field indicate the TLV's type (4-15 bits), the 435 following message types are currently defined: 437 Value Meaning 438 0 USER_BASIC_INFO 439 1 USER_PPP_INFO 440 2 ACCESS_IFSRV_INFO 441 3 USER_IPV4_INFO 442 4 USER_IPV6_INFO 443 5 USER_QOS_AUTH_INFO 444 6 ROUTEV4_INFO 445 7 ROUTEV6_INFO 446 8 STATIC_USER_INFO 448 The Length field defines the length of the value portion in bytes. 449 The TLV is padded to 4-bytes alignment; padding is not included in 450 the Length field (so a 3-byte value would have a length of 3, but the 451 total size of the TLV would be 8 bytes). 453 Unrecognized TLVs MUST be ignored. 455 IANA management of the CUSP Object TLV type identifier codespace is 456 described in Section 11. 458 The details about the attributes of Objective TLV are specified in 459 [Section 4.1 of draft-cuspdt-rtgwg-cu-separation-infor-model-00] 461 6. Control Message Format 463 CUSP Control TLV have a common format. They begin with a CUSP common 464 header (see Section 3). It is followed by control TLV fields defined 465 for each different control operations. It may also include one or 466 more type-length-value (TLV) encoded control data sets. Each TLV has 467 the same structure as described in Section 6.1. 469 For each CUSP message type, rules are defined that specify the set of 470 objects that the message can carry. We use the Backus-Naur Form 471 (BNF) (see [RBNF]) to specify such rules. Square brackets refer to 472 optional sub-sequences. An implementation MUST form the CUSP 473 messages using the object ordering specified in this document. 475 6.1. Control TLV Format 477 A CUSP control may include a set of one or more optional TLVs. All 478 CUSP control TLVs have the following format: 480 Type: 2 bytes 481 Length: 2 bytes 482 Value: variable 484 A CUSP control TLV is comprised of 2 bytes for the type, 2 bytes 485 specifying the TLV length, and a value field. 487 Control Type (8 bits): The following message types are currently 488 defined: 490 Value Meaning 491 0 Hello 492 1 Statistics 494 The Length field defines the length of the value portion in bytes. 495 The TLV is padded to 4-bytes alignment; padding is not included in 496 the Length field (so a 3-byte value would have a length of 3, but the 497 total size of the TLV would be 8 bytes). 499 Unrecognized TLVs MUST be ignored. 501 IANA management of the CUSP Object TLV type identifier codespace is 502 described in Section 11. 504 6.2. Hello Message 506 The Hello message is a CUSP message sent by a UP to a CP and by a CP 507 to a UP in order to establish a CUSP session. The Type field of the 508 CUSP common header for the Hello message is set to 2. 510 Once the TCP connection has been successfully established, the first 511 message sent by the UP to the CP or by the CP to the UP MUST be a 512 Hello message. 514 Any message received prior to a Hello message MUST trigger a protocol 515 error condition causing an ERROR message to be sent with Error-Type 516 Version_ Negotiation_Failed and the CUSP session establishment 517 attempt MUST be terminated by closing the TCP connection. 519 The Hello message is used to establish a CUSP session between the 520 CUSP peers. During the establishment phase, the CUSP peers exchange 521 version information. If both parties agree on such version 522 negotiation, the CUSP session is successfully established. 524 The format of a Hello message is as follows: 526 ::= 527 528 :: = 530 Version (4 bytes) : specifies the CP/UP supported CUSP's version, 531 currently, the version is 1. 533 6.3. Statistics Message 535 If the CUSP session down, the CU separation BNG required that the 536 users' information should be reserved. And if the CUSP session 537 restart, the CP may request the UP to report the previous session's 538 statistics to synchronize user information. 540 The Type field of the CUSP common header for the Statistics message 541 is set to 3/4/5/6. 543 The format of a Statistics message is as follows: 545 ::= 546 547 ::= 549 ClassID (2 bytes): specified the statistics type of CUS session, the 550 following statistics types are currently defined: 552 Value Meaning 553 0 objective message statistic 554 1 Source report message statistic 555 2 Event report message statistic 557 Event (2 bytes): specified the Statistics message's subtypes, the 558 following subtypes are currently defined: 560 Value Meaning 561 0 request Statistics message 562 1 begin Statistics message 563 2 Statistics data message 564 3 End Statistics message 566 Note that, the event value MUST be synchronized with the type of 567 comment header. 569 7. Event TLV Format 571 CUSP Event TLV have a common format. They begin with a CUSP common 572 header (see Section 3). It is followed by Event TLV fields defined 573 for each different Events. It may also include one or more type- 574 length-value (TLV) encoded Event data sets. Each TLV has the same 575 structure as described in Section 7.1. 577 For each CUSP message type, rules are defined that specify the set of 578 objects that the message can carry. We use the Backus-Naur Form 579 (BNF) (see [RBNF]) to specify such rules. Square brackets refer to 580 optional sub-sequences. An implementation MUST form the CUSP 581 messages using the object ordering specified in this document. 583 7.1. Event TLV Format 585 A CUSP Event may include a set of one or more optional TLVs. All 586 CUSP Event TLVs have the following format: 588 Type: 2 bytes 589 Length: 2 bytes 590 Value: variable 592 A CUSP Event TLV is comprised of 2 bytes for the type, 2 bytes 593 specifying the TLV length, and a value field. 595 Event Type (8 bits): The following message types are currently 596 defined: 598 Value Meaning 599 0 USER_TRAFFIC_INFORMATION 600 1 USER_DETECT_RESULT_ INFORMATION 602 The Length field defines the length of the value portion in bytes. 603 The TLV is padded to 4-bytes alignment; padding is not included in 604 the Length field (so a 3-byte value would have a length of 3, but the 605 total size of the TLV would be 8 bytes). 607 Unrecognized TLVs MUST be ignored. 609 IANA management of the CUSP Object TLV type identifier codespace is 610 described in Section 11. 612 7.2. USER_TRAFFIC_INFORMATION Message 614 The USER_TRAFFIC_INFORMATION Message be used to reported the user's 615 traffic statistics by UP. 617 The format of a USER_TRAFFIC_INFORMATION message is as follows: 619 ::= 620 621 ::= 622 623 < EgressBytes > 625 USER_ID (4 bytes): is the identifier of user. This parameter is 626 unique and mandatory. This attribute is used to distinguish 627 different users. 629 StatisticsType (4 bytes): be used to indicate the Statistics type, 630 the following types are currently defined: 632 Value Meaning 633 0 IPv4 traffic statistic 634 1 IPv6 traffic statistic 636 IngressPackets (8 bytes): be used to present the ingress packets. 638 IngressBytes (8 bytes): be used to present the ingress bytes. 640 EgressPackets (8 bytes): be used to present the egress packets. 642 EgressBytes (8 bytes): be used to present the egress bytes. 644 7.3. USER_DETECT_RESULT_ INFORMATION Message 646 The USER_TRAFFIC_INFORMATION Message be used to reported the user 647 detect fail by UP. 649 The format of a USER_DETECT_RESULT_ INFORMATION message is as 650 follows: 652 < USER_DETECT_RESULT_ INFORMATION Message>::= 653 < USER_DETECT_RESULT_ INFORMATION _TLV> 654 < USER_DETECT_RESULT_ INFORMATION _TLV>::= 656 USER_ID (4 bytes): is the identifier of user. This parameter is 657 unique and mandatory. This attribute is used to distinguish 658 different users. 660 DetectFail (2 bytes): be used to indicate that the user detect fail. 662 8. Resource Report TLV Format 664 CUSP Resource Report TLV have a common format. They begin with a 665 CUSP common header (see Section 3). It is followed by Event TLV 666 fields defined for each different Resources. It may also include one 667 or more type-length-value (TLV) encoded Resource Report data sets. 668 Each TLV has the same structure as described in Section 7.1. 670 8.1. Resource Report TLV Format 672 A CUSP Resource Report may include a set of one or more optional 673 TLVs. All CUSP Resource Report TLVs have the following format: 675 Type: 2 bytes 676 Length: 2 bytes 677 Value: variable 679 A CUSP Resource Report TLV is comprised of 2 bytes for the type, 2 680 bytes specifying the TLV length, and a value field. 682 Resource Type (8 bits): The following message types are currently 683 defined: 685 Value Meaning 686 0 RESOURCE_IF_INFO 687 1 RESOURCE_SLOT_INFO 689 The Length field defines the length of the value portion in bytes. 690 The TLV is padded to 4-bytes alignment; padding is not included in 691 the Length field (so a 3-byte value would have a length of 3, but the 692 total size of the TLV would be 8 bytes). 694 Unrecognized TLVs MUST be ignored. 696 IANA management of the CUSP Object TLV type identifier codespace is 697 described in Section 11. 699 The details about the attributes of Resource Report TLV are specified 700 in [Section 4.2 of draft-cuspdt-rtgwg-cu-separation-infor-model-00] 702 9. Error Message Format 704 Error messages are used by the CP or UPs to notify the other side of 705 the connection of problems. They are mostly used by the UPs to 706 indicate a failure of a request initiated by the CP. 708 The format of an Error message is as follows: 710 ::= 711 713 ERRID (4 bytes): be used to indicate the error type, the following 714 types are currently defined: 716 Value Meaning 717 00~1000 Reserved 718 1001 version negotiation failed 719 1002 TLV type cannot be recognized 720 1003 TLV length Anomaly 721 1004 TLV objective Anomaly 722 1005 Statistics failed 723 1006 Statistics request not support 725 10. Security Considerations 727 None. 729 11. IANA Considerations 731 CUSP has been registered as TCP port XXXX. 733 12. Normative References 735 [I-D.cuspdt-rtgwg-cu-separation-bng-deployment] 736 Gu, R., Hu, S., and Z. Wang, "Deployment Model of Control 737 Plane and User Plane Separation BNG", draft-cuspdt-rtgwg- 738 cu-separation-bng-deployment-00 (work in progress), 739 October 2017. 741 [I-D.cuspdt-rtgwg-cu-separation-infor-model] 742 Wang, Z., Gu, R., Lopezalvarez, V., and S. Hu, 743 "Information Model of Control-Plane and User-Plane 744 separation BNG", draft-cuspdt-rtgwg-cu-separation-infor- 745 model-00 (work in progress), February 2018. 747 [I-D.cuspdt-rtgwg-cusp-requirements] 748 Hu, S., Gu, R., Lopezalvarez, V., Song, J., and Z. Wang, 749 "Requirements for Control Plane and User Plane Separated 750 BNG Protocol", draft-cuspdt-rtgwg-cusp-requirements-01 751 (work in progress), February 2018. 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, 755 DOI 10.17487/RFC2119, March 1997, 756 . 758 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 759 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 760 . 762 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 763 Used to Form Encoding Rules in Various Routing Protocol 764 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 765 2009, . 767 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 768 N., and JR. Rivers, "Extending ICMP for Interface and 769 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 770 April 2010, . 772 Authors' Addresses 774 Shujun Hu 775 China Mobile 776 32 Xuanwumen West Ave, Xicheng District 777 Beijing, Beijing 100053 778 China 780 Email: hushujun@chinamobile.com 782 Donald Eastlake, 3rd 783 Huawei 784 1424 Pro Shop Court 785 Davenport, FL 33896 786 USA 788 Email: d3e3e3@gmail.com 790 Zitao Wang 791 Huawei 792 101 Software Avenue, Yuhua District 793 Nanjing, Jiangsu 210012 794 China 796 Email: wangzitao@huawei.com 797 Fengwei Qin 798 China Mobile 799 32 Xuanwumen West Ave, Xicheng District 800 Beijing, Beijing 100053 801 China 803 Email: qinfengwei@chinamobile.com 805 Zhenqiang Li 806 China Mobile 807 32 Xuanwumen West Ave, Xicheng District 808 Beijing, Beijing 100053 809 China 811 Email: lizhenqiang@chinamobile.com 813 Jun Song 814 Huawei 815 101 Software Avenue, Yuhua District 816 Nanjing, Jiangsu 210012 817 China 819 Tee Mong Chua 820 Singapore Telecommunications Limited 821 31 Exeter Road, #05-04 Comcentre Podium Block 822 Singapore City 239732 823 Singapore 825 Email: teemong@singtel.com