idnits 2.17.1 draft-geng-detnet-control-plane-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 04, 2019) is 1756 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'I-D.geng-detnet-info-distribution' is mentioned on line 121, but not defined == Missing Reference: 'IEEE802.1Qbv' is mentioned on line 134, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-00 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Experimental Huawei 5 Expires: January 5, 2020 F. Qin 6 China Mobile 7 July 04, 2019 9 DetNet Control Plane Framework 10 draft-geng-detnet-control-plane-00 12 Abstract 14 This document defines DetNet control plane framework. It specifies 15 the guidance of DetNet control plane implementation. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 5, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. DetNet Control Plane Classification . . . . . . . . . . . . . 3 60 3.1. Fully Distributed Control Plane . . . . . . . . . . . . . 3 61 3.2. Fully Centralized Control Plane . . . . . . . . . . . . . 3 62 3.3. Hybrid Control Plane . . . . . . . . . . . . . . . . . . 4 63 4. DetNet Control Plane Considerations . . . . . . . . . . . . . 5 64 4.1. Explicit Route . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 6 66 4.3. Seamless Redundancy . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Deterministic Networking (DetNet) provides the capability to carry 76 specified unicast or multicast data flows for real-time applications 77 with extremely low data loss rates and bounded latency within a 78 network domain. As discussed in the Deterministic Networking 79 Architecture[I-D.ietf-detnet-architecture], Techniques used to 80 provide this capability include reserving data plane resources for 81 individual (or aggregated) DetNet flows in some or all of the 82 intermediate nodes along the path of the flow, providing explicit 83 routes for DetNet flows, and distributing data from DetNet flow 84 packets over time and/or space to ensure delivery of each packet's 85 data in spite of the loss of a path. 87 All these DetNet specific technologies need support of protocal from 88 both data plane and control plane. 90 DetNet data plane framework is defined in 91 [I-D.ietf-detnet-data-plane-framework]. This document defines DetNet 92 control plane framework. It specifies the guidance of DetNet control 93 plane implementation. 95 2. Terminologies 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 Terminologies for DetNet go along with the definition in 102 [I-D.ietf-detnet-architecture]. 104 3. DetNet Control Plane Classification 106 This section defines three classes of DetNet control plane: fully 107 distributed control plane, fully centralized control plane, hybrid 108 control plane, based on different network architectures, showing how 109 configuration information exchanges between various entities in the 110 network. 112 3.1. Fully Distributed Control Plane 114 In a fully distributed configuration model, UNI information is 115 transmitted over DetNet UNI protocol from the user side to the 116 network side; then UNI information and network configuration 117 information propagate in the network over distributed control plane 118 protocol. For example: 120 1) IGP collects topology information and DetNet capabilities of 121 network([I-D.geng-detnet-info-distribution]); 123 2) Control Plane of the Edge Node(Ingress) receives a flow 124 establishment request from UNI and calculates a/some valid path(s); 126 3) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 127 explicit route. After receiving the PATH message, the other Edge 128 Node(Egress) sends a Resv message with distributed label and resource 129 reservation request. 131 Current distributed control plane protocol,e.g., RSVP-TE[RFC3209], 132 SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while 133 the configuration of a fine-grained schedule, e.g.,Time Aware 134 Shaping(TAS) defined in [IEEE802.1Qbv], is not supported. 136 3.2. Fully Centralized Control Plane 138 In the fully centralized configuration model, UNI information is 139 transmitted from Centralized User Configuration (CUC) to Centralized 140 Network Configuration(CNC). Configurations of routers for DetNet 141 flows are performed by CNC with network management protocol. For 142 example: 144 1) CNC collects topology information and DetNet capability of network 145 through Netconf; 147 2) CNC receives a flow establishment request from UNI and calculates 148 a/some valid path(s); 150 3) CNC configures the devices along the path for flow transmission. 152 3.3. Hybrid Control Plane 154 In the hybrid configuration model, controller and control plane 155 protocols work together to offer DetNet service, and there are a lot 156 of possible combinations. For example: 158 1) CNC collects topology information and DetNet capability of network 159 through IGP/BGP-LS; 161 2) CNC receives a flow establishment request from UNI and calculates 162 a/some valid path(s); 164 3) Based on the calculation result, CNC distributes flow path 165 information to Edge Node(Ingress) and other information(e.g. 166 replication/elimination) to the relevant nodes. 168 4) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 169 explicit route. After receiving the PATH message, the other Edge 170 Node(Egress) sends a Resv message with distributed label and resource 171 reservation request. 173 or 175 1) Controller collects topology information and DetNet capability of 176 network through IGP/BGP-LS; 178 2) Control Plane of Edge Node(Ingress) receives a flow establishment 179 request from UNI; 181 3) Edge Node(Ingress) sends the path establishment request to CNC 182 through PCEP; 184 4) After Calculation, CNC sends back the path information of the flow 185 to the Edge Node(Ingress) through PCEP; 187 5) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with 188 explicit route. After receiving the PATH message, the other Edge 189 Node(Egress) sends a Resv message with distributed label and resource 190 reservation request. 192 There are also other variations that can be included in the hybrid 193 control plane. This draft can not coverer all the control plane data 194 needed in hybrid configuration models. Every solution has there own 195 mechanism and corresponding parameters to make it work. 197 4. DetNet Control Plane Considerations 199 This section gives general instructions about how to implement 200 different DetNet technologies in control plane. New requirements for 201 the current protocal are highlighted. 203 4.1. Explicit Route 205 Explicit Route is required in DetNet to provide stable transport 206 service and guarante that DetNet service is not effected when the 207 network topology changes. The following features are necessary to 208 have explicit route in DetNet: 210 o Path Computation 212 Explicit path for DetNet is supposed to meet the SLA(Service Level 213 Agreement) requirement or resource guarantee from the application/ 214 client, which include: bandwidth, maximum end-to-end delay, maximum 215 end-to-end delay variation, maximum loss ratio and so on. In an 216 distributed system with IGP-TE, CSPF(Contstraint Shortest Path First) 217 can be used to compute a set of feasible paths for a DetNet Service. 218 In a system with a network controller, PCE(Path Computation Engine) 219 can compute paths satisfying the requirements of DetNet with the 220 network information collected from the DetNet domain. 222 o Setting up a path 224 After choosing a path that meets the requirement, an explicit path is 225 supposed to set up in a DetNet domain. DetNet flows are steered 226 through the network along their allocated path. RSVP-TE can be used 227 to set up a path with flow identification. The packets with the flow 228 identification would be routed as the RSVP-TE specifies. Segment 229 Routing is another option and no flow status is needed excepct for 230 the ingress node. SR policy is insterted into the packet at the 231 ingress node and the packet . 233 o Strict or Loose 235 An explicit path is strict when every intermidate hop is specified so 236 that its route can't change. An explicit path is loose when any IGP 237 route is allowed along the path. Generally, end-to-end SLA guarantee 238 needs a strict explicit in DetNet. However, when the IGP route is 239 known and can meet the SLA requirement, Loose explicit path is also 240 acceptable. 242 4.2. Resource Reservation 244 Congestion could cause uncontrolled delay and packet loss. DetNet 245 flows are supposed to be protected from congestion, so enough 246 resource reservation for DetNet service is necessary. Resource in 247 the network is complex and hard to quantize, for example: packet 248 processing resource, buffer size, port bandwidth and so on. The 249 resource a flow occupies is determined by the flow characteristics. 251 o Resource Allocation 253 Port bandwidth is one of the basic attributes of the network device 254 which is easy to get and calculate. In the current implementation, 255 network resource allocation means bandwidth allocation. DetNet flow 256 is characterized with traffic specification, which is defined in 257 [I-D.ietf-detnet-flow-information-model] , including : Interval, Max 258 Packets Per Interval and Max Payload Size. Flow rate is the an 259 average value, while traffic specification describes the worst case 260 of the traffic. And time concept is introduced in traffic 261 spefication.The resource reservation in DetNet can be worst-case 262 bandwidth reservation, and avoid confiction in an interval may also 263 be considered. Buffer resource is also in the scope to avoid packet 264 loss when the buffer is not enough. 266 o Device Configuration with or withour Flow Discrimination 268 The resouce allocation is guaranteed by device configuration. For 269 example, the value of output port bandwidth reservation can be 270 configured as the parameter of queue management and scheduling 271 algorithm. When the DetNet flows are aggregated, a group of DetNet 272 flows shared the allocated resource in the network device. When the 273 DetNet flows are treated independently, the device should maintains a 274 mapping relationship between DetNet flows and its corresponding 275 resource. 277 4.3. Seamless Redundancy 279 Seamless Redundancy is guaranteed by the packet replication and 280 elimination. The flow is replicated and go through parallel paths to 281 avoid packet loss caused by device failure. The network device 282 should 284 o Explicit Path 285 The current signalling that can set up an explicit path, as mentioned 286 above like RSVP-TE or Segment Routing, can support an P2P or P2MP 287 path. Seamless Redundancy requires P2MP2P path. Protocal extentions 288 are required to support this new feature. 290 o Flow Identification and Sequence Number 292 The nodes that execute Packet Replication or Elmination are supposed 293 to identify different DetNet flows and the nodes that execute Packet 294 Elimination are supposed to discriminate packets in one DetNet flow. 295 The flow identification and the rule of the sequence number should be 296 specified in the relay nodes by distributed signalling or a 297 centralized controller. 299 5. IANA Considerations 301 This document makes no request of IANA. 303 Note to RFC Editor: this section may be removed on publication as an 304 RFC. 306 6. Security Considerations 308 TBD 310 7. Acknowledgements 312 TBD 314 8. Normative References 316 [I-D.ietf-detnet-architecture] 317 Finn, N., Thubert, P., Varga, B., and J. Farkas, 318 "Deterministic Networking Architecture", draft-ietf- 319 detnet-architecture-13 (work in progress), May 2019. 321 [I-D.ietf-detnet-data-plane-framework] 322 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 323 Bryant, S., and J. Korhonen, "DetNet Data Plane 324 Framework", draft-ietf-detnet-data-plane-framework-00 325 (work in progress), May 2019. 327 [I-D.ietf-detnet-flow-information-model] 328 Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet 329 Flow Information Model", draft-ietf-detnet-flow- 330 information-model-03 (work in progress), March 2019. 332 [IEEE802.1Qcc] 333 IEEE, "IEEE, "Stream Reservation Protocol (SRP) 334 Enhancements and Performance Improvements (IEEE Draft 335 P802.1Qcc)", 2017, 336 .". 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, 340 DOI 10.17487/RFC2119, March 1997, 341 . 343 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 344 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 345 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 346 . 348 Authors' Addresses 350 Xuesong Geng 351 Huawei 353 Mach(Guoyi) Chen 354 Huawei 356 Fengwei Qin 357 China Mobile 359 Email: qinfengwei@chinamobile.com