PCEP Extension for DetNet Bounded LatencyZTE CorporationChinaxiong.quan@zte.com.cnChina MobileBeijingChinaliupengyjy@chinamobile.com
Routing
PCEIn certain networks, such as Deterministic Networking (DetNet), it
is required to consider the bounded latency for path selection.
This document describes the extensions to PCEP to carry deterministic
latency constraints and distribute deterministic paths for
end-to-end path computation in DetNet service.Introduction describes the Path Computation Element Protocol (PCEP)
which is used between a Path Computation Element (PCE) and a Path
Computation Client (PCC) (or other PCE) to enable computation of
Multi-protocol Label Switching (MPLS) for Traffic Engineering Label
Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model
describes a set of extensions to PCEP to enable active
control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted
in , a PCE MUST be able to compute the path of a TE LSP by
operating on the TED and considering bandwidth and other constraints
applicable to the TE LSP service request. The constraint parameters
are provided such as metric, bandwidth, delay, affinity, etc.
However these parameters can't meet the DetNet requirements.According to , Deterministic Networking (DetNet) operates
at the IP layer and delivers service which provides extremely low data
loss rates and bounded latency within a network domain. The bounded
latency indicates the minimum and maximum end-to-end latency from source
to destination and bounded jitter (packet delay variation).
has proposed the
packet treatment which should support new functions such as
queuing mechanisms to ensure the deterministic latency.
The computing method of end-to-end delay bounds is defined in .
It is the sum of the 6 delays in DetNet bounded latency model. And these
delays should be measured and ccollected, but the related mechanisms
are out of this document. The end-to-end delay bounds can also be computed
as the sum of non queuing delay bound and queuing delay bound along the
path. The upper bounds of non queuing delay are constant and depend on the
specific network and the value of queuing delay bound depends on the
queuing mechanisms deployed along the path.As per , explicit path should
be calculated and established in control plane to guarantee the
deterministic transimission. When the PCE is deployed, the path
computation should be applicable for DetNet networks. It is required
that bounded latency including minimum and maximum end-to-end latency
and bounded delay variation are considered during the deterministic
path selection for PCE. The bounded latency constriants should be
extended for PCEP. Moreover, the information along the deterministic
path should be provided to the PCC after the path conputation such as
queuing parameters. This document describes the extensions to PCEP to carry deterministic
latency constraints and distribute deterministic paths for
end-to-end path computation in DetNet service.Requirements LanguageThe 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.TerminologyThe terminology is defined as and
.PCEP ExtensionsMETRIC ObjectThe METRIC object is defined in Section 7.8 of , comprising
metric-value and metric-type (T field), and a flags field, comprising
a number of bit flags (B bit and C bit). This document defines two
types for the METRIC object.End-to-End Bounded Delay Metric has proposed the Path Delay metric type of the METRIC object
to represent the sum of the Link Delay metric of all links along a P2P path.
This document proposes the End-to-End Bounded Delay metric in PCEP to
represent the sum of Output delay, Link delay, Frame preemption delay,
Processing delay, Regulation delay and Queuing delay as defined in
along a deterministic path. Or the
End-to-End Bounded Delay metric can be encoded as the sum of
non queuing delay bound and queuing delay bound along the deterministic
path. The extensions for End-to-End Bounded Delay Metric are as
following shown:
T=TBD1: End-to-End Bounded Delay Metric.
The value of End-to-End Bounded Delay Metric is the encoding
in units of microseconds with 32 bits.
The B bit MUST be set to suggest a maximum bound for the
end-to-end delay of deterministic path. The end-to-end delay
must be less than or equal to the value.
A PCC MAY use the End-to-End Bounded Latency metric in a Path
Computation Request (PCReq) message to request a deterministic path
meeting the end-to-end latency requirement. A PCE MAY use the End-to-End
Bounded Latency metric in a Path Computation Reply (PCRep) message
along with a NO-PATH object in the case where the PCE cannot compute
a path meeting this constraint. A PCE can also use this metric to
send the computed end-to-end bounded latency to the PCC.End-to-End Bounded Jitter Metric has proposed the Path Delay Variation metric type of the METRIC
object to represent the sum of the Link Delay Variation metric of all links
along the path. This document proposes the End-to-end Bounded Jitter metric in PCEP to
represent the difference between the end-to-end upper bounded latecny and
the end-to-end lower bounded latecny along a deterministic path.
The extensions for End-to-End Bounded Jitter Metric are as
following shown:
T=TBD2: End-to-End Bounded Jitter Metric.
The value of End-to-End Bounded Jitter Metric is the encoding
in units of microseconds with 32 bits.
The B bit MUST be set to suggest a maximum bound for the
end-to-end jitter of deterministic path. The end-to-end jitter
must be less than or equal to the value.
A PCC MAY use the End-to-End Bounded Jitter metric in a PCReq
message to request a deterministic path meeting the end-to-end
delay variation requirement. A PCE MAY use the End-to-End Bounded
Jitter metric in a PCRep message along with a NO-PATH object in
the case where the PCE cannot compute a path meeting this constraint.
A PCE can also use this metric to send the computed end-to-end bounded
Jitter to the PCC.LSP ObjectThe LSP Object is defined in Section 7.3 of . This document
defiend a new flag (D-flag) to present the deterministic path for
the LSP-EXTENDED-FLAG TLV carried in LSP Object as defined in
. D (Request for Deterministic Path) : If the bit is set to 1, it
indicates that the PCC requests PCE to compute the deterministic path.
A PCE would also set this bit to 1 to indicate that the deterministic
path is included by PCE and encoded in the PCRep, PCUpd or PCInitiate
message.Deterministic Path ObjectThe Explicit Route Object (ERO) is defined in to encode
the path of a TE LSP through the network. SR-ERO subobject is used
for SR-TE path which consists of one or more SIDs as defined in .
SRV6-ERO subobject is used for SRv6 path as defined in
. As defined in , the end-to-end delay bounds
can be presented as the sum of non queuing delay bound and queuing delay
bound along the path. The upper bounds of non queuing delay are constant
and depend on the specific network, but the value of queuing delay bound
depends on the queuing mechanisms deployed along the deterministic path.
So to meet the requirements of the end-to-end delay, the PCE should
select a queuing mechanism and configure the related parameters to the
PCC. This document defines Deterministic Path Object (DPO) to distribute
the deterministic latency information through DetNet networks.DPO Object-Class is TBD3.DPO Object-Type is TBD4.The format of the DPO object body is as follows:Deterministic Latency Type (16bits): indicates the type of queuing
algorithm and each type represents the corresponding queuing
mechanisms. The type can be defined refer to the queuing mechanisms
which have been discussed such as .
More types can be defined due to the new queuing mechanisms.1: indicates the Time Aware Shaping [IIEEE802.1Qbv].2: indicates the Credit-Based Shaper[IEEE802.1Q-2014].3: indicates the Asynchronous Traffic Shaping [IEEE802.1Qcr].4: indicates the Cyclic Queuing and Forwarding [IEEE802.1Qch].5: indicates the Deadline Based Forwarding
and .6: indicates the Multiple Cyclic Buffers Queuing Mechanism
.7: indicates the ADN mechanism defined in
. Deterministic Latency Infomation Sub-TLV (variable): indicuates the corresponding
Deterministic Latency Parameters. The current Sub-TLVs including Deadline Sub-TLV and
Cycle Sub-TLV are proposed as following sections.Deadline Sub-TLVDeadline Sub-TLV is optional for the Queuing Information Structure.
The deadline-based queue mechanism has been proposed in [draft-stein-srtsn] and
. The deadlines along the path
should be computed at PCE and configured to the PCC, and then inserted
into the packet headers. When the Queuing Algorithm Type is set to indicate
the deadline-based queuing mechanisms, the Deadline Sub-TLV should be used
to carry the deadline parameters.Type (16bits): TBD3, indicates the type of Deadline Sub-TLV.Length (16bits): indicated the length of Deadline Sub-TLV.Deadline (32bits): indicates the deadline time for a node to
forward a DetNet flow.Cycle Sub-TLVCycle Sub-TLV is optional for the Queuing Information Structure.
The cyclic-based queue mechanism has been proposed in [IEEE802.1Qch] and
improved in [draft-dang-queuing-with-multiple-cyclic-buffers]. The clycle
along the path should be computed at PCE and configured to the PCC,
and then inserted into the packet headers. When the Queuing Algorithm
Type is set to indicate the cycle-based queuing mechanisms, the Cycle
Sub-TLV should be used to carry the cycle parameters.Type (16bits): TBD4, indicates the type of Cycle Sub-TLV.Length (16bits): indicated the length of Cycle Sub-TLV.Cycle Profile ID (32bits): indicates the profile ID which the
cyclic queue applied at a node.Cycle ID (32bits): indicates the Cycle ID for a node to
forward a DetNet flow.AcknowledgementsTBAIANA ConsiderationsTBASecurity ConsiderationsTBAReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsPath Computation Element (PCE) Communication Protocol (PCEP)Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsPath Computation Element Communication Protocol (PCEP) Extensions for Stateful PCENorth-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPM-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)Multi-Topology (MT) Routing in OSPFA Path Computation Element (PCE)-Based ArchitectureOSPFv2 Multi-Instance ExtensionsSR-PCEDetNet ArchitectureLSP Extended FlagsDetNet Bounded LatencyHuawei Technologies Co. LtdEPFLEPFLHuawei Technologies Co. LtdEricsson This document presents a timing model for sources, destinations, and
DetNet transit nodes. Using the model, it provides a methodology to
compute end-to-end latency and backlog bounds for various queuing
methods. The methodology can be used by the management and control
planes and by resource reservation algorithms to provide bounded
latency and zero congestion loss for the DetNet service.
Asynchronous Deterministic Networking Framework for Large-Scale NetworksSangmyung UniversityETRIETRIHuaweiChina MobileThis document describes an overall framework of Asynchronous Deterministic Networking (ADN) for large-scale networks. It specifies the functional architecture and requirements for providing latency and jitter bounds to high priority traffic, without time- synchronization of network nodes.A Queuing Mechanism with Multiple Cyclic BuffersHuaweiHuawei This document presents a queuing mechanism with multiple cyclic
buffers.
Segment Routed Time Sensitive NetworkingRAD Routers perform two distinct user-plane functionalities, namely
forwarding (where the packet should be sent) and scheduling (when the
packet should be sent). One forwarding paradigm is segment routing,
in which forwarding instructions are encoded in the packet in a stack
data structure, rather than programmed into the routers. Time
Sensitive Networking and Deterministic Networking provide several
mechanisms for scheduling under the assumption that routers are time
synchronized. The most effective mechanisms for delay minimization
involve per-flow resource allocation.
SRTSN is a unified approach to forwarding and scheduling that uses a
single stack data structure. Each stack entry consists of a
forwarding portion (e.g., IP addresses or suffixes) and a scheduling
portion (deadline by which the packet must exit the router). SRTSN
thus fully implements network programming for time sensitive flows,
by prescribing to each router both to-where and by-when each packet
should be sent.
Deadline Based Deterministic ForwardingZTE CorporationZTE CorporationChina Mobile This document describes a deterministic forwarding mechanism based on
deadline. The mechanism enhances strict priority scheduling
algorithm with dynamically adjusting the priority of the queue
according to its deadline attribute.
Deadline OptionZTE CorporationZTE Corporation This document introduces new IPv6 options for Hop-by-Hop Options
header, to carry deadline related information for deterministic
flows.
DetNet Enhancements for Large-Scale Deterministic NetworksZTE CorporationChina MobileThis document describes enhancements to DetNet to achieve the differentiated DetNet QoS in large-scale deterministic networks including the overall requirements and solutions with deterministic resources, routes and services.Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplaneHuawei TechnologiesRtBrick IncCiena CorporationCisco Systems, Inc.RtBrick IncChina TelecomThe Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link-State IGPs. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a PCE. Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This document describes the extensions required for SR support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS is described in RFC 8664. This document extends it to support SRv6 (SR over IPv6).Deterministic Networking (DetNet) Controller Plane FrameworkIndependentHuaweiHuaweiChina MobileEricssonThis document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification.Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.