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.

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 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. Terminologies
• 3. DetNet Control Plane Classification
• 3.1. Fully Distributed Control Plane
• 3.2. Fully Centralized Control Plane
• 3.3. Hybrid Control Plane
• 4. DetNet Control Plane Considerations
• 4.1. Explicit Route
• 4.2. Resource Reservation
• 4.3. Seamless Redundancy
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. Normative References
• Authors' Addresses

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.

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:

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.

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:

• 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.

• 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 .

• 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 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.

[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.

• 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

• 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

• Explicit Path

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.

• 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

Authors' Addresses