idnits 2.17.1 draft-haleplidis-bcause-forces-gap-analysis-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 (November 4, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Data' is mentioned on line 281, but not defined == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Haleplidis 3 Internet-Draft 4 Intended status: Informational J. Hadi Salim 5 Expires: May 7, 2020 Mojatatu Networks 6 November 4, 2019 8 ForCES architecture CUSP applicability 9 draft-haleplidis-bcause-forces-gap-analysis-01 11 Abstract 13 This document provides a gap-analysis on how the ForCES architecture 14 meets the requirements for CUSP. In addition it provides a ForCES 15 XML model that implements the current proposed CUSP information 16 model. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 7, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. ForCES overview . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. ForCES protocol . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Meeting CUSP requirements . . . . . . . . . . . . . . . . . . 8 60 4.1. Transmit information tables . . . . . . . . . . . . . . . 8 61 4.2. Message Priority . . . . . . . . . . . . . . . . . . . . 9 62 4.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.4. Support for secure communication . . . . . . . . . . . . 10 64 4.5. Version negotiation . . . . . . . . . . . . . . . . . . . 10 65 4.6. Capability Exchange . . . . . . . . . . . . . . . . . . . 10 66 4.7. CP primary/backup capability . . . . . . . . . . . . . . 11 67 4.8. Event Notification . . . . . . . . . . . . . . . . . . . 11 68 4.9. Query Statistics . . . . . . . . . . . . . . . . . . . . 12 69 4.10. Beyond the CUSP requirements . . . . . . . . . . . . . . 12 70 5. Control and user plane information models . . . . . . . . . . 12 71 5.1. Information model for the Control Plane . . . . . . . . . 12 72 5.1.1. User related information . . . . . . . . . . . . . . 12 73 5.1.2. Interface related information . . . . . . . . . . . . 18 74 5.1.3. Device related information . . . . . . . . . . . . . 19 75 5.2. Information model for User Plane . . . . . . . . . . . . 21 76 6. ForCES XML model for CUSP info model . . . . . . . . . . . . 25 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 82 10.2. Informative References . . . . . . . . . . . . . . . . . 39 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 85 1. Terminology and Conventions 87 1.1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 1.2. Definitions 95 This document reiterates the terminology defined by the ForCES 96 architecture in various documents for the sake of clarity. 98 FE Model - The ForCES model used for describing resources to be 99 managed/controlled. This includes three components; the modeling 100 of individual Logical Functional Block (LFB model), the logical 101 interconnection between LFBs (LFB topology), and the FE-level 102 attributes, including LFB components, capabilities and events. 103 The FE model provides the basis to define the information elements 104 exchanged between CEs and FEs in the the ForCES Protocol 105 [RFC5810]. 107 LFB (Logical Functional Block) Class - A template that represents 108 a resource that is being modeled. Most LFBs relate to packet 109 processing in the data path; however, that is not always the case. 110 LFB classes are the basic building blocks of the FE model. 112 LFB Instance - A runtime instantiation of an LFB class. 114 ForCES Component - A ForCES Component is a well-defined, uniquely 115 identifiable and addressable ForCES model building block. A 116 component has a 32-bit ID, name, type, and an optional synopsis 117 description. These are often referred to simply as components. 119 ForCES Protocol - Protocol that runs in the Fp reference points in 120 the ForCES Framework [RFC3746]. 122 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 123 architecture that defines the ForCES protocol messages, the 124 protocol state transfer scheme, and the ForCES protocol 125 architecture itself as defined in the ForCES Protocol 126 Specification [RFC5810]. 128 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 129 ForCES protocol architecture that uses the capabilities of 130 existing transport protocols to specifically address protocol 131 message transportation issues, such as how the protocol messages 132 are mapped to different transport media (like TCP, IP, ATM, 133 Ethernet, etc.), and how to achieve and implement reliability, 134 ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that 135 is mandated for ForCES. 137 2. Introduction 139 The ForCES architecture comprises: 141 1. Data model definition [RFC5812] serving as a basis for the 142 architecture constructs acted on by the protocol. 144 2. The ForCES protocol (PL) [RFC5810] which acts on the model 145 component constructs for the purpose of control/management. 147 3. A transport mapping layer(TML) which takes the PL constructs and 148 maps them to underlying convenient transport(s) and then delivers 149 them to the target end points. Currently there is only one 150 standardized TML based on SCTP; [RFC5811]. however more could be 151 defined - example QUIC [I-D.ietf-quic-transport] appears to be a 152 very good fit. 154 This document presents the ForCES architecture as a basis for CUSP. 155 For contextual overview, any performance numbers or prescribed 156 "experience" in this document are based on deployment experience over 157 many years at large and small deployment environments for embedded, 158 cloud as well as data centre environments. Some of these deployments 159 (still operational at time of writting) have been publicly hinted at 160 in media [media1], [media2]. 162 3. ForCES overview 164 In this section we present a quick overview of the ForCES 165 architecture. The reader is encouraged to read the relevant 166 documents, in particular 5810 [RFC5810], 5812 [RFC5812] and 5811 167 [RFC5811]. 169 The origins of ForCES lie in the desire to separate control and 170 datapath; where "datapath" was intended to be packet processing 171 resources. Over time, however, due to the convenience of the ForCES 172 architecture it has been used for controlling and managing arbitrary 173 (other than packet processing) resources. As long as one can 174 abstract the resources using the ForCES model, the protocol semantics 175 allows using ForCES protocol to control and manage said resources. 177 In the case of the CUSP BNG information model 178 [I-D.cuspdt-rtgwg-cu-separation-infor-model], as we will show later 179 the attributes such as interfaces, user statistics and QoS parameters 180 can all be modeled as resources. 182 3.1. ForCES protocol 184 The ForCES protocol features can be summarized as: 186 1. Transport independence. The ForCES protocol is intended to run 187 on a variety of chosen protocols. This was design intent to 188 separate the PL from the different transports for given 189 resources and environments. As an example, one of the original 190 desires was to directly run over PCI-Express. 192 2. Simplified ForCES layer when possible: 194 * Security is left up to the transport choice keeping the 195 ForCES layer simple. As an example, RFC 5811 defines running 196 ForCES on top of SCTP with IPSEC for security. TLS has been 197 introduced also in deployments over time with SCTP, although 198 no standards docs have been published for this. 200 * Optional configurable Controller high availability. 201 FEs(resource owners) when desired can connect to multiple 202 controllers in both cold or hot standby mode [RFC5810], 203 [RFC7121]. 205 * Controller-controller connectivity could be taken care of by 206 other existing technologies. For example, in known 207 deployments of ForCES controller to controller connectivity 208 and mastership delegation has been taken care by using 209 specialized control applications that interact with external 210 consensus-driven infrastructure implementations such as the 211 various Raft-based utilities. 213 3. Transport requirements. Deployment experience with ForCES as 214 depicted in the SCTP TML (RFC 5811 [RFC5811]) has shown an 215 absolute need for a variety of shades of reliability. Requests 216 from the control to the resource must be reliably delivered, 217 immediately (think a FIB update) and so are the responses back. 218 However, transactions like synchronous reports of statistics 219 could afford to be lost once in a while; in other words 220 retransmitting such stats is not useful since they are 221 monotonically incrementing. This helps reduce noise in 222 situations of congestion. Likewise, packet redirects coming 223 from outside the box could afford to be lost since the end peer 224 will end up retransmitting anyways. Think OSPF link state 225 updates for example or BGP on top of TCP. 227 4. Node overload. Deployment experience has shown the need to 228 protect against node overload in a work-conserving mode (thus 229 optimal resource usage). The SCTP TML prioritizes both compute 230 and wire resources to favor requests made to the controlled- 231 resource as well as responses back to the controller over 232 events; whereas, events are prioritized over redirect packets. 233 With this approach, there is no need to provide hacks and 234 workarounds like non-work conserving approaches (such as rate 235 limiting redirects to the controller). As an example, 236 delivering from the resource owner (FE) a SET response to a 237 request to update a FIB entry is considered more important than 238 delivering an event for a link going down (then back up); the 239 link event will be prioritized over an externally sourced BGP 240 packet requiring further controller processing. 242 5. Transactional capabilities in the form of 2 phase commits. 244 6. Wire Serialization. Encoding on the wire is binary. The data 245 model is sufficient to describe the content on the wire. 247 7. Transactional scalability, low latency and high throughput. The 248 original desire of ForCES was to be able to achieve very high 249 throughput transactions for the purpose of updating one or more 250 datapath tables (depending on the table contents, achieving 10s 251 to 100s of thousands of table updates/second is possible). It 252 has been demonstrated in deployments that ForCES supports these 253 throughput numbers along with supporting handling of millions of 254 events per seconds. The choice of making the underlying 255 protocol as binary, topped with allowing for command batching 256 allows the protocol to achieve these goals. 258 8. Various execution modes for transactions {Execute-all-or-none, 259 Execute-until-error, Execute-all-despite-errors}. The default 260 mode of execution in ForCES is the atomic Execute-all-or-none 261 where the resource controller(CE) asks the resource owner(FE) to 262 run a transaction and abort if anything fails. The reader is 263 referred to look at [RFC5810] for more details. 265 9. Communication methods. ForCES provides two communication 266 methods for a controller to receive data from the device, namely 267 request/response and publish/subscribe. ForCES allows the 268 controller at any time to access (request) any resource, and 269 allows for a controller to subscribe to any supported resources 270 events. 272 10. API affinity. The ForCES architecture provides (very) few 273 simple protocol verbs which act upon a multitude of nouns as 274 represented by the ForCES model. This allows powerful 275 programmatic interfaces i.e. the "API" construct boils down to a 276 formulation of operations in the form of a "verb" or a command 277 acting on a set "nouns" (describing a resource path) followed by 278 "optional arguments" in the form of data. The grammar could be 279 described as: 281 [Data] 283 In other words, the ForCES semantic allows composing of rich 284 services on top of the basic grammar. The expressive simplicity 285 of the protocol is achieved due to the few verbs which act on 286 the agreed-to modeled LFB components. The protocol is totally 287 agnostic of the nature of the resource being controlled/managed. 288 It is up to the modeler to describe the resource in the manner 289 that is fitting (although frowned-upon, one could describe the 290 resource model exactly as it is implemented and reduce the 291 generalities and therefore translation overhead). The model is 292 highly extensible and for this reason, the knowledge of the 293 resource control is offloaded to the service layer and a basic 294 infrastructure is all that is needed. 296 The ForCES verbs are: {GET, SET, DELETE, REPORT and a few 297 helpers}. 299 11. Traffic sensitive protocol level connectivity detection. ForCES 300 layer heartbeats could be sent in either or both directions. 301 Heartbeats, however are only sent when the link is idle. 303 12. Dynamic association of FEs to CEs. FEs register and unregister 304 to controllers and advertise their capabilities and capacities. 306 3.2. ForCES Model 308 The ForCES Model features can be summarized as: 310 1. Data model modularity through LFB class definition. 312 2. Data model type definitions via atomic types, complex/compound 313 types, grouping of compound types in the form of structures and 314 indexed/keyed tables which then end up composing addressable 315 components within an LFB class. 317 3. Hierarchical/tree definition of control/config/state components 318 which is acted on by a controller via the ForCES protocol. 320 4. Information-modeled metadata and expectations. 322 5. Built in LFB class resource capability definition/advertisement. 324 6. Publish/subscribe LFB event model with expressive trigger and 325 report definitions. Filters include: 327 * Hysteresis - used to suppress generation of notifications for 328 oscillations around a condition value. Example, "generate an 329 event if the link laser goes below 10 or goes above 15". 331 * Count - used to suppress event generation around occurrence 332 count. Example, "report the event to the client only after 5 333 consecutive occurrences". 335 * Time interval - used to suppress event generation around a 336 time limit. Example, "Generate an event if table foo row 337 hasn't been used in the last 10 minutes". 339 There could be multiple filters defined per event. Example of 340 compound filtering: "Generate an event when the count reaches 5 341 or every 10 minutes when there is at least one event". 343 7. Data model flexibility/extensibility through augmentations, and 344 inheritance. 346 8. Backward and forward compatibility via LFB design and versioning 347 rules. 349 9. Formal constraints for validation of defined components. 351 4. Meeting CUSP requirements 353 This section describes how ForCES meets the CUSP requirements 354 [I-D.cuspdt-rtgwg-cusp-requirements]. We hope to convince the reader 355 that there already exists a robust IETF architecture which has a 356 large deployment experience that meets all the CUSP requirements. 358 4.1. Transmit information tables 360 One of the main requirements for the CUSP protocol is the ability to 361 efficiently transmit information tables. In a few words, ForCES is a 362 wire-optimized protocol able to efficiently send and receive data. 363 The following list addresses each of the stated requirements inCUSP 364 requirements [I-D.cuspdt-rtgwg-cusp-requirements]. 366 REQ1: "The separation protocol SHOULD be lightweight to support at 367 least 2000 bytes for at least 2000 users per second." 369 For the protocol throughput, this translates to support at 370 least 4Mbytes per second. There are no limitations in the 371 protocol or architecture that constrain throughput. Typical 372 throughput constraints observed in deployments tend to be wire 373 bandwidth or in certain cases accessing ASIC for setting or 374 dumping tables. ForCES deployments in real production, 375 depending on environment have been demonstrated to support 10s 376 to 100s thousands of table updates and millions of event per 377 second. 379 REQ2: "The separation protocol SHOULD support data encoded as either 380 XML or binary." 382 ForCES encodes formalized modeled data values as binary to be 383 efficient on the wire as discussed earlier. RFC 5812 384 [RFC5812] defines the data model which is carried in the 385 protocol RFC 5810 [RFC5810]. While it is not advisable for 386 reasons of efficiency, one could define content in UTF-8 XML. 388 REQ3: "Batching and command grouping ability SHOULD be provided. 389 Also the protocol MUST have an all-or-nothing semantics." 391 As has been discussed in previous sections of this document, 392 in regards to batching, ForCES inherently provides batching of 393 protocol messages as well as pipelining. Regarding command 394 grouping, ForCES messages are ordered and are received in the 395 order they are sent. Finally, ForCES has an Execution Mode 396 flag that supports, among others, the execute-all-or-none 397 semantic. 399 REQ4: "The protocol SHOULD be able to support at least hundreds of 400 devices and tens of thousands of ports. In effect the 401 protocol field sizes SHOULD correspond to large numbers." 403 ForCES uses unsigned integers of 32 bit size for identifiers. 404 As such, for a specific level of hierarchy, ForCES can address 405 up to 4,294,967,296 unique object, more than enough for this 406 requirement. 408 The authors believes that the ForCES framework meets the requirement 409 to efficiently transmit information tables 411 4.2. Message Priority 413 REQ5: "The separation protocol MUST provide a means to express the 414 protocol message priorities." 416 As has been discussed earlier, the ForCES transport protocol 417 (TML) is responsible for priority levels and currently 418 supports up to 8 different priority levels. The current 419 implementation of TML, SCTP-TML supports three priority 420 channels, a high priority, reliable channel, a medium 421 priority, semi-reliable channel and a low priority, unreliable 422 channel. 424 The authors believe that ForCES meets the protocol message priority 425 requirements. 427 4.3. Reliability 429 REQ6: "The separation protocol MUST provide a heartbeat monitoring 430 mechanism which SHOULD have the ability to distinguish whether 431 the interruption is an actual failure." 433 ForCES provides a parametrizable heartbeat mechanism that 434 allows the controller to modify the frequency of the 435 heartbeats and a piggybacking mechanism where protocol 436 messages are considered heartbeats themselves and as such 437 reduce the number of individual heartbeats. ForCES also 438 allows the controller to turn off the heartbeat mechanism, 439 making the device ignore the heartbeats, for example in the 440 case of a planned update while the controller is being 441 updated. ForCES is able to support these heartbeat mechanism 442 features since these parameters have been modeled as resources 443 and as such are made available to the controller for 444 configuration. 446 The authors believe ForCES meets the requirements for reliability. 448 4.4. Support for secure communication 450 REQ7: "The separation protocol MUST protect against man-in-the- 451 middle attacks and security in a variety of scenarios. TLS 452 and IPsec are good candidates." 454 As has been discussed earlier, ForCES's TML is responsible for 455 security services and is expected to employ TLS or IPsec. 456 Specifically, the current defined TML, SCTP-TML, utilizes 457 IPsec. ForCES has also been deployed with the use of TLS with 458 SCTP. 460 The authors believe ForCES meets the security requirements. 462 4.5. Version negotiation 464 REQ8: "The separation protocol MUST provide some mechanisms to 465 perform version negotiation for protocol versions." 467 ForCES provides different layers of version negotiation. 468 There is a protocol field that specifies the current version 469 of the ForCES protocol with which the controller and the 470 device can agree to. In regards to the various supported 471 resource (LFB) models, after the association has been 472 established between the controller and the device, the 473 controller can request and discover the current supported 474 version of LFBs classes. 476 The authors believe that ForCES meets the requirements version 477 negotiation requirements. 479 4.6. Capability Exchange 481 REQ9: "The protocol MUST provide mechanisms to exchange the device's 482 capabilities." 483 ForCES provides a means to model each resource's capabilities 484 in detail. The capabilities can then be queried at any time 485 by the controller. Thus the controller is able to determine, 486 after the association has been complete, the capabilities of 487 each resource. 489 The authors believe that ForCES meets the protocol capability 490 exchange requirement. 492 4.7. CP primary/backup capability 494 REQ10: "CUSP should provide mechanisms to support backup CPs. It 495 should provide a mechanism to determine which CP is the 496 primary and a mechanism to switch between primary and backup." 498 The ForCES architecture has been engineered with high 499 availability mechanisms such as cold and hot standby, as 500 defined by RFC7121 [RFC7121]. ForCES allows a single master 501 writer and multiple backups which can act as readers (1+M). 502 This was done for the sake of simplicity of the HA mode. 503 ForCES allows the controller to specify which is the master 504 and the order a backup will be selected from a pool of backup 505 controllers. When the master is down, the device sends out an 506 event and selects the next best candidate. 508 The authors believe that ForCES meets the protocol primary and backup 509 requirement. 511 4.8. Event Notification 513 REQ11: "The protocol SHOULD be able to asynchronously notify the 514 controller of events. Examples are sending responses back, 515 user tracing, statistics collection and report user detected." 517 The ForCES architecture exposes a publish/subscribe event 518 model. The events are published using the ForCES model on a 519 per resource level. An event definition constitutes of the 520 event target, meaning the monitored value, the trigger and the 521 reported value. ForCES allows the controller to subscribe to 522 any event defined by any resource. In addition ForCES also 523 allows filtering of events for further refinement. 525 The authors believe this requirement is fully met by ForCES. 527 4.9. Query Statistics 529 REQ12: " The CUSP protocol MUST provide a way to query statistics." 531 As discussed earlier, ForCES provides two distinct approaches 532 to receiving statistics. Either by the controller polling the 533 device to get the updated values, or the controller can 534 subscribe to event notification and receive periodic updated 535 statistics. 537 The authors believe this requirement is fully met by ForCES. 539 4.10. Beyond the CUSP requirements 541 One requirement that believe is important but is not specified in the 542 CUSP document is the separation of the protocol and the data model. 544 A singular protocol with varying data models makes it feasible to 545 cater for various access technologies: it allows a single control 546 interface for multi-access devices that provide termination of 547 subscribers over fixed access nodes(DSLAM and OLTs), fixed-wireless 548 and hybrid access. ForCES is an excellent fit for reasons described 549 thus far. In addition, any changes or new types of access 550 technologies will not require a protocol change, rather a new LFB 551 model definition. 553 5. Control and user plane information models 555 In this section we provide individual ForCES based XML models for 556 different parts of the CUSP information model 558 5.1. Information model for the Control Plane 560 5.1.1. User related information 562 563 564 565 UserID 566 Identification of a user 567 uint32 568 569 570 571 IEEEMac 572 MAC address 573 byte[6] 574 575 576 577 AccessDataType 578 Indicates the protocol being used for the user's 579 access 580 581 uint16 582 583 584 PPPoE 585 586 587 588 IPoE 589 590 591 592 593 594 595 596 UserBasicRow 597 User Basic Information 598 599 600 userID 601 The user id 602 UserID 603 604 605 MacAddress 606 The MAC Address of the user 607 IEEEMAC 608 609 610 AccessType 611 The access type of the user 612 613 AccessDataType 614 615 616 SessionID 617 Identifier of PPPoE session 618 619 uint32 620 621 622 InnerVLANID 623 Inner VLAN ID 624 625 uint16 626 627 628 OuterVLANID 629 Outer VLAN ID 630 631 uint16 632 633 634 UserInterface 635 Binding interface of a specific user 636 637 uint32 638 639 640 641 642 IPv4InfoRow 643 IPv4 User Information 644 645 646 userID 647 The user id 648 UserID 649 650 651 UserIPv4 652 A user's IPv4 Address 653 byte[4] 654 655 656 MaskLength 657 The subnet mask length 658 uint32 659 660 661 Gateway 662 The user's gateway 663 byte[4] 664 665 666 VRF 667 Identifier of VRF instance 668 uint32 669 670 672 673 674 675 IPv6SelectorType 676 IPv6 Type selector 677 678 uchar 679 680 681 IPv6Address 682 Value contains an IPv6 Address 683 684 685 PDAddress 686 Value contains PD address 687 688 689 690 691 692 IPv6InfoRow 693 IPv6 User Information 694 695 696 userID 697 The user id 698 UserID 699 700 701 IPv6Type 702 IPv6 Type selector 703 IPv6SelectorType 704 705 706 IPv6orPD 707 An IPv6 address or a PD 708 byte[16] 709 710 711 PrefixLen 712 The prefix length for either an IPv6 Address 713 or Prefix Delegation 714 715 uint32 716 717 718 VRF 719 Identifier of VRF instance 720 uint32 721 722 723 724 725 726 RateSizeType 727 Rate and size for committed and peak 728 729 730 731 CIR 732 Commited Information Rate 733 734 uint32 735 736 737 PIR 738 Peak Information Rate 739 uint32 740 741 742 CBS 743 Commited Burst Size 744 uint32 745 746 747 PBS 748 Peak Burst Size 749 uint32 750 751 752 753 754 QoSRow 755 User's QoS 756 757 758 userID 759 The user id 760 UserID 761 762 763 RateSize 764 Rate and size for committed and peak 765 766 RateSizeType 767 768 769 QoSProfile 770 Standard profile from operator 771 uint32 772 773 774 775 776 777 778 ControlPlaneUser 779 The control plane components for users 780 781 1.0 782 783 784 UserInfo 785 User Informational model 786 787 788 789 UserBasic 790 User Basic Information 791 UserBasicRow 792 793 794 IPv4Info 795 Optional IPv4 information 796 797 IPv4InfoRow 798 799 800 IPv6Info 801 Optional IPv6 information 802 803 IPv6InfoRow 804 805 806 QoSInfo 807 Optional QoS Profile 808 809 QoSRow 810 811 812 813 814 815 817 819 Figure 1: User related information 821 5.1.2. Interface related information 823 824 825 826 827 ServiceDataType 828 Service Type 829 830 831 PPPonly 832 If true, interface only supports 833 PPP user 834 uint16 835 836 837 IPv4Trig 838 If true, interface supports the 839 user being triggered to connect to 840 internet via IPv4 841 uint16 842 843 844 IPv6Trig 845 If true, interface supports the 846 user being triggered to connect to 847 internet via IPv6 848 uint16 849 850 851 NDTrig 852 If true, interface supports the 853 user being triggered to connect to 854 Internet via neighbor discovery 855 uint16 856 857 858 ARPProxy 859 If true, ARP Proxy is enabled on 860 this interface 861 uint16 862 863 864 865 866 867 InterfaceInfoRow 868 Interface information 869 870 871 IfIndex 872 Index assigned to an interface 873 uint32 874 875 876 bas_enable 877 Bas enable flag 878 uint16 879 880 881 ServiceType 882 Service Type 883 ServiceDataType 884 885 886 887 888 889 890 ControlPlaneInterface 891 The control plane components for interfaces 892 893 1.0 894 895 896 Interface 897 Interface Information 898 899 InterfaceInfoRow 900 901 902 903 904 906 Figure 2: Interface related information 908 5.1.3. Device related information 910 911 912 913 AddressRow 914 Address field distribute table row 915 916 917 918 AddressSegment 919 Address Segment 920 byte[4] 921 922 923 AddressSegmentMask 924 Address Segment Mask 925 byte[4] 926 927 928 AddressSegmentVRF 929 Address Segment VRF instance 930 identifier 931 uint32 932 933 934 IfIndex 935 Index assigned to an interface 936 937 uint32 938 939 940 maskLength 941 Length of the mask 942 uint32 943 944 945 946 947 948 949 ControlPlaneDevice 950 The control plane components for device 951 952 1.0 953 954 955 Device 956 Device Information 957 958 AddressRow 959 960 962 963 964 966 Figure 3: Device related information 968 5.2. Information model for User Plane 970 971 972 973 UserID 974 Identification of a user 975 uint32 976 977 978 979 IEEEMac 980 MAC address 981 byte[6] 982 983 984 985 IfTypeDataType 986 Type of Interface 987 988 uint32 989 990 991 Ethernet 992 An ethernet interface 993 994 995 996 GE 997 A Gigabit Ethernet interface 998 999 1000 1001 EtherTrunk 1002 An EtherTrunk interfaces 1003 1004 1005 1006 1007 1008 1009 1010 LinkTypeDataType 1011 Link Types 1012 1013 uint32 1014 1015 1016 PointToPoint 1017 A point to point link 1018 1019 1020 1021 Broadcast 1022 A broadcast link 1023 1024 1025 Multipoint 1026 A multipoint link 1027 1028 1029 1030 1031 1032 1033 IfStateType 1034 Current operational state of the 1035 interface 1036 1037 uchar 1038 1039 1040 Up 1041 Up 1042 1043 1044 Down 1045 Down 1046 1047 1048 Testing 1049 In testing mode 1050 1051 1052 Unknown 1053 Status cannot be determined 1054 1055 1056 1057 Dormant 1058 Dormant 1059 1060 1061 NotPresent 1062 Component is missing 1063 1064 1065 1066 1067 1068 1069 1070 PortResourcesRow 1071 Port resources table row 1072 1073 1074 IfIndex 1075 Index assigned to an interface 1076 uint32 1077 1078 1079 IfName 1080 Name of the interface 1081 string[64] 1082 1083 1084 IfType 1085 Type of Interface 1086 IfTypeDataType 1087 1088 1089 LinkType 1090 Link Types 1091 LinkTypeDataType 1092 1093 1094 MacAddress 1095 The MAC Address of the link 1096 IEEEMAC 1097 1098 1099 IfState 1100 Current operational state of the 1101 interface 1102 IfStateType 1103 1104 1105 1106 1107 1108 StatDataType 1109 Traffic Type 1110 1111 uint32 1112 1113 1114 IPv4 1115 IPv4 traffic 1116 1117 1118 IPv6 1119 IPv6 traffic 1120 1121 1122 1123 1124 1125 1126 TrafficStatisticsRow 1127 Traffic stats per user 1128 1129 1130 userID 1131 The user id 1132 UserID 1133 1134 1135 StatType 1136 Traffic Type 1137 StatDataType 1138 1139 1140 IngressPackets 1141 Ingress packet stats 1142 uint64 1143 1144 1145 IngressByte 1146 Ingress byte stats 1147 uint64 1148 1149 1150 EgressPackets 1151 Egress packet stats 1152 uint64 1153 1154 1155 EgressBytes 1156 Egress byte stats 1157 uint64 1158 1159 1160 1161 1162 1163 1164 1165 User 1166 The user plane components 1167 1.0 1168 1169 1170 PortResourceTable 1171 The port resource table for available 1172 network resources 1173 1174 PortResourcesRow 1175 1176 1177 1178 StatisticsTable 1179 Stats per user 1180 1181 TrafficStatisticsRow 1182 1183 1184 1185 1186 1188 Figure 4: Information model for User Plane 1190 6. ForCES XML model for CUSP info model 1192 In this section we provide the whole ForCES based XML model of the 1193 information model of the CUSP BNG. 1195 1196 1198 1199 1200 Arbitrary 1201 Any kind of packet 1203 1204 1205 1206 1207 1208 UserID 1209 Identification of a user 1210 uint32 1211 1212 1213 1214 IEEEMac 1215 MAC address 1216 byte[6] 1217 1218 1219 1220 AccessDataType 1221 Indicates the protocol being used for the user's 1222 access 1223 1224 uint16 1225 1226 1227 PPPoE 1228 1229 1230 1231 IPoE 1232 1233 1234 1235 1236 1237 1238 1239 IfTypeDataType 1240 Type of Interface 1241 1242 uint32 1243 1244 1245 Ethernet 1246 An ethernet interface 1247 1248 1249 1250 GE 1251 A Gigabit Ethernet interface 1252 1253 1254 1255 EtherTrunk 1256 An EtherTrunk interfaces 1257 1258 1259 1260 1261 1262 1263 1264 LinkTypeDataType 1265 Link Types 1266 1267 uint32 1268 1269 1270 PointToPoint 1271 A point to point link 1272 1273 1274 1275 Broadcast 1276 A broadcast link 1277 1278 1279 Multipoint 1280 A multipoint link 1281 1282 1283 1284 1285 1286 1287 IfStateType 1288 Current operational state of the 1289 interface 1290 1291 uchar 1292 1293 1294 Up 1295 Up 1296 1297 1298 Down 1299 Down 1300 1301 1302 Testing 1303 In testing mode 1304 1305 1306 Unknown 1307 Status cannot be determined 1308 1309 1310 1311 Dormant 1312 Dormant 1313 1314 1315 NotPresent 1316 Component is missing 1317 1318 1319 1320 1321 1322 1323 1324 PortResourcesRow 1325 Port resources table row 1326 1327 1328 IfIndex 1329 Index assigned to an interface 1330 uint32 1331 1332 1333 IfName 1334 Name of the interface 1335 string[64] 1336 1337 1338 IfType 1339 Type of Interface 1340 IfTypeDataType 1341 1342 1343 LinkType 1344 Link Types 1345 LinkTypeDataType 1346 1347 1348 MacAddress 1349 The MAC Address of the link 1350 IEEEMAC 1351 1352 1353 IfState 1354 Current operational state of the 1355 interface 1356 IfStateType 1357 1358 1359 1360 1361 StatDataType 1362 Traffic Type 1363 1364 uint32 1365 1366 1367 IPv4 1368 IPv4 traffic 1369 1370 1371 IPv6 1372 IPv6 traffic 1373 1374 1375 1376 1377 1378 1379 1380 TrafficStatisticsRow 1381 Traffic stats per user 1382 1383 1384 userID 1385 The user id 1386 UserID 1387 1388 1389 StatType 1390 Traffic Type 1391 StatDataType 1392 1393 1394 IngressPackets 1395 Ingress packet stats 1396 uint64 1397 1398 1399 IngressByte 1400 Ingress byte stats 1401 uint64 1402 1403 1404 EgressPackets 1405 Egress packet stats 1406 uint64 1407 1408 1409 EgressBytes 1410 Egress byte stats 1411 uint64 1412 1413 1414 1415 1416 1417 UserBasicRow 1418 User Basic Information 1419 1420 1421 userID 1422 The user id 1423 UserID 1424 1425 1426 MacAddress 1427 The MAC Address of the user 1428 IEEEMAC 1429 1430 1431 AccessType 1432 The Access Type of the user 1433 1434 AccessDataType 1435 1436 1437 SessionID 1438 Identifier of PPPoE session 1439 1440 uint32 1441 1442 1443 InnerVLANID 1444 Inner VLAN ID 1445 1446 uint16 1447 1448 1449 OuterVLANID 1450 Outer VLAN ID 1451 1452 uint16 1453 1454 1455 UserInterface 1456 Binding interface of a specific user 1457 1458 uint32 1459 1460 1461 1462 1463 IPv4InfoRow 1464 IPv4 User Information 1465 1466 1467 userID 1468 The user id 1469 UserID 1470 1471 1472 UserIPv4 1473 A user's IPv4 Address 1474 byte[4] 1475 1476 1477 MaskLength 1478 The subnet mask length 1479 uint32 1480 1481 1482 Gateway 1483 The user's gateway 1484 byte[4] 1485 1486 1487 VRF 1488 Identifier of VRF instance 1489 uint32 1490 1492 1493 1494 1495 1496 IPv6SelectorType 1497 IPv6 Type selector 1498 1499 uchar 1500 1501 1502 IPv6Address 1503 Value contains an IPv6 Address 1504 1505 1506 PDAddress 1507 Value contains PD address 1508 1509 1510 1511 1512 1513 IPv6InfoRow 1514 IPv6 User Information 1515 1516 1517 userID 1518 The user id 1519 UserID 1520 1521 1522 IPv6Type 1523 IPv6 Type selector 1524 IPv6SelectorType 1525 1526 1527 IPv6orPD 1528 An IPv6 address or a PD 1529 byte[16] 1530 1531 1532 PrefixLen 1533 The prefix length for either an IPv6 Address 1534 or Prefix Delegation 1535 1536 uint32 1537 1538 1539 VRF 1540 Identifier of VRF instance 1541 uint32 1542 1543 1544 1545 1546 1547 RateSizeType 1548 Rate and size for committed and peak 1549 1550 1551 1552 CIR 1553 Commited Information Rate 1554 1555 uint32 1556 1557 1558 PIR 1559 Peak Information Rate 1560 uint32 1561 1562 1563 CBS 1564 Commited Burst Size 1565 uint32 1566 1567 1568 PBS 1569 Peak Burst Size 1570 uint32 1571 1572 1573 1574 1575 QoSRow 1576 User's QoS 1577 1578 1579 userID 1580 The user id 1581 UserID 1582 1583 1584 RateSize 1585 Rate and size for committed and peak 1586 1587 RateSizeType 1589 1590 1591 QoSProfile 1592 Standard profile from operator 1593 uint32 1594 1595 1596 1597 1598 1599 1600 ServiceDataType 1601 Service Type 1602 1603 1604 PPPonly 1605 If true, interface only supports 1606 PPP user 1607 uint16 1608 1609 1610 IPv4Trig 1611 If true, interface supports the 1612 user being triggered to connect to 1613 internet via IPv4 1614 uint16 1615 1616 1617 IPv6Trig 1618 If true, interface supports the 1619 user being triggered to connect to 1620 internet via IPv6 1621 uint16 1622 1623 1624 NDTrig 1625 If true, interface supports the 1626 user being triggered to connect to 1627 Internet via neighbor discovery 1628 uint16 1629 1630 1631 ARPProxy 1632 If true, ARP Proxy is enabled on 1633 this interface 1634 uint16 1635 1636 1638 1639 1640 1641 InterfaceInfoRow 1642 Interface information 1643 1644 1645 IfIndex 1646 Index assigned to an interface 1647 uint32 1648 1649 1650 bas_enable 1651 Bas enable flag 1652 uint16 1653 1654 1655 ServiceType 1656 Service Type 1657 ServiceDataType 1658 1659 1660 1661 1662 1663 AddressRow 1664 Address field distribute table row 1665 1666 1667 1668 AddressSegment 1669 Address Segment 1670 byte[4] 1671 1672 1673 AddressSegmentMask 1674 Address Segment Mask 1675 byte[4] 1676 1677 1678 AddressSegmentVRF 1679 Address Segment VRF instance 1680 identifier 1681 uint32 1682 1683 1684 IfIndex 1685 Index assigned to an interface 1686 1687 uint32 1688 1689 1690 maskLength 1691 Length of the mask 1692 uint32 1693 1694 1695 1696 1697 1698 1699 ControlPlaneUser 1700 The control plane components for users 1701 1702 1.0 1703 1704 1705 UserInfo 1706 User Informational model 1707 1708 1709 1710 UserBasic 1711 User Basic Information 1712 UserBasicRow 1713 1714 1715 IPv4Info 1716 Optional IPv4 information 1717 1718 IPv4InfoRow 1719 1720 1721 IPv6Info 1722 Optional IPv6 information 1723 1724 IPv6InfoRow 1725 1726 1727 QoSInfo 1728 Optional QoS Profile 1729 1730 QoSRow 1731 1732 1733 1735 1736 1737 1738 1739 ControlPlaneInterface 1740 The control plane components for interfaces 1741 1742 1.0 1743 1744 1745 Interface 1746 Interface Information 1747 1748 InterfaceInfoRow 1749 1750 1751 1752 1753 1754 ControlPlaneDevice 1755 The control plane components for device 1756 1757 1.0 1758 1759 1760 Device 1761 Device Information 1762 1763 AddressRow 1764 1765 1766 1767 1768 1769 User 1770 The user plane components 1771 1.0 1772 1773 1774 PortResourceTable 1775 The port resource table for available 1776 network resources 1777 1778 PortResourcesRow 1779 1780 1781 1782 StatisticsTable 1783 Stats per user 1784 1785 TrafficStatisticsRow 1786 1787 1788 1789 1790 1791 1793 Figure 5: ForCES based CUSP Info Model 1795 7. Acknowledgements 1797 Thanks to Joel Halpern and Diego Lopez for discussions (during IETF 1798 104) that led to the creation of this document. 1800 The activities of Evangelos Haleplidis have been carried out with 1801 funding provided via the StandICT.eu initiative, funded with Grant 1802 Agreement no. 780439 under the European Commission's Horizon 2020 1803 Programme. 1805 8. IANA Considerations 1807 TBD 1809 9. Security Considerations 1811 TBD 1813 10. References 1815 10.1. Normative References 1817 [I-D.cuspdt-rtgwg-cu-separation-infor-model] 1818 Hu, S., Eastlake, D., Wang, Z., Lopezalvarez, V., Qin, F., 1819 Li, Z., and T. Chua, "Information Model of Control-Plane 1820 and User-Plane Separation BNG", draft-cuspdt-rtgwg-cu- 1821 separation-infor-model-03 (work in progress), October 1822 2018. 1824 [I-D.cuspdt-rtgwg-cusp-requirements] 1825 Hu, S., Lopezalvarez, V., Qin, F., Li, Z., Chua, T., 1826 Eastlake, D., Wang, Z., and J. Song, "Requirements for 1827 Control Plane and User Plane Separated BNG Protocol", 1828 draft-cuspdt-rtgwg-cusp-requirements-03 (work in 1829 progress), October 2018. 1831 [I-D.ietf-quic-transport] 1832 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1833 and Secure Transport", draft-ietf-quic-transport-23 (work 1834 in progress), September 2019. 1836 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1837 "Forwarding and Control Element Separation (ForCES) 1838 Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, 1839 . 1841 [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., 1842 Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and 1843 J. Halpern, "Forwarding and Control Element Separation 1844 (ForCES) Protocol Specification", RFC 5810, 1845 DOI 10.17487/RFC5810, March 2010, 1846 . 1848 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 1849 Layer (TML) for the Forwarding and Control Element 1850 Separation (ForCES) Protocol", RFC 5811, 1851 DOI 10.17487/RFC5811, March 2010, 1852 . 1854 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1855 Element Separation (ForCES) Forwarding Element Model", 1856 RFC 5812, DOI 10.17487/RFC5812, March 2010, 1857 . 1859 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, 1860 "High Availability within a Forwarding and Control Element 1861 Separation (ForCES) Network Element", RFC 7121, 1862 DOI 10.17487/RFC7121, February 2014, 1863 . 1865 10.2. Informative References 1867 [media1] "Forces-vzn", , 06 2016, 1868 . 1871 [media2] "Forces-vzn2", , 06 2016, 1872 . 1875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1876 Requirement Levels", BCP 14, RFC 2119, 1877 DOI 10.17487/RFC2119, March 1997, 1878 . 1880 Authors' Addresses 1882 Evangelos Haleplidis 1883 M. Aleksandrou 29B 1884 Paiania, Athens 19002 1885 Greece 1887 Email: ehalep@gmail.com 1889 Jamal Hadi Salim 1890 Mojatatu Networks 1891 Suite 200, 15 Fitzgerald Road 1892 Ottawa, Ontario K2H 9G1 1893 Canada 1895 Email: hadi@mojatatu.com