SRv6 for Deterministic Networking
(DetNet)Huaweigengxuesong@huawei.comHuaweilizhenbin@huawei.comHuaweimach.chen@huawei.comDeterministic Networking provides service with low jitter, bounded
latency and low loss rate, using technologies of explicit route,
resource reservation and service protection.This document specifies how
to implement Deterministic Networking (DetNet) in a SRv6 Network.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.With more and more applications running in the Internet, quality of
the service gains more and more attention, especially for some new
applications, for example Cloud VR, Cloud Game, HDV (high-definition
video) and so on, SLA (Service Level Agreement), including jitter, delay
and loss rate, influences the users' experience significantly. So SLA
guarantee is an important issue which requires new technologies and
solutions for the network.Deterministic Networking (DetNet defined in )
provides a capability to carry specified data flows for real-time
applications with extremely low data loss rates, low jitter and bounded
latency within a network domain. Techniques used include: 1) providing
explicit paths for DetNet flows that satisfies the SLA requirement from
user and do not immediately change with the network topology; 2)
reserving data plane resources for DetNet flows along the allocated path
of the flow; 3) replicates DetNet flows into two or more copies and
transport different copies through different path in parallel, called
service protection.Segment Routing(SR) leverages the source routing paradigm. An ingress
node steers a packet through an ordered list of instructions, called
"segments". SR can be applied over IPv6 data plane using Routing
Extension Header(SRH, ). A segment in Segment
Routing is not limited to a routing/forwarding function. An SRv6 Segment
can indicate functions that are executed locally in the node where they
are defined. describes some
well-known functions and segments associated to them. SRH TLVs() also provides meta-data for segment processing. All
these features make SRv6 suitable to carry DetNet flows, by defining new
segments associated with DetNet functions and meta data for DetNet.This document describes the concepts needed by implementing DetNet in
an SRv6-based domain and provides considerations for any corresponding
implementation.Editor's note: DetNet is limited in a controlled network domain, and
it is not the only method to provide SLA guarantee. But it is a good
start to discuss how to use SRv6 to have a SLA-guaranteed network
service.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 and :DetNet domainThe portion of a network that is DetNet aware. It includes end
systems and DetNet nodesDetNet edge nodeAn instance of a DetNet relay node that acts as a source and/ or
destination at the DetNet service sub-layer. For example, it can
include a DetNet service sub-layer proxy function for DetNet service
protection (e.g., the addition or removal of packet sequencing
information) for one or more end systems, or starts or terminates
resource allocation at the DetNet forwarding sub-layer, or
aggregates DetNet services into new DetNet flows. It is analogous to
a Label Edge Router (LER) or a Provider Edge (PE) router.DetNet relay nodeA DetNet node including a service sub-layer function that
interconnects different DetNet forwarding sub-layer paths to provide
service protection. A DetNet relay node participates in the DetNet
service sub-layer. It typically incorporates DetNet forwarding
sub-layer functions as well, in which case it is collocated with a
transit node.DetNet transit nodeA DetNet node operating at the DetNet forwarding sub-layer, that
utilizes link layer and/or network layer switching across multiple
links and/or sub-networks to provide paths for DetNet service
sub-layer functions. Typically provides resource allocation over
those paths. An MPLS LSR is an example of a DetNet transit node.End systemEnd systems of interest to this document are either sources or
destinations of DetNet flows. And end system may or may not be
DetNet forwarding sub-layer aware or DetNet service sub-layer
aware.DetNet service sub-layerDetNet functionality is divided into two sub-layers. One of them
is the DetNet service sub-layer, at which a DetNet service, e.g.,
service protection is provided.DetNet forwarding sub-layerDetNet functionality is divided into two sub-layers. One of them
is the DetNet forwarding sub-layer, which optionally provides
resource allocation for DetNet flows over paths provided by the
underlying network.As mentioned above, there are mainly three technologies/functions
defined in DetNet: Explicit Route, Resource Reservation and Service
Protection. Explicit Route is the basic of the other two technologies,
and guarantees the path satisfies the SLA requirement from application.
Resource Reservation protects DetNet flows from network congestion,
which could reduce the end-to-end latency and congestion loss; Service
Protection prevents DetNet flow from random media errors and equipment
failures, which makes the loss rate extremely low.In , DetNet functionality is implemented in
two sub-layers in the protocol stack: the DetNet service sub-layer and
the DetNet forwarding sub-layer. The DetNet service sub-layer provides
DetNet service, e.g., service protection. The DetNet forwarding
sub-layer supports DetNet service in the underlying network, by
providing explicit routes and resource allocation to DetNet flows. There
is no obvious protocol stack as MPLS, in SRv6 both service sub-layer and
forwarding sub-layer are implemented through SRH.The following picture shows that a general DetNet enabled network
defined in :In SRv6 for DetNet, the outer IPv6 Header with the SRH is used for
carrying DetNet flows. Explicit path is instantiated in the segment list
of SRH, and other functions/arguments for service protection (packet
replication, elimination and ordering, PREOF) and resource reservation
(packet queuing and scheduling) are also defined in the specified SID.
Meta data for DetNet could be instantiated in the Optional TLVs.The figure below shows that an IPv6 flow is sent out from the end
station E1. The packet of the flow is encapsulated in an outer
IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and
transported through an SRv6 DetNet domain. In the Egress(Eg), the
outer IPv6 header+SRH of the packet is popped, and the packet is sent
to the destination E2.The DetNet packet processing is as follows:Ingress:Inserts the SRv6 Policy that will steer the packet from Ingress
to the destinationThe methods and mechanisms used for defining, instantiating and
applying the policy are outside of this document. An example of
policies are described in Flow Identification and Sequence Number are carried in the
SRH.Relay Node 1(Replication Node):Replicates the payload and IPv6 Header with the SRH. This is a
new function in the context of SRv6 Network Programming which will
associate a given SID to a replication instruction in the node
originating and advertising the SID. The replication instruction
includes:The removal of the existing IPv6+SRH headerThe encapsulation into a new outer IPv6+SRH header. Each
packet (the original and the duplicated) are encapsulated into
respectively new outer IPv6+SRH headers.Binding two different SRv6 Policies respectively to the
original packet and the replicated packet, which can steer the
packets from Relay Node 1 to Relay Node 2 through two tunnels.Relay Node 2(Elimination Node):Eliminates the redundant packets.Binds a new SRv6 Policy to the survival packet, which steers
the packet from Relay Node 2 to Egress.Egress:Decapsulates the outer Ipv6 header.Sends the inter packet to the End Station 2.The DetNet packet encapsulation is illustrated here below. It has
to be noted that, in the example below, the R2 address is a SRH SID
associated to a TBD function related to the packet replication the
node R1 has to perform. The same (or reverse) apply to node R2 which
is in charge of the discard of the duplicated packet. Here also a new
function will have a new SID allocated to it and representing the
delete of the duplication in R2.End Station1 output packet: (E1,E2)Ingress output packet: (In, T1)(R1,T1, SL=2)(E1,E2)Transit Node1 output packet: (In, R1)(R1,T1,SL=1)(E1,E2)Relay Node1 output packets : (R1,T2)(R2,T2,SL=2)(E1,E2),
(R1,T3)(R2,T3,SL=2)(E1,E2)Transit Node2 output packet: (R1, R2)(R2,T2,SL=1)(E1,E2)Transit Node3 output packet: (R1, R2)(R2,T3,SL=1)(E1,E2)Relay Node2 output packet: (R2, T4)(Eg,T4,SL=2)(E1,E2)Transit Node4 output packet: (R2, Eg)(Eg,T4,SL=1)(E1,E2)Egress out : (E1,E2)Flow Identification and sequence number are necessary in the
encapsulation of SRv6 for DetNet in order to support service
protection. Replication nodes decide which DetNet flows are supposed
to be replicated by identifying the flow with the flow identification.
Elimination nodes decide whether a packet should be dropped because of
redundancy by identifying the flow identification and sequence
number.1. Edge node->Controller: Sends a path computation requirement
containing that service protection in order to have ultra-reliability
through PCEP/BGP extenisons.2. Controller->Edge node: Computes a P2MP2P path, including
replication nodes and elimination nodes. Between a pair of replication
node and elimination node, there are more than one path, and if any
equipment failure happens in one of them, the DetNet service is not
interrupted. Send the path computation result to the edge node through
PCEP/BGP extensions.3. Controller->Relay Node : In a P2MP2P path, every pair of
replication node and elimination node should be configured to identify
different DetNet flows by the different flow identifications, and the
rule of sequence number should be negotiated between relay nodes.
After replication or elimination, the explicit path to the next relay
is also required through BGP extensions or Netconf YANG.The figure below shows that an IPv6 flow is sent out from the end
station E1. The packet of the flow is encapsulated in an outer
IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and
transported through an SRv6 DetNet domain. In the Egress(Eg), the
outer IPv6 header+SRH of the packet is popped, and the packet is sent
to the destination E2.The DetNet packet processing is as follows:Ingress:Inserts the SRv6 Policy that will steer the packet from Ingress
to the destination.The methods and mechanisms used for defining, instantiating and
applying the policy are outside of this document. An example of
policies are described in Explicit route and the corresponding resource is carried in the
SRH.T1 Node (Transit Node):Forward the packet with the allocated resource.This is a new function in the context of SRv6 Network
Programming which will associate a given SID to a replication
instruction in the node originating and advertising the SID. The
instruction includes:Forward the packet to the link bound to the SIDUse the resource when forwarding the packetThe processing of T2 and T3 Node is similar.Egress:Decapsulates the outer IPv6 header.Sends the inter packet to the End Station 2.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. Some of the resource in
the network is complex and hard to quantize, e.g., packet processing
resource; while some of them is easy to get and calculate, e.g.,
buffer size, port bandwidth and so on. In order to use the allocated
resource for the DetNet flow, SRv6 for DetNet is supposed to carry the
information of the resource. And the network device could transit the
packet following the instruction in the SRH with the corresponding
resources.1. Edge node->Controller: Sends a path computation
requirement containing the flow characteristics and resource
reservation request through BGP/PCEP.2. Controller->Edge node: The controller should collect the
network resource information of the network, e.g., bandwidth, buffer
size and so on, and maintain the resource status for every
device/output port. Based on the flow characteristics, the controller
should find a path which can guarantee that there are enough resources
in every device/output port the flow goes through. The controller
sends the path computation results back to the edge node, and update
the resources status of the network through BGP/PCEP.3. Controller->Transit Node: Every transit node along the path
should be configured in order to make sure that when the DetNet flow
goes through, the allocated resource for this flow is able to be used
and no more resource than what is allocated will be used for the same
flow through BGP/Netconf YANG.\SRv6 could support explicit route using segment list without extra
extension. In DetNet, explicit route could be used with service
protection or resource reservation. When explicit route works with
service protection, a P2MP2P path is required to indicate the behavior
of replication and elimination. When explicit route works with resource
reservation, the explicit path indicates the nodes or links a DetNet
flow goes through, and also indicates the resource allocated for the
DetNet flow in the specified nodes or links.This document makes no request of IANA.Note to RFC Editor: this section may be removed on publication as an
RFC.TBDThank you for valuable comments from James Guichard and Andrew
Mails.