idnits 2.17.1 draft-meng-sfc-broadband-usecases-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 18 characters in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3330 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-softwire-lw4over6' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC6333' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'RFC6519' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'RFC6888' is defined on line 837, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-sfc-problem-statement (ref. 'I-D.ietf-sfc-problem-statement') Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 service function chain C. Xie 3 Internet-Draft Q. Sun 4 Intended status: Standards Track China Telecom 5 Expires: September 10, 2015 W. Meng 6 C. Wang 7 ZTE Corporation 8 B. Khasnabish 9 ZTE TX, Inc. 10 March 9, 2015 12 service function chain Use Cases in Broadband 13 draft-meng-sfc-broadband-usecases-03 15 Abstract 17 This document discusses about service function chain use cases in 18 different scenarios of broadband network. The document provides 19 analysis of different solutions and also describes the feasible 20 deployment scenarios corresponding to each solution. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 5 58 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Internet Access from Homes . . . . . . . . . . . . . . . . 6 60 3.1.1. Native IPv4 Network or Native IPv6 Network . . . . . . 6 61 3.1.2. IPv4/IPv6 Coexist Network . . . . . . . . . . . . . . 7 62 3.2. Internet Access from Enterprises . . . . . . . . . . . . . 11 63 3.3. Internet Access from Campuses . . . . . . . . . . . . . . 12 64 3.4. Added-value Service Access . . . . . . . . . . . . . . . . 12 65 3.4.1. Destination Address Accounting(DAA) . . . . . . . . . 13 66 3.4.2. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 3.4.3. VoIP/MoIP . . . . . . . . . . . . . . . . . . . . . . 16 68 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 17 69 4.1. Service Function Chain Symmetry . . . . . . . . . . . . . 17 70 4.2. Deploying consideration . . . . . . . . . . . . . . . . . 17 71 4.2.1. Standalone mode . . . . . . . . . . . . . . . . . . . 17 72 4.2.2. Directly connecting mode . . . . . . . . . . . . . . . 19 73 4.3. Pool consideration . . . . . . . . . . . . . . . . . . . . 21 74 4.4. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 21 75 4.5. Unify home router . . . . . . . . . . . . . . . . . . . . 21 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 78 7. Normative References . . . . . . . . . . . . . . . . . . . . . 24 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 81 1. Introduction 83 The object of SFC is trying to unload services from legacy devices in 84 traditional network and deal with such services through corresponding 85 service functions which are topologically independent from physical 86 devices. 88 As increasingly large number of customers, the possibility of 89 deployment SFC in broadband network seems emergency. And this 90 document aims to illustrate the possibly typical and unified service 91 function chains in Broadband Networks and analyze the possible 92 deployments of diverse service function chains in broadband network. 94 In figure 1, here outlines the possible SFC deployment architecture 95 in Broadband Networks. This architecture tries to simplify and unify 96 the services in CPEs and unloads the services from CPEs to the SFCs 97 in Access Networks to achieve virtual CPE functions. And as well, 98 extracts the services in BNASs and offloads the services from BNASs 99 to the SFCs in Barrier Networks to accomplish virtual BNAS functions. 100 As a result of that, the Internet Service Provider can manage and 101 maintain the whole Broadband Networks more flexibly. 103 +-----------+ +-----------+ 104 | Host1 | ... | HostN | 105 +-----+-----+ +-----+-----+ 106 | | 107 +-----+-----+ +-----+-----+ 108 | classifer | | classifer | 109 +-----+-----+ +-----+-----+ 110 | | 111 |---------|---------| 112 | 113 +-------+---------+ 114 | SFCs/vCPEs | 115 . +-------+---------+ . 116 . | . 117 +-------|---------+ +-------|---------+ +-------|---------+ 118 |switch/classifier| |switch/classifier| |switch/classifier| ... 119 +-------|---------+ +-------|---------+ +-------|---------+ 120 | | | 121 +---------------------|--------------------+ 122 | 123 +------+------+ 124 | SFCs/vBNASs | 125 +------+------+ 126 | 127 --------|-------- 128 / | \ 129 | Internet | 130 \ | / 131 --------|-------- 133 Figure 1: SFC Architecture of Broadband Network 135 2. Convention and Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 The terms about SFC are defined in [I-D.ietf-sfc-problem-statement]. 143 The terms about CGN/DS-Lite/Lightweight 4o6/MAP/NAT64 are defined in 144 [RFC6888]/[RFC6333]/ [I-D.ietf-softwire-lw4over6]/ 145 [I-D.ietf-softwire-map]/ [RFC6146]. 147 3. Use cases 149 The following sections highlight some of the most common broadband 150 network use case scenarios and are in no way exhaustive. 152 3.1. Internet Access from Homes 154 Figure 2 illustrates an abstract architecture of broadband network, 155 including CPE sitting in home access network, BNAS as broadband access 156 network gateway,CR located in bone network and the Internet. 158 +---+ +------+ +-----+ +---------+ 159 |CPE|------| BNAS |--------| CR |------| Internet| 160 +---+ +------+ +-----+ +---------+ 162 Figure 2: Architecture of Broadband Network 164 Also, the Broadband Forum(BBF) is developing a study document(SD- 165 326), which aims to study market requirements and usecases for 166 Flexible Service Chaining. Except that, this document tries to 167 develop more typical usecases in Broadband Networks. 169 3.1.1. Native IPv4 Network or Native IPv6 Network 171 ----------------------------------------------------------------------------> 172 +--- + +-------+ +-----+ +----------+ 173 | | |DPI/DFI| | LB/ | |URL Filter|---| 174 |--| UM |---| /Qos |---| FRR |---| /FW/PC | | 175 | +----+ | +-------+ | +-----+ | +----------+ | 176 +---+ +------+ | | | +-----+ +---------+ 177 |CPE|--| BNAS-|-------|-----------|---------|-------------| CR |-----| Internet| 178 +---+ +------+ +-----+ +---------+ 180 Figure 3: Native IPv4 Network or Native IPv6 Network 182 Figure 3 shows possible deployment of SFC in native IPv4 network or 183 native IPv6 network. As UM(users management) service, which is the 184 main service of BNAS device in traditional network, consumes large 185 memory and resources, it seems reasonable to decouple UM service from 186 legacy BNAS device and treat it as a service node , which may include 187 DHCP,AAA functions and some other functions related to users 188 management. And what's more, only users subscription messages 189 (protocol messages) go through UM service. Once a user is approved 190 by UM service, the following data flow of this user go through the 191 other service function chain which is assigned to this data flow. 193 'BNAS-' means some functions have been unburdened from traditional 194 BNAS,such as user management,Qos,Load Balance and so forth. 196 Given that SFC is applied in Broadband network, the main SFs may 197 cover: User Management, DPI, DFI, Qos, Load Balance, Fast Reroute, 198 URL Filter,Firewall,Parental Control and so forth. And the possible 199 order is not as strict as above. The upstream/downstream traffic may 200 go through different permutations and combination of these SNs. For 201 example: 203 SFC1: UM 205 This SFC stands for the process of subsribers's log-in and log-out. 206 All the broadband subscribers's log-in messages and log-out messages 207 need go through this SFC. After approved by this SFC, then the users 208 flow can access the Internet or other services through differentiated SFCs. 210 SFC2: Qos 212 This SFC shows some bandwidth restrictions or several priority-based 213 schedules are applied to this approved subscriber. Almost each home 214 subscriber has a corresponding subscribed bandwidth, different 215 services from a home have distinctive priority as well. As a result, 216 this is a basic SFC used in internet access from homes. 218 SFC3: Qos--LB 220 This SFC extends SFC2, which utilizes load balance to offload 221 approved subscribers's flow from an overload path. This is also a 222 typical scenario in broadband network, especially in metropolitan 223 area network. 225 SFC4: Qos--LB--URL Filter 227 Based on SFC3, this SFC gives extra restrictions to the content 228 the approved subscriber wants to access. 230 SFC5: Qos--Parental Control 232 This is similar to SFC4,except there is no Load Balance. Another 233 difference is that SFC5 offers some restrictions to downstream 234 traffic in terms of content. SFC5 allows some legal or appropriate 235 contents to flow to subscribers, while some illegal or inappropriate 236 contents are blocking. 238 3.1.2. IPv4/IPv6 Coexist Network 240 As showed below in figure 4, the main difference between IPv4/IPv6 241 native network and IPv4/IPv6 coexist network is whether there exists 242 a NAT funtion. Although in IPv4 native network, there maybe exist 243 NAT44 function as a result of limited IPv4 address, we try to put 244 this scenario together with other IPv6 transition scenarioes in this 245 section and discuss them in detail. 247 ----------------------------------------------------------------------------> 248 +--- + +-------+ +-----+ +----------+ 249 | | |DPI/DFI| | LB/ | |URL Filter|---| 250 |-----|NAT |---| /Qos |---| FRR |---| /FW/PC | | 251 | +----+ | +-------+ | +-----+ | +----------+ | 252 +---+ +------+ | | | +-----+ +---------+ 253 |CPE|--| BNAS-|---------|-----------|---------|-------------| CR |---| Internet| 254 +---+ +------+ +-----+ +---------+ 256 Figure 4: IPv4/IPv6 Coexist Network 258 Whether NAT stands for NAT44 or NAT64 or NAT46 depends on the the 259 Internet Server Provider. It may be NAT44, which reflects the 260 communication between IPv4 private customer and IPv4 public server. 261 Or it may be NAT64, which means the communication between IPv6 262 customer and IPv4 Server. And where NAT is deployed is the 263 preferance of the Internet Server Provider as well. It may be 264 besides BNAS,which stands for distributed deployment, or besides 265 CR,which represents central deployment. 267 Above figure 4 just gives a simple example of a possible deployment 268 position in distributed deployment scenario. Actually, there are 269 some other complicated IPv6 transition scenarioes . And this section 270 tries to give some typical examples in IPv4/IPv6 coexist network, and 271 conclude a feasible SFC architecture in IPv4/IPv6 coexist network. 272 Also, in the following sections, the other SFs emphasized in section 273 3.1.1 are not highlighted, just try to keep the diagram simple and 274 suitable for the draft's specification. 276 3.1.2.1. NAT44 278 Figure 5 illustrates a simple NAT44 scenario how SF-NAT is deployed 279 and how SF-NAT may work. 281 . 282 : 283 | 284 ............... | 285 External realm | 286 ISP network--> |-------------+ 287 | ++---|----++ 288 | | SF-NAT44 | 289 | ++---|----++ 290 |-------------+ 291 ++--|----+ 292 ........... | BNAS- | 293 Internal realm ++------++ 294 | | 295 ISP network--> | | 296 | | 297 ++------++ ++------++ 298 | CPE1 | | CPE2 | etc. 299 ++------++ ++------++ 301 Figure 5: NAT44 303 In distributed broadband networks, SNs may be deployed beside BNAS. 304 These SNs may contain or logically connect to SF-NAT and other 305 service functions such as UM,QOS,Load Balance,etc. 307 Here gives an example of possible SFC in IPv4/IPv6 coexist network, 308 which combines NAT function with the service functions in native 309 IPv4/IPv6 network. 311 SFC6: Qos--NAT--LB--URL Filter 313 SFC6 combines NAT function with SFC4, and represents the classical 314 scenario in IPv4/IPv6 coexist network. After customers have 315 subscribed, apply subscriber-based Qos policy, then transform IPv4/ 316 IPv6 address into IPv4 address, and do five-tuple load balance for 317 the outbound traffic. 319 At last, monitor the outbound traffic and decide whether to permit 320 them to the internet or block them. 322 After the first packet of an outbound flow has been processed by this 323 SFC, this SFC can do SFP optimization to bypass NAT service function 324 to improve the experience of this subscriber. Then, for the 325 following packets of this outbound flow, the SFF connects to NAT 326 service function can forward them according to the forwarding table 327 which is derived from the NAT service function. 329 As for the inbound flow of this subscriber, there exists an open 330 issue: how the inbound flow is steered to the same NAT service 331 function or the same SFF which connects to the same NAT service 332 function. 334 3.1.2.2. DS-Lite 336 Figure 6 describes a scenario of DS-lite, which completes IPv4 337 communication between IPv4 private customer and IPv4 server across 338 IPv6 network through tunnels. And the main principle of DS-Lite is 339 to encapsulate IPv4 packets in IPv6 Header and forward this IPv4-in- 340 IPv6 packets to CGN device and enforce NAT function in CGN device. 341 Generally, CGN device resides in BNAS device. 343 +-----------+ 344 | IPv4 Host | 345 +-----+-----+ 346 | 347 +---------|---------+ 348 | CPE- | 349 +---------|---------+ 350 +-----------------+ 351 | +-----|--------+ 352 | | SF-Dslite-Enc| 353 | +-----|--------+ 354 +-----------------+ 355 ||| 356 |||<-IPv4-in-IPv6 softwire 357 ||| 358 +--------|||--------+ 359 | BNAS- | 360 +--------|||--------+ 361 +----------------------+ 362 | +----------|----------+ 363 | | SF-Dslite-Dec | 364 | | SF-NAT | 365 | +----------|----------+ 366 +-----------------+ 367 | 368 | 369 --------|-------- 370 / | \ 371 | IPv4 Internet | 372 \ | / 373 --------|-------- 375 Figure 6: DS-Lite 377 SFC7: Dslite-Enc---Dslite-Dec---NAT---LB---URL Filter 379 When the outbound flow are received by the CPE, the CPE sends them to 380 a specific classifier which determines the flow should be forwarded 381 directly or dealed with DS-Lite process. if the flow should be dealed 382 with DS-Lite process, then the classifier sends the datagram within 383 service header encapsulation to Softwire-SN which contains SF-Dslite- 384 Encapsulation instance. In this instance, it fulfils DS-Lite 385 encapsulate and then encapsulates overlay header and forwards this 386 flow to nexthop in the traditional network. 388 Next, the BNAS- receives the processed flow, the BNAS- sends them to 389 a classifier and finds they are legal flow and need to be dealed with 390 DS-Lite process. then, this flow are forwarded to SF-Dslite- 391 Decapsulation to decapsulate DS-Lite encapsulation. And as well, 392 forwarded to SF-NAT to create and maintain the NAT mapping table for 393 DS-Lite subscriber. SF-Dslite-decapsulation and SF-NAT can reside in 394 one service function or two different service functions. After that, 395 completes the subsequent SFs. 397 In other words, BNAS-,itself, would decouple DS-lite-related 398 functions to specific service function(s). What!_s more, if SFP 399 optimization function is enabled, BNAS- acts as SFF which connectes 400 to SF-NAT, and derives the NAT/forwarding table from SF-NAT and 401 bypasses SF-NAT to improve the experience of this subscriber. 403 If deploy SFC7 in this scenario, there also exists a consideration: 404 how to address the relationship between the access side SFC domain 405 and the network side SFC domain. If they are deployed in two 406 different SFC domain, how to cooperate between the SF-Dslite- 407 Encapsulation service function and SF-Dslite-Decapsulation service 408 function. On the other hand, if they are deployed in one big SFC 409 domain, it seems more feasible to carry out this SFC7. 411 3.2. Internet Access from Enterprises 413 ------------------------------------------------------------------------------------> 414 +-------+ +-----+ +----------+ 415 |DPI/DFI| | LB/ | |URL Filter|---| 416 +-----+ |----| /Qos |---| FRR |---| /FW/PC | | 417 |host1|--| +----------+ | +-------+ | +-----+ | +----------+ | 418 +-----+ | |URL Filter| +-----+ | | +-----+ +---------+ 419 ---| /FW/PC |--| SR- |-----------|---------|-------------| CR |---| Internet| 420 +-----+ | +----------+ +-----+ +-----+ +---------+ 421 |host2|--| 422 +-----+ 424 Figure 7: Internet access from enterprises 426 Internet access from enterprises is another network service. They 427 lease some ports or even some devices from Internet Server Providers. 428 In addition to internal s service functions which are situated in the 429 internal enterprise network, there maybe deploy many external ISP's 430 service functions which are sitted on the way to the internet. And 431 what's more, there maybe deploy IPsec along with VPN users for the 432 sake of the security of enterprise network. 434 Internal service functions may include: Firewall, NAT function, etc. 436 As for external service functions deployed by ISP, typical service 437 functions are VPN, like L2VPN,L3VPN,IPsec,IPsec VPN etc. 438 Conventionally, there is a NAT function residing on SR, converting 439 VPN traffic to public traffic to access the internet. 441 In some cases, service providers need to assign differentiated 442 services to VPN users. In other words, different VPN users may go 443 through differentiated SFC. But, VPN traffic are all encapsulated in 444 outer MPLS header or some other transport headers, how the public 445 network elements classify them to different SFCs? At this time, 446 there maybe need create a mapping between VPN ID/VPN Name and 447 corresponding SFC on the service provider edge device. 449 Other external service functions involved in Internet access from 450 enterprise network maybe similar to home network, for example, 451 DPI,DFI,Qos,Load Balance, URL Filter,Firewall,Parental Control and so 452 on. 454 SFC8: URL Filter--FW---NAT---Qos---Load Balance----FW 456 Here, you may see two FW functions. One is in the inner of 457 enterprise, which represents the URL constrains from the perspective 458 of enterprise. While the other one is sitted in the ISP network, out 459 of the inner enterprise, and stands for the URL restrictions from the 460 standpoint of ISP. 462 3.3. Internet Access from Campuses 464 TBD 466 3.4. Added-value Service Access 468 To promote their primary service, ISP try to provide value-added 469 services to add value to the standard service offering. Here maybe 470 focus on some significant value-added services in broadband network 471 such as IPTV,VOIP,etc. 473 3.4.1. Destination Address Accounting(DAA) 475 Figure 8 illustrates a possible deployment of DAA funtion in 476 broadband network. 478 +-----+ 479 |host1|--| 480 +-----+ | +-------+ +----------+ +-----+ +---------+ 481 --| CPE |---| BRAS+DAA |------| CR |---| Internet| 482 +-----+ | +-------+ +----------+ +-----+ +---------+ 483 |host2|--| 484 +-----+ 486 Figure 8: DAA Deployment in broadband network 488 In this diagram, DAA assists BRAS to accomplish finer-granularity 489 outbound filter or/and inbound filter based on destination IP 490 address. But,in central deployment scenario of DS-Lite, there is a 491 IPv4-in-IPv6 tunnel from CPE to CR. As a result of that, BRAS cannot 492 identify the true IPv4 destination address in this IPv4-in-IPv6 493 packets. And then, BRAS cannot enforce DAA function to manage the 494 subscriber more flexibly. 496 SFC9: DAA----Dslite-Enc----Dslite-Dec----NAT 497 +-----------+ +-----------+ 498 | Host1 | | Host2 | 499 +-----+-----+ +-----+-----+ 500 | | 501 +-----|-----+ +-----|-----+ 502 | CPE2- | | CPE2- | 503 +-----|-----+ +-----|-----+ 504 | | 505 |---------|---------| 506 | 507 +-------|---------+ 508 | SF-DAA | 509 +-------|---------+ 510 | 511 +-------|---------+ 512 | SF-Dslite-Enc | 513 +-------|---------+ 514 | 515 ||| 516 |||<--softwire 517 ||| 518 +--------|||--------+ 519 | CR | 520 +--------|||--------+ 521 +----------------------+ 522 | +----------|-----+ 523 | | SF-Dslite-Dec | 524 | | SF-NAT | 525 | +----------|-----+ 526 +----------------------+ 527 | 528 | 529 --------|-------- 530 / | \ 531 | Internet | 532 \ | / 533 --------|-------- 535 Figure 9: DAA + Softwire Deployment in broadband network 537 3.4.2. IPTV 539 Figure 10 illustrates a possible deployment of IPTV network via SFC. 541 <---------------------------------------------------- 542 +----+ 543 |STB1|-------| 544 +----+ | 545 | 546 +----+ +-------+ +------+ 547 |STB2|---| BNAS1-|----| Qos1 |---------| 548 +----+ +-------+ +------+ | 549 | | 550 +----+ | | 551 |STB3|-------| | 552 +----+ | 553 +---------+ +-----+ 554 +----+ | DPI/DFI |-----| CDN | 555 |STB4|-------| +---------+ +-----+ 556 +----+ | | 557 | | 558 +----+ +-------+ +------+ | 559 |STB5|---| BNAS2-|----| Qos2 |---------| 560 +----+ +-------+ +------+ 561 | 562 +----+ | 563 |STB6|-------| 564 +----+ 566 Figure 10: IPTV network via SFC 568 IPTV is a IP multicast service, in which multi-subscribers should 569 receive the same traffic from the multicast source like Content 570 Distribution Network. Supposed there are six IPTV subscribers, from 571 STB1 to STB6, they are located in different districts and they all 572 need to receive traffic from Program 1. A possible SFC abstract here 573 is : 575 SFC10: DPI--Qos1 577 |---Qos2 579 In SFC10, as for the inbound traffic, there are two different 580 outputs, Qos1 and Qos2. Firstly, traffic from multicast source go 581 through DPI, which used for detecting whether the multicast traffic 582 are legal or unmalicious. After that, legal traffic propagate to 583 different Qos, and next, each goes through different BNAS- to 584 different STB subscirbers separately. 586 3.4.3. VoIP/MoIP 588 TBD 590 4. Considerations 592 4.1. Service Function Chain Symmetry 594 A complete end-to-end access in broadband network should consist of a 595 set of service function instances in a specific order. 597 4.2. Deploying consideration 599 4.2.1. Standalone mode 601 In broadband networks, service function components are hanging next 602 to routers such as CPEs/BNASs/CRs. All traffics would be received 603 and steered by routers. Routers send the traffic to classifier in 604 which traffic that matches classification criteria is forwarded along 605 a given SFP to realize the specifications of an SFC. 607 +-----------+ 608 | Host | 609 +-----+-----+ 610 | 611 | 612 +---------|---------+ +-------------------+ 613 | | | ------------- | 614 | CPE -----> | SFP | | 615 | <----- -------------- | 616 +---------|---------+ +-------------------+ 617 | 618 | 619 --------|------- 620 / | \ 621 | ISP core network | 622 \ | / 623 ------- | ------- 624 | 625 | 626 +---------|---------+ +-------------------+ 627 | | | ----------- | 628 | BNAS |----> | SFP | | 629 | <----| ----------- | 630 +---------|---------+ +-------------------+ 631 | 632 | 633 --------|-------- 634 / | \ 635 | Internet | 636 \ | / 637 --------|-------- 639 Figure 11: Standalone mode 641 Take DS-Lite CGN for example. 643 Outbound traffic: 645 In the example shown in Figure X, a datagram received by the CPE from 646 the host at address 10.0.0.1, using TCP DST port 10000, will be 647 translated to a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC 648 port 5000 in the Internet. 650 When the datagram 1 is received by the CPE, the CPE sent it to a 651 specific classifier which determines the datagram should be forwarded 652 directly or dealed with DS-Lite process. Then the classifier sends 653 the datagram within service header encapsulated to the first element 654 of SFP. SF-SOFTWIRE encapsulates the datagram in another datagram 655 (datagram 2) and forwards it BACK to CPE over the softwire. The 656 datagram 2 would be sent to the Dual-Stack Lite carrier-grade NAT by 657 CPE. 659 When the BNAS receives datagram 2, the BNAS sends it to a classifier 660 and find it need to be dealed with DS-Lite process. Then the 661 classifier send the datagram within service header encapsulated to 662 the first element of SFP. 664 SF-SOFTWIRE decapsulates the datagram 2 to datagram 1 and forwards it 665 SF-NAT, which determines from its NAT table that the datagram 666 received on the softwire with TCP SRC port 10000 should be translated 667 to datagram 3 with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000. 669 The translated datagram would be also sent back to BNAS for next 670 forwarding. 672 Inbound traffic: 674 Figure x shows an inbound message received at the classifer. When 675 the BNAS receives datagram 1, the BNAS sends it to a classifier. 676 Then the classifier sends the datagram within service header 677 encapsulated to the first element of SFP. SF- NAT looks up the IP/ 678 TCP DST information in its translation table. In the example in 679 Figure 3, the NAT changes the TCP DST port to 10000, sets the IP DST 680 address to 10.0.0.1, and it will be sent back to BNAS to forwards the 681 datagram to the softwire. The SF-SOFTWIRE of the CPE decapsulates 682 the IPv4 datagram inbound softwire datagram and forwards it to the 683 host. 685 4.2.2. Directly connecting mode 687 There is another mode to deploy service function components. In 688 broadband home networks, service function components are directly 689 connected to the network. They are connected straight to a BNAS or 690 Routers. 692 Under this scenario, it seems like more costly than standalone mode 693 during transition period. 695 | +-----------+ 696 out | Host | 697 | +-----+-----+ 698 v | 699 +---------|---------+ +-------------+ 700 | |-out->classifier A | 701 | | +------|------+ 702 | CPE | | 703 | | | 704 | | out 705 +---------/\--------+ | 706 || | 707 +<===== in =====+------v------+ 708 | | 709 | SFP A | 710 | | 711 +<----- out-----+------/\-----+ 712 | || 713 +---------v---------+ || 714 | | || 715 | | || 716 | BNAS | || 717 | | +------||-----+ 718 | |==in=>classifier B | 719 +---------|---------+ +-------------+ 720 --------|-------- /\ 721 / | \ || 722 | METRO NETWORK | in 723 \ | / || 724 ---------^-------- 725 . 726 . 727 +---------+---------+ 728 | | 729 | | +-------------+ 730 | CR | | SFP N | 731 | | +-------------+ 732 | | 733 +-------------------+ 735 Figure 12: Directly connecting mode 737 Take NAT44 for example. 739 Outbound traffic: 741 For directly connecting mode, the difference in dealing with traffic 742 is whether the network steer the traffic loopback. That means 743 service function node could send datagrams directly to the next hop. 745 For example, when the outbound datagram is received by the BNAS and 746 processed by classifer A and SF-NAT which forward the processed 747 datagram straight next to router. 749 Inbound traffic: 751 It is quite similar with the process of dealing with outbound 752 traffic. when the inbound datagram is received by the router and 753 processed by classifer B and SF-NAT which forward the processed 754 datagram straight next to NAT BNAS. 756 4.3. Pool consideration 758 In traditional networks, pools are configured in router one by one. 759 Pool configuration means these IP addresses in each pool MUST be 760 advertised for creating forward routing path to ensures that the 761 message is routed to the correct target, especially to inbound 762 traffic. Thus, pool location is a problem we must face to in SFC 763 framework. 765 In standalone mode shown in figure 6, pool could be configured in the 766 classifier beside gateway and advertised by the gateway itself. The 767 classifier would assign IP addresses to service functions for 768 creating mapping table. Both-bound traffic should be forward to 769 gateway first and then for NAT treatment in relative service function 770 components. 772 In Directly connecting mode shown in figure 7, pool could be 773 configured in classifier B and advertised by classifier B for 774 creating inbound routing path. 776 There is a mechanism to manage the address pools centrally. Pools 777 could be assigned to classifiers by management server which is 778 handled by Operators centrally. 780 4.4. NAT traversal 782 TBD 784 4.5. Unify home router 786 TBD 788 5. IANA Considerations 790 This memo includes no request to IANA. 792 6. Security Considerations 794 TBD 796 7. Normative References 798 [I-D.ietf-sfc-problem-statement] 799 Quinn, P. and T. Nadeau, "Service Function Chaining 800 Problem Statement", draft-ietf-sfc-problem-statement-13 801 (work in progress), February 2015. 803 [I-D.ietf-softwire-lw4over6] 804 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 805 I. Farrer, "Lightweight 4over6: An Extension to the DS- 806 Lite Architecture", draft-ietf-softwire-lw4over6-13 (work 807 in progress), November 2014. 809 [I-D.ietf-softwire-map] 810 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 811 Murakami, T., and T. Taylor, "Mapping of Address and Port 812 with Encapsulation (MAP)", draft-ietf-softwire-map-13 813 (work in progress), March 2015. 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 819 "Remote Authentication Dial In User Service (RADIUS)", 820 RFC 2865, June 2000. 822 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 823 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 824 October 2010. 826 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 827 NAT64: Network Address and Protocol Translation from IPv6 828 Clients to IPv4 Servers", RFC 6146, April 2011. 830 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 831 Stack Lite Broadband Deployments Following IPv4 832 Exhaustion", RFC 6333, August 2011. 834 [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 835 Stack Lite", RFC 6519, February 2012. 837 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 838 and H. Ashida, "Common Requirements for Carrier-Grade NATs 839 (CGNs)", BCP 127, RFC 6888, April 2013. 841 Authors' Addresses 843 Xie Chongfeng 844 China Telecom 845 Room 502, No.118, Xizhimennei Street 846 Beijing 847 China 849 Email: xiechf01@gmail.com,xiechf@ctbri.com.cn 851 Sun Qiong 852 China Telecom 853 Room 708, No.118, Xizhimennei Street 854 Beijing 855 China 857 Email: bingxuere@gmail.com,sunqiong@ctbri.com.cn 859 Wei Meng 860 ZTE Corporation 861 No.50 Software Avenue, Yuhuatai District 862 Nanjing 863 China 865 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 867 Cui Wang 868 ZTE Corporation 869 No.50 Software Avenue, Yuhuatai District 870 Nanjing 871 China 873 Email: wang.cui1@zte.com.cn 875 Bhumip Khasnabish 876 ZTE TX, Inc. 877 55 Madison Avenue, Suite 160 878 Morristown, New Jersey 07960 879 USA 881 Email: bhumip.khasnabish@ztetx.com