Internet DRAFT - draft-zha-detnet-requirments
draft-zha-detnet-requirments
Network Working Group Y. Zha
Internet Draft Huawei Technologies
Intended status: Informational L. Geng
Expires: September 2016 China Mobile
March 16, 2016
Deterministic Networking Requirements on Data and Control Plane
draft-zha-detnet-requirments-00
Abstract
Deterministic Networking (DetNet) is focused on how to serve time
critical flow with low data loss and bounded delay. Unlike
contemporary solution which improves QoS such as TE, redundant
bandwidth provisioning and dedicated channel reservation, DetNet
provides more general approaches that use IP-based techniques and
guarantee the worst-case latency of DetNet flows while allowing
sharing among best-effort flows. For this purpose, DetNet may
require upgraded or redefined data plane as well as control plane,
since current networking cannot assure maximum end-to-end latency.
This document describes some technical requirements on possible
data plane, control plane and DetNet flow modeling that can help
to clarify those capabilities DetNet should have.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Zha and Geng Expires September 16 2016 [Page 1]
Internet-Draft DetNet Requirements March 2016
This Internet-Draft will expire on September 16, 2016.
Copyright Notice
Copyright (c) 2014 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
(http://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
2. Conventions used in this document ............................3
3. Overall Architecture .........................................4
4. Data Plane Requirements ......................................4
4.1. MPLS to Support DetNet Flow Forwarding ..................4
4.2. DetNet Flow Identification ..............................5
4.3. Deterministic Forwarding Capability .....................6
5. Control Plane Requirements ...................................7
5.1. Distributed or Centralized Control ......................7
5.2. Southbound/Northbound Interfaces ........................8
5.3. Peer-to-Peer Reservation Protocol .......................9
6. Requirements on DetNet Flow Modeling .........................9
7. Requirements on Synchronization and OAM .....................10
8. Security Considerations .....................................10
9. IANA Considerations .........................................10
10. Acknowledgments ............................................10
11. References .................................................10
11.1. Normative References ..................................10
11.2. Informative References ................................11
1. Introduction
The rapid growth of the existing communication system and its
access into almost all aspects of daily life has led to great
dependency on services it provides. The communication network, as
it is today, has applications such as multimedia and peer-to-peer
file sharing distribution that require Quality of Service (QoS)
which guarantees delay and jitter to maintain a certain level of
Zha and Geng Expires September 16, 2016 [Page 2]
Internet-Draft DetNet Requirements March 2016
performance. Meanwhile, cellular network has become key element in
modern social network with increasing popularity over the past
years. A communication system with extreme real-time and high
reliability is essential for the next concurrent and next
generation cellular networks as well as its bearer network for E-
2-E performance requirements.
Conventional transport network is IP-based for the benefits of
high bandwidth and low cost. However, the delay and jitter
guarantee becomes a challenge in case of contention since the
service is not deterministic but best effort. With more and more
rigid demand in latency control in the future network [METIS],
deterministic networking [I-D.finn-detnet-architecture] becomes a
promising solution to meet the requirement of ultra low-latency of
certain applications and use cases. There are already typical
issues for latency sensitive networking requirements in midhaul
and backhaul network to support LTE and future 5G network [5G].
Moreover not only the telecom industry but also other vertical
industries have increasing demand on delay-sensitive
communications as automation becomes increasingly popular recently.
More specifically, CoMP techniques, D-2-D, industrial automation
and gaming/media service all have great dependency on low delay
communications as well as high reliability to guarantee the
service performance. Note that the deterministic networking is not
equal to low latency as it is more focused on the worst case delay
bound of the duration of certain application or service. It can be
argued that without high certainty and absolute delay guarantee,
low delay provisioning is just relative [RFC3393], which is not
sufficient to some delay-critical service since delay violation in
an instance cannot be tolerated. Overall, the requirements from
vertical industries seem to be well aligned with the expected low
latency and high determinist performance of future networks
This document only describes technical requirements and design
principles on data plane, control plane and modeling to minimize
the scope of this document since a full coverage of DetNet can be
found in [I-D.finn-detnet-architecture]
2. Conventions used in this document
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to
be interpreted as carrying [RFC2119] significance.
Zha and Geng Expires September 16, 2016 [Page 3]
Internet-Draft DetNet Requirements March 2016
3. Overall Architecture
Draft [I-D.finn-detnet-architecture] provides an overall picture
of the DetNet operation. The draft covers almost every aspects of
deterministic service provisioning which will be indeed asking for
an architectural upgrade. An entire working system is needed for
end-to-end delay-guaranteed service provisioning, but the WG may
only works on several topics as the final deliverables. Meanwhile,
there are still some open issues on both design and implementation
of data plane and control plane.
Based on the current architecture, three key aspects are
identified: how to specify the data plane (including the
forwarding in [I-D.finn-detnet-architecture]) and what is the
essential characteristic of the data plane enabling deterministic
forwarding; how to design appropriate control protocols and
mechanisms to serve end-to-end DetNet flows; what and how modeling
should be defined to describe basic principles of both data plane
and control plane.
4. Data Plane Requirements
As mentioned in the current charter, DetNet focus on Layer 3
techniques to support deterministic latency applications. Without
redefining the hardware and physical layers, potential data plane
must be compatible with Layer 2 operations (i.e. TSN) In the
architectural draft[I-D.finn-detnet-architecture], the data plane
is described as the most fundamental element of the network,
comprising the device and forwarding plane, which decides the
queuing, scheduling and shaping of traffic. In order to provide
converged networking in which DetNet flows get bounded delay
guarantee while non-DetNet flows are best-effort, the DetNet data
plane should specify to answer the following questions: how to use
existing technologies for Layer 3 operation, MPLS may be a good
candidate to setup end-to-end deterministic flow path; how to
identify the DetNet data flow; a standardized mechanism of DetNet
flow forwarding including queuing, transmission, shaping and etc.
4.1. MPLS to Support DetNet Flow Forwarding
IEEE works on Layer 1-2 technologies where TSN has successfully
provided a potential solution to the problem of serving timing
critical data flow in Ethernet. In order to expand the guaranteed
delay provisioning to the scale of the entire network, it is
critical for DetNet WG to define the Layer forwarding. As
mentioned in current charter, the goal is to use existing
Zha and Geng Expires September 16, 2016 [Page 4]
Internet-Draft DetNet Requirements March 2016
technology that can be compatible with TSN work. Given that, MPLS
technology is a good candidate for it maturity and robustness.
MPLS lies between Layer 3 and 2 with an encapsulation of different
protocols. Supposing that deterministic forwarding is ready at
each hop under TSN, MPLS can carry Ethernet frames to utilize TSN
techniques to provide an end-to-end label switched DetNet path. In
this way, the WG may needs to further define how to use MPLS in
the following aspects:
-Setup Label Switched Path (LSP) for DetNet flow with label
definition and QoS mapping.
-Latency-aware LSP installment and removing. RSVP-TE may not be
suitable for DetNet flows as it only describes macro-parameters
such as bandwidth. An extension may be desirable with latency
parameter.
-Supporting Layer-2 techniques such as pseudowire.
4.2. DetNet Flow Identification
Identification is the first step among all corresponding
operations related to DetNet flows. Because of the unified
transmission of both deterministic traffic flow and conventional
best effort flows, DetNet flow needs to be identified for certain
processes. Basically, there are two questions need to be taken are
of based on the authors' opinions: first, how to identify the flow
entity; second, how to identify its delay bound requirement.
Flow identification can be done via some tuple matching approach,
such as {VLAN identifier, destination MAC address} pair,
source/destination address, port, MAC address and so on. All these
approach can mark a unique flow in the network. However, they are
all dependent to the source. In other words, if the source is
sending both DetNet flow and best effort flow, this approach does
not work. To tackle with this challenge, a different destination
MAC address or a VLAN ID could be used. And so does the MPLS
labels.
A transformation in Layer 2 or a proxy function could be a
solution. More fundamental solution can be redefining new flag or
defining new flow model without doing the tuple matching.
Meanwhile, the flow identification should be application-aware and
impendent of sending source. An alternative approach can be
similar to those in Service Function Chain (SFC) to define
encapsulation format be agnostic to the layer at which it is
Zha and Geng Expires September 16, 2016 [Page 5]
Internet-Draft DetNet Requirements March 2016
applied and the service that is being constructed. However, this
provision certainly need more work depending on the acceptance of
WG.
The second issue is how to identify the delay bound of the target
flow being required. This is a new question which has not been
well discussed. For DetNet, we want to do absolute delay bound
provisioning while allowing best effort traffic to share
unscheduled traffic. In this way, how to provision just enough
resource to the DetNet flow is the major problem. So first needs
is to know the delay bound of the application flow. Treat all
DetNet flow as the same does not make sense since one flow
requires 1ms delay but the other requires 10ms which are all
deterministic but definitely needs different amount of network
resources.
Currently, the flow can be marked with QoS level, e.g. 0-7,
denotes the level of priority of the flow. There is no absolute
delay information of the flow as QoS level only specifies the
general characteristic of the data flow. A new mechanism to label
the absolute delay bound is necessary and it can be done via a
mapping algorithm between delay bound and current QoS labeling.
4.3. Deterministic Forwarding Capability
Although, DetNet will not define new hardware or physical layer,
different flow forwarding mechanism including queuing,
transmission selection, and shaping equipped by different network
devices or network elements can lead to the uncertainty of the
timing. To achieve predictable delay introduced in every hop, a
standard of queuing, transmission selection, shaping, and
preemption is needed to unify all the NEs in forwarding plane. TSN
can be expected to support this but sufficiently well-defined
characteristics should be defined in the WG. In the authors'
opinion, at least two features should be defined:
-Frame preemption. As transmitted via the same medium,
deterministic flow should always have absolute priority against
best effort flow, which means the DetNet flow should be first
scheduled if there is any. The problem is if the port is
transmitting a best effort flow, the incoming DetNet flow has to
wait a MTU transmission time thus introduce 12us delay in a 1GE
line. So the best effort flow should be permeable to the DetNet
flow. TSN 802.1qbu is working preemption solution for Ethernet,
DetNet should be expected to have this capability either in Layer
2 or Layer 3. In addition to current TSN solution which is mainly
focused on cut best effort packet into smaller packet with
Zha and Geng Expires September 16, 2016 [Page 6]
Internet-Draft DetNet Requirements March 2016
encapsulation, preemption on demand or real time preemption should
also be considered to avoid overhead and save latency.
-Time aware scheduling: preemption can solve the conflict between
DetNet flow and best effort flow by giving DetNet flow absolute
priority to preempt normal traffic. Conflict between DetNet flows
can still introduce uncertain delay. So scheduling of DetNet
traffic in advance with time aware capability is desirable to
solve this conflict.
5. Control Plane Requirements
In the use case draft [I-D.draft-ietf-detnet-use-cases], several
use cases summarize the needs of unified control and management
protocols and control plane. Control plane is the key component of
DetNet that can unify the existing Layer 2 technology and Layer 3
to deliver a fully functional solution for delay guarantee service.
Note that here "control plane" is used just for simplicity to
represent all control and management mechanism and protocols which
does not mean the separation of control and forwarding plane in
SDN.
The DetNet control plane design should include: architectural
choice as distributed or centralized control;
southbound/northbound interface; peer-to-peer reservation
protocols.
5.1. Distributed or Centralized Control
Assuming the data plane upgrade can provide deterministic
forwarding behavior at each hop, a unified control mechanism is
demanded to provide end-to-end delay guarantee. Although the
architecture draft propose a controller based centralized control
plane mechanism, it has not been decided yet to solely focus on
centralized only. The WG should also consider some distributed
solution with reservation protocols since centralized resource
reservation may introduce addition latency.
Introducing centralized controller seems to be the simple and
stringent forward solution. SDN is the new fashion right now with
separation of control plane from device to a remote controller.
For DetNet, if there is a central controller can do the path
computing, resource reservation and transmission selection based
on the information and delay requirement of the target flow on
every hop, it definitely can help to minimize the delay. First of
all, path computing has to be relied on central controller to
select the best forwarding path based on the DetNet flow request
Zha and Geng Expires September 16, 2016 [Page 7]
Internet-Draft DetNet Requirements March 2016
and global information of the network. Secondly, reserve enough
resource at every hop is challenging for end-to-end delay
guarantee which can be benefited from a control resource manager
to make the DetNet flow get just enough resource at every hop.
Thirdly, transmission selection or scheduling at each hop is also
crucial to serve the flow in time. A central arbiter can be
equipped to make the DetNet flow travel pass the multi-hop with
green light all the way
On the other hand, centralized controller is offsite and has to
communicate with all the NEs of entire network which can bring in
addition latency. For DetNet flows that require ms delay, the time
cost of communication to the controller and communication between
control and NEs is not affordable. So a distributed control
mechanism is also considered to be promising in some scenarios.
With distributed control, the DetNet flows do not have to wait the
controller to acknowledge and configure the downstream NEs. An
efficient reserve protocol is needed to reserve bandwidth, buffer
and other resource at each hop along the forwarding path. Also, a
hybrid approach can also be helpful as the controller can setup
the path and distributed protocol to reserve the resource at each
hop.
5.2. Southbound/Northbound Interfaces
Within SDN architecture, southbound and northbound are the key
interfaces which are close related the NEs and flow model. If
there is a central controller for DetNet, it needs to know the
forwarding capabilities of the NEs and then send the configuration
to the NEs to serve the DetNet flow. All of this information is
transmitted via southbound interface. Also the controller should
get the service level requirements via northbound interface which
is based on the service model of DetNet flows.
Southbound interface should enables communication between control
plane and network elements with following information:
-The resource inventory of the network elements, such as left over
bandwidth, unscheduled time slot on link or the size of the unused
buffer.
-Topology information of the network, it can be the similar work
that is being done in I2RS or TEAS.
-The data plane information of NEs, which include the queuing,
transmission selection, shaping and preemption related information.
Zha and Geng Expires September 16, 2016 [Page 8]
Internet-Draft DetNet Requirements March 2016
-The scheduling or QoS setting on the data plane and the
configuration information that makes the change.
Northbound interface enables communication between applications
and control and it should contain information related to:
-Service level delay requirement which can be transformed into
device configuration change in the controller.
-Flow and service description which can be relied on flow model
and configuration model.
5.3. Peer-to-Peer Reservation Protocol
As mentioned in section 5.1, distributed reservation protocols are
also desired even in a centralized architecture to reduce the
setup time caused by communication with controller. And ideal case
is that, a peer-to-peer protocol for a S-D pair to reserve
resource for DetNet flow without a central controller. Of cause
this will be an efficient and sophisticated approach if WG can
make it possible to deploy. In the authors' opinion, this peer-to-
peer reservation protocol should have characteristics such as:
-A hop by hop reservation protocol that reserve resource for the
coming DetNet flow before arriving to the next hop. The DetNet
flow will just pass through the hop using pre-setup resource.
-Only control packet or reservation signal is processed at each
hop, DetNet flow will be transmitted transparently all the way to
destination.
-This multi-hop signaling should start transmission of DetNet flow
immediately after setting up the path to next hop without
configure end-to-end path.
6. Requirements on DetNet Flow Modeling
DetNet flow modeling is one the most important deliverables of
this WG. How to model the DetNet flow will decide how to serve the
flow and how to reserve the resource, which are all the main focus
of the WG. Model is about description of characteristic of flow
transmission, technical requirements and network resource demands.
Traditional flow model is based on RSVP model which includes peak
rate, sustain rate, burst and etc. this is not feasible for
deterministic service provisioning as the bandwidth itself is not
a accurate description of latency. The DetNet flow modeling should
include:
Zha and Geng Expires September 16, 2016 [Page 9]
Internet-Draft DetNet Requirements March 2016
-Application-aware description of the flow.
-Timing information of the flow so that the network can provide
accurate service to guarantee the delay requirement.
-Data transmission information of the flow including packet size,
interval, traffic pattern and so on.
-Network-aware constraints on networking environment.
7. Requirements on Synchronization and OAM
Since operations and scheduling can be time-aware in DetNet and
absolute delay bound is a must in a multi-hop network, time
synchronization is necessary. Besides, in both centralized and
distributed architecture, delay measuring among multi-hops and
synchronization is a must for DetNet.
There is also a need for OAM system and protocols which can help
to provide E2E delay sensitive service provisioning.
More details of synchronization and OAM will be provided in next
version.
8. Security Considerations
TBD
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgments
This document has benefited from reviews, suggestions, comments
and proposed text provided by the following members, listed in
alphabetical order: Yuanlong Jiang and Oilver Huang.
11. References
11.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP
Performance Metrics (IPPM) ", RFC 3393, November 2002.
Zha and Geng Expires September 16, 2016 [Page 10]
Internet-Draft DetNet Requirements March 2016
11.2. Informative References
[I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-finn-detnet-problem-statement-02 (work in
progress), October 2015.
[I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic Networking
Architecture", draft-finn-detnet-architecture-03 (work in
progress), March 2016.
[I-D.draft-ietf-detnet-use-cases]
Ethan Grossman, et al, "Deterministic Networking Use Cases",
draft-ietf-detnet-use-cases-08, March 2016.
[METIS] METIS Document Number: ICT-317669-METIS/D1.1, Scenarios,
requirements and KPIs for 5G mobile and wireless system, April 29,
2013. Available on line at: <https://www.metis2020.com/wp-
content/uploads/deliverables/METIS_D1.1_v1.pdf>
[5G] Ericsson white paper, "5G Radio Access, Challenges for 2020
and Beyond." June 2013. Available at:
<http://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf>
[CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND
ENHANCEMENT ", MARCH 2015,
<https://www.ngmn.org/uploads/media/NGMN_RANEV_D3_CoMP_Evaluation_
and_Enhancement_v2.0.pdf>
[LTE-Latency]Samuel Johnston, "LTE Latency: How does it compare to
other technologies?" report of OpenSignal March 10, 2014.
<http://opensignal.com/blog/2014/03/10/lte-latency-how-does-it-
compare-to-other-technologies/>
[EA12] P. C. Evans, M. Annunziata, "Industrial Internet: Pushing the
Boundaries of Minds and Machines", General Electric White paper,
November 2012.
Zha and Geng Expires September 16, 2016 [Page 11]
Internet-Draft DetNet Requirements March 2016
[UHD-video] Petr Holub, "Ultra-High Definition Videos and Their
Applications over the Network", The 7th International Symposium on
VICTORIES Project, OCTOBER 8, 2014. <http://www.aist-
victories.org/jp/7th_sympo_ws/PetrHolub_presentation.pdf>
Authors' Addresses
Yiyong Zha
Huawei Technologies
Email: zhayiyong@huawei.com
Liang Geng
China Mobile
Email: liang.geng@hotmail.com
Zha and Geng Expires September 16, 2016 [Page 12]
