idnits 2.17.1 draft-cups-rtgwg-cu-separation-requirement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-23 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-22 ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Bcause Workgroup T. Yu 3 Internet-Draft March 8, 2019 4 Intended status: Informational 5 Expires: September 9, 2019 7 Requirements for BNG Control-plane And User-plane Separation 8 draft-cups-rtgwg-cu-separation-requirement-00 10 Abstract 12 This document aims to abstract reqruriment of an extensible and 13 flexible Control Plane (CP) and User Plane (UP) Separated BNG 14 Architecture. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 9, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Specification of Requirements . . . . . . . . . . . . . . . . 2 52 3. CU Seperation Basic Model . . . . . . . . . . . . . . . . . . 3 53 4. Protocol Independent Relay (PIR) . . . . . . . . . . . . . . 3 54 5. Generic-Service Flow Protocol (GSF) . . . . . . . . . . . . . 4 55 6. Management Interface . . . . . . . . . . . . . . . . . . . . 8 56 7. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 59 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 62 1. Introduction 64 The architecture aims to decouple CP and UP. 66 CP focus on protocol signaling processing, service info management, 67 and communication with external servers (e.g. Radius, DHCP servers). 69 Up focus on packet forwarding based on forwarding instructions from 70 CP. 72 CUPS architecture brings significant benefits below: 74 o Simplified management: UP is simplified focus on forwarding 75 behavior. Interactions with service platforms are decoupled to 76 CP. 78 o Higher Resiliency: CPUS architecture allows CP inter-site 79 resiliency and UP multi-homing active-active resiliency. 81 o Fast service provisioning: with a highly abstracted service based 82 interface between CP and UP, CUPS architecture allows fast 83 innovation on CP with minimum changes on UP. 85 o Higher IP address utilization: As IP address management 86 centralized into CP, CP can have the intelligence to optimize the 87 best subnet allocated to UP. 89 2. Specification of Requirements 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. CU Seperation Basic Model 99 To support communication between the Control Plane and User Plane, 100 several interfaces are involved. Figure 1 illustrates the three 101 communication interfaces between CP and UP BNG. 103 +----------------------------------+ 104 | | 105 | BNG-CP | 106 | | 107 +--+--------------+--------------+-+ 108 | | | 109 1.PIR | 2.GSF| 3.Magment | 110 | | | 111 | | | 112 +--+--------------+-------------+--+ 113 | | 114 | BNG-UP | 115 | | 116 +----------------------------------+ 118 Figure 1: Interfaces between the BNG-CP and the BNG-UP 120 4. Protocol Independent Relay (PIR) 122 To archieve a dis-aggregated system, a protocol independent Relay 123 channel is required. PIP allows BNG to relay signaling protocols to 124 the remote CP instead of processing and maintain status locally. 126 o PIR MUST be protocol independent. It means it has the capability 127 to rely and protocols without extra customization. It can be a 128 Relay channel for any protocols that requires paticipations of CP, 129 e.g. PPP, DHCP, ICMP (with options). 131 o PIR MUST be reliable, in case of packet loss, retransmission 132 applies. PIR SHOULD be TCP based. 134 o PIR MUST provide a secure connectivity between BNG and remote CP. 135 PIR MUST provide authentication mechanism between UP and remote 136 CP. PIR MAY provide encryption between UP and remote CP, e.g. 137 IPSEC. 139 o PIR MUST provide a keepalive/heartbeat mechanism allowing 140 detecting the availability between UP and remote CP. 142 o A UP MUST have the capability to identify protocol packets and 143 relay via PIR. 145 o A UP MUST have the capability to relay part of the protocols to 146 remove server. For example relay DHCP to remote CP but IGMP and 147 PIM remain locally. 149 o PIR MAY be applied in any service access point: vlan-sub 150 interface, PW, GRE, L2TP tunnel, etc. 152 5. Generic-Service Flow Protocol (GSF) 154 GSF protocol is the interface for CP to deliver service based 155 forwarding entries. Also UP will use this interface to notify 156 whether the forwarding entries successfully delivered. 158 GSF SHOULD be highly flexible and extendable considering the variety, 159 complexity of BNG services and possibility of the future service. To 160 achieve this, a "generic-service" is abstracted with requirement 161 below: 163 GSF is designed to be service oriented instead of instruction 164 oriented. GSF defines service module precisely and UP adopts the 165 service to the pipeline itself. 167 o A generic-service MUST have ONE identifier (GSI). The identifier 168 CAN be: 170 * GSI1: intf + sMAC + sIP (normal way of identifing a subscriber) 172 * GSI2: sMAC + sIP + dIP + dIP (subscriber traffic toward a 173 particular platform) 175 * GSI3: dIP with mask (identifying ip pool prefix) 177 * GSI4: sIP with mask (identifying a NAT ip pool input from 178 subscriber private side to internet public) 180 * GSI5: dIP with mask (identifying a NAT ip pool input from 181 internet public side to subscriber private) 183 * GSI6: dIP with mask + dPort with mask (identifying an ACL 184 criteria matching traffic toward specific IP+ port range) 186 * GSI7: intf + VLAN(s) + PPPOE session ID + sMAC + sIP 187 (identifying an PPPOE session over VLAN(s)) 189 * GSI8: intf + sMAC + sIPV6 prefix (identifing a V6 subscriber) 191 GSI SHOULD have the capability of using L2+L3+L4 with mask info to 192 identify a GS, GSI MAY use L5~L7 information to identify a GS. 194 o A generic-service MUST have at least one and MAY have more than 195 one fowarding behavior (GSB). The behavior CAN be: 197 * NSB1: Route recursive. Basic FIB search and forward. An 198 example of this GSB is: direct traffic of a subscriber to a 199 MPLS based core network. 201 * GSB2: A specific GSI. The usage of this behavior includes but 202 not limited: 204 + Service bounding within UP: The behavior of GSI2 is GSI1, 205 which means GSI2 is a sub-service of GSI1. This allows UP 206 process per flow based service + per subscriber based 207 service. 209 + Service channing within UP: The behavior of GSI1 is GSI4, 210 which means NAT need to be done after finishing processing 211 subscriber service. 213 * GSB3: Search a forwarding entry in a specific GSI table. One 214 usage of this behavior is to direct traffic from internet to 215 subscriber side. After processing GSI3, the behavior is to 216 search the right user table in GSI1 table to obtain following 217 user/flow based forwarding entries. 219 * GSB4: Policy based routing, this allows UP to recursive traffic 220 into RSVP-TE LSP, SR-TE LSP (color based also). 222 * GSB5: Service channing, this allows UP to redirect (part of) 223 traffic of subscribers towards remote service platforms (e.g. 224 external NAT platform, cleanning center, DPI). 226 o A generic-service MUST have at least one and MAY have more than 227 one service attribute (GSA). The attribute CAN be: 229 * Service type: specify the GS is subscriber, FIB entry for pool, 230 NAT instance, etc. This attribute is mandontary. 232 * Subscriber ID: this attribute is used to group GSs belong to 233 same subscriber, e.g. V4+V6, flow based(GSI2)+subscriber 234 based(GSI1), fixed + wireless (hybrid-access) 236 * QOS related attribute, e.g.: 238 + fowarding priority(best effort, Assured Forwarding, WRED 239 info, etc.) 241 + policing/shaping speed (CIR, PIR) 243 * Credit/Volumne control. 245 * Subnets for network behind a CPE (framed-routes) 247 * Service alive validation method (e.g. ARP detect for IPOE) 249 * Whether able to be subscribed via OAM channel for traffic 250 counters. This is an enable switch for usage-report. 252 * Inheritance of the attribute: This is used in case of service 253 bounding or channing. This attribute CAN be: independent, 254 inherit, overwrite. 256 Below diagrams give some examples of using GS to compose BNG service 257 flows: 259 GSA GSB 260 |-------------| |---------| 261 | GSI2 | | GSI3 | 262 |-------------| |---------| 263 | GSB1 | | GSB3 | 264 |-------------| |---------| 265 | GSA: | | GSA: | 266 | type=subs | |type=pool| 267 | S-ID=1 | | | 268 |-------------| |---------| 270 GSA' 271 |-------------| 272 | GSI1' | 273 |-------------| 274 | GSB1 | 275 |-------------| 276 | GSA: | 277 | type=subs | 278 | S-ID=2 | 279 |-------------| 281 Subs GS table IP Pool GS table 283 Figure 2: Basic BNG Service Flow 285 Figure 2 shows how to use GS to form basic service flow for IPOE 286 subscribers. 288 Traffic user->network: Search "Subs GS table" based on sMAC and sIP, 289 traffic match GSA entry and get fowarding behavior is normal route 290 recursive. UP will forward traffic based on FIB entries of dIP of 291 the packet, which are learned from internet core. 293 Traffic network->user: Search FIB entries based on dIP will match the 294 IP pool GS table, which is a sub-set of FIB table. The forwarding 295 behavior (GSB3) is to search Subs GS table. UP will search Subs GS 296 table and get the match entry, forward traffic to the interface and 297 vlans of the curresponding subscriber. 299 User->Network: 300 |-----------| |-----------| |-----------| |-----------| 301 | GS1 Table | | GS2 Table | | GS3 Table | | GS4 Table | 302 |-----------| |-----------| |-----------| |-----------| 304 Figure 3: BNG service flow with service channing 306 GS1 table is services of subscribers table, the format example of 307 service in GS1 is as below: 309 ---------------------- 311 GS1-1 313 GSI1-1: dIP = 50.0.0.2, dPort = 520 315 GSB1-1: GSI2-1 and SR-policy with color = gold 317 GSA1-1: service-type: service of subcriber 319 subscriber id = any 321 qos type: ef (inherit) 323 qos speed: cir = 128k (independent) 325 ---------------------- 327 GS1-2 329 GSI1-2: match any 331 GSB1-2: GSI2-1 333 GSA1-2: service-type: service of subcriber 335 subscriber id = any 336 qos type: be (inherit) 338 qos speed: no limit(inherit) 340 ---------------------- 342 GS2 table is subscriber table, the format example is as below: 344 GS2-1 346 GSI2-1: intf = 1/0/2, VLAN = 10, sMAC = 00-20-56-C0-00-0B, sIP = 347 10.123.0.23 349 GSB2-1: GSI3-1 351 GSA2-1: service-type: subcriber 353 subscriber id = 1000 355 qos type: be 357 qos speed: CIR = 10M, PIR = 20M (independent) 359 ---------------------- 361 GS3 table is CGN NAT table, the format example is as below: 363 GS3-1 365 GSI3-1: sIP = 130.123.0.0/24 367 GSB3-1: Route recursive 369 GSA3-1: service-type: CGN NAT 371 ---------------------- 373 The service flow above defines a subscriber with 2 services (VoIP and 374 Internet), with subscriber based QOS (CIR = 10M, PIR = 20M) and 375 service based QOS (VoIP, ef, cir = 128k), VoIP services goes into a 376 gold SR-policy and internet traffic does best effort foewarding with 377 CGN NAT translation. 379 6. Management Interface 381 For CUPS architecture, the CP MUST provide a single point for 382 management of entire "CUPS" BNG. 384 Management interface for the CUPS system MUST provide support for 385 both configuration of UPs, and state retrieval. 387 Management interface is used to report status, statistics, events 388 from UP to CP. And also CP can use interface to query status of UP. 389 This interface uses NETCONF protocol. 391 Netconf working group has already (or almost) standardized couple of 392 mechanism can be used in CPUS architecture: 394 [I-D.ietf-netconf-subscribed-notifications] provides the mechanism of 395 notifing any status changes of subscribers, resource utilisation 396 etc.. 398 [I-D.ietf-netconf-yang-push] provides the mechanism of a continuous, 399 customized stream of updates from a YANG datastore. 401 UP Should have YANG datastores and subscribed by CP below: 403 o GS status datastore: maintain session status, in case of status 404 change of GS, notification will be sent to CP. For example: 406 * Subscriber status changes, due to failure of heartbeat 407 detection, redial of a subscriber, change of stack statue (V4, 408 V6), change of hybrid-access bundling status. 410 * NAT session table aged out. 412 * Packet loss of particular policer 414 o GS status datastore: maintain traffic statistics where applicable. 415 For example: 417 * Traffic counter of VoIP service. 419 * Traffic counter of NAT table. 421 [RFC5539] provides security mechanism for management interface. 423 7. Resiliency 425 o CP MUST provide resiliency mechanism, it MAY be intra-site or 426 inter-site resiliency. 428 o UP SHOULD NOT synchronise subscriber forwarding entries across 429 each other to achieve resiliency. 431 o UP SHOULD provide multi-homed connection for BNG access links. 433 o UP SHOULD provide single-active resiliency 435 o CPUS SHOULD provide hot and warm resiliency mechanism. Hot 436 resiliency means forwarding entries are pre-installed on both 437 active and backup, where warm not pre-installed, re-installation 438 applies in case of UP failure. 440 o CUPS MAY provide a mix of hot and warm resiliency. E.g. BNG-A is 441 master, BNG-B is hot backup, BNG-C is warm-backup, in case of a 442 faulure of BNG-C, uplift BNG-C to hot-backup. 444 o UP SHOULD provide active-active resiliency 446 o UP SHOULD support designated forwarder mechanims which allows a 447 subscriber based load banlancing across UP. 449 8. Security Considerations 451 TBD 453 9. IANA Considerations 455 TBD 457 10. Normative References 459 [I-D.ietf-netconf-subscribed-notifications] 460 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 461 A. Tripathy, "Subscription to YANG Event Notifications", 462 draft-ietf-netconf-subscribed-notifications-23 (work in 463 progress), February 2019. 465 [I-D.ietf-netconf-yang-push] 466 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 467 Nygaard, E., Bierman, A., and B. Lengyel, "Subscription to 468 YANG Datastores", draft-ietf-netconf-yang-push-22 (work in 469 progress), February 2019. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997, 474 . 476 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 477 RFC 5539, DOI 10.17487/RFC5539, May 2009, 478 . 480 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 481 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 482 May 2017, . 484 Author's Address 486 Tianpeng Yu 488 EMail: yutianpeng.ietf@gmail.com