Internet DRAFT - draft-geng-detnet-control-plane
draft-geng-detnet-control-plane
Network Working Group X. Geng
Internet-Draft M. Chen
Intended status: Experimental Huawei
Expires: January 5, 2020 F. Qin
China Mobile
July 04, 2019
DetNet Control Plane Framework
draft-geng-detnet-control-plane-00
Abstract
This document defines DetNet control plane framework. It specifies
the guidance of DetNet control plane implementation.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Geng, et al. Expires January 5, 2020 [Page 1]
Internet-Draft Abbreviated-Title July 2019
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DetNet Control Plane Classification . . . . . . . . . . . . . 3
3.1. Fully Distributed Control Plane . . . . . . . . . . . . . 3
3.2. Fully Centralized Control Plane . . . . . . . . . . . . . 3
3.3. Hybrid Control Plane . . . . . . . . . . . . . . . . . . 4
4. DetNet Control Plane Considerations . . . . . . . . . . . . . 5
4.1. Explicit Route . . . . . . . . . . . . . . . . . . . . . 5
4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 6
4.3. Seamless Redundancy . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Deterministic Networking (DetNet) provides the capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low data loss rates and bounded latency within a
network domain. As discussed in the Deterministic Networking
Architecture[I-D.ietf-detnet-architecture], Techniques used to
provide this capability include reserving data plane resources for
individual (or aggregated) DetNet flows in some or all of the
intermediate nodes along the path of the flow, providing explicit
routes for DetNet flows, and distributing data from DetNet flow
packets over time and/or space to ensure delivery of each packet's
data in spite of the loss of a path.
All these DetNet specific technologies need support of protocal from
both data plane and control plane.
DetNet data plane framework is defined in
[I-D.ietf-detnet-data-plane-framework]. This document defines DetNet
control plane framework. It specifies the guidance of DetNet control
plane implementation.
Geng, et al. Expires January 5, 2020 [Page 2]
Internet-Draft Abbreviated-Title July 2019
2. Terminologies
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Terminologies for DetNet go along with the definition in
[I-D.ietf-detnet-architecture].
3. DetNet Control Plane Classification
This section defines three classes of DetNet control plane: fully
distributed control plane, fully centralized control plane, hybrid
control plane, based on different network architectures, showing how
configuration information exchanges between various entities in the
network.
3.1. Fully Distributed Control Plane
In a fully distributed configuration model, UNI information is
transmitted over DetNet UNI protocol from the user side to the
network side; then UNI information and network configuration
information propagate in the network over distributed control plane
protocol. For example:
1) IGP collects topology information and DetNet capabilities of
network([I-D.geng-detnet-info-distribution]);
2) Control Plane of the Edge Node(Ingress) receives a flow
establishment request from UNI and calculates a/some valid path(s);
3) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
explicit route. After receiving the PATH message, the other Edge
Node(Egress) sends a Resv message with distributed label and resource
reservation request.
Current distributed control plane protocol,e.g., RSVP-TE[RFC3209],
SRP[IEEE802.1Qcc], can only reserve bandwidth along the path, while
the configuration of a fine-grained schedule, e.g.,Time Aware
Shaping(TAS) defined in [IEEE802.1Qbv], is not supported.
3.2. Fully Centralized Control Plane
In the fully centralized configuration model, UNI information is
transmitted from Centralized User Configuration (CUC) to Centralized
Network Configuration(CNC). Configurations of routers for DetNet
flows are performed by CNC with network management protocol. For
example:
Geng, et al. Expires January 5, 2020 [Page 3]
Internet-Draft Abbreviated-Title July 2019
1) CNC collects topology information and DetNet capability of network
through Netconf;
2) CNC receives a flow establishment request from UNI and calculates
a/some valid path(s);
3) CNC configures the devices along the path for flow transmission.
3.3. Hybrid Control Plane
In the hybrid configuration model, controller and control plane
protocols work together to offer DetNet service, and there are a lot
of possible combinations. For example:
1) CNC collects topology information and DetNet capability of network
through IGP/BGP-LS;
2) CNC receives a flow establishment request from UNI and calculates
a/some valid path(s);
3) Based on the calculation result, CNC distributes flow path
information to Edge Node(Ingress) and other information(e.g.
replication/elimination) to the relevant nodes.
4) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
explicit route. After receiving the PATH message, the other Edge
Node(Egress) sends a Resv message with distributed label and resource
reservation request.
or
1) Controller collects topology information and DetNet capability of
network through IGP/BGP-LS;
2) Control Plane of Edge Node(Ingress) receives a flow establishment
request from UNI;
3) Edge Node(Ingress) sends the path establishment request to CNC
through PCEP;
4) After Calculation, CNC sends back the path information of the flow
to the Edge Node(Ingress) through PCEP;
5) Using RSVP-TE, Edge Node(Ingress) sends a PATH message with
explicit route. After receiving the PATH message, the other Edge
Node(Egress) sends a Resv message with distributed label and resource
reservation request.
Geng, et al. Expires January 5, 2020 [Page 4]
Internet-Draft Abbreviated-Title July 2019
There are also other variations that can be included in the hybrid
control plane. This draft can not coverer all the control plane data
needed in hybrid configuration models. Every solution has there own
mechanism and corresponding parameters to make it work.
4. DetNet Control Plane Considerations
This section gives general instructions about how to implement
different DetNet technologies in control plane. New requirements for
the current protocal are highlighted.
4.1. Explicit Route
Explicit Route is required in DetNet to provide stable transport
service and guarante that DetNet service is not effected when the
network topology changes. The following features are necessary to
have explicit route in DetNet:
o Path Computation
Explicit path for DetNet is supposed to meet the SLA(Service Level
Agreement) requirement or resource guarantee from the application/
client, which include: bandwidth, maximum end-to-end delay, maximum
end-to-end delay variation, maximum loss ratio and so on. In an
distributed system with IGP-TE, CSPF(Contstraint Shortest Path First)
can be used to compute a set of feasible paths for a DetNet Service.
In a system with a network controller, PCE(Path Computation Engine)
can compute paths satisfying the requirements of DetNet with the
network information collected from the DetNet domain.
o Setting up a path
After choosing a path that meets the requirement, an explicit path is
supposed to set up in a DetNet domain. DetNet flows are steered
through the network along their allocated path. RSVP-TE can be used
to set up a path with flow identification. The packets with the flow
identification would be routed as the RSVP-TE specifies. Segment
Routing is another option and no flow status is needed excepct for
the ingress node. SR policy is insterted into the packet at the
ingress node and the packet .
o Strict or Loose
An explicit path is strict when every intermidate hop is specified so
that its route can't change. An explicit path is loose when any IGP
route is allowed along the path. Generally, end-to-end SLA guarantee
needs a strict explicit in DetNet. However, when the IGP route is
Geng, et al. Expires January 5, 2020 [Page 5]
Internet-Draft Abbreviated-Title July 2019
known and can meet the SLA requirement, Loose explicit path is also
acceptable.
4.2. Resource Reservation
Congestion could cause uncontrolled delay and packet loss. DetNet
flows are supposed to be protected from congestion, so enough
resource reservation for DetNet service is necessary. Resource in
the network is complex and hard to quantize, for example: packet
processing resource, buffer size, port bandwidth and so on. The
resource a flow occupies is determined by the flow characteristics.
o Resource Allocation
Port bandwidth is one of the basic attributes of the network device
which is easy to get and calculate. In the current implementation,
network resource allocation means bandwidth allocation. DetNet flow
is characterized with traffic specification, which is defined in
[I-D.ietf-detnet-flow-information-model] , including : Interval, Max
Packets Per Interval and Max Payload Size. Flow rate is the an
average value, while traffic specification describes the worst case
of the traffic. And time concept is introduced in traffic
spefication.The resource reservation in DetNet can be worst-case
bandwidth reservation, and avoid confiction in an interval may also
be considered. Buffer resource is also in the scope to avoid packet
loss when the buffer is not enough.
o Device Configuration with or withour Flow Discrimination
The resouce allocation is guaranteed by device configuration. For
example, the value of output port bandwidth reservation can be
configured as the parameter of queue management and scheduling
algorithm. When the DetNet flows are aggregated, a group of DetNet
flows shared the allocated resource in the network device. When the
DetNet flows are treated independently, the device should maintains a
mapping relationship between DetNet flows and its corresponding
resource.
4.3. Seamless Redundancy
Seamless Redundancy is guaranteed by the packet replication and
elimination. The flow is replicated and go through parallel paths to
avoid packet loss caused by device failure. The network device
should
o Explicit Path
Geng, et al. Expires January 5, 2020 [Page 6]
Internet-Draft Abbreviated-Title July 2019
The current signalling that can set up an explicit path, as mentioned
above like RSVP-TE or Segment Routing, can support an P2P or P2MP
path. Seamless Redundancy requires P2MP2P path. Protocal extentions
are required to support this new feature.
o Flow Identification and Sequence Number
The nodes that execute Packet Replication or Elmination are supposed
to identify different DetNet flows and the nodes that execute Packet
Elimination are supposed to discriminate packets in one DetNet flow.
The flow identification and the rule of the sequence number should be
specified in the relay nodes by distributed signalling or a
centralized controller.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
TBD
7. Acknowledgements
TBD
8. Normative References
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-00
(work in progress), May 2019.
[I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet
Flow Information Model", draft-ietf-detnet-flow-
information-model-03 (work in progress), March 2019.
Geng, et al. Expires January 5, 2020 [Page 7]
Internet-Draft Abbreviated-Title July 2019
[IEEE802.1Qcc]
IEEE, "IEEE, "Stream Reservation Protocol (SRP)
Enhancements and Performance Improvements (IEEE Draft
P802.1Qcc)", 2017,
<http://www.ieee802.org/1/files/private/cc-drafts/>.".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
Authors' Addresses
Xuesong Geng
Huawei
Mach(Guoyi) Chen
Huawei
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Geng, et al. Expires January 5, 2020 [Page 8]
