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