DetNet B. Varga, Ed.
Internet-Draft J. Farkas
Intended status: Standards Track Ericsson
Expires: May 4, 2017 October 31, 2016
DetNet Service Modeldraft-varga-detnet-service-model-01
Abstract
This document describes service model for scenarios requiring
deterministic networking.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Varga & Farkas Expires May 4, 2017 [Page 1]

Internet-Draft DetNet Service Model October 20162. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The lowercase forms with an initial capital "Must", "Must Not",
"Shall", "Shall Not", "Should", "Should Not", "May", and "Optional"
in this document are to be interpreted in the sense defined in
[RFC2119], but are used where the normative behavior is defined in
documents published by SDOs other than the IETF.
3. Terminology and Definitions
Additional terms to [I-D.ietf-detnet-architecture] used in this
draft.
DetLink: Direct link between two entities (node/end system) used for
deterministic transport.
DetNet flow: A DetNet flow is a sequence of packets to which the
DetNet service is to be provided, see
[I-D.ietf-detnet-architecture]. This document distinguishes the
following three formats of DetNet flows:
App-flow: An App-flow is a data flow between the applications
requiring deterministic service. An App-flow does not contain
any DetNet related attributes.
DetNet-s-flow: A DetNet-s-flow is an App-flow extended with some
DetNet service layer attributes.
DetNet-st-flow: A DetNet-st-flow is an App-flow extended with
both DetNet service layer and DetNet transport layer
attributes, i.e., encapsulated according to the forwarding
paradigm of the DetNet domain.
DetNet-NNI: NNI between DetNet domains.
DetNet-UNI: UNI of a DetNet edge node to provide DetNet service for
a connected node or end system.
DetNetwork: Transport network between DetNet-st-flow endpoints.
Varga & Farkas Expires May 4, 2017 [Page 3]

Internet-Draft DetNet Service Model October 20164. End systems connected to DetNet
Deterministic connectivity service is required by time/loss sensitive
application(s) running on an end system during communication with its
peer(s). Such a data exchange has various requirements on delay and/
or loss parameters.
A DetNet flow [I-D.ietf-detnet-architecture] can have different
formats during while it is transported between the peer end systems.
Therefore, the following possible formats of a DetNet flow are
distinguished in this document:
o App-flow: native format of a DetNet flow. It does not contain any
DetNet related attributes.
o DetNet-s-flow: specific format of a DetNet flow. It is an App-
flow extended with some DetNet service related attributes (i.e.,
Flow-ID and/or Seq-num).
o DetNet-st-flow: specific format of a DetNet flow. It is an App-
flow extended with both DetNet service layer and DetNet transport
layer attributes, i.e., encapsulated according to the forwarding
paradigm of the DetNet domain.
App-flow and DetNet-s-flow are generated by end systems. DetNet-st-
flow can be generated by a DetNet edge node or an end system that is
an integral part of a DetNet domain. Further details are described
below. This document uses the exact DetNet flow type where it is
important to distinguish the flow type; otherwise, the generic term,
i.e., DetNet flow is used.
The native data flow between the source/destination end systems is
referred to as application-flow (App-flow) as shown in Figure 1. The
traffic characteristics of an App-flow can be CBR (constant bit rate)
or VBR (variable bit rate) and can have L1 or L2 or L3 encapsulation
(e.g., TDM (time-division multiplexing), Ethernet, IP).
[Note: Interworking function for L1 application-flows is out-of-scope
in this document, therefore, not depicted in figures.]
Varga & Farkas Expires May 4, 2017 [Page 4]

Internet-Draft DetNet Service Model October 2016
+-----------+ +-----------+
/ Application \<---native data flow--->/ Application \
|-------------| (App-flow) +-------------+
| End | | End |
| System | | System |
| -------- | | -------- |
| | NIC | | | | NIC | |
+-----+-------+ +-------+-----+
| ____ ____ |
| __/ \_____/ \____ |
| / \ |
+--------| DetNet |-----+
\ Networking /
\ ___ __ _/
\__/ \___/ \____/
Figure 1: End systems connected to DetNet
An end system may or may not be DetNet transport layer aware or
DetNet service layer aware, see [I-D.ietf-detnet-architecture]. That
is, an end system may or may not contain DetNet specific
functionality. End systems with DetNet functionalities may have the
same or different transport layer as the connected DetNet domain.
Grouping of end systems are shown in Figure 2. (Note: A "TSN end
system" of [I-D.ietf-detnet-dp-alt] is an example for a "DetNet
unaware end system".)
+---------------------------------------+
No DetNet | DetNet unaware |
functions | end system |
+-------------------+-------------------+
With DetNet | DetNet aware | DetNet |
Functions | end system | end system |
+-------------------+-------------------+
Some DetNet DetNet Service
Service Layer and Transport Layer
Figure 2: Grouping of end systems
End system(s) may or may not be directly connected to the DetNet
transport network. This document assumes direct connection in the
remaining part. The end system types are:
o A "DetNet unaware end system" originates a native data flow (App-
flow). Such end systems usually assume dedicated (and direct)
connectivity to their peers, which is replaced by the DetNet
Varga & Farkas Expires May 4, 2017 [Page 5]

Internet-Draft DetNet Service Model October 2016
network. Its connection to a DetNet network requires a DetNet
edge node, that creates a DetNet-st-flow (with proper Flow-ID and
Seq-num attributes) by encapsulating the native data flow
according to the forwarding paradigm of the connected DetNet
domain.
o A "DetNet aware end system" may contain some DetNet specific
service functionalities and it extends the App-flow with related
DetNet specific flow attributes (i.e., Flow-ID and/or Seq-num).
The resulting flow is referred to as DetNet-s-flow as it contains
service layer specific fields, but the format of the DetNet-s-flow
encapsulation is not identical with the forwarding paradigm (i.e.,
the transport layer) of the DetNet domain. Therefore, it has to
be connected to a DetNet edge node. DetNet aware end systems can
be, e.g., an IP end system with some DetNet service functions
connected to an MPLS-based DetNet domain.
o A "DetNet end node" has DetNet functionalities and the same
forwarding paradigm as the connected DetNet domain. It can be
treated as an integral part of the DetNet domain, therefore, it is
connected to a DetNet relay node (or to a DetNet transit node).
It originates a DetNet-st-flow (i.e., the App-flow is extended
within the end system with all the DetNet specific flow attributes
used inside the DetNet domain).
These end systems are shown in Figure 3. A DetNet-UNI ("U" on
Figure 3) is assumed in this document to be a packet-based reference
point and provides connectivity over the DetNet domain. A DetNet-UNI
may add forwarding technology specific encapsulation to the App-flow
/ DetNet-s-flow and transport it as a DetNet-st-flow over the
network.
Varga & Farkas Expires May 4, 2017 [Page 6]

Internet-Draft DetNet Service Model October 2016
DetNet unaware DetNet aware
end system end system
_ _
/ \ / \
/App\ /App\
/--O--\<-----App-flow-- /-(O)-\
| | |--V--|<--DetNet-s-flow--
| NIC | <-DetNet-st-flow- | NIC | <-DetNet-st-flow-
+--+--+ +----+ +--+--+ +----+
| | |T-PE| | | |T-PE|
+--------U +- +--------U +-
| | | | | |
| +----+ | +----+
Attachment Edge Attachment Edge
Circuit Node Circuit Node
DetNet
end system
_
/ \
/App\
/-(O)-\
|--W--|<--DetNet-st-flow--
| NIC |
+--+--+ +----+
| | |S-PE|
+--------+ +-
| | |
| +----+
Internal Relay
Link Node
Figure 3: Types of end systems
[Note: DetNet aware end systems can be also treated as a special mix
of a DetNet unaware system and a DetNet end system. It is similar to
a DetNet end system as its data flow contains DetNet attributes,
however, those attributes cannot be used directly inside the DetNet
domain, e.g., due to the different transport layer. Therefore, it is
also similar to DetNet unaware end systems as it must be connected to
a DetNet edge node to adapt, e.g., the encapsulation of the DetNet
flow to the forwarding paradigm of the DetNet domain. A typical
example showing a DetNet aware end system can be the following
scenario: an end system encapsulates its App-flow in IP-RTP packets.
It assumes a single connection to its peer, therefore, the Seq-num
field is not used by the end-system. It is connected to an MPLS-
Varga & Farkas Expires May 4, 2017 [Page 7]

Internet-Draft DetNet Service Model October 2016
based DetNet domain that has redundant paths and applies service
protection via the duplication and elimination functionality. As per
[I-D.ietf-detnet-architecture], the addition or removal of packet
sequencing information is the job of a DetNet edge node. As
forwarding is MPLS-based, the Seq-num required for service protection
is created and added to the DetNet-s-flow by the DetNet edge node (in
the PW control-word field).]
5. DetNet service model5.1. Service parameters
The DetNet service can be defined as a service that provides a
capability to carry a unicast or a multicast data flow for an
application with constrained requirements on network performance,
e.g., low packet loss rate and/or latency.
Delay and loss parameters are somewhat correlated because the effect
of late delivery can be equivalent to loss. However, not all
applications require hard limits on both parameters (delay and loss).
For example, some real-time applications allow graceful degradation
if loss happens (e.g., sample-based processing, media distribution).
Some others may require high-bandwidth connections that make the
usage of techniques like flow duplication economically challenging or
even impossible. Some applications may not tolerate loss, but are
not delay sensitive (e.g., bufferless sensors).
Primary transport service attributes for DetNet transport are:
o Bandwidth parameter(s),
o Delay parameter(s),
o Loss parameter(s),
o Connectivity type.
Time/loss sensitive applications may have somewhat special
requirements especially for loss (e.g., no loss in two consecutive
communication cycles; very low outage time, etc.).
Two connectivity types are distinguished: point-to-point (p2p) and
point-to-multipoint (p2mp). Connectivity type p2mp is created by a
transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity
is a superposition of p2mp connections.)
Varga & Farkas Expires May 4, 2017 [Page 8]

Internet-Draft DetNet Service Model October 2016
o DetNet-st-flow endpoint: DetNet edge node UNI ("U") or DetNet end
system's internal reference point ("W").
o DetNet-UNI: UNI interface ("U") on a DetNet edge node.
o DetNet-NNI: NNI interface ("N") between DetNet domains.
Data flow endpoints ("O", "V" and "W" in Figure 4 and Figure 5) are
more challenging from control perspective as they are internal
reference points of end systems. They are providing access to
deterministic transport for the native data flow (App-flow).
DetNet-UNI and DetNet-NNI ("U" and "N" in Figure 4) are assumed in
this document to be packet-based reference points and provide
connectivity over the packet network and between domains. A DetNet-
UNI adds networking technology specific encapsulation to the App-flow
/ DetNet-s-flow in order to transport it as a DetNet-st-flow over the
network. There are many similarities regarding the functions of a
DetNet-st-flow endpoint ("W") and a DetNet-UNI ("U") but there may be
some differences. For example, in-order delivery is expected in end
system internal reference points, whereas it is considered optional
over the DetNet-UNI.
5.4. Service scenarios
Using the above defined reference points, two major service scenarios
can be identified:
o End-to-End-Service: the service reaches out to final source or
destination nodes, so it is an e2e service between application
hosting devices (end systems).
o DetNet-Service: the service connects networking islands, so it is
a service between the borders of network domain(s).
End-to-End-Service is defined between App-flow endpoints, whereas
DetNet-Service is between DetNet-st-flow endpoints. This allows the
peering of same layers/functions.
5.5. Data flows
Three possible DetNet flow formats are distinguished for unambiguous
references:
o App-flow: data flow requiring deterministic transport between two
App-flow endpoints; data format is application specific (e.g., bit
stream directly mapped to Ethernet frames, etc.). It does not
contain any DetNet attributes.
Varga & Farkas Expires May 4, 2017 [Page 11]

Internet-Draft DetNet Service Model October 2016
o DetNet-s-flow: similar to the App-flow, but extended with some
DetNet attributes as DetNet aware end systems have some DetNet
service layer functionalities. However, the encapsulation format
differs from the forwarding paradigm of the connected DetNet
domain, so those attributes cannot be used directly.
o DetNet-st-flow: data flow between DetNet-UNIs ("U") and/or DetNet
end systems ("W"). This flow is extended with both DetNet service
layer and DetNet transport layer attributes. This format allows
simple flow recognition/transport/etc. during forwarding in the
DetNet domain.
5.6. Service components/segments
The follwoing building blocks are used as reference to service
components/segments:
o DetLink: direct link between two entities (node/end system) used
for deterministic transport.
o DetNetwork: network between DetNet nodes.
Any DetNet service scenario can be described using DetLink and
DetNetwork components/segments. For example, the service between the
App-flow endpoints in Figure 4 can be composed as a DetLink-1
(between the end system on the left and the edge node of Domain-1) +
DetNetwork-1 (of Domain-1) + DetLink-2 (between Domain-1 and Domain-
2) + DetNetwork-2 (of Domain-2) + DetLink-3 (between edge node of
Domain-2 and the end system on the right).
6. DetNet service instances6.1. Attributes used by DetNet functions
The three DetNet functions (congestion protection, explicit routes,
service protection) require two data flow related attributes to work
properly:
o Flow-ID and
o Sequence number (Seq-Num).
These attributes are extracted from the ingress packets of the node
[I-D.ietf-detnet-architecture]. Flow-ID is used by all the three
DetNet functions, but sequence number is used only by the duplicate
elimination functionality.
Varga & Farkas Expires May 4, 2017 [Page 12]

Internet-Draft DetNet Service Model October 2016
Flow-ID must be unique per network domain. Its encoding format is
specific to the forwarding paradigm of the domain and to the
capabilities of intermediate nodes to identify data flows. For
example, in case of "PW over MPLS", one option is to construct the
Flow-ID by the PW label and the LSP label (denoted as [PW-label;LSP-
label]). In such a case, intermediate P nodes have to check all
labels to identify a DetNet flow, what may not be a valid option in
some deployment scenarios. Another possible option is to use a
dedicated LSP per data flow, so the LSP label itself can be used as a
Flow-ID (denoted as [LSP-label]). In such a case, the intermediate P
nodes do not have to check the whole label stack to recognize a data
flow (DetNet flow), however, it results in larger L-FIB tables on the
MPLS nodes.
[Note: Seq-num requires a control-word in the label stack in MPLS
domains, which should be recognized by intermediate S-PE (relay)
nodes.]
6.2. Service instance for DetNet flows
The DetNet network reference model is shown in Figure 6 for a DetNet-
Service scenario (i.e. between two DetNet-UNIs). In this figure, the
end systems ("A" and "B") are connected directly to the edge nodes of
the PSN ("PE1" and "PE2"). End-systems participating DetNet
communication may require connectivity before setting up an App-flow
that requires the DetNet service. Such a service instance and the
one dedicated for DetNet service share the same attachment circuit.
Packets belonging to a DetNet flow are selected by a filter
configured on the attachment circuit ("F1" and "F2"). As a result,
data flow specific attachment circuits ("AC-A + F1" and "AC-B + F2")
are terminated in the flow specific service instance ("SI-1" and "SI-
2"). A PSN tunnel is used to provide connectivity between the
service instances. The encapsulation used over the PSN tunnel are
described in [I-D.ietf-detnet-dp-alt].
The PSN tunnel is used to transport exclusivelly the packets of the
DetNet flow between "SI-1" and "SI-2". The service instances are
configured to implement a flow specific routing or bridging function
depending on what connectivity the participating end systems require
(L3 or L2). The service instance and the PSN tunnel may or may not
be shared by multiple DetNet flows. Sharing the service istance by
multiple DetNet flows requires properly populated forwarding tables
of the service instance.
Serving regular traffic and DetNet flows by the same service instance
is out-of-scope in this draft, but some related thoughts are
described in Annex 1. Such a combination can provide the required
connectivity before setting up a DetNet service.
Varga & Farkas Expires May 4, 2017 [Page 13]

Internet-Draft DetNet Service Model October 2016
encoding function of technology border nodes (where forwarding
paradigm changes) to adapt to capabilities of the next hop node.
They push a further (forwarding paradigm specific) Flow-ID to packet
header ensuring that flows can be easily recognized by domain
internal nodes. This additional Flow-ID might be removed when the
packet leaves a given technology domain.
[Note: Seq-num attribute may require a similar functionality at
technology border nodes.]
The additional (domain specific) Flow-ID can be
o created by a domain specific function or
o derived from the Flow-ID added to the App-flow,
so that it must be unique inside the given domain. Note, that the
Flow-ID added to the App-flow is still present in the packet, but
transport nodes may lack the function to recognize it; that's why the
additional Flow-ID is added (pushed).
7.2. Flow-ID mapping examples
IP nodes and MPLS nodes are assumed to be configured to push such an
additional (domain specific) Flow-ID when sending traffic to an
Ethernet switch (as shown in the examples below).
Figure 7 shows a scenario where an IP end system ("IP-A") is
connected via two Ethernet switches ("ETH-n") to an IP router ("IP-
1").
Varga & Farkas Expires May 4, 2017 [Page 15]

Internet-Draft DetNet Service Model October 2016
Figure 9 shows a scenario where there is a DetNet flow between the
end systems ("A" and "B"). "SI-n" denotes the L2 VPN service
instance of "PEn". Regular traffic of the L2 VPN instance use "PW-
12", "PW-13" and "PW-23". However, for transport of DetNet traffic
between "A" and "B" a separate PW ("PW-AB") has to be used. "PW-AB"
is a somewhat special PW (called here "virtual PW") and it is treated
differently than PWs used by regular traffic (i.e., PW-13, PW-12, and
PW-23). Namely, "PW-AB" is used exclusivelly by the DetNet flow
between "A" and "B". "PW-AB" does not participate in flooding and no
MAC addresses are associated with it (not considered for the MAC
learning process). "PW-AB" may use the same LSP as "PW-13" or a
dedicated one.
Regular traffic between "A" and "B" has an encapsulation [PW-13_label
; LSP_label], whereas DetNet flow has [PW-AB_label ; LSP_label].
12.2. L3 service instance shared by regular and DetNet traffic
In case of a L3 DetNet service, the service instance implements
routing. In MPLS-based PSN, such a "routing service" can be provided
by IP VPNs ([RFC4364]). However, the IP VPN service adds only a
single label (VPN label) during forwarding, therefore, the label
stack does not contain a "control word" (i.e., there is no field to
encode a sequence number). Therefore, transport of DetNet flows
requires the combination of IP VPN and PW technologies.
Adding DetNet flows to the network results in a somewhat modified
label stack structure, as a DetNet flow requires its packet PW
encapsulation ([RFC6658]).
Varga & Farkas Expires May 4, 2017 [Page 19]

Internet-Draft DetNet Service Model October 2016
+---------+
| PE2|
| +----+ |
VPN-12 | |SI-2| |
+----------------+ | |
+-----|---+ | +-+--+ |
| +--+-+ | +---|-----+
"A" ------+ | | |
| |SI-1| | |
| +-+-++ | | VPN-23
|PE1 . | | |
+----.-|- + |
. | + --|-----+
. | VPN-13 | +-+--+ |
. +---------------+ | |
. | | +------ "B"
+.................+SI-3| |
PW-AB | +----+ |
| PE3|
+ --------+
Figure 10: DetNet L3 VPN Service
Figure 10 shows a scenario where there is a DetNet flow between the
end systems ("A" and "B"). "SI-n" denotes the L3 VPN service
instance of "PEn". Regular traffic of the L3 VPN instance use as
service label "VPN-12", "VPN-13" and "VPN-23". However, for
transport of DetNet traffic between "A" and "B" a PW ("PW-AB") has to
be used, what ensures that DetNet flow can be recognized by
intermediate P nodes and a control world can be also present. "PW-
AB" is used exclusivelly by the DetNet flow between "A" and "B".
"PW-AB" may use the same LSP as regular traffic (labeled by "VPN-13")
or a dedicated one.
Regular traffic between "A" and "B" has an encapsulation [VPN-
13_label ; LSP_label], whereas DetNet flow has [PW-AB_label ;
LSP_label].
13. Annex 2 - Integrating Layer 3 and Layer 2 QoS
Sophisticated QoS mechanisms are available in Layer 3 (L3), see,
e.g., [RFC7806] for an overview. Although, Layer 2 (L2) QoS and
queuing used to be simpler; it has been evolving, it is now equipped
with Time-Sensitive Networking (TSN) features [IEEE8021TSN]. The TSN
features may be beneficial or even essential for DetNet flows if
Layer 2 links or sub-networks are included in their path. Therefore,
it is worth investigating the problems arising when both Layer 3 and
Varga & Farkas Expires May 4, 2017 [Page 20]

Internet-Draft DetNet Service Model October 2016
Layer 2 QoS features are supported by a node; even without diving
deep into solution/implementation details.
In IEEE Std 802.1Q-2005, eight traffic classes are supported,
allowing separate queues for each priority as illustrated in
Figure 11. Any traffic class-based transmission selection algorithm
can be implemented in addition to the strict priority algorithm
mandated by IEEE Std 802.1Q-2005. The priority information is
encoded in the 3-bit field carried in a tag in the frame header.
Note that the IEEE 802.1Q architecture specifies queuing at the
output port; however, implementations may differ. Consequently, the
following figures only show the queuing at the output port that is
selected by the forwarding decision for the transmission of a frame.
| | | | |
+---v---+ +---v---+ +---v---+ +---v---+ +---v---+
| Queue | | Queue | | Queue | | Queue | | Queue |
| for | | for | | for | | for | ... | for |
|Traffic| |Traffic| |Traffic| |Traffic| |Traffic|
|Class 7| |Class 6| |Class 5| |Class 4| |Class 0|
+---+---+ +---+---+ +---+---+ +---+---+ +---+---+
| | | | |
+---v----------v----------v----------v-------------v---+
| Transmission Selection |
+--------------------------+---------------------------+
|
v
Figure 11: Queuing in IEEE 802.1Q-2005
The Layer 2 QoS architecture has been evolving, see, e.g., IEEE Std
802.1Q-2014 [IEEE8021Q], which specifies the Credit-Based Shaper
(originally specified by IEEE Std 802.1Qav). There are recent IEEE
802.3 and 802.1 standards and ongoing projects to enhance the QoS
supported by Ethernet and Layer 2 networks. For instance, frame
preemption is specified by IEEE Std 802.3br ([IEEE8023br], to be
amended to [IEEE8023]) and IEEE Std 802.1Qbu ([IEEE8021Qbu], to be
amended to [IEEE8021Q]) where time-critical (express) frames can
suspend the transmission of non-time-critical (preemptable) frames
while one or more time-critical frames are transmitted. Another
recently published specification is IEEE Std 802.1Qbv [IEEE8021Qbv],
which specifies time-aware queue-draining controlled by transmission
gates in order to schedule the transmission of frames relative to a
known timescale, which can be provided by time synchronization. The
architecture extended with time-aware queuing and frame preemption is
illustrated in Figure 12. These time-sensitive networking extensions
provide deterministic behavior in Layer 2 networks. The ongoing IEEE
802.1 projects provide further extensions to the QoS architecture,
Varga & Farkas Expires May 4, 2017 [Page 21]

Internet-Draft DetNet Service Model October 2016
flow to leverage TSN features in a Layer 2 sub-network in order to
meet the DetNet flow's requirements, which may be spoiled otherwise.
Figure 13 provides a theoretical illustration for the integration of
the Layer 3 and Layer 2 QoS architecture. The figure only shows the
queuing after the routing decision. The figure also illustrates
potential implementation dependent borders (Brdr). The borders shown
in the figure are critical in the sense that the high priority DetNet
flows have to be transferred via a different Service Access Points
(SAPs) through these borders than the low priority (background)
flows. Having a single SAP for these very different traffic types
may result in possible QoS degradation for the DetNet flows because
packets of other flows could delay the transmission of DetNet
packets. For instance, different SAPs are needed for the DetNet
flows and other flows when they get to Layer 3 queuing after the
routing decision via Brdr-d. Furthermore, a different SAP is needed
for DetNet packets than other packets when they get to Layer 2
queuing from Layer 3 queuing via Brdr-c. Similarly, different SAPs
are needed for the express and for the preemptable frames when they
get to the MAC layer from Layer 2 queuing via Brdr-b, which is
provided by the IEEE 802.1Q architecture as shown in Figure 12. It
depends on the implementation whether or not Brdr-a exists.
Varga & Farkas Expires May 4, 2017 [Page 23]

Internet-Draft DetNet Service Model October 2016
Not all the functions depicted in Figure 13 are necessarily present
in an implementation. A function may be combined with another one or
may be completely missing. For instance, it may be the case that
there is no Layer 3 queuing for DetNet packets, but they get directly
to the Layer 2 queues. Alternatively, an implementation may combine
the Layer 3 queues and the Layer 2 queues such that there is a single
level of queues. There are further alternatives in addition to the
ones mentioned here.
Different implementation approaches, i.e., different node designs are
illustrated in Figure 14 and Figure 15. Figure 14 illustrates a
monolithic node design where there is a single feature rich chip and
relatively simple interfaces. The single chip implements all routing
(and/or bridging) features as well as almost all QoS features. (Some
aspects of frame preemption may be implemented on the interface.)
Figure 15 illustrates a linecard-based design where each linecard has
its own chip, which implements routing and QoS features.
+---------+ +----------------+ +---------+
|Interface| | | |Interface|
+---------+ | | +---------+
| |
+---------+ | | +---------+
|Interface| | | |Interface|
+---------+ | | +---------+
| Chip |
. | | .
. | | .
. | | .
| |
+---------+ | | +---------+
|Interface| | | |Interface|
+---------+ +----------------+ +---------+
Figure 14: Monolithic node design
Varga & Farkas Expires May 4, 2017 [Page 25]