One document matched: draft-dt-detnet-dp-alt-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc0791 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY rfc1122 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY rfc6814 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6814.xml">
<!ENTITY rfc3232 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3232.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2205 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY rfc2460 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY rfc2474 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY rfc2702 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2702.xml">
<!ENTITY rfc2784 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY rfc2784 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY rfc2890 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml">
<!ENTITY rfc3031 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY rfc3032 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY rfc3168 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY rfc3209 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY rfc3270 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml">
<!ENTITY rfc3443 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3443.xml">
<!ENTITY rfc3473 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3931 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY rfc3985 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3985.xml">
<!ENTITY rfc4023 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4023.xml">
<!ENTITY rfc4303 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc4385 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY rfc4446 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4446.xml">
<!ENTITY rfc4447 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4447.xml">
<!ENTITY rfc4448 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4448.xml">
<!ENTITY rfc4553 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4553.xml">
<!ENTITY rfc4664 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml">
<!ENTITY rfc4817 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4817.xml">
<!ENTITY rfc4875 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml">
<!ENTITY rfc5086 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5086.xml">
<!ENTITY rfc5087 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5087.xml">
<!ENTITY rfc5254 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5254.xml">
<!ENTITY rfc5129 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml">
<!ENTITY rfc5305 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY rfc5331 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5331.xml">
<!ENTITY rfc5332 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5332.xml">
<!ENTITY rfc5440 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY rfc5462 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml">
<!ENTITY rfc5586 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml">
<!ENTITY rfc5659 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5659.xml">
<!ENTITY rfc5921 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5921.xml">
<!ENTITY rfc5960 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5960.xml">
<!ENTITY rfc6073 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6073.xml">
<!ENTITY rfc6275 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY rfc6371 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6371.xml">
<!ENTITY rfc6373 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6373.xml">
<!ENTITY rfc6378 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6378.xml">
<!ENTITY rfc6426 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6426.xml">
<!ENTITY rfc6437 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml">
<!ENTITY rfc6540 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6540.xml">
<!ENTITY rfc6564 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml">
<!ENTITY rfc6621 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6621.xml">
<!ENTITY rfc6658 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6658.xml">
<!ENTITY rfc6718 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6718.xml">
<!ENTITY rfc6733 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6733.xml">
<!ENTITY rfc6790 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY rfc6864 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6864.xml">
<!ENTITY rfc7045 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml">
<!ENTITY rfc7167 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7167.xml">
<!ENTITY rfc7198 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7198.xml">
<!ENTITY rfc7209 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7209.xml">
<!ENTITY rfc7271 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7271.xml">
<!ENTITY rfc7348 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml">
<!ENTITY rfc7399 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml">
<!ENTITY rfc7426 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY rfc7432 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY rfc7510 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml">
<!ENTITY rfc7637 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml">
<!ENTITY rfc7752 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml">
<!ENTITY rfc7676 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7676.xml">
<!ENTITY rfc7813 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7813.xml">
<!ENTITY rfc7872 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml">
<!ENTITY I-D.ietf-detnet-problem-statement PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-detnet-problem-statement.xml">
<!ENTITY I-D.finn-detnet-architecture PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.finn-detnet-architecture.xml">
<!ENTITY I-D.ietf-isis-pcr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-pcr.xml">
<!ENTITY I-D.ietf-6man-segment-routing-header SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-segment-routing-header.xml">
<!ENTITY I-D.ietf-spring-segment-routing SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing.xml">
<!ENTITY I-D.ietf-v6ops-ipv6-ehs-in-real-world SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-ehs-in-real-world.xml">
<!ENTITY I-D.ietf-sunset4-gapanalysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sunset4-gapanalysis.xml">
<!ENTITY I-D.ietf-bier-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bier-architecture.xml">
<!ENTITY I-D.eckert-bier-te-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eckert-bier-te-arch.xml">
<!ENTITY I-D.ietf-intarea-gre-ipv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-gre-ipv6.xml">
<!ENTITY I-D.ietf-6man-rfc2460bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc2460bis.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
<!ENTITY I-D.ietf-mpls-residence-time SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-residence-time">
<!ENTITY I-D.mirsky-bier-pmmm-oam SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mirsky-bier-pmmm-oam.xml">
<!ENTITY I-D.ooamdt-rtgwg-oam-gap-analysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ooamdt-rtgwg-oam-gap-analysis.xml">
<!ENTITY I-D.kumarzheng-bier-ping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kumarzheng-bier-ping.xml">
<!ENTITY I-D.mirsky-bier-path-mtu-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mirsky-bier-path-mtu-discovery.xml">
<!ENTITY I-D.ooamdt-rtgwg-ooam-requirement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ooamdt-rtgwg-ooam-requirement.xml">
<!ENTITY I-D.ietf-bier-mpls-encapsulation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bier-mpls-encapsulation.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="info"
docName="draft-dt-detnet-dp-alt-04"
ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev="DetNet data plane alternatives">
DetNet Data Plane Protocol and Solution Alternatives</title>
<author role="editor" fullname="Jouni Korhonen" initials="J." surname="Korhonen">
<organization abbrev="Broadcom">Broadcom</organization>
<address>
<postal>
<street>3151 Zanker Road</street>
<city>San Jose</city>
<code>95134</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author fullname="János Farkas" initials="J." surname="Farkas">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Konyves Kálmán krt. 11/B</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>janos.farkas@ericsson.com</email>
</address>
</author>
<!-- author fullname="Norman Finn" initials="N." surname="Finn">
<organization abbrev="Cisco">Cisco</organization>
<address>
<email>nfinn@cisco.com</email>
</address>
</author -->
<!-- author fullname="Olivier Marce" initials="O." surname="Marce">
<organization abbrev="Nokia Bell Labs">Nokia Bell Labs</organization>
<address>
<email>Olivier.Marce@nokia.com</email>
</address>
</author -->
<author fullname="Gregory Mirsky" initials="G." surname="Mirsky">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author fullname="Pascal Thubert" initials="P." surname="Thubert">
<organization abbrev="Cisco">Cisco</organization>
<address>
<email>pthubert@cisco.com</email>
</address>
</author>
<author fullname="Yan Zhuang" initials="Y." surname="Zhuang">
<organization abbrev="Huawei">Huawei</organization>
<address>
<email>zhuangyan.zhuang@huawei.com</email>
</address>
</author>
<author initials='L.' surname="Berger" fullname='Lou Berger'>
<organization abbrev="LabN">LabN Consulting, L.L.C.</organization>
<address>
<email>lberger@labn.net</email>
</address>
</author>
<date />
<workgroup>DetNet</workgroup>
<abstract>
<t>
This document identifies existing IP and MPLS, and other encapsulations
that run over IP and/or MPLS data plane technologies that can be considered
as the base line solution for deterministic networking data
plane definition.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sec_intro">
<t>
Deterministic Networking (DetNet) <xref
target="I-D.ietf-detnet-problem-statement"/> provides a capability to carry
unicast or multicast data flows for real-time applications with extremely
low data loss rates, timely delivery and bounded packet delay variation
<xref target="I-D.finn-detnet-architecture"/>. The deterministic networking
Quality of Service (QoS) is expressed as 1) the minimum and the maximum
end-to-end latency from source (talker) to destination (listener), and 2)
probability of loss of a packet. Only the worst-case values for the
mentioned parameters are concerned.
</t>
<t>
There are three techniques to achieve the QoS required by deterministic
networks:
<list style="symbols">
<t>Congestion protection,</t>
<t>explicit routes,</t>
<t>service protection.</t>
</list>
This document identifies existing IP and Multiprotocol Label Switching (MPLS)
<xref target="RFC3031"/>, layer-2 or layer-3 encapsulations and transport
protocols that could be considered as foundations for a deterministic
networking data plane. The full scope of the deterministic networking data
plane solution is considered including, as appropriate: quality of service
(QoS); Operations, Administration and Maintenance (OAM); and time
synchronization among other criteria described in <xref target="sec_crit"/>.
</t>
<t>
This document does not select a deterministic networking data plane protocol.
It does, however, elaborate what it would require to adapt and use a specific
protocol as the deterministic networking data plane solution. This document
is only concerned with data plane considerations and, specifically, with
topics that potentially impact potential deterministic networking aware data
plane hardware. Control plane considerations are out of scope of this
document.
</t>
</section>
<section title="Terminology">
<t>
This document uses the terminology established in the DetNet architecture
<xref target="I-D.finn-detnet-architecture"/>.
</t>
</section>
<section title="DetNet Data Plane Overview" anchor="sec_dt_dp">
<t>
A "Deterministic Network" will be composed of DetNet enabled nodes i.e., End
Systems, Edge Nodes, Relay Nodes and collectively deliver DetNet
services. DetNet enabled nodes are interconnected via Transit Nodes
(i.e., routers) which support DetNet, but are not DetNet service
aware. Transit nodes see DetNet nodes as end points.
All DetNet enabled nodes are connect to
sub-networks, where a point-to-point link is also considered as a
simple sub-network. These
sub-networks will provide DetNet compatible service for support of DetNet
traffic. Examples of sub-networks include IEEE 802.1TSN and
OTN. Of course, multi-layer DetNet systems may also be possible, where
one DetNet appears as a sub-network, and provides service to, a higher layer
DetNet system. A simple DetNet concept network is shown in <xref
target="fig_detnet"/>.
</t>
<figure anchor="fig_detnet" align="center"
title="A Simple DetNet Enabled Network">
<artwork align="center"><![CDATA[
TSN Edge Transit Relay DetNet
End System Node Node Node End System
+---------+ +.........+ +---------+
| Appl. |<---:Svc Proxy:-- End to End Service ---------->| Appl. |
+---------+ +---------+ +---------+ +---------+
| TSN | |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |
+---------+ +---+ +---+ +---------+ +---------+ +---------+
|Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport|
+-------.-+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.-----+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
]]></artwork>
</figure>
<!--t> arch-07 adds service and transport layers.
The protocol stack model of the data plane described in <xref
target="I-D.finn-detnet-architecture"/> defines functional primitives for
ingress and egress packets, which are used by the three techniques (see
<xref target="sec_intro"/>) to ensure deterministic forwarding. <xref
target="I-D.finn-detnet-architecture"/> does not specify the relationship
between the DetNet Service and Transport layers used in this document to
investigate data plane options as explained in the following. The goal of
this document is to evaluate possible data plane technologies and compare
their characteristics from DetNet perspective.
</t-->
<t>
The DetNet data plane is logically divided into two layers (also see
<xref target="fig_adaptation"/>):
<list style="hanging">
<t hangText="DetNet Service Layer"><vspace blankLines="1"/>
The DetNet service layer provides adaptation of DetNet services. It is
composed of a shim layer to carry deterministic flow specific attributes,
which are needed during forwarding and for service protection. DetNet
enabled end systems originate and terminate the DetNet Service layer and
are peers at the DetNet Service layer. DetNet relay and edge nodes also
implement DetNet Service layer functions. The DetNet service layer is used
to deliver traffic end to end across a DetNet domain.
<vspace blankLines="1"/></t>
<t hangText="DetNet Transport Layer"><vspace blankLines="1"/>
The DetNet transport layer is required on all DetNet nodes. All DetNet
nodes are end points at the transport layer. Non-DetNet service aware
transit nodes deliver traffic between DetNet nodes. The DetNet transport
layer operates below and supports the DetNet Service layer and optionally
provides congestion protection for DetNet flows.
</t>
</list>
Distinguishing the function of these two DetNet data plane layers helps to
explore and evaluate various combinations of the data plane solutions
available. This separation of DetNet layers, while helpful, should not be
considered as formal requirement. For example, some technologies may violate
these strict layers and still be able to deliver a DetNet service.
</t>
<figure anchor="fig_adaptation" align="center"
title="DetNet adaptation to data plane">
<artwork align="center"><![CDATA[
.
.
+-----------+
| Service | PW, RTP/(UDP), GRE
+-----------+
| Transport | (UDP)/IPv6, (UDP)/IPv4, MPLS LSPs, BIER
+-----------+
.
.
]]></artwork>
</figure>
<t>
The two logical layers defined here aim to help to identify which data
plane technology can be used for what purposes in the DetNet context. This
layering is similar to the data plane concept of MPLS, where some part of
the label stack is "Service" specific (e.g., PW labels, VPN labels) and an
other part is "Transport" specific (e.g, LSP label, TE label(s)).
</t>
<t>
In some networking scenarios, the end system initially provides a DetNet
flow encapsulation, which contains all information needed by DetNet nodes
(e.g., Real-time Transport Protocol (RTP) <xref target="RFC3550"/> based
DetNet flow transported over a native UDP/IP network or PseudoWire). In
other scenarios, the encapsulation formats might differ significantly. As an
example, a CPRI "application's" I/Q data mapped directly to Ethernet frames
may have to be transported over an MPLS-based packet switched network (PSN).
</t>
<t>
There are many valid options to create a data plane solution for DetNet
traffic by selecting a technology approach for the DetNet Service layer and
also selecting a technology approach for the DetNet Transport layer. There are
a high number of valid combinations. Therefore, not the combinations but the
different technologies are evaluated along the criteria collected in <xref
target="sec_crit"/>. Different criteria apply for the DetNet Service layer and
the DetNet Transport layer, however, some of the criteria are valid for both
layers.
</t>
<t>
One of the most fundamental differences between different potential
data plane options is the basic addressing and headers used by DetNet
end systems. For example, is the basic service a Layer 2 (e.g., Ethernet) or
Layer 3 (i.e., IP) service. This decision impacts how DetNet end systems
are addressed, and the basic forwarding logic for the DetNet Service layer.
</t>
<section title="Example DetNet Service Scenarios" anchor="sec_dt_dp_svc">
<t>
In an attempt to illustrate a DetNet date plane, this document uses the
Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) <xref
target="RFC5254"/> reference model shown in <xref target="fig_pw_detnet"/> as
the foundation for different DetNet data plane deployment options and how
layering could work. Other reference models are possible but not covered in
this document. Note that other technologies can be also used to implement
DetNet, Multi-Segment PW is only used here to illustrate functions, features
and layering from the perspective of the architecture.
</t>
<figure anchor="fig_pw_detnet" align="center"
title="Pseudo Wire switching reference model">
<artwork><![CDATA[
Native |<--------Multi-Segment Pseudowire----->| Native
Service | PSN PSN | Service
(AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
| V V 1 V V 2 V V |
| +-----+ +-----+ +---- + |
+---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+
| |---|-----|........PW1...........|...PW3..........|---|----| |
|CE1| | | | | | | | | |CE2|
| |---------|........PW2...........|...PW4..........|--------| |
+---+ | | |==========| |==========| | | +---+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| PW switching point |
| |
|<------------------- Emulated Service ------------------->|
]]></artwork>
</figure>
<t>
<xref target="fig_8021_detnet"/> illustrates how DetNet can provide services
for IEEE 802.1TSN end systems over a DetNet enabled network. The edge nodes
insert and remove required DetNet data plane encapsulation. The 'X' in
the edge and relay nodes represents a potential DetNet flow packet
replication and elimination point. This conceptually parallels L2VPN
services, and could leverage existing related solutions as discussed
below.
</t>
<figure align="center" anchor="fig_8021_detnet"
title="IEEE 802.1TSN over DetNet">
<artwork><![CDATA[
TSN |<----- End to End DetNet Service ----->| TSN
Service | Transit Transit | Service
TSN (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) TSN
End | V V 1 V V 2 V V | End
System | +-----+ +-----+ +---- + | System
+---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+
| |---|-----|.X_..DetNet Flow1..X..|...DF3........X.|---|----| |
|CE1| | | \ | | | | / | | |CE2|
| | |...X_...DF2........X..|...DF4......X_..| | |
+---+ | |==========| |==========| | +---+
^ +-----+ +-----+ +-----+ ^
| Edge Node Relay Node Edge Node |
| |
|<--------------- Emulated TSN Service ------------------->|
]]></artwork>
</figure>
<t>
<xref target="fig_native_detnet"/> illustrates how end to end native DetNet
service can be provided. In this case, the end systems are able to send and
receive native DetNet flows. For example, as PseudoWire (PW) encapsulated
IP. Like earlier the 'X' in the end systems, edge and relay nodes represents
potential DetNet flow packet replication and elimination points. Here the
relay nodes may change the underlying transport, for example replacing IP
with MPLS or tunneling IP over MPLS (e.g., via L3VPNs), or simply
interconnect network domains.
</t>
<figure align="center" anchor="fig_native_detnet"
title="Native DetNet">
<artwork><![CDATA[
DetNet DetNet
Service Transit Transit Service
DetNet | |<-Tunnel->| |<-Tunnel->| | DetNet
End | V 1 V V 2 V | End
System | +-----+ +-----+ +-----+ | System
+---+ | |S-PE1|==========|S-PE2|==========|S-PE3| | +---+
| X....DFa.....X_.......DF1.......X_....DF3........X.....DFa...X |
|CE1|=========| \ | | / | | / |========|CE2|
| | | | \......DF2.....X_......DF4....../ | | | |
+---+ | |==========| |==========| | +---+
^ +-----+ +-----+ +-----+ ^
| Relay Node Relay Node Relay Node |
| |
|<------------- End to End DetNet Service ---------------->|
]]></artwork>
</figure>
<t>
<xref target="fig_iw_detnet"/> illustrates how a IEEE 802.1TSN end system
could communicate with a native DetNet end system through an edge node which
provides a TSN to DetNet inter-working capability. The edge node would add
and remove required DetNet data plane encapsulation as well as provide any
needed address mapping. As in previous figures, the 'X' in the end systems,
edge and relay nodes represents potential DetNet flow packet duplication and
elimination points.
</t>
<figure align="center" anchor="fig_iw_detnet"
title="IEEE 802.1TSN to native DetNet">
<artwork><![CDATA[
TSN |<----- End to End DetNet Service -------------->|
Service | Transit Transit |
TSN (AC) | |<-Tunnel->| |<-Tunnel->| DetNet | DetNet
End | V V 1 V V 2 V Service | End
System | +-----+ +-----+ +-----+ | V System
+---+ | |T-PE1|==========|S-PE1|==========|S-PE2| | +---+
| |---|-----|.X_.......DF1......X..|...DF3........X.|...DFa...X |
|CE1| | | \ | | | | / |========|CE2|
| | | \.....DF2.......X..|...DF4....../ | | | |
+---+ | |==========| |==========| | +---+
^ +-----+ +-----+ +-----+ ^
| Edge Node Relay Node Relay Node |
| |
|<----------------- End to End Service ------------------->|
]]></artwork>
</figure>
</section>
</section>
<section title="Criteria for data plane solution alternatives" anchor="sec_crit">
<t>
This section provides criteria to help to evaluate potential options. Each
deterministic networking data plane solution alternative is described and
evaluated using the criteria described in this section. The used criteria
enumerated in this section are selected so that they highlight the existence
or lack of features that are expected or seen important to a solution
alternative for the data plane solution.
</t>
<t>
The criteria for the DetNet Service layer:
<list style="hanging">
<t hangText="#1">
Encapsulation and overhead
</t>
<t hangText="#2">
Flow identification (Service ID part of the DetNet flows)
</t>
<t hangText="#3">
Packet sequencing and duplicate elimination
</t>
<t hangText="#5">
Flow duplication and merging
</t>
<t hangText="#6">
Operations, Administration and Maintenance (capabilities)
</t>
<t hangText="#8">
Class and quality of service capabilities (DetNet Service specific)
</t>
<t hangText="#10">Technical maturity</t>
</list>
</t>
<t>
The criteria for the DetNet Transport layer:
<list style="hanging">
<t hangText="#1">Encapsulation and overhead</t>
<t hangText="#2">Flow identification</t>
<t hangText="#4">Explicit routes (network path)</t>
<t hangText="#5">
Flow duplication and merging (sometimes, flow duplication and merging
is also doable at the transport layer, not just at the service layer)
</t>
<t hangText="#6">Operations, Administration and Maintenance (capabilities,
performance management, packet traceability)</t>
<t hangText="#8">
Class and quality of service capabilities (DetNet Transport specific)
</t>
<t hangText="#9">Packet traceability (can be part of OAM)</t>
<t hangText="#10">Technical maturity</t>
</list>
</t>
<t>[Editor's Note: numbering is off because #7 is removed.]</t>
<t>[Editor's Note: #9 should(?) be integrated into #6.]</t>
<t>
Most of the criteria is relevant for both the DetNet Service and DetNet
Transport layers. However, different aspects of the same criteria may relevant
for different layers, for example, as it is the case with criteria #5 Packet
replication and elimination.
</t>
<section title="#1 Encapsulation and overhead" anchor="sec_crit_encap">
<t>
Encapsulation and overhead is related to how the DetNet data plane
carries DetNet flow. In several cases a DetNet flow has to be
encapsulated inside other protocols, for example, when transporting a
layer-2 Ethernet frame over an IP transport network. In some cases a
tunneling like encapsulation can be avoided by underlying transport
protocol translation, for example, translating layer-2 Ethernet frame
including addressing and flow identification into native IP traffic. Last
it is possible that sources and destinations handle deterministic flows
natively in layer-3. This criteria concerns what is the encapsulation
method the solution alternative support: tunneling like encapsulation,
protocol translation or native layer-3 transport. In addition to the
encapsulation mechanism this criteria is also concerned with the processing
and specifically the encapsulation header overhead.
</t>
</section>
<section title="#2 Flow identification" anchor="sec_crit_streamid">
<t>
The solution alternative has to provide means to identify specific
deterministic flows. The flow identification can, for example,
be an explicit field in the data plane encapsulation header or implicitly
encoded into the addressing scheme of the used data plane protocol or their
combination. This criteria concerns the availability and details of
deterministic flow identification the data plane protocol alternative has.
</t>
</section>
<section title="#3 Packet sequencing and duplicate elimination" anchor="sec_crit_seq">
<t>
The solution alternative has to provide means for end systems to number
packets sequentially and transport that sequencing information along with
the sent packets. In addition to possible reordering of packets other
important uses for sequencing are detecting duplicates and lost packets.
</t>
<t>
In a case of intentional packet duplication a combination of flow
identification and packet sequencing allows for detecting and eliminating
duplicates at the destination (see <xref target="sec_crit_repdup"/> for
more details).
</t>
</section>
<section title="#4 Explicit routes" anchor="sec_crit_explicit">
<t>
The solution alternative has to provide a mechanism(s) for establishing
explicit routes that all packets belonging to a deterministic flow will
follow. The explicit route can be seen as a form of source routing or a
pre-reserved path e.g., using some network management procedure. It should
be noted that the explicit route does not need to be detailed to a level
where every possible intermediate node along the path is part of the named
explicit route. RSVP-TE <xref target="RFC3209"/> supports explicit routes,
and typically provides pinned data paths for established LSPs. At Layer-2,
the IEEE 802.1Qca <xref target="IEEE802.1Qca"/> specification defines how
to do explicit path control in a bridged network and its IETF counter part
is defined in <xref target="RFC7813"/>. This criteria concerns the
available mechanisms for explicit routes for the data plane protocol
alternative.
</t>
</section>
<section title="#5 Flow duplication and merging" anchor="sec_crit_repdup">
<t>
Flow duplication and flow merging are methods being considered to
provide DetNet service protection. The objective for supporting flow
duplication and flow merging is to enable hitless (or lossless) 1+1
protection. Other methods, if so identified, are also permissible.
</t>
<t>
The solution alternative has to provide means for end systems, relay and
edge nodes to be able to duplicate packets into duplicate flows, and later
merge the flows into one for duplicate elimination. The duplication and
merging may take place at multiple points in the network in order to ensure
that one (or more) equipment failure event(s) still leave at least one path
intact for a deterministic networking flow. The goal is again to enable
hitless 1+1 protection in a way that no packet gets lost or there is no
ramp up time when either one of the paths fails for one reason or another.
</t>
<t>
Another concern regarding packet duplication is how to enforce duplicated
packets to take different route or path while the final destination still
remains the same. With strict source routing, all the intermediate hops
are listed and paths can be guaranteed to be non-overlapping. Loose source
routing only signals some of the intermediate hops and it takes additional
knowledge to ensure that there is no single point of failure.
</t>
<t>
The IEEE 802.1CB (seamless redundancy) <xref target="IEEE8021CB"/> is an
example of Ethernet-based solution that defines packet sequence numbering,
flow duplication, flow merging, duplicate packet identification and
elimination. The deterministic networking data plane solution alternative
at layer-3 has to provide equivalent functionality. This criteria concerns
the available mechanisms for packet replication and duplicate deletion the
data plane protocol alternative has.
</t>
</section>
<section title="#6 Operations, Administration and Maintenance" anchor="sec_crit_oam" >
<t>
The solution alternative should demonstrate availability of appropriate
standardized OAM tools that can be extended for deterministic networking
purposes with a reasonable effort, when required. The OAM tools do not
necessarily need to be specific to the data plane protocol as it could be
the case, for example, with MPLS-based data planes. But any OAM-related
implications or requirements on data plane hardware must be considered.
</t>
<t>
The OAM includes but is not limited to tools listed in the requirements for
overlay networks <xref target="I-D.ooamdt-rtgwg-ooam-requirement"/>.
Specifically, the performance management requirements are of interest at
both service and transport layers.
</t>
</section>
<section title="#8 Class and quality of service capabilities"
anchor="sec_crit_qos">
<t>
Class and quality of service, i.e., CoS and QoS, are terms that are often
used interchangeably and confused. In the context of DetNet, CoS is used
to refer to mechanisms that provide traffic forwarding treatment based on
aggregate group basis and QoS is used to refer to mechanisms that provide
traffic forwarding treatment based on a specific DetNet flow basis.
Examples of CoS mechanisms include DiffServ which is enabled by IP header
differentiated services code point (DSCP) field <xref target="RFC2474"/>
and MPLS label traffic class field <xref target="RFC5462"/>, and at
Layer-2, by IEEE 802.1p priority code point (PCP).
</t>
<t>
Quality of Service (QoS) mechanisms for flow specific traffic treatment
typically includes a guarantee/agreement for the service, and allocation of
resources to support the service. Example QoS mechanisms include discrete
resource allocation, admission control, flow identification and isolation,
and sometimes path control, traffic protection, shaping, policing and
remarking. Example protocols that support QoS control include <xref
target="RFC2205">Resource ReSerVation Protocol (RSVP)</xref> (RSVP) and
RSVP-TE <xref target="RFC3209"/> and <xref target="RFC3473"/>.
</t>
<t>
A critical DetNet service enabled by QoS (and perhaps CoS) is delivering
zero congestion loss. There are different mechanisms that maybe used
separately or in combination to deliver a zero congestion loss service.
The key aspect of this objective is that DetNet packets are not discarded
due to congestion at any point in a DetNet aware network.
</t>
<t>
In the context of the data plane solution there should be means for flow
identification, which then can be used to map a flow against specific
resources and treatment in a node enforcing the QoS. For DetNet, certain
aspects of CoS and QoS may be provided by the underlying sub-net
technology, e.g., actual queuing or IEEE 802.3x priority flow control
(PFC).
</t>
</section>
<section title="#9 Packet traceability" anchor="sec_crit_trace">
<t>
For the network management and specifically for tracing implementation or
network configuration errors any means to find out whether a packet is a
replica, which node performed replication, and which path was intended for
the replica, can be very useful. This criteria concerns the availability
of solutions for tracing packets in the context of data plane protocol
alternative. Packet traceability can also be part of OAM.
</t>
</section>
<section title="#10 Technical maturity" anchor="sec_crit_matu">
<t>
The technical maturity of the data plane solution alternative is crucial,
since it basically defines the effort, time line and risks involved for
the use of the solution in deployments. For example, the maturity level
can be categorized as available immediately, available with small
extensions, available with re-purposing/redefining portions of the protocol
or its header fields. Yet another important measure for maturity is the
deployment experience. This criteria concerns the maturity of the data
plane protocol alternative as the solution alternative. This
criteria is particularly important given, as previously noted, that
the DetNet data plane solution is expected to impact, i.e., be
supported in, hardware.
</t>
</section>
</section>
<!-- ================================================================= -->
<section title="Data plane solution alternatives">
<t>
The following sections describe and rate deterministic data plane solution
alternatives. In "Analysis and Discussion" section each alternative is
evaluated against the criteria given in <xref target="sec_crit"/> and rated
using the following: (M)eets the criteria, (W)ork needed, and (N)ot suitable
or too much work envisioned.
</t>
<section title="DetNet Transport layer technologies" anchor="sec_net">
<section title="Native IPv6 transport" anchor="sec_alt_ipv6">
<section title="Solution description">
<t>
This section investigates the application of native IPv6 <xref
target="RFC2460"/> as the data plane for deterministic networking along
the criteria collected in <xref target="sec_crit"/>.
</t>
<t>
The application of higher OSI layer headers, i.e., headers deeper in the
packet, can be considered. Two aspects have to be taken into account for
such solutions. (i) Those header fields can be encrypted. (ii) Those
header fields are deeper in the packet, therefore, routers have to apply
deep packet inspection. See further details in <xref
target="sec_alt_higher"/>.
</t>
</section>
<section title="Analysis and Discussion" anchor="sec_alt_ipv6_ana">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
IPv6 can encapsulate DetNet Service layer headers (and associated DetNet
flow payload) like any other upper-layer header indicated by the Next
Header. The fixed header of an IPv6 packet is 40 bytes <xref
target="RFC2460"/>. This overhead is bigger if any Extension Header is
used, and a generic behaviour for host and forwarding nodes is specified
in <xref target="RFC7045"/>. However, the exact overhead (<xref
target="sec_crit_encap"/>) depends on what solution is actually used to
provide DetNet features, e.g., explicit routing or DetNet service
protection if any of these is applied.
<vspace blankLines="1"/>
IPv6 has two types of Extension Headers that are processed by intermediate
routers between the source and the final destination and may be of
interest for the data plane signaling, the Routing Header that is used to
direct the traffic via intermediate routers in a strict or loose source
routing way, and the Hop-by-Hop Options Header that carries optional
information that must be examined by every node along a packet's delivery
path. The Hop-by-Hop Options Header, when present, must immediately follow
the IPv6 Header and it is not possible to limit its processing to the end
points of Source Routed segments.
<vspace blankLines="1"/>
IPv6 also provides a Destination Options Header that is used to carry
optional information to be examined only by a packet's destination
node(s). The encoding of the options used in the Hop-by-Hop and in the
Destination Options Header indicates the expected behavior when a
processing IPv6 node does not recognize the Option Type, e.g. skip or
drop; it should be noted that due to performance restrictions nodes may
ignore the Hop-by-Hop Option Header, drop packets containing a Hop-by-Hop
Option Header, or assign packets containing a Hop-by-Hop Option Header to
a slow processing path
<xref target="I-D.ietf-6man-rfc2460bis"/> (e.g. punt packets from hardware
to software forwarding which is highly detrimental to the performance).
<vspace blankLines="1"/>
The creation of new Extension Headers that would need to be processed by
intermediate nodes is strongly discouraged. In particular, new Extension
Header(s) having hop-by-hop behavior must not be created or specified.
New options for the existing Hop-by-Hop Header should not be created or
specified unless no alternative solution is feasible
<xref target="RFC6564"/>.
<vspace blankLines="1"/>
</t>
<t hangText="#2 Flow identification (W)">
<vspace blankLines="1"/>
The 20-bit flow label field of the fixed IPv6 header is suitable to
distinguish different deterministic flows. But guidance on the use of the
flow label provided by <xref target="RFC6437"/> places restrictions on how
the flow label can be used. In particular, labels should be chosen from an
approximation to a discrete uniform distribution. Additionally, existing
implementations generally do not open APIs to control the flow label from
the upper layers.
<vspace blankLines="1"/>
Alternatively, the Flow identification could
be transported in a new option in the Hop-by-Hop Options Header.
<vspace blankLines="1"/></t>
<t hangText="#4 Explicit routes (W)">
<vspace blankLines="1"/>
One possibility is for a Software-Defined Networking (SDN)
<xref target="RFC7426"/> based approach to be applied to compute, establish
and manage the explicit routes, leveraging Traffic Engineering (TE)
extensions to routing protocols <xref target="RFC5305"/>
<xref target="RFC7752"/> and evolving to the
Path Computation Element (PCE) Architecture <xref target="RFC5440"/>,
though a number of issues remain to be solved <xref target="RFC7399"/>.
<vspace blankLines="1"/>
Segment Routing (SR) <xref target="I-D.ietf-spring-segment-routing"/> is a
new initiative to equip IPv6 with explicit routing capabilities.
The idea for the DetNet data plane would be to apply SR to IPv6 with the
addition of a new type of routing extension header <xref
target="I-D.ietf-6man-segment-routing-header"/> to explicitly signal the
path in the data plane between the source and the destination, and/or
between replication points and elimination points if this functionality
is used.
<vspace blankLines="1"/>
</t>
<t hangText="#5 Flow duplication and merging (W)">
<vspace blankLines="1"/>
The functionality of replicating a packet exists in IPv6 but is limited
to multicast flows. In order to enforce replicated packets to take
different routes and eventually again merge flow (bring them to a specific
merging point), IP-in-IP encapsulation and Segment Routing could be
leveraged to signal a segment in a packet. A replication point would
insert a different routing header in each copy it makes, the routing
header providing explicitly the hops to the merging point for that
particular replica of the packet, in a strict or in a loose source
routing fashion. A flow merging point would pop the routing headers from
the various copies it gets and do the rest of the required processing
for merging the two flows into one flow.
<vspace blankLines="1"/>
</t>
<t hangText="#6 Operations, Administration and Maintenance (M/W)">
<vspace blankLines="1"/>
IPv6 enjoys the existing toolbox for generic IP network management.
However, IPv6 specific management features are still not at the level
comparable to that of IPv4. Particular areas of concerns are those that
are IPv6 specific, for example, related to neighbor discovery protocol
(ND), stateless address autoconfiguration (SLAAC), subscriber
identification, and security. While the standards are already mostly in
place the implementations in deployed equipment can be lacking or
inadequate for commercial deployments. This is larger issue with older
existing equipment.
<vspace blankLines="1"/></t>
<t hangText="#8 Class and quality of service capabilities (W)">
<vspace blankLines="1"/>
IPv6 provides support for CoS and QoS. CoS is provided by DiffServ which
is enabled by IP header differentiated services code point (DSCP) and QoS
is defined as part of <xref target="RFC2205">RSVP</xref>. DiffServ
support is widely available, while RSVP for IP packets is generally not
supported.
<vspace blankLines="1"/></t>
<t hangText="#9 Packet traceability (W)">
<vspace blankLines="1"/>
The traceability of replicated packets involves the capability to resolve
which replication point issued a particular copy of a packet, which
segment was intended for that replica, and which particular packet of
which particular flow this is. Sequence also depends on the sequencing
mechanism. As an example, the replication point may be indicated as the
source of the packet if IP-in-IP encapsulation is used to forward along
segments. Another alternate to IP-in-IP tunneling along segments would be
to protect the original source address in a destination option similar to
the Home Address option <xref target="RFC6275"/> and then use the address
of the replication point as source in the IP header.
<vspace blankLines="1"/>
The traceability also involves the capability to determine if a particular
segment is operational. While IPv6 as such has no support for reversing a
path, it appears source route extensions such as the one defined for
segment routing could be used for tracing purposes. Though it is not a
usual practice, IPv6 <xref target="RFC2460"/> expects that a Source Route
path may be reversed, and the standard insists that a node must not
include the reverse of a Routing Header in the response unless the
received Routing Header was authenticated.
<vspace blankLines="1"/></t>
<t hangText="#10 Technical maturity (M/W)">
<vspace blankLines="1"/>
IPv6 has been around about 20 years. However, large scale global and
commercial IPv6 deployments are rather new dating only few years back to
around 2012. While IPv6 has proven itself for best effort traffic,
DiffServ usage is less common and QoS capabilities are not
currently present. Additional, there are number of small issues
to work on as they show up once operations experience grows.
<vspace blankLines="1"/>
The <eref target="http://6lab.cisco.com/stats/">Cisco 6Lab site</eref>
provides information on IPv6 deployment per country, indicating figures
for prefixes, transit AS, content and users. Per this site, many
countries, including Canada, Brazil, the USA, Germany, France, Japan,
Portugal, Sweden, Finland, Norway, Greece, and Ecuador, achieve a
deployment ratio above 30 percent, and the overall adoption reported
by <eref target="https://www.google.com/intl/en/ipv6/statistics.html">
Google Statistics</eref> is now above 10 percent.
<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Summary">
<t>
IPv6 supports a significant portion of the identified DetNet data plane
criteria today. There are aspects of the DetNet data plane that are not
fully supported, notably QoS, but these can be incrementally added or
supplemented by the underlying sub-network layer. IPv6 may be a choice as
the DetNet Transport layer in networks where other technologies such as
MPLS are not deployed.
</t>
</section>
</section>
<section title="Native IPv4 transport" anchor="sec_alt_ipv4">
<section title="Solution description">
<t>
IPv4 <xref target="RFC0791"/> is in principle the same as IPv6, except that
it has a smaller address space. However, IPv6 was designed around the fact
that extension headers are an integral part of the protocol and operation
from the beginning, although the practice may some times prove differently
<xref target="RFC7872"/>. IPv4 does support header options, but these have
historically not been supported in hardware-based forwarding so are
generally blocked or handled at a much slower rate. In either case, the
use of IP header options is generally avoided. In the context of
deterministic networking data plane solutions the major difference between
IPv4 and IPv6 seems to be the practical support for header extensibility.
Anything below and above the IP header independent of the version is
practically the same.
</t>
</section>
<section title="Analysis and Discussion" anchor="sec_alt_ipv4_ana">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/> The fixed header of an IPv4 packet is 20 bytes
<xref target="RFC0791"/>. IP options add overhead, but are not
generally used and are not considered as part of this document.
<vspace blankLines="1"/></t>
<t hangText="#2 Flow identification (W)">
<vspace blankLines="1"/>
The IPv4 header has a 16-bit identification field that was originally
intended for assisting fragmentation and reassembly of IPv4 packets as
described in <xref target="RFC0791"/>. The identification field has also
been proposed to be used for actually identifying flows between two IP
addresses and a given protocol for detecting and removing duplicate
packets <xref target="RFC1122"/>. However, recent update <xref
target="RFC6864"/> to both <xref target="RFC0791"/> and <xref
target="RFC1122"/> restricts the use of IPv4 identification field only to
fragmentation purposes.
<vspace blankLines="1"/>
The IPv4 also has a stream identifier option <xref target="RFC0791"/>,
which contains a 16-bit SATNET stream identifier. However, the option has
been deprecated <xref target="RFC6814"/>. The conclusion is that stream
identification does not work nicely with IPv4 header alone and a
traditional 5-tuple identification might not also be enough in a case of a
flow duplication or encrypted flows. For a working solution, upper layer
protocol headers such as RTP or PWs may be required for unambiguous flow
identification. There is also emerging work within the IETF that may
provide new flow identification alternatives.
<vspace blankLines="1"/></t>
<t hangText="#4 Explicit routes (W)">
<vspace blankLines="1"/>
IPv4 has two source routing option specified: the loose source and record
route option (LSRR), and the strict source and record route option (SSRR)
<xref target="RFC0791"/>. The support of these options in the Internet is
questionable but within a closed network the support may be assumed. But
as both these options use IP header options, which are generally not
supported in hardware, use of these options are questionable. Of course,
the same options of SDN and SR approaches discussed above for IPv6 may be
equally applicable to IPv4.
<vspace blankLines="1"/></t>
<t hangText="#5 Flow duplication and merging (W/N)">
<vspace blankLines="1"/>
The functionality of replicating a packet exists in IPv4 but is limited to
multicast flows. In general the issue regarding the IPv6 packet
replication also applies to IPv4. Duplicate packet detection for IPv4 is
studied in <xref target="RFC6621"/> to a great detail in the context of
simplified multicast forwarding. In general there is no good way to detect
duplicated packets for IPv4 without additional upper layer protocol
support.
<vspace blankLines="1"/></t>
<t hangText="#6 Operations, Administration and Maintenance (M)">
<vspace blankLines="1"/>
IPv4 enjoys the extensive and "complete" existing toolbox for generic IP
network management.
<vspace blankLines="1"/></t>
<t hangText="#8 Class and quality of service capabilities (M/W)">
<vspace blankLines="1"/>
IPv4 provides support for CoS and QoS. CoS is provided by DiffServ which
is enabled by IP header differentiated services code point (DSCP) and QoS
is defined as part of <xref target="RFC2205">RSVP</xref>. DiffServ
support is widely available, while RSVP for IP packets is generally not
supported.
<vspace blankLines="1"/></t>
<t hangText="#9 Packet traceability (W)">
<vspace blankLines="1"/>
The IPv4 has similar needs and requirements for traceability as IPv6 (see
<xref target="sec_alt_ipv6_ana"/>). The IPv4 has a traceroute option
<xref target="RFC6814"/> that could be used to record the route the packet
took. However, the option has been deprecated <xref target="RFC6814"/>.
<vspace blankLines="1"/></t>
<t hangText="#10 Technical maturity (M/W)">
<vspace blankLines="1"/>
IPv4 can be considered mature technology with over 30 years of
implementation, deployment and operations experience. As with IPv6,
today's commercial implementations and deployments of IPv4 generally lack
any support for QoS.
<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Summary">
<t>
The IPv4 has specifications to support most of the identified DetNet data
plane criteria today. However, several of those have already been
deprecated or their wide support is not guaranteed. The DetNet data plane
criteria that are not fully supported could be incrementally added or
supplemented by the underlying sub-network layer. Unfortunately, the IPv4
has had limited success getting its extensions deployed at large. However,
introducing new extensions might have a better success in closed networks
(like DetNet) than in Internet. Due to the popularity of the IPv4, it
should be considered as a potential choice for the DetNet Transport layer.
</t>
</section>
</section>
<section title="Multiprotocol Label Switching (MPLS)" anchor="sec_alt_mpls">
<!--
<section title="MPLS used for DetNet">
-->
<t>
Multiprotocol Label Switching Architecture (MPLS) <xref target="RFC3031"/>
and its variants, MPLS with Traffic Engineering (MPLS-TE) <xref
target="RFC3209"/> and <xref target="RFC3473"/>, and MPLS Transport
Profile (MPLS-TP) <xref target="RFC5921"/> is a widely deployed technology
that switches traffic based on MPLS label stacks <xref target="RFC3032"/>
and <xref target="RFC5960"/>. MPLS is the foundation for Pseudowire-based
services <xref target="sec_alt_pwe"/> and emerging technologies such as
Bit-Indexed Explicit Replication (BIER) <xref target="sec_alt_bier"/> and
<eref target="https://datatracker.ietf.org/wg/spring/charter/"> Source
Packet Routing</eref>.
</t>
<t>
MPLS supports the equivalent of both the DetNet Service and DetNet
Transport layers, and provides a very rich set of mechanisms that can be
reused directly, and perhaps augmented in certain cases, to deliver DetNet
services. At the DetNet Transport layer, MPLS provides forwarding,
protection and OAM services. At the DetNet Service Layer it provides
client service adaption, directly, via Pseudowires <xref
target="sec_alt_pwe"/> and via other label-like mechanisms such as EPVN
<xref target="sec_alt_evpn"/>. A representation of these options are
shown in <xref target="fig_mpls_clients"/>.
</t>
<figure anchor="fig_mpls_clients" align="center"
title="MPLS-based Services">
<artwork align="center"><![CDATA[
PW-Based EVPN Labeled IP
Services Services Transport
|------------| |-----------------------------| |------------|
Emulated EVPN over LSP EVPN w/ ESI ID IP
Service
+------------+
| Payload |
+------------+ +------------+ +------------+ (Service)
| PW Payload | | Payload | |ESI Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|PW Lbl(S=1) | |VPN Lbl(S=1)| |VPN Lbl(S=0)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
. . . .
. . . . (Transport)
. . . .
~~~~~~~~~~~ denotes DetNet Service <-> DetNet Transport layer boundary
]]></artwork>
</figure>
<t>
MPLS can be controlled in a number of ways including via a control
plane, via the management plane, or via centralized controller
(SDN) based approaches. MPLS also provides standard control plane
reference points. Additional information on MPLS architecture and
control can be found in <xref target="RFC5921"/>. A summary of
MPLS control plane related functions can be found in
<xref target="RFC6373"/>. The remainder of this section will focus
on the MPLS transport data plane, additional information on the
MPLS service data plane can be found below in
<xref target="sec_alt_mpls_svc"/>.
</t>
<!--
</section>
-->
<section title="Solution description">
<t>
The following draws heavily from <xref target="RFC5960"/>.
</t>
<t>
Encapsulation and forwarding of packets traversing MPLS LSPs
follows standard MPLS packet encapsulation and forwarding as
defined in <xref target="RFC3031"/>, <xref target="RFC3032"/>,
<xref target="RFC5331"/>, and <xref target="RFC5332"/>.
</t>
<t>
Data plane Quality of Service capabilities are included in the
MPLS in the form of Traffic Engineered (TE) LSPs
<xref target="RFC3209"/> and the MPLS Differentiated Services
(DiffServ) architecture <xref target="RFC3270"/>. Both E-LSP and
L-LSP MPLS DiffServ modes are defined. The Traffic Class field
(formerly the EXP field) of an MPLS label follows the definition
of <xref target="RFC5462"/> and <xref target="RFC3270"/>.
</t>
<t>
Except for transient packet reordering that may occur, for example,
during fault conditions, packets are delivered in order on L-LSPs,
and on E-LSPs within a specific ordered aggregate.
</t>
<t>
The Uniform, Pipe, and Short Pipe DiffServ tunneling and TTL
processing models are described in <xref target="RFC3270"/> and
<xref target="RFC3443"/> and may be used for MPLS LSPs.
</t>
<t>
Equal-Cost Multi-Path (ECMP) load-balancing is possible with MPLS
LSPs and can be avoided using a number of techniques. The same
holds for Penultimate Hop Popping (PHP).
</t>
<t>
MPLS includes the following LSP types:
</t>
<t><list style="symbols">
<t>Point-to-point unidirectional</t>
<t>Point-to-point associated bidirectional</t>
<t>Point-to-point co-routed bidirectional</t>
<t>Point-to-multipoint unidirectional</t>
</list></t>
<t>
Point-to-point unidirectional LSPs are supported by the basic MPLS
architecture <xref target="RFC3031"/>.
</t>
<t>
A point-to-point associated bidirectional LSP between LSRs A and B
consists of two unidirectional point-to-point LSPs, one from A to
B and the other from B to A, which are regarded as a pair
providing a single logical bidirectional transport path.
</t>
<t>
A point-to-point co-routed bidirectional LSP is a point-to-point
associated bidirectional LSP with the additional constraint that
its two unidirectional component LSPs in each direction follow the
same path (in terms of both nodes and links). An important
property of co-routed bidirectional LSPs is that their
unidirectional component LSPs share fate.
</t>
<t>
A point-to-multipoint unidirectional LSP functions in the same
manner in the data plane, with respect to basic label processing
and packet-switching operations, as a point-to-point
unidirectional LSP, with one difference: an LSR may have more than
one (egress interface, outgoing label) pair associated with the
LSP, and any packet it transmits on the LSP is transmitted out all
associated egress interfaces. Point-to-multipoint LSPs are
described in <xref target="RFC4875"/> and
<xref target="RFC5332"/>. TTL processing and exception handling
for point-to- multipoint LSPs is the same as for point-to-point
LSPs.
</t>
<t>
Additional data plane capabilities include Linear Protection,
<xref target="RFC6378"/> and <xref target="RFC7271"/>. And the in
progress work on MPLS support for time synchronization
<xref target="I-D.ietf-mpls-residence-time"/>.
</t>
</section>
<section title="Analysis and Discussion">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
There are two perspectives to consider when looking at encapsulation.
The first is encapsulation to support services. These considerations are
part of the DetNet service layer and are covered below, see Sections
<xref format="counter" target="sec_alt_pwe"/> and <xref format="counter"
target="sec_alt_evpn"/>.
<vspace blankLines="1"/>
The second perspective relates to encapsulation, if any, which is needed to
transport packets across network. In this case, the MPLS label stack,
<xref target="RFC3032"/> is used to identify flows across a network.
MPLS labels are compact and highly flexible. They can be stacked to
support client adaptation, protection, network layering, source routing,
etc.
<vspace blankLines="1"/>
The number of DetNet Transport layer specific labels is flexible and
support a wide range of applicable functions and MPLS domain
characteristics (e.g., TE-tunnels, Hierarchical-LSPs, etc.).
<vspace blankLines="1"/> </t>
<t hangText="#2 Flow identification (M)">
<vspace blankLines="1"/>
MPLS label stacks provide highly flexible ways to identify flows.
Basically, they enable the complete separation of traffic classification
from traffic treatment and thereby enable arbitrary combinations of both.
<vspace blankLines="1"/> For the DetNet flow identification the MPLS
label stack can be used to support n-layers of DetNet flow
identification. For example, using dedicated LSP per DetNet flow would
simplify flow identification for intermediate transport nodes, and
additional hierarchical LSPs could be used to facilitate scaling.
<vspace blankLines="1"/> </t>
<t hangText="#4 Explicit routes (M)">
<vspace blankLines="1"/>
MPLS supports explicit routes based on how LSPs are established, e.g.,
via TE explicit routes <xref target="RFC3209"/>. Additional, but not
required, capabilities are being defined as part of Segment Routing (SR)
<xref target="I-D.ietf-spring-segment-routing"/>.
<vspace blankLines="1"/> </t>
<t hangText="#5 Flow duplication and merging (M/W)">
<vspace blankLines="1"/>
MPLS as DetNet Transport layer supports the replication via
point-to-multipoint LSPs. At the MPLS LSP level, there are mechanisms
defined to provide 1+1 protection, which could help in realizing the flow
merging function. The current definitions <xref target="RFC6378"/> and
<xref target="RFC7271"/> use OAM mechanisms to support and coordinate
protection switching and packet loss is possible during a switch. While
such this level of protection may be sufficient for many DetNet
applications, when truly hitless (i.e., zero loss) switching is required,
additional mechanisms will be needed. It is expected that these
additional mechanisms will be defined at a DetNet layer.
<vspace blankLines="1"/> </t>
<t hangText="#6 Operations, Administration and Maintenance (M)">
<vspace blankLines="1"/>
MPLS already includes a rich set of OAM functions at both the Service and
Transport Layers. This includes LSP ping [ref] and those enabled via the
MPLS Generic Associated Channel <xref target="RFC5586"/> and registered
by <eref
target="http://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml">
IANA</eref>.
<vspace blankLines="1"/> </t>
<t hangText="#8 Class and quality of service capabilities (M/W)">
<vspace blankLines="1"/>
As previously mentioned, Data plane Quality of Service capabilities are
included in the MPLS in the form of Traffic Engineered (TE) LSPs <xref
target="RFC3209"/> and the MPLS Differentiated Services (DiffServ)
architecture <xref target="RFC3270"/>. Both E-LSP and L-LSP MPLS
DiffServ modes are defined. The Traffic Class field (formerly the EXP
field) of an MPLS label follows the definition of <xref
target="RFC5462"/> and <xref target="RFC3270"/>. One potential open area
of work is synchronized, time based scheduling. Another is shaping, which
is generally not supported in shipping MPLS hardware.
<vspace blankLines="1"/>
</t>
<t hangText="#9 Packet traceability (M)">
<vspace blankLines="1"/>
MPLS supports multiple tracing mechanisms. A control based one is
defined in <xref target="RFC3209"/>. An OAM based mechanism is defined
in MPLS On-Demand Connectivity Verification and Route Tracing <xref
target="RFC6426"/>.
<vspace blankLines="1"/>
</t>
<t hangText="#10 Technical maturity (M)">
<vspace blankLines="1"/>
MPLS as a mature technology that has been widely deployed in many
networks for many years. Numerous vendor products and multiple
generations of MPLS hardware have been built and deployed.
</t>
</list>
</t>
</section>
<section title="Summary">
<t>
MPLS is a mature technology that has been widely deployed. Numerous
vendor products and multiple generations of MPLS hardware have been built
and deployed. MPLS LSPs support a significant portion of the identified
DetNet data plane criteria today. Aspects of the DetNet data plane that
are not fully supported can be incrementally added. It's worth noting that
a number of limitations are in shipping hardware, versus at the protocol
specification level, e.g., shaping.
</t>
</section>
</section>
<section title="Bit Indexed Explicit Replication (BIER)" anchor="sec_alt_bier">
<t>
<xref target="I-D.ietf-bier-architecture">Bit Indexed Explicit Replication
</xref> (BIER) is a network plane replication technique that was initially
intended as a new method for multicast distribution. In a nutshell, a BIER
header includes a bitmap that explicitly signals the destinations that are
intended for a particular packet, which means that 1) the source is aware of
the individual destinations and 2) the BIER control plane is a simple extension
of the unicast routing as opposed to a dedicated multicast data plane, which
represents a considerable reduction in OPEX. For this reason, the technology
is getting a lot of traction from Service Providers. In the context of DetNet,
BIER may be applicable for implementing packet replication, as described in
<xref target="sec_alt_bier"/>.
</t>
<t>
The encapsulation of a BIER packet in an MPLS network is shown in
<xref target="fig_BIER_MPLS"/>
</t>
<figure anchor="fig_BIER_MPLS" align="center"
title="BIER packet in MPLS encapsulation">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIER-MPLS label | |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| Ver | Len | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM| Reserved | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<section title="Solution description">
<t>
A distinctive BIER payload type (with its own Proto(col) ID) would be created
for DetNet, providing a header that would identify:
<list style="symbols">
<t>Version;</t>
<t>Sequence Number;</t>
<t>Timestamp;</t>
<t>Payload type, e.g. data vs. OAM.</t>
</list>
A DetNet node, collocated with a BFIR (Bit-Forwarding Ingress Router) may use
multiple BIER sub-domains to create replicated flows. Downstream DetNet
nodes, collocated with BFER (Bit-Forwarding Ingress Router) would terminate
redundant flows based on Sequence Number and/or Timestamp information. Thus a
DetNet node may be collocated with a BFER in one BIER sub- domain and with a
BFIR in another, and a DetNet flow could traverse several BIER sub-domains.
</t>
<figure anchor="fig_BIER_DetNet" align="center"
title="DetNet in BIER domain">
<artwork align="center"><![CDATA[
+-----+
| A |
+-----+
/ \
. .
/ .
. \
/ .
. .
/ \
+-----+ +-----+
| B | | C |
+-----+ +-----+
/ \ / \
. . . .
/ \ . .
. . / \
/ \ . .
. . . .
/ \ / \
+-----+ +-----+ +-----+
| D | | E | | F |
+-----+ +-----+ +-----+
\ . . /
. . . .
\ . . .
. . . /
\ . . .
. . . .
\ . . /
+-----+ +-----+
| G | | H |
+-----+ +-----+
]]></artwork>
</figure>
<t>
Consider a DetNet flow that must traverse BIER enabled domain from A to G and H.
DetNet may use three BIER subdomains:
<list style="symbols">
<t>A-B-D-E-G (dash-dot): A is BFIR, E and G are BFERs,</t>
<t>A-C-E-F-H (dash-double-dot): A is BFIR, E and H are BFERs,</t>
<t>E-G-H (dotted): E is BFIR, G and H are BFERs.</t>
</list>
</t>
<t>
DetNet node A sends DetNet into red and purple BIER sub-domains. DetNet node
E receives DetNet packet and sends into green sub-domain while terminating
duplicates and those that are deemed "too-late".
</t>
<t>
DetNet nodes G and H receive DetNet flows, terminate duplicates and those
that are too-late.
</t>
</section>
<section title="Analysis and Discussion" anchor="sec_alt_bier_ana">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
BIER over MPLS network encapsulation ("BIER over MPLS"), <xref
target="fig_BIER_MPLS"/>, is being defined <xref
target="I-D.ietf-bier-mpls-encapsulation"/> within the BIER working group.
<vspace blankLines="1"/></t>
<t hangText="#2 Flow identification (M)">
<vspace blankLines="1"/>
Flow identification and separation can be achieved through use of BIER
domains and/or Entropy value in the BIER over MPLS, <xref
target="fig_BIER_MPLS"/>.
<vspace blankLines="1"/></t>
<t hangText="#4 Explicit routes (M)">
<vspace blankLines="1"/>
Explicit routes may be used as underlay for BIER domain. BIER underlay may
be calculated using PCE and instantiated using any southbound mechanism.
<vspace blankLines="1"/></t>
<t hangText="#5 Flow duplication and merging (M/W)">
<vspace blankLines="1"/>
Packet replication, as indicated by its name, is a core function of the
Bit-Indexed Explicit Replication. Elimination of the duplicates and/or
too-late packets cannot be done within BIER sub-domain but may be done at
DetNet overlay at the edge of the BIER sub-domain.
<vspace blankLines="1"/>
[Editor's note: how about the flow merging?]
<vspace blankLines="1"/></t>
<t hangText="#6 Operations, Administration and Maintenance (M/W)">
<vspace blankLines="1"/>
BIER over MPLS guarantees that OAM is fate-sharing, i.e. in-band with a
data flow being monitored or measured. Additionally, BIER over MPLS enables
passive performance measurement, e.g. with the marking method <xref
target="I-D.mirsky-bier-pmmm-oam"/>. Existing OAM protocols can be applied
and used in BIER over MPLS as demonstrated in <xref
target="I-D.ooamdt-rtgwg-oam-gap-analysis"/>, while new protocols are being
worked on, e.g. ping/traceroute <xref target="I-D.kumarzheng-bier-ping"/>
or Path MTU Discovery <xref target="I-D.mirsky-bier-path-mtu-discovery"/>.
<vspace blankLines="1"/></t>
<t hangText="#8 Class and quality of service capabilities (M/W)">
<vspace blankLines="1"/>
Class of Service can be inherited from the underlay of the particular BIER
sub-domain. Quality of Service, i.e. scheduling and bandwidth reservations
can be used among other constraints in calculating explicit paths for the
BIER sub-domain's underlay.
<vspace blankLines="1"/></t>
<t hangText="#9 Packet traceability (W)">
<vspace blankLines="1"/>
Ability to do passive performance measurement by using OAM field of the
BIER over MPLS, <xref target="fig_BIER_MPLS"/>, is unmatched and
significantly simplifies truly passive tracing of selected flows and
packets within them.
<vspace blankLines="1"/></t>
<t hangText="#10 Technical maturity (W)">
<vspace blankLines="1"/>The BIER over MPLS is nearing finalization
within the BIER WG and several experimental implementations are
expected soon.
</t>
</list></t>
</section>
<section title="Summary">
<t>
BIER over MPLS supports a significant portion of the identified DetNet
data plane requirements, including controlled packet replication, traffic
engineering, while some requirements, e.g. duplicate and too-late packet
elimination may be realized as function of the DetNet overlay. BIER over
MPLS is a viable candidate as the DetNet Transport layer in MPLS
networks.
</t>
</section>
</section>
</section> <!-- Net layer technolofes -->
<!-- ============================================================ -->
<section title="DetNet Service layer technologies" anchor="sec_det">
<!--section title="Layer-2 tunneling over IP"-->
<section title="Generic Routing Encapsulation (GRE)" anchor="sec_alt_gre">
<section title="Solution description">
<t>
Generic Routing Encapsulation (GRE) <xref target="RFC2784"/> provides an
encapsulation of an arbitrary network layer protocol over another arbitrary
network layer protocol. The encapsulation of a GRE packet can be found in
<xref target="fig_gre_encap"/>.
</t>
<figure anchor="fig_gre_encap" title="Encapsulation of a GRE packet">
<artwork align="center"><![CDATA[
+-------------------------------+
| Delivery Header |
+-------------------------------+
| GRE Header |
+-------------------------------+
| Payload packet |
+-------------------------------+
]]></artwork></figure>
<t>
Based on RFC2784, <xref target="RFC2890"/> further includes sequencing
number and Key in optional fields of the GRE header, which may help to
transport DetNet traffic flows over IP networks. The format of a GRE header
is presented in <xref target="fig_gre_hdr"/>.
</t>
<figure title="Format of a GRE header" anchor="fig_gre_hdr">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-----------------------------------------------------------------+
| Checksum (optional) | Reserved1 (Optional) |
+-----------------------------------------------------------------+
| Key (optional) |
+-----------------------------------------------------------------+
| Sequence Number (optional) |
+-----------------------------------------------------------------+
]]></artwork></figure>
</section>
<section title="Analysis and Discussion">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
GRE can provide encapsulation at the service layer over the transport
layer. A new protocol type for DetNet traffic should be
allocated as an "Ether Type" in <xref target="RFC3232"/> and in <eref
target="http://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers">IANA
Ethernet Numbers</eref>. The fixed header of a GRE packet is 4 octets
while the maximum header is 16 octets with optional fields in <xref
target="fig_gre_hdr"/>.
<vspace blankLines="1"/></t>
<t hangText="#2 Flow identification (W)">
<vspace blankLines="1"/>
There is no flow identification field in GRE header. However, it can rely
on the flow identification mechanism applied in the delivery protocols,
such as flow identification stated in IP Sections <xref format="counter"
target="sec_alt_ipv6"/> and <xref format="counter" target="sec_alt_ipv4"/>
when the delivery protocols are IPv6 and IPv4 respectively.
Alternatively, the Key field can also be extended to carry the flow
identification. The size of Key field is 4 octets.
<vspace blankLines="1"/></t>
<t hangText="#3 Packet sequencing and duplicate elimination (M/W)">
<vspace blankLines="1"/>
As stated in <xref target="sec_alt_gre"/>, GRE provides an optional
sequencing number in its header to provide sequencing services for
packets. The size of the sequencing number is 32 bits. The GRE header
could be extended to indicate the duplicated packets by defining a flag
in reserved fields or using the sequencing number of a flow.
<vspace blankLines="1"/></t>
<t hangText="#5 Flow duplication and merging (W/N)">
<vspace blankLines="1"/>
GRE has no flow/packet replication and merging support in its header. It
can use the transport IPv4/IPv6 protocols at the transport layer to
replicate the packets and take the different routes as discussed in
<xref target="sec_alt_ipv6"/> and <xref target="sec_alt_ipv4"/>.
<vspace blankLines="1"/></t>
<t hangText="#6 Operations, Administration and Maintenance (M)">
<vspace blankLines="1"/>
GRE uses the network management provided by the IP protocols as
transport layer.
<vspace blankLines="1"/></t>
<t hangText="#8 Class and quality of service capabilities (W) ">
<vspace blankLines="1"/>
For the class of service capability, an optional code point field to
indicate CoS of the traffic could be added into the GRE header.
Otherwise, GRE can reuse the class and quality of service of delivery
protocols at transport layer such as IPv6 and IPv4 stated in
<xref target="sec_alt_ipv6"/> and <xref target="sec_alt_ipv4"/>.
<vspace blankLines="1"/></t>
<t hangText="#10 Technical maturity (M)">
<vspace blankLines="1"/>
GRE has been developed over 20 years. The delivery protocol mostly used is
IPv4, while the IPv6 support for GRE is to be standardized now in IETF as
<xref target="RFC7676"/>. Due to its good extensibility,
GRE has also been extended to support network virtualization in Data
Center, which is NVGRE <xref target="RFC7637"/>.
</t>
</list></t>
</section>
<section title="Summary">
<t>
As a tunneling protocol, GRE can encapsulate a wide variety of
network layer protocols over another network layer, which can
naturally serve as the service layer protocol for DetNet.
Currently, it supports a portion of the Detnet service layer
criteria, and still some are not fully supported but can be
incrementally added or supported by delivery protocols at as the
transport layer. In general, GRE can be a choice as the DetNet
service layer and can work with IPv6 and IPv4 as the DetNet
Transport layer.
</t>
</section>
</section>
<section title="MPLS-based Services for DetNet" anchor="sec_alt_mpls_svc">
<t>
MPLS based technologies support both the DetNet Service and DetNet
Transport layers. This, as well as a general overview of MPLS, is
covered above in <xref target="sec_alt_mpls"/>. Following sections focus
on the DetNet Service Layer which provides client service
adaption, via Pseudowires <xref
target="sec_alt_pwe"/> and via native and other label-like
mechanisms such as EPVN in <xref
target="sec_alt_evpn"/>. A representation of these options was
previously discussed and is shown in
<xref target="fig_mpls_clients"/>.
</t>
<t> The following text is adapted from <xref target="RFC5921"/>:
<list style="none">
<t>
The MPLS native service adaptation functions interface the client
layer network service to MPLS. For Pseudowires, these adaptation
functions are the payload encapsulation described in Section 4.4
of <xref target="RFC3985"/> and Section 6 of
<xref target="RFC5659"/>. For network layer client services, the
adaptation function uses the MPLS encapsulation format as defined
in <xref target="RFC3032"/>.
<vspace blankLines="1"/></t>
<t>
The purpose of this encapsulation is to abstract the data plane of
the client layer network from the MPLS data plane, thus
contributing to the independent operation of the MPLS network.
<vspace blankLines="1"/></t>
<t>
MPLS may itself be a client of an underlying server layer. MPLS
can thus also be bounded by a set of adaptation functions to this
server layer network, which may itself be MPLS. These adaptation
functions provide encapsulation of the MPLS frames and for the
transparent transport of those frames over the server layer
network.
<vspace blankLines="1"/></t>
<t>
While MPLS service can provided on a true end-system to end-system
basis, it's more likely that DetNet service will be provided over
Pseudowires as described in <xref target="sec_alt_pwe"/> or via an
EPVN-based service described in <xref target="sec_alt_evpn"/> .
<vspace blankLines="1"/></t>
<t>
MPLS labels in the label stack may be used to identify
transport paths, see <xref target="sec_alt_mpls"/>, or as
service identifiers. Typically a single label is used for
service identification.
<vspace blankLines="1"/></t>
<t>
Packet sequencing mechanisms are added in client-related adaptation
processing, see Sections <xref format="counter" target="sec_alt_pwe"/> and
<xref format="counter" target="sec_alt_evpn"/>.
<vspace blankLines="1"/></t>
<t>
The MPLS client inherits its Quality of Service (QoS) from
the MPLS transport layer, which in turn inherits its QoS from the
server (sub-network) layer. The server layer therefore needs to
provide the necessary QoS to ensure that the MPLS client QoS
commitments can be satisfied.
</t>
</list>
</t>
</section>
<section title="Pseudo Wire Emulation Edge-to-Edge (PWE3)" anchor="sec_alt_pwe">
<section title="Solution description">
<t>
Pseudo Wire Emulation Edge-to-Edge (PWE3) <xref target="RFC3985"/> or
simply PseudoWires (PW) provide means of emulating the essential attributes
and behaviour of a telecommunications service over a packet switched
network (PSN) using IP or MPLS transport. In addition to traditional
telecommunications services such as T1 line or Frame Relay, PWs also
provide transport for Ethernet service <xref target="RFC4448"/> and for
generic packet service <xref target="RFC6658"/>. <xref target="fig_pwe3_stack"/>
illustrate the reference PWE3 stack model.
</t>
<figure title="PWE3 protocol stack reference model" anchor="fig_pwe3_stack">
<artwork align="center"><![CDATA[
+----------------+ +----------------+
|Emulated Service| |Emulated Service|
|(e.g., Eth, ...)|<= Emulated Service =>|(e.g., Eth, ...)|
+----------------+ +----------------+
| Payload | | Payload | CW,
| Encapsulation |<=== Pseudo Wire ====>| Encapsulation | Timing,
| | | | Seq., ..
+----------------+ +----------------+
|PW Demultiplexer| |PW Demultiplexer|
| PSN Tunnel, |<==== PSN Tunnel ====>| PSN Tunnel, | MPLS.
| PSN & Physical | | PSN & Physical | L2TP,
| Layers | | Layers | IP, ..
+-------+--------+ ___________ +---------+------+
| / \ |
+============/ PSN \==============+
\ /
\___________/
]]>
</artwork></figure>
<t>
PWs appear as a good data plane solution alternative for a number of
reasons. PWs are a proven and deployed technology with a rich OAM control
plane <xref target="RFC4447"/>, and enjoy the toolbox developed for MPLS
networks in a case of MPLS-based PSN. Furthermore, PWs may have an
optional Control Word (CW) as part of the payload encapsulation between
the PSN and the emulated service that is, for example, capable of frame
sequencing and duplicate detection. The encapsulation layer may also
provide timing using RTP as described in Sections 5.2.2, 5.4.1 and 5.4.2
of <xref target="RFC3985"/> and utilized by <xref target="RFC4553"/><xref
target="RFC5087"/>. Furthermore, advanced DetNet node functions are
conceptually already supported by PW framework (with some added functional
required), such as the DetNet Relay node modeled after the Multi-Segment
PWE3 <xref target="RFC5254"/>.
</t>
<t>
PWs can be also used if the PSN is IP, which enables the application of PWs
in networks that do not have MPLS enabled in their core routers. One
approach to provide PWs over IP is to provide MPLS over IP in some way and
then leverage what is available for PWs over MPLS. The following standard
solutions are available both for IPv4 and IPv6 to follow this approach. The
different solutions have different overhead as discussed in the following
subsection. The MPLS-in-IP encapsulation is specified by <xref
target="RFC4023"/>. The IPv4 Protocol Number field or the IPv6 Next Header
field is set to 137, which indicates an MPLS unicast packet. (The use of
the MPLS-in-IP encapsulation for MPLS multicast packets is not supported.)
The MPLS-in-GRE encapsulation is specified in <xref target="RFC4023"/>,
where the IP header (either IPv4 or IPv6) is followed by a GRE header,
which is followed by an MPLS label stack. The protocol type field in the
GRE header is set to MPLS Unicast (0x8847) or Multicast (0x8848). MPLS over
L2TPv3 over IP encapsulation is specified by <xref target="RFC4817"/>. The
MPLS-in-UDP encapsulation is specified by <xref target="RFC7510"/>, where
the UDP Destination Port indicates tunneled MPLS packet and the UDP Source
Port is an entropy value that is generated by the encapsulator to uniquely
identify a flow. MPLS-in-UDP encapsulation can be applied to enable
UDP-based ECMP (Equal-Cost Multipath) or Link Aggregation. All these
solutions can be secured with IPsec <xref target="RFC4303"/>.
</t>
</section>
<section title="Analysis and Discussion">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
PWs offer encapsulation services practically for practically any type of
payload over any PSN. New PW types need a code point allocation <xref
target="RFC4446"/> and in some cases an emulated service specific
document.
<vspace blankLines="1"/>
Specifically in the case of the MPLS PSN the PW encapsulation overhead is
minimal. Typically minimum two labels and a CW is needed, which totals to
12 octets. PW type specific handling might, however, allow optimizations
on the emulated service in the provider edge (PE) device's native service
processing (NSP) / forwarder function. These optimizations could be used,
for example, to reduce header overhead. Ethernet PWs already have rather
low overhead <xref target="RFC4448"/>. Without a CW and VLAN tags the
Ethernet header gets reduced to 14 octets (minimum Ethernet header
overhead is 26).
<vspace blankLines="1"/>
The overhead is somewhat bigger in case of IP PSN if an MPLS over IP
solution is applied to provide PWs. IP adds at least 20 (IPv4) or 40 (IPv6)
bytes overhead to the PW over MPLS overhead; furthermore, the GRE, L2TPv3,
or UDP header has to be taken into account if any of these further
encapsulations is used.
<vspace blankLines="1"/></t>
<t hangText="#2 Flow identification (M)">
<vspace blankLines="1"/>
PWs provide multiple layers of flow identification, especially in the case
of the MPLS PSN. The PWs are typically prepended with an endpoint specific
PW label that can be used to identify a specific PW per endpoint.
Furthermore, the MPLS PSN also uses one or more labels to transport
packets over specific label switched paths (that then would carry PWs).
So, a DetNet flow can be identified in this example by the service and
transport layer labels. IP (and other) PSNs may need other mechanisms,
such as, UDP port numbers, upper layer protocol header (like RTP) or some
IP extension header to provide required flow identification.
<vspace blankLines="1"/></t>
<t hangText="#3 Packet sequencing and duplicate elimination (M)">
<vspace blankLines="1"/>
As mentioned earlier PWs may contain an optional CW that is able to
provide sequencing services. The size of the sequence number in the
generic CW is 16 bits, which might be, depending on the used link and
DetNet flow speed be too little. The PW duplicate detection mechanism is
already conceptually specified <xref target="RFC3985"/> but no emulated
service makes use of it currently.
<vspace blankLines="1"/></t>
<t hangText="#5 Flow duplication and merging (W)">
<vspace blankLines="1"/>
PWs could use a (extended) version of existing transport layer provided
protection mechanisms (e.g., hitless 1+1 protection) for both flow
duplication and flow merging. The service layer has to provide the
functionality to map DetNet flows into appropriate transport layer
connection.
<vspace blankLines="1"/></t>
<t hangText="#6 Operations, Administration and Maintenance (M/W)">
<vspace blankLines="1"/>
PWs have rich control plane for OAM and in a case of the MPLS PSN enjoy
the full control plane toolbox developed for MPLS network OAM likewise
IP PSN has the full toolbox of IP network OAM tools. There could be,
however, need for deterministic networking specific extensions for the
mentioned control planes.
<vspace blankLines="1"/></t>
<t hangText="#8 Class and quality of service capabilities (M/W)">
<vspace blankLines="1"/>
In a case of IP PSN the 6-bit differentiated services code point (DSCP)
field can be used for indicating the class of service <xref
target="RFC2474"/> and 2-bit field reserved for the explicit congestion
notification (ECN) <xref target="RFC3168"/>. Similarly, in a case of MPLS
PSN, there are 3-bit traffic class field (TC) <xref target="RFC5462"/> in
the label reserved for for both Explicitly TC-encoded-PSC LSPs (E-LSP)
<xref target="RFC3270"/> and ECN <xref target="RFC5129"/>. Due to the
limited number of bits in the TC field, their use for QoS and ECN
functions is restricted and intended to be flexible. Although the QoS/CoS
mechanism is already in place some clarifications may be required in the
context of deterministic networking flows, for example, if some
specific mapping between bit fields have to be done.
<vspace blankLines="1"/>
When PWs are used over MPLS, MPLS LSPs can be used to provide both CoS
(E-LSPs and L-LSPs) and QoS (dedicated TE LSPS).
<vspace blankLines="1"/></t>
<t hangText="#10 Technical maturity (M)">
<vspace blankLines="1"/>
PWs, IP and MPLS are proven technologies with wide variety of deployments
and years of operational experience. Furthermore, the estimated work for
missing functionality (packet replication and elimination) does not appear
to be extensive, since the existing protection mechanism already gets close
to what is needed from the deterministic networking data plane solution.
<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Summary">
<t>
PseudoWires appear to be a strong candidate as the deterministic networking
data plane solution alternative for the DetNet Service layer. The strong
points are the technical maturity and the extensive control plane for OAM.
This holds specifically for MPLS-based PSN.
</t>
<t>
Extensions are required to realize the packet replication and duplicate
detection features of the deterministic networking data plane.
</t>
</section>
</section>
<section title="MPLS-Based Ethernet VPN (EVPN)" anchor="sec_alt_evpn">
<section title="Solution description">
<t>
MPLS-Based Ethernet VPN (EVPN), in the form documented in
<xref target="RFC7432"/> and <xref target="RFC7209"/>, is an
increasingly popular approach to delivering MPLS-based Ethernet
services and is designed to be the successor to Virtual Private LAN
Service (VPLS), <xref target="RFC4664"/>.
</t>
<t>
EVPN provides client adaptation and reuses the MPLS data plane
discussed above in <xref target="sec_alt_mpls_svc"/>. While not
required, the PW Control Word is also used. EVPN
control is via BGP, <xref target="RFC7432"/>, and may use TE-LSPs,
e.g., controlled via <xref target="RFC3209"/> for MPLS transport.
Additional EVPN related RFCs and in progress drafts are being
developed by the <eref target="https://tools.ietf.org/wg/bess/">
BGP Enabled Services Working Group</eref>.
</t>
</section>
<section title="Analysis and Discussion">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
EVPN generally uses a single MPLS label stack entry to support its
client adaptation service. The optional addition of a second label is
also supported. In certain cases PW Control Word may also be used.
<vspace blankLines="1"/>
</t>
<t hangText="#2 Flow identification (W)">
<vspace blankLines="1"/>
EVPN currently uses labels to identify flows per {Ethernet Segment
Identifier, VLAN} or per MAC level. Additional definition will be
needed to standardize identification of finer granularity DetNet flows
as well as mapping of TSN services to DetNet Services.
<vspace blankLines="1"/>
</t>
<t hangText="#3 Packet sequencing and duplicate elimination (M)">
<vspace blankLines="1"/>
Like MPLS, EVPN generally orders packets similar to Ethernet.
Reordering is possible primarily during path changes and protection
switching. In order to avoid misordering due to ECMP, EVPN uses the
"Preferred PW MPLS Control Word" <xref target="RFC4385"/> (in which
case EVPN inherits this function from PWs) or the entropy labels <xref
target="RFC6790"/>.
<vspace blankLines="1"/>
If additional ordering mechanisms are required, such mechanisms will
need to be defined.
<vspace blankLines="1"/>
</t>
<t hangText="#5 Flow duplication and merging (M/W)">
<vspace blankLines="1"/>
EVPN relies on the MPLS layer for all protection functions. See <xref
target="sec_alt_mpls"/> and <xref target="sec_alt_mpls_svc"/>. Some
extensions, either at the EVPN or MPLS levels, will be need to support
those DetNet applications which require true hitless (i.e., zero loss)
1+1 protection switching. (Network coding may be an interesting
alternative to investigate to delivering such hitless loss protection
capability.)
<vspace blankLines="1"/>
</t>
<t hangText="#6 Operations, Administration and Maintenance (M/W)">
<vspace blankLines="1"/>
Nodes supporting EVPN may participate in either or both Ethernet level
and MPLS level OAM. It is likely that it may make sense to map or
adapt the OAM functions at the different levels, but such has yet to be
defined. <xref target="RFC6371"/> provides some useful background on
this topic.
<vspace blankLines="1"/>
</t>
<t hangText="#8 Class and quality of service capabilities (M/W)">
<vspace blankLines="1"/>
EVPN is largely silent on the topics of CoS and QoS, but the 802.1 TSN
Ethernet and existing MPLS TE mechanisms can be directly used. The
inter-working of such is new work and within the scope of DetNet. The
existing MPLS mechanisms include both CoS (E-LSPs and L-LSPs) and QoS
(dedicated TE LSPs).
<vspace blankLines="1"/>
</t>
<t hangText="#10 Technical maturity (M)">
<vspace blankLines="1"/>
EVPN is a second (or third) generation MPLS-based L2VPN service
standard. From a data plane standpoint it makes uses of existing MPLS
data plane mechanisms. The mechanisms have been widely implemented and
deployed.
</t>
</list>
</t>
</section>
<section title="Summary">
<t>
EVPN is the emerging successor to VPLS. EVPN is standardized, implemented
and deployed. It makes use of the mature MPLS data plane. While offering
a mature and very comprehensive set of features, certain DetNet required
features are not fully/directly supported and additional standardization
in these areas are needed. Examples include: mapping CoS and QoS; use of
labels per DetNet flow, and hitless 1+1 protection.
</t>
</section>
</section>
<section title="Higher layer header fields" anchor="sec_alt_higher">
<t>
Fields of headers belonging to higher OSI layers can be used to implement
functionality that is not provided e.g., by the IPv6 or IPv4 header fields.
However, this approach cannot be always applied, e.g., due to encryption.
Furthermore, even if this approach is applicable, it requires deep packet
inspection from the routers and switches. There are implementation
dependent limits how far into the packet the lookup can be done
efficiently in the fast path. When encryption is not used, a safe bet
is generally between 128 and 256
octets for the maximum lookup depth. Various higher layer protocols can be
applied. Some examples are provided here for the sequence numbering feature
(<xref target="sec_crit_seq"/>).
</t>
<section title="TCP">
<t>
The TCP header includes a sequence number parameter, which can be applied
to detect and eliminate duplicate packets if DetNet service protection
is used. As the TCP header is right after the IP header, it does not
require very deep packet inspection; the 4-byte sequence number is
conveyed by bits 32 through 63 of the TCP header. In addition to
sequencing, the TCP header also contain source and destination port
information that can be used for assisting the flow identification.
</t>
</section>
<section title="RTP">
<section title="Solution Description">
<t>
Real-time Transport Protocol (RTP) <xref target="RFC3550"/> is often
used to deliver time critical traffic in IP networks. RTP is typically
carried on top of UDP/IP. However, as noted earlier in <xref
target="sec_alt_pwe"/> PseudoWires also have a well-defined way of
embedding and transposting RTP headers as part of its payload
encapsulation headers/sub-layer. RTP is also augmented by its own
control protocol RTCP, which monitors the data delivery and provides
minimal control and identification functionality. RTCP packets do not
carry "media payload". Although both RTP and RTCP are typically used
with UDP/IP transport they are designed to be independent of the
underlying transport and network layers.
</t>
<t>
The RTP header includes a 2-byte sequence number, which can be used to
detect and eliminate duplicate packets if DetNet service protection is
used. The sequence number is conveyed by bits 16 through 31 of the RTP
header. In addition to the sequence number the RTP header has also
timestamp field (bits 32 through 63) that can be useful for time
synchronization purposes. Furthermore, the RTP header has also one or
more synchronization sources (bits starting from 64) that can
potentially be useful for flow identification purposes.
</t>
</section>
<section title="Analysis and Discussion">
<t><list style="hanging">
<t hangText="#1 Encapsulation and overhead (M)">
<vspace blankLines="1"/>
RTP adds minimum 12 octets of header overhead. Typically 8 octets overhead
of UDP header has to be also added, at least in a case when RTP is
transported over IP. Although RTCP packets do not contribute to the media
payload transport they still consume overall network capacity, since all
participants to an RTP session including sourcess and multicast session
destinations are expected to send RTCP reports.
<vspace blankLines="1"/></t>
<t hangText="#2 Flow identification (M)">
<vspace blankLines="1"/>
The RTP header contains a
synchronization source (SSRC) identifier. The intent is that no two
synchronization sources within the same RTP session have the
same SSRC identifier.
<vspace blankLines="1"/></t>
<t hangText="#3 Packet sequencing and duplicate elimination (M)">
<vspace blankLines="1"/>
The RTP header contains a 16 bit sequence number. The sequence number
can be also used to detect duplicate packets.
<vspace blankLines="1"/></t>
<t hangText="#5 Flow duplication and merging (M/W)">
<vspace blankLines="1"/>
RTP has precedence of being used for hitless protection switching <xref
target="ST20227"/>, which essentially is equivalent to DetNet service
protection. Furthermore, recent work in IETF for RTP stream duplication
<xref target="RFC7198"/> as a mechanism to protect media flows from
packet loss is again equivalent to Detnet service protection.
<vspace blankLines="1"/></t>
<t hangText="#6 Operations, Administration and Maintenance (M)">
<vspace blankLines="1"/>
RTP has its own control protocol RTCP for (minimal) management and stream
monitoring purposes. Existing IP OAM tools can directly leveraged when
RTP is deployed over IP transport.
<vspace blankLines="1"/></t>
<t hangText="#8 Class and quality of service capabilities (M/W)">
<vspace blankLines="1"/>
TBD. [Editor's note: relies on lower layers to provide CoS/QoS]
<vspace blankLines="1"/></t>
<t hangText="#10 Technical maturity (M)">
<vspace blankLines="1"/>
RTP has been deployed and used in large commercial systems for over ten
years and can be considered a mature technology.
<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Summary">
<t>
RTP appears to be a good candidate as the deterministic networking data
plane solution alternative for the DetNet Service layer. The strong points
are the technical maturity and the fact it was designed for transporting
time-sensitive payload from the beginning. RTP is specifically well suited
to be used with (UDP)/IP transport.
</t>
<t>
Extensions may be required to realize the packet replication and duplicate
detection features of the deterministic networking data plane. However,
there is already precedence of similar solutions that could potentially be
leveraged <xref target="ST20227"/><xref target="RFC7198"/>.
</t>
</section>
</section>
</section> <!-- Det layer technologies -->
</section>
</section>
<!-- ===================================================================== -->
<section title="Summary of data plane alternatives">
<t>The following table summarizes the criteria (<xref target="sec_crit"/>)
used for the evaluation of data plane options.
</t>
<!--texttable anchor="tab_all_summary" title="PseudoWire criteria summary">
<ttcol align="left">Alternative</ttcol>
<ttcol align="left">Comments</ttcol>
<c>Native IPv4</c>
<c>..</c>
<c>Native IPv6</c>
<c>..</c>
<c>GRE</c>
<c>..</c>
<c>L2TP</c>
<c>..</c>
<c>MPLS</c>
<c>..</c>
<c>PWE</c>
<c>..</c>
<c>BIER</c>
<c>..</c>
</texttable-->
<texttable anchor="Items" title="Evaluation criteria">
<preamble>Applicability per Alternative</preamble>
<ttcol align="center">Item #</ttcol>
<ttcol align="center">Meaning</ttcol>
<c> #1</c><c>Encapsulation and overhead</c>
<c> #2</c><c>Flow identification</c>
<c> #3</c><c>Packet sequencing and duplicate elimination</c>
<c> #4</c><c>Explicit routes</c>
<c> #5</c><c>Flow duplication and merging</c>
<c> #6</c><c>Operations, Administration and Maintenance</c>
<c> #8</c><c>Class and quality of service capabilities</c>
<c> #9</c><c>Packet traceability</c>
<c>#10</c><c>Technical maturity</c>
</texttable>
<t>There is no single technology that could meet all the criteria on its
own. Distinguishing the DetNet Service and the DetNet Transport, as explained
in (<xref target="sec_dt_dp"/>), allows a number of combinations, which can
meet most of the criteria. There is no room here to evaluate all possible
combinations. Therefore, only some combinations are highlighted here, which
are selected based on the number of criteria that are met and the maturity of
the technology (#10).
</t>
<t>The following table summarizes the evaluation of the data plane options
that can be used for the DetNet Transport Layer against the evaluation
criteria. Each value in the table is from the corresponding section.
</t>
<texttable anchor="SumDTL" title="DetNet Transport Layer">
<preamble>Applicability per Transport Alternative</preamble>
<ttcol align="center">Solution</ttcol>
<ttcol align="left"> #1</ttcol>
<ttcol align="left"> #2</ttcol>
<ttcol align="left"> #4</ttcol>
<ttcol align="left"> #5</ttcol>
<ttcol align="left"> #6</ttcol>
<ttcol align="left"> #8</ttcol>
<ttcol align="left"> #9</ttcol>
<ttcol align="left">#10</ttcol>
<c>IPv6</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>W</c>
<!-- 4--> <c>W</c>
<!-- 5--> <c>W</c>
<!-- 6--> <c>M</c>
<!-- 8--> <c>W</c>
<!-- 9--> <c>W</c>
<!--10--> <c>M/W</c>
<c>IPv4</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>W</c>
<!-- 4--> <c>W</c>
<!-- 5--> <c>W/N</c>
<!-- 6--> <c>M</c>
<!-- 8--> <c>M/W</c>
<!-- 9--> <c>W</c>
<!--10--> <c>M/W</c>
<c>MPLS</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>M</c>
<!-- 4--> <c>M</c>
<!-- 5--> <c>M/W</c>
<!-- 6--> <c>M</c>
<!-- 8--> <c>M/W</c>
<!-- 9--> <c>M</c>
<!--10--> <c>M</c>
<c>BIER</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>M</c>
<!-- 4--> <c>M</c>
<!-- 5--> <c>M/W</c>
<!-- 6--> <c>M/W</c>
<!-- 8--> <c>M/W</c>
<!-- 9--> <c>M</c>
<!--10--> <c>W</c>
<postamble>Summarizing Transport capabilities
</postamble>
</texttable>
<t>The following table summarizes the evaluation of the data plane options
that can be used for the DetNet Service Layer against the criteria
evaluation criteria. Each value in the table is from the corresponding
section.
</t>
<texttable anchor="SumDSL" title="DetNet Service Layer">
<preamble>Applicability per Service Alternative</preamble>
<ttcol align="center">Solution</ttcol>
<ttcol align="left"> #1</ttcol>
<ttcol align="left"> #2</ttcol>
<ttcol align="left"> #3</ttcol>
<ttcol align="left"> #5</ttcol>
<ttcol align="left"> #6</ttcol>
<ttcol align="left"> #8</ttcol>
<ttcol align="left">#10</ttcol>
<c>GRE</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>W</c>
<!-- 3--> <c>M/W</c>
<!-- 5--> <c>W/N</c>
<!-- 6--> <c>M</c>
<!-- 8--> <c>W</c>
<!--10--> <c>M</c>
<c>PWE3</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>M</c>
<!-- 3--> <c>M</c>
<!-- 5--> <c>W</c>
<!-- 6--> <c>M/W</c>
<!-- 8--> <c>M/W</c>
<!--10--> <c>M</c>
<c>EVPN</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>W</c>
<!-- 3--> <c>M</c>
<!-- 5--> <c>M/W</c>
<!-- 6--> <c>M/W</c>
<!-- 8--> <c>M/W</c>
<!--10--> <c>M</c>
<c>RTP</c>
<!-- 1--> <c>M</c>
<!-- 2--> <c>M</c>
<!-- 3--> <c>M</c>
<!-- 5--> <c>M/W</c>
<!-- 6--> <c>M</c>
<!-- 8--> <c>M/W</c>
<!--10--> <c>M</c>
<postamble>Summarizing Service capabilities
</postamble>
</texttable>
<t>
PseudoWire (<xref target="sec_alt_pwe"/>) is a technology that is mature
and meets most of the criteria for the DetNet Service layer as shown in the
table above. From upper layer protocols PWs or RTP can be a candidate for
non-MPLS PSNs. The identified work for PWs is to figure out how to implement
duplicate detection for these protocols (e.g., based on <xref
target="RFC3985"/>). In a case of RTP there is precedence of implementing
packet duplication and duplicate elimination <xref target="ST20227"/><xref
target="RFC7198"/>.
</t>
<t>
PWs can be carried over MPLS or IP. MPLS is the most common technology that
is used as PSN for PseudoWires; furthermore, MPLS is a mature technology and
meets most DetNet Transport layer criteria. IPv[46] can be also used as PSN
and both are mature technologies, although both generally only support CoS
(DiffServ) in deployed networks. RTP is independent of the underlying
transport technology and network. However, it is well suited for UDP/IP
transport or embedded as a part of the PseudoWire timing sub-layer.
</t>
</section>
<section title="Security considerations">
<t>
This document does not add any new security considerations beyond what the
referenced technologies already have.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document has no IANA considerations.
</t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>The author(s) ACK and NACK.
</t>
<t> The following people were part of the DetNet Data Plane Design Team:
<list style="bullets">
<t>Jouni Korhonen</t>
<t>János Farkas</t>
<t>Norman Finn</t>
<t>Olivier Marce</t>
<t>Gregory Mirsky</t>
<t>Pascal Thubert</t>
<t>Zhuangyan Zhuang</t>
</list></t>
<t>
Substantial contributions were received from:
<list style="bullets">
<t>Balázs Varga (service model)</t>
</list>
</t>
<t>
The DetNet chairs serving during the DetNet Data Plane Design Team:
<list style="bullets">
<t>Lou Berger</t>
<t>Pat Thaler</t>
</list></t>
</section>
</middle>
<back>
<!--references title="Normative References">
&rfc2119;
</references-->
<references title="Informative References">
&rfc0791;
&rfc1122;
&rfc3232;
&rfc2205;
&rfc2460;
&rfc2474;
&rfc2784;
&rfc2890;
&rfc3031;
&rfc3032;
&rfc3168;
&rfc3209;
&rfc3270;
&rfc3443;
&rfc3473;
&rfc3550;
&rfc3985;
&rfc4023;
&rfc4303;
&rfc4385;
&rfc4446;
&rfc4447;
&rfc4448;
&rfc4553;
&rfc4664;
&rfc4817;
&rfc4875;
&rfc5087;
&rfc5129;
&rfc5254;
&rfc5305;
&rfc5331;
&rfc5332;
&rfc5440;
&rfc5462;
&rfc5586;
&rfc5659;
&rfc5921;
&rfc5960;
&rfc6275;
&rfc6371;
&rfc6373;
&rfc6378;
&rfc6426;
&rfc6437;
&rfc6564;
&rfc6621;
&rfc6658;
&rfc6790;
&rfc6814;
&rfc6864;
&rfc7045;
&rfc7198;
&rfc7209;
&rfc7271;
&rfc7399;
&rfc7426;
&rfc7432;
&rfc7510;
&rfc7637;
&rfc7752;
&rfc7676;
&rfc7813;
&rfc7872;
&I-D.finn-detnet-architecture;
&I-D.ietf-detnet-problem-statement;
&I-D.ietf-6man-rfc2460bis;
&I-D.ietf-6man-segment-routing-header;
&I-D.ietf-bier-architecture;
&I-D.ietf-mpls-residence-time;
&I-D.ietf-spring-segment-routing;
&I-D.mirsky-bier-pmmm-oam;
&I-D.ooamdt-rtgwg-oam-gap-analysis;
&I-D.kumarzheng-bier-ping;
&I-D.mirsky-bier-path-mtu-discovery;
&I-D.ooamdt-rtgwg-ooam-requirement;
&I-D.ietf-bier-mpls-encapsulation;
<reference anchor="ST20227"
target="https://www.smpte.org/digital-library">
<front>
<title>Seamless Protection Switching of SMPTE ST 2022 IP Datagrams</title>
<author>
<organization>SMPTE 2022</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="ST" value="2022-7:2013"/>
</reference>
<reference anchor="IEEE8021CB"
target="http://www.ieee802.org/1/files/private/cb-drafts/d2/802-1CB-d2-1.pdf">
<front>
<title>Draft Standard for Local and metropolitan area networks - Seamless Redundancy</title>
<author initials="N. F." surname="Finn" fullname="Norman Finn">
<organization>IEEE 802.1</organization>
</author>
<date month="December" year="2015"/>
</front>
<seriesInfo name="IEEE P802.1CB /D2.1" value="P802.1CB"/>
<format type="PDF" target="http://www.ieee802.org/1/files/private/cb-drafts/d2/802-1CB-d2-1.pdf"/>
</reference>
<reference anchor="IEEE802.1Qca"
target="https://standards.ieee.org/findstds/standard/802.1Qca-2015.html">
<front>
<title>IEEE 802.1Qca Bridges and Bridged Networks - Amendment 24: Path Control and Reservation</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date month="June" year="2015"/>
</front>
<seriesInfo name="IEEE P802.1Qca/D2.1" value="P802.1Qca"/>
<format type="PDF" target="http://www.ieee802.org/1/files/private/ca-drafts/d2/802-1Qca-d2-1.pdf"/>
</reference>
</references>
<section title="Examples of combined DetNet Service and Transport layers" anchor="sec_comb">
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:08:41 |