idnits 2.17.1 draft-aoch-nvo3-flow-split-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 : ---------------------------------------------------------------------------- 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 (July 3, 2017) is 2482 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) -- Missing reference section? 'I-D.ietf-nvo3-arch' on line 181 looks like a reference -- Missing reference section? 'I-D.ietf-nvo3-use-case' on line 187 looks like a reference -- Missing reference section? 'RFC7365' on line 193 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 WG Z. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track T. Ao 5 Expires: January 4, 2018 ZTE Corporation 6 July 3, 2017 8 Flow split in Metro Area Network 9 draft-aoch-nvo3-flow-split-00.txt 11 Abstract 13 In the future, there will be some new application appeared known as 14 4K/8K high quality video or VR/AR application.These application needs 15 high bandwidth and low lantacy.In order to meet these requirements, 16 the flow model of traditional MAN should be changed. This article 17 describes a new device using in MAN to support spliting DC's and 18 Internet's flow, support to build edge DC in MAN and change MAN flow 19 model from pipe type to umbrella type. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 4, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Device model . . . . . . . . . . . . . . . . . . . . . . . . 2 58 4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Forward and shunt . . . . . . . . . . . . . . . . . . . . 3 60 4.2. Interface . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.3. Other Function . . . . . . . . . . . . . . . . . . . . . 4 62 4.3.1. PUPVPVxLAN function . . . . . . . . . . . . . . . . . 4 63 4.3.2. Leaf switch function . . . . . . . . . . . . . . . . 4 64 4.3.3. VxLAN smart mapping to VxLAN . . . . . . . . . . . . 4 65 4.3.4. QoS function and rating limiting in VxLAN . . . . . . 4 66 4.3.5. EVPN protocol . . . . . . . . . . . . . . . . . . . . 4 67 4.3.6. DHCP snooping and relay function in VxLAN tunnel . . 4 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 7. Information References . . . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 This document describes a type of device using in Metro Network to 76 distribute the user's flows,and forward them to different direction 77 of MAN. Service Provider can use this device to separate the 78 valuable flow from Internet flow,and redirect the flow to the edge 79 cloude.such as 4K/8K video or AR/VR application. 81 2. Terminology 83 FSD(Flow Split Device): device to split user flow according to the 84 control flow table, include forwarding plane and stack module. 86 3. Device model 88 FSD equipment's model is described as below. 90 +----------------+ +-----------------+ 91 | stack module +---> | SDN controller | 92 | | | | 93 +-------+--------+ +--------+--------+ 94 ^ | 95 | +-----------------+ 96 | | 97 | ^ 98 +--------+-----+--+ 99 | forwarding plane| +----------------> 100 +------------> | | 101 +-----------------+ +----------------> 103 The forwarding plane is the datapath of the FSD. Before it working 104 ,its forwarding table will be configurated by the SDN controller with 105 NATCONF or OFPCONFIG protocol. 107 User's data flow is sended to the forwarding plane. In normal 108 condition, the flow will be forwarded according to the preconfig 109 table in the forwarding plane. 111 4. Functionality 113 4.1. Forward and shunt 115 Forward and shunt For Internet flow,the packet will be forwarded by 116 FSD according to pre configuration flow table. The capacity of flow 117 table is a big problem to the shunt device if using MAC address 118 forwarding. In a large Metro network the number of the items of flow 119 table maybe up to one million, so the C/S VLAN(QinQ) forwarding 120 function will be considered to reducing the capacity of the flow 121 table. 123 For local flow,which is disposed in the edge cloud, should be shunted 124 in the FSD according to the dynamical flow table. The protocol such 125 as openflow should be supported to create the dynamical forwarding 126 flow table. 128 4.2. Interface 130 VxLAN tunnel should be supported in the uplink of the FSD to the edge 131 cloud direction, and IP interface should be supported in the uplink 132 to the Internet direction. In other word, FSD will separate the 133 east-west flow and south-north flow of the access network. 135 There are three kinds of interface should be supported in the 136 downlink of the FSD, VLAN interface,QinQ interface and VxLAN 137 interface. VLAN interface is for enterprise subscriber to access in, 138 QinQ interface is for internet user,and VxLAN tunnel interface is for 139 some VxLAN private line service. 141 4.3. Other Function 143 Many other functions should be supported in FSD for different 144 requirements,as below: 146 4.3.1. PUPVPVxLAN function 148 For user isolation and VxLAN internal flow statistic and charging. 150 4.3.2. Leaf switch function 152 for realize the leaf-spine frame in DC Downlink port VLAN,QinQ, 154 4.3.3. VxLAN smart mapping to VxLAN 156 in uplink port for packet forward 158 4.3.4. QoS function and rating limiting in VxLAN 160 for Forwarding priority and service control in VxLAN 162 4.3.5. EVPN protocol 164 for the information synchronization in layer2 network 166 4.3.6. DHCP snooping and relay function in VxLAN tunnel 168 and so on... 170 5. Security Considerations 172 Service Gateway must have the capability of checking the validation 173 of user's address. 175 6. IANA Considerations 177 N/A 179 7. Information References 181 [I-D.ietf-nvo3-arch] 182 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 183 Narten, "An Architecture for Data Center Network 184 Virtualization Overlays (NVO3)", draft-ietf-nvo3-arch-08 185 (work in progress), September 2016. 187 [I-D.ietf-nvo3-use-case] 188 Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 189 "Use Cases for Data Center Network Virtualization Overlay 190 Networks", draft-ietf-nvo3-use-case-17 (work in progress), 191 February 2017. 193 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 194 Rekhter, "Framework for Data Center (DC) Network 195 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 196 2014, . 198 Authors' Addresses 200 Zhonghua Chen 201 China Telecom 202 No.1835, South PuDong Road 203 Shanghai 201203 204 China 206 Phone: +86 18918588897 207 Email: 18918588897@189.cn 209 Ting Ao 210 ZTE Corporation 211 No.889, BiBo Road 212 Shanghai 201203 213 China 215 Phone: +86 21 68897642 216 Email: ao.ting@zte.com.cn