Internet DRAFT - draft-dt-detnet-dp-alt
draft-dt-detnet-dp-alt
DetNet J. Korhonen, Ed.
Internet-Draft Broadcom
Intended status: Informational J. Farkas
Expires: September 22, 2016 G. Mirsky
Ericsson
P. Thubert
Cisco
Y. Zhuang
Huawei
L. Berger
LabN
March 21, 2016
DetNet Data Plane Protocol and Solution Alternatives
draft-dt-detnet-dp-alt-00
Abstract
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.
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 September 22, 2016.
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
Korhonen, et al. Expires September 22, 2016 [Page 1]
Internet-Draft DetNet data plane alternatives March 2016
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 3
3. Criteria for data plane solution alternatives . . . . . . . . 6
3.1. #? DetNet Service Interface . . . . . . . . . . . . . . . 6
3.2. #1 Encapsulation and overhead . . . . . . . . . . . . . . 7
3.3. #2 Flow identification . . . . . . . . . . . . . . . . . 7
3.4. #3 Packet sequencing . . . . . . . . . . . . . . . . . . 7
3.5. #4 Explicit routes . . . . . . . . . . . . . . . . . . . 8
3.6. #5 Packet replication and deletion . . . . . . . . . . . 8
3.7. #6 Operations, Administration and Maintenance . . . . . . 9
3.8. #7 Time synchronization . . . . . . . . . . . . . . . . . 9
3.9. #8 Class and quality of service capabilities . . . . . . 9
3.10. #9 Packet traceability . . . . . . . . . . . . . . . . . 10
3.11. #10 Technical maturity . . . . . . . . . . . . . . . . . 10
4. Data plane solution alternatives . . . . . . . . . . . . . . 11
4.1. DetNet Transport layer technologies . . . . . . . . . . . 11
4.1.1. Native IPv6 transport . . . . . . . . . . . . . . . . 11
4.1.2. Native IPv4 transport . . . . . . . . . . . . . . . . 14
4.1.3. Multiprotocol Label Switching (MPLS) . . . . . . . . 16
4.2. DetNet Service layer technologies . . . . . . . . . . . . 21
4.2.1. Generic Routing Encapsulation (GRE) . . . . . . . . . 21
4.2.2. Layer-2 Tunneling Protocol (L2TP) . . . . . . . . . . 24
4.2.3. Virtual Extensible LAN (VXLAN) . . . . . . . . . . . 24
4.2.4. MPLS-based Services . . . . . . . . . . . . . . . . . 24
4.2.5. Pseudo Wire Emulation Edge-to-Edge (PWE3) . . . . . . 26
4.2.6. MPLS-Based Ethernet VPN (EVPN) . . . . . . . . . . . 30
4.2.7. Bit Indexed Explicit Replication (BIER) . . . . . . . 33
4.2.8. Higher layer header fields . . . . . . . . . . . . . 41
5. Summary of data plane alternatives . . . . . . . . . . . . . 42
6. Security considerations . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Informative References . . . . . . . . . . . . . . . . . 43
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Appendix A. Examples of combined DetNet Service and Transport
layers . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
Korhonen, et al. Expires September 22, 2016 [Page 2]
Internet-Draft DetNet data plane alternatives March 2016
1. Introduction
Deterministic Networking (DetNet) [I-D.finn-detnet-problem-statement]
provides a capability to carry unicast or multicast data flows for
real-time applications with extremely low data loss rates and known
upper bound maximum latency [I-D.finn-detnet-architecture]. The
deterministic networking Quality of Service (QoS) is expressed as 1)
the maximum end-to-end latency from sender (talker) to receiver
(listener), and 2) probability of loss of a packet. Only the worst-
case values for the mentioned parameters are concerned.
There are three techniques to achieve the QoS required by
deterministic networks:
o zero congestion loss,
o explicit routes,
o packet replication and deletion.
This document identifies existing IP and Multiprotocol Label
Switching (MPLS) [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 Section 3.
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.
2. DetNet Data Plane Overview
[Editor's note: all/portions of the following may be moved to the
DetNet Architecture document at some future point.]
A "Deterministic Network" will be composed of DetNet enabled "End
Systems", DetNet enabled "Edge Nodes", and DetNet enabled "Network
Nodes". DetNet enabled nodes will provide a DetNet service to
attached DetNet End Systems. All DetNet enabled systems and nodes
will be interconnected by sub-networks. These sub-networks will
provide DetNet compatible service for support of DetNet traffic.
Examples of sub-networks include 802.1TSN and a point-to-point OTN
link. Of course, multi-layer DetNet systems may be possible too,
Korhonen, et al. Expires September 22, 2016 [Page 3]
Internet-Draft DetNet data plane alternatives March 2016
where one DetNet appears as a sub-network, and provides service to, a
higher layer DetNet system. A simple DetNet is shown in Figure 1.
+------+ +------+
| End |<-------------Deterministic flow--------------->| End |
|System| |System|
+--+---+ +-+----+
| <--------------DetNet flow-----------------> |
| ,+-''''--.
| [ Sub ]
|Link [ Network ]
| +-....--'
| |
| +------+ +-------+ ,-'''-. +-------+ +------+
| | Edge |Link |Network|--[ Sub ]--|Network|--| Edge |
+----| Node |-----| Node | [Network] | Node | | Node |
+------+ +-------+ +-...-' +-------+ +------+
Figure 1: A Simple DetNet Enabled Network
This DetNet data plane is logically divided into two layers:
o The DetNet Service layer provides adaptation of DetNet services.
It is composed of a shim layer to carry DetNet flow specific
attributes, which are needed during forwarding. End systems
originate and terminate the DetNet Service layer and are peers at
the DetNet Service layer.
o The DetNet Transport layer is supported by all DetNet aware
systems and nodes. It operates below the DetNet Service layer.
The DetNet Transport layer is used to relay traffic end to end
across a DetNet domain.
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.
A number of data plane technology candidates are discussed later in
this document. They can be mapped to the two layers as shown in
Figure 2.
Korhonen, et al. Expires September 22, 2016 [Page 4]
Internet-Draft DetNet data plane alternatives March 2016
.
.
.
+-----------+
| Service | PW, RTP, UDP, GRE, L2TP, VXLAN
~~~~~~~~~~~~~
| Transport | IPv6, IPv4, MPLS LSPs, BIER, BIER-TE
+-----------+
.
.
Figure 2: DetNet adaptation to data plane
Both the DetNet Service and the DetNet Transport layers are provided
by a single technology in some solutions, e.g. the DetNet Service
layer is PW and the DetNet Transport layer is MPLS in case of PW over
MPLS. Nonetheless, both the DetNet Service and the DetNet Transport
layers can include multiple technology layers in other solutions in
order to provide the capabilities needed for DetNet flows. For
instance, the DetNet Transport layer can comprise MPLS-in-GRE
(Section 4.2.5) in one solution. In another solution, the DetNet
Service layer can include, e.g., RTP in UDP (Section 4.2.8).
[Editor's note: I'm not sure if the remainder of this section says
anything not present in the next section. Will need to revisit as
part of the pre-pub review.]
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 Section 3. Different
criteria apply for the DetNet Service layer and the DetNet Transport
layer, however, some of the criteria are valid for both layers.
The criteria for the DetNet Service layer:
#1 Encapsulation and overhead
#2 Flow identification (Flow ID part of the DetNet flows)
#3 Packet sequencing (sequence number)
#5 Packet replication and deletion (note: only the packet deletion
for seamless redundancy)
#6 Operations, Administration and Maintenance (capabilities)
#7 Time synchronization (e.g., time stamping)
#8 Class and quality of service capabilities (DetNet Service
specific)
#10 Technical maturity
Korhonen, et al. Expires September 22, 2016 [Page 5]
Internet-Draft DetNet data plane alternatives March 2016
The criteria for the DetNet Transport layer:
#1 Encapsulation and overhead
#2 Flow identification
#4 Explicit routes (network path)
#5 Packet replication and deletion (note: only the packet
replication for seamless redundancy)
#6 Operations, Administration and Maintenance (capabilities)
#7 Time synchronization (time/phase sync of nodes)
#8 Class and quality of service capabilities (DetNet Transport
specific)
#9 Packet traceability (verification purposes)
#10 Technical maturity
[Editor's note: #7 is more of OAM feature.]
Some of the criteria are relevant for both the DetNet Service and
DetNet Transport layers. The two layers provide together what is
needed to meet certain criteria, e.g., flow identification.
Different aspects are valid for the two different layers for other
criteria, e.g., time synchronization. Furthermore, technical
maturity is a criteria valid for both layers.
3. Criteria for data plane solution alternatives
This section provides criteria to help to evaluate potential options.
The criteria can be broken down based on layer. That is if the
criteria is focused on delivering DetNet service adaptation, i.e., is
concerned with the DetNet Service layer, or if the criteria is
focused on transporting flows across an end to end DetNet domain.
[Editor's note: which is TBD.]
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.
3.1. #? DetNet Service Interface
[Editor's note: this criteria needs a bit more discussion.]
One of the most fundamental differences between different potential
data plane options is the basic addressing and headers used by DetNet
clients. 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 points are addressed, and the basic forwarding logic of
the DetNet Service layer.
Korhonen, et al. Expires September 22, 2016 [Page 6]
Internet-Draft DetNet data plane alternatives March 2016
3.2. #1 Encapsulation and overhead
Encapsulation and overhead is related to how the DetNet data plane
carries DetNet user traffic. In several cases a deterministic 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 former 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 talkers and
listeners 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 of the
processing and specifically the encapsulate header overhead.
3.3. #2 Flow identification
The solution alternative has to provide means to identify specific
deterministic flows. The flow identification can, for example, be
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.
3.4. #3 Packet sequencing
[Editor's note: is in order delivery a strict requirement? if so, it
should be stated as such and separately from any other requirement.
There are multiple ways to solve this criteria.]
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
packets one of the important uses for sequencing is detecting
duplicates. In a case of intentional packet duplication a
combination of flow identification and packet sequencing allows for
detecting and discarding duplicates at the receiver (see Section 3.6
for more details). This criteria concerns the availability and
details of the packet sequencing capabilities the data plane protocol
alternative has.
Korhonen, et al. Expires September 22, 2016 [Page 7]
Internet-Draft DetNet data plane alternatives March 2016
3.5. #4 Explicit routes
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 [RFC3209] supports explicit routes, and typically provides
pinned data paths for established LSPs. At Layer-2, the IEEE
802.1Qca [IEEE8021Qca] specification defines how to do explicit path
control in a bridged network and its IETF counter part is defined in
[I-D.ietf-isis-pcr]. This criteria concerns the available mechanisms
for explicit routes for the data plane protocol alternative.
3.6. #5 Packet replication and deletion
The objective for supporting packet replication and deletion is to
enable hitless (or lossless) 1+1 protection, which is also called
Seamless redundancy in [I-D.finn-detnet-architecture]. Data plane
solutions need to meet this objective independent of the particular
solution used. In other words, a packet replication and deletion is
one identified method for a data plane solution to provide seamless
redundancy and other methods, if so identified, are permissible.
The solution alternative has to provide means for end systems and/or
relay systems to be able to replicate packets, and later eliminate
all but one of the replicas, 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 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.
Another concern regarding packet replication is how to enforce
replicated packets to take different route 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.
[Editor's note: at the DetNet Transport layer this criteria does not
concern packet deletion, only the packet replication. The packet
deletion belongs to the DetNet Service layer]
Korhonen, et al. Expires September 22, 2016 [Page 8]
Internet-Draft DetNet data plane alternatives March 2016
The IEEE 802.1CB [IEEE8021CB] is an example of Ethernet-based
solution that defines packet sequence numbering, packet replication,
and duplicate packet identification and deletion. 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.
3.7. #6 Operations, Administration and Maintenance
The solution alternative should demonstrate an 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.
3.8. #7 Time synchronization
Time synchronization between DetNet systems and nodes can be used to
enable fine grain scheduling of traffic along an end-to-end data
path. Such scheduling can be used to deliver very low jitter and
latency. [DetNet-ARCH] refers to a synchronization target of less
than 1 microsecond. Meeting such time synchronization objectives is
likely to require specific hardware support, both at the
synchronization protocol level and at the (time synchronized) packet
scheduling level. It is worth noting that certain aspects of time
synchronization and packet scheduling may be provided by the
underlying sub-net technology, e.g., [IEEE802.1Qbv] and
[IEEE802.1Qch].
3.9. #8 Class and quality of service capabilities
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 [RFC2474] and MPLS label traffic class field
[RFC5462], and at Layer-2, by IEEE 802.1p priority code point (PCP).
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,
Korhonen, et al. Expires September 22, 2016 [Page 9]
Internet-Draft DetNet data plane alternatives March 2016
flow identification and isolation, and sometimes path control,
traffic protection, shaping, policing and remarking. Example
protocols that support QoS control include Resource ReSerVation
Protocol [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473].
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.
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.
Hereto, 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).
3.10. #9 Packet traceability
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 trace is a
form of OAM.
3.11. #10 Technical maturity
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 repurposing/
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.
Korhonen, et al. Expires September 22, 2016 [Page 10]
Internet-Draft DetNet data plane alternatives March 2016
4. Data plane solution alternatives
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 Section 3 and
rated using the following: (M)eets the criteria, (W)ork needed, and
(N)ot suitable or too much work envisioned.
4.1. DetNet Transport layer technologies
4.1.1. Native IPv6 transport
4.1.1.1. Solution description
This section investigates the application of native IPv6 [RFC2460] as
the data plane for deterministic networking along the criteria
collected in Section 3.
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
Section 4.2.8.
4.1.1.2. Analysis and Discussion
Encapsulation and overhead (M/W)
The DetNet Service layer encapsulated DetNet flows are assumed to
be handled natively at layer-3 by IPv6 at the first place. The
fixed header of an IPv6 packet is 40 bytes [RFC2460]. This
overhead is bigger if any Extension Header is used, and a generic
behaviour for host and forwarding nodes is specified in [RFC7045].
However, the exact overhead (Section 3.2) depends on what solution
is actually used to provide DetNet features, e.g., explicit
routing or seamless redundancy if any of these is applied.
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.
Korhonen, et al. Expires September 22, 2016 [Page 11]
Internet-Draft DetNet data plane alternatives March 2016
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 [I-D.ietf-6man-rfc2460bis] (e.g. punt packets from
hardware to software forwarding which is highly detrimental to the
performance).
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 [RFC6564].
Flow identification (M/W)
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 [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.
Alternatively, the Flow identification could be transported in a
new option in the Hop-by-Hop Options Header.
Explicit routes (W)
The general assumption is that a Software-Defined Networking (SDN)
[RFC7426] based approach is applied to compute, establish and
manage the explicit routes, leveraging Traffic Engineering (TE)
extensions to routing protocols [RFC5305]
[I-D.ietf-idr-ls-distribution] and evolving to the Path
Computation Element (PCE) Architecture [RFC5440], though a number
of issues remain to be solved [RFC7399].
Segment Routing (SR) [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
Korhonen, et al. Expires September 22, 2016 [Page 12]
Internet-Draft DetNet data plane alternatives March 2016
[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.
Another concern regarding packet replication is how to enforce
replicated packets to take different route 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.
Packet replication (W) 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,
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 elimination point for that
particular replica of the packet, in a strict or in a loose source
routing fashion. An elimination point would pop the routing
headers from the various copies it gets and forward or receive the
packet if it is the final destination.
Operations, Administration and Maintenance (M/W)
IPv6 enjoys the existing toolbox for generic IP network
management. However, IPv6 specific management features are still
not at the level of that IPv4 has. This specifically concerns the
areas 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 largely only an issue with old existing
equipment.
Class and quality of service capabilities (M)
The traffic class field of the fixed IPv6 header is designed for
this purpose.
Packet traceability (M/W/N)
Korhonen, et al. Expires September 22, 2016 [Page 13]
Internet-Draft DetNet data plane alternatives March 2016
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 [RFC6275] and then use the address of the
replication point as source in the IP header.
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
[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.
Technical maturity (M/W)
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 there are
number of small issues to work on as they show up once operations
experience grows.
The Cisco 6Lab site [1] 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 Google
Statistics [2] is now above 10 percent.
4.1.1.3. Summary
TBD.
4.1.2. Native IPv4 transport
Korhonen, et al. Expires September 22, 2016 [Page 14]
Internet-Draft DetNet data plane alternatives March 2016
4.1.2.1. Solution description
IPv4 [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 [I-D.ietf-v6ops-ipv6-ehs-in-real-world]. IPv4
never really needed any extension headers to work properly, thus
support for IPv4 options outside closed networks cannot typically be
guaranteed. 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.
4.1.2.2. Analysis and Discussion
Encapsulation and overhead (M)
The fixed header of an IPv4 packet is 20 bytes [RFC0791]. IP
options add overhead and the maximum IPv4 header size if 60 octets
leaving only 40 octets for possible options.
Flow identification (W/N)
The IPv4 header has a 16-bit identification field that was
originally intended for assisting fragmentation and reassembly of
IPv4 packets as described in [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 [RFC1122]. However, recent update
[RFC6864] to both [RFC0791] and [RFC1122] restricts the use of
IPv4 identification field only to fragmentation purposes.
The IPv4 also has a stream identifier option [RFC0791], which
contains a 16-bit SATNET stream identifier. However, the option
has been deprecated [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. For a working solution upper layer
protocol headers such as the RTP are required for unambiguous flow
identification.
Explicit routes (M/W)
IPv4 has two source routing option specified: the loose source and
record route option (LSRR), and the strict source and record route
option (SSRR) [RFC0791]. The support of these options in the
Korhonen, et al. Expires September 22, 2016 [Page 15]
Internet-Draft DetNet data plane alternatives March 2016
Internet is questionable but within a closed network the support
may be assumed.
Packet replication (W/N)
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 [RFC6621] to a great detail in
the context of simplified multicast forwarding.
Operations, Administration and Maintenance (M)
IPv4 enjoys the extensive and "complete" existing toolbox for
generic IP network management.
Class and quality of service capabilities (M)
The type of service (TOS) field of the fixed IPv4 header is
designed for this purpose.
Packet traceability (W/N)
The IPv4 has a traceroute option [RFC1393] that could be used to
record the route the packet took. However, the option has been
deprecated [RFC6814]. Similarly to IPv6 new work would be needed
to allow better traceability of IPv4 packets.
Technical maturity (M/W)
IPv4 can be considered mature technology with over 30 years of
implementation, deployment and operations experience. However, no
new IPv4 standards development is "allowed" anymore
[RFC6540][I-D.ietf-sunset4-gapanalysis].
4.1.2.3. Summary
TBD.
4.1.3. Multiprotocol Label Switching (MPLS)
4.1.3.1. Solution description
Multiprotocol Label Switching Architecture (MPLS) [RFC3031] and its
variants, MPLS with Traffic Engineering (MPLS-TE) [RFC3209] and
[RFC3473], and MPLS Transport Profile (MPLS-TP) [RFC5921] is a widely
deployed technology that switches traffic based on MPLS label stacks
Korhonen, et al. Expires September 22, 2016 [Page 16]
Internet-Draft DetNet data plane alternatives March 2016
[RFC3032] and [RFC5960]. MPLS is the foundation for Pseudowire-based
services Section 4.2.5 and emerging technologies such as Bit-Indexed
Explicit Replication (BIER) Section 4.2.7.1 and Source Packet Routing
[3].
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 Section 4.2.5 and via other label-like mechanisms such as
EPVN Section 4.2.6. A representation of these options are shown in
Figure 3.
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
Figure 3: MPLS-based Services
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 [RFC5921]. A summary of MPLS control plane
related functions can be found in [RFC6373]. The remainder of this
section will focus [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 Section 4.2.4.
Korhonen, et al. Expires September 22, 2016 [Page 17]
Internet-Draft DetNet data plane alternatives March 2016
The following is a work in progress and draws heavily from [RFC5960]
and may be updated, replaced or removed.
Encapsulation and forwarding of packets traversing MPLS LSPs follows
standard MPLS packet encapsulation and forwarding as defined in
[RFC3031], [RFC3032], [RFC5331], and [RFC5332].
Data plane Quality of Service capabilities are included in the MPLS
in the form of Traffic Engineered (TE) LSPs [RFC3209] and the MPLS
Differentiated Services (DiffServ) architecture [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 [RFC5462] and [RFC3270].
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.
The Uniform, Pipe, and Short Pipe DiffServ tunneling and TTL
processing models are described in [RFC3270] and [RFC3443] and may be
used for MPLS LSPs.
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).
MPLS includes the following LSP types:
o Point-to-point unidirectional
o Point-to-point associated bidirectional
o Point-to-point co-routed bidirectional
o Point-to-multipoint unidirectional
Point-to-point unidirectional LSPs are supported by the basic MPLS
architecture [RFC3031].
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.
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
Korhonen, et al. Expires September 22, 2016 [Page 18]
Internet-Draft DetNet data plane alternatives March 2016
co-routed bidirectional LSPs is that their unidirectional component
LSPs share fate.
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 [RFC4875] and
[RFC5332]. TTL processing and exception handling for point-to-
multipoint LSPs is the same as for point-to-point LSPs.
Additional data plane capabilities include Linear Protection,
[RFC6378] and [RFC7271]. And the in progress work on MPLS support
for time synchronization [I-D.ietf-mpls-residence-time].
4.1.3.2. Analysis and Discussion
#? DetNet Service Interface (M)
The DetNet service interface is enabled through the DetNet Service
Layer it provides client service adaption, directly, via
Pseudowires Section 4.2.5 and via other label-like mechanisms such
as EPVN Section 4.2.6.
#1 Encapsulation and overhead (M)
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 4.2.5 and 4.2.6.
The second perspective relates to encapsulation, if any, is needed
to transport packets across network. In this case, the MPLS label
stack, [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.
#2 Flow identification (M)
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.
Korhonen, et al. Expires September 22, 2016 [Page 19]
Internet-Draft DetNet data plane alternatives March 2016
#3 Packet sequencing (M)
Packet ordering in MPLS is generally similar to packet ordering in
Ethernet. MPLS implementations can also support ECMP for certain
types of traffic which can to lead to out of order delivery.
There are defined techniques to avoid ECMP and ensure in order
delivery during normal operation. Out of order delivery is still
possible in certain MPLS protection scenarios. If additional
ordering mechanisms are required, these are likely to be
implemented at the DetNet Service Layer.
#4 Explicit routes (M)
MPLS supports explicit routes based on how LSPs are established,
e.g., via TE explicit routes [RFC3209]. Additional, but not
required, additional capabilities are being defined as part of
Segment Routing (SR) [I-D.ietf-spring-segment-routing].
#5 Packet replication and deletion (M/W)
At the MPLS LSP level, there are mechanisms defined to provide 1+1
protection. The current definitions [RFC6378] and [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 man 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 the DetNet Service Layer.
#6 Operations, Administration and Maintenance (M)
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 [RFC5586]
and registered by IANA [4].
#7 Time synchronization (M/W)
MPLS itself does not provide any time synchronization service.
The expectations is that the actual time-based scheduling will be
provided by the sub-network layer, e.g., by [TSNTG], and that the
DetNet transport layer will merely need to facilitate time
synchronization (with hardware support) across multiple sub-
network domains and technologies. Work is in progress
Korhonen, et al. Expires September 22, 2016 [Page 20]
Internet-Draft DetNet data plane alternatives March 2016
[I-D.ietf-mpls-residence-time] that may satisfy, or serve as a
building block for, DetNet time synchronization.
#8 Class and quality of service capabilities (M/W)
As previously mentioned, Data plane Quality of Service
capabilities are included in the MPLS in the form of Traffic
Engineered (TE) LSPs [RFC3209] and the MPLS Differentiated
Services (DiffServ) architecture [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 [RFC5462] and [RFC3270]. One potential open area of work is
synchronized, time based scheduling.
#9 Packet traceability (M)
MPLS supports multiple tracing mechanisms. A control based one is
defined in [RFC3209]. An OAM based mechanism is defined in MPLS
On-Demand Connectivity Verification and Route Tracing [RFC6426].
#10 Technical maturity (M)
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.
4.1.3.3. Summary
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.
4.2. DetNet Service layer technologies
4.2.1. Generic Routing Encapsulation (GRE)
4.2.1.1. Solution description
Generic Routing Encapsulation (GRE) [RFC2784] provides an
encapsulation of an arbitrary network layer protocol over another
Korhonen, et al. Expires September 22, 2016 [Page 21]
Internet-Draft DetNet data plane alternatives March 2016
arbitrary network layer protocol. The encapsulation of a GRE packet
can be found in Figure 4.
+-------------------------------+
| |
| Delivery Header |
| |
+-------------------------------+
| |
| GRE Header |
| |
+-------------------------------+
| |
| Payload packet |
| |
+-------------------------------+
Figure 4: Encapsulation of a GRE packet
Based on RFC2784, [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 Figure 5.
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) |
+-----------------------------------------------------------------+
Figure 5: Format of a GRE header
4.2.1.2. Analysis and Discussion
Encapsulation and overhead (M)
GRE provides encapsulation for a network layer protocol over
anther network layer protocol. A new protocol type for DetNet
traffics should be allocated as an "Ether Type" in [RFC1700] and
in IANA Ethernet Numbers. [5] The fixed header of a GRE packet is
4 octets while the maximum header is 16 octets with optional
fields in Figure 5.
Korhonen, et al. Expires September 22, 2016 [Page 22]
Internet-Draft DetNet data plane alternatives March 2016
Flow identification (W)
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 4.1.1 and 4.1.2 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.
Packet sequencing (M)
As stated in Section 4.2.1, GRE provides an optional sequencing
number in its header to provide sequencing services for packets.
The size of the sequencing number is 32 bits.
Duplicate packet deletion (N)
GRE has no packet replication and deletion currently in its header
and should be extended or rely on delivery protocols.
Operations, Administration and Maintenance (W/N)
[note: rely on the delivery protocol] GRE has no packet
replication and deletion currently and should be relied on
delivery protocols.
Time synchronization (W/N)
[note: rely on the delivery protocol] GRE has no packet
replication and deletion currently and should be relied on
delivery protocols.
Class and quality of service capabilities (W/N)
[note: rely on the delivery protocol] GRE has no packet
replication and deletion currently and should be relied on
delivery protocols. For the class of service capability, an
optional code point field to indicate CoS of a traffic can be
extended in GRE header.
Technical maturity (M)
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 [I-D.ietf-intarea-gre-ipv6]. Due to
its good extensibility, GRE is also extended to support network
virtualization in Data Center, which is NVGRE [RFC7637].
Korhonen, et al. Expires September 22, 2016 [Page 23]
Internet-Draft DetNet data plane alternatives March 2016
4.2.1.3. Summary
TBD.
4.2.2. Layer-2 Tunneling Protocol (L2TP)
[Editor's note: L2TPv3 [RFC3931] content to be provided later, if
needed]
4.2.3. Virtual Extensible LAN (VXLAN)
[Editor's note: VXLAN [RFC7348] content to be provided later, if
needed]
4.2.4. MPLS-based Services
4.2.4.1. Solution description
MPLS supports the equivalent of both the DetNet Service and DetNet
Transport layers. This, as well as a general overview of MPLS, is
covered above in Section 4.1.3. This section will focus on the
DetNet Service Layer it provides client service adaption, via
Pseudowires in Section 4.2.5 and via native and other label-like
mechanisms such as EPVN in Section 4.2.6. A representation of these
options was previously discussed and is shown in Figure 3.
4.2.4.2. Analysis and Discussion
#? DetNet Service Interface (M)
The following text is adapted from [RFC5921]:
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 [RFC3985] and Section 6 of [RFC5659]. For network layer client
services, the adaptation function uses the MPLS encapsulation
format as defined in [RFC3032].
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.
MPLS may itself be a client of an underlying server layer. MPLS
can thus also 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
Korhonen, et al. Expires September 22, 2016 [Page 24]
Internet-Draft DetNet data plane alternatives March 2016
transparent transport of those frames over the server layer
network.
While MPLS service can provided on and true end-system to end-
system basis, it's more likely that DetNet service will be
provided over Pseudowires as described in Section 4.2.5 or via an
EPVN-based service described in Section 4.2.6 .
#1 Encapsulation and overhead (M)
MPLS labels in the label stack may be used to identify transport
paths, see Section 4.1.3, or as service identifiers. Typically a
single label is used for service identification. Additional
details on how client adaptation makes use of such labels is part
of actual client-related adaptation processing, see Sections 4.2.5
and 4.2.6.
#2 Flow identification (M)
This is basically the same as MPLS at the DetNet transport layer.
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. Typically a separate label will be added
per service being supported by a node.
#3 Packet sequencing (M)
This is the same as MPLS at the DetNet transport layer. If
additional ordering mechanisms are required, these will be needed
(and added) in client-related adaptation processing, see Sections
4.2.5 and 4.2.6.
#4 Explicit routes (N/A)
Explicit routes are part of the DetNet transport layer, see
Section 4.2.6, or as part of multi-segment PWEs, Section 4.2.5.
#5 Packet replication and deletion (M/W)
This is the same as MPLS at the DetNet transport layer.
Additional capability may also be provided as part of client-
related adaptation processing see Section 4.2.5.
Korhonen, et al. Expires September 22, 2016 [Page 25]
Internet-Draft DetNet data plane alternatives March 2016
#6 Operations, Administration and Maintenance (M)
This is the same as MPLS at the DetNet transport layer.
Additional capability may also be provided as part of client-
related adaptation processing.
#7 Time synchronization (TBD)
It's unclear at this time if any additional capability is needed
at this level.
#8 Class and quality of service capabilities (M/W)
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.
#9 Packet traceability (M)
This is the same as MPLS at the DetNet transport layer.
#10 Technical maturity (M)
This is the same as MPLS at the DetNet transport layer.
4.2.4.3. Summary
This is the same as MPLS at the DetNet transport layer. 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.
4.2.5. Pseudo Wire Emulation Edge-to-Edge (PWE3)
Korhonen, et al. Expires September 22, 2016 [Page 26]
Internet-Draft DetNet data plane alternatives March 2016
4.2.5.1. Solution description
PSeudo Wire Emulation Edge-to-Edge (PWE3) [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 [RFC4448] and for generic
packet service [RFC6658]. Figure 6 illustrate the reference PWE3
stack model.
+----------------+ +----------------+
|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 \==============+
\ /
\___________/
Figure 6: PWE3 protocol stack reference model
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 [RFC4447], and enjoy the toolbox developed for MPLS
networks. 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
[RFC5087].
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
Korhonen, et al. Expires September 22, 2016 [Page 27]
Internet-Draft DetNet data plane alternatives March 2016
encapsulation is specified by [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 [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 [RFC4817]. The MPLS-in-UDP
encapsulation is specified by [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.
4.2.5.2. Analysis and Discussion
Encapsulation and overhead (M)
PWs offer encapsulation services practically for any types of
payloads over any PSN. New PW types need a code point allocation
[RFC4446] and in some cases an emulated service specific document.
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 [RFC4448]. Without a CW and VLAN tags the
Ethernet header gets reduced to 14 octets (minimum Ethernet header
overhead is 26).
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.
Flow identification (M)
[Editor's note: this criteria has not been checked against the
latest view of flow identification after the separation of
transport and service layers.]
Korhonen, et al. Expires September 22, 2016 [Page 28]
Internet-Draft DetNet data plane alternatives March 2016
PWs provide multiple layers of flow identification, especially in
the case of the MPLS PSN. The PWs are typically prepended with a
PW label that can be used to identify a specific PW. Furthermore,
the PSN also uses one or more labels to transport packets over a
specific label switched paths (that then would carry PWs). 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.
Packet sequencing (M)
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.
Duplicate packet deletion (W)
The PW duplicate detection mechanism also exists in theory
[RFC3985] but no emulated service makes use of it currently.
Operations, Administration and Maintenance (M/W)
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 have the full toolbox of IP network OAM tools.
There could be, however, need for deterministic networking
specific extensions for the mentioned control planes.
Time synchronization (M/W)
It is possible to carry time synchronization information as part
of the PW encapsulation layer (see for example [RFC5087]).
Whether the timing precision is enough for all deterministic
networking use cases vary, and it is possible existing mechanisms
are not adequate for all use cases. IP PSNs have already
demonstrated the use of time synchronization as a part of PWE3
[RFC5086].
Class and quality of service capabilities (M)
In a case of IP PSN the 6-bit differentiated services code point
(DSCP) field can be used for indicating the class of service
[RFC2474] and 2-bit field reserved for the explicit congestion
notification (ECN) [RFC3168]. Similarly, in a case of MPLS PSN,
there are 3-bit traffic class field (TC) [RFC5462] in the label
reserved for for both Explicitly TC-encoded-PSC LSPs (E-LSP)
[RFC3270] and ECN [RFC5129]. Due to the limited number of bits in
Korhonen, et al. Expires September 22, 2016 [Page 29]
Internet-Draft DetNet data plane alternatives March 2016
the TC field, their use for QoS and ECN functions 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.
Technical maturity (M)
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
deletion) does not appear to be extensive, since the existing
protection mechanism already get close to what is needed from the
deterministic networking data plane solution.
4.2.5.3. Summary
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.
Extensions are required to realize the packet replication and
duplicate detection features of the deterministic networking data
plane.
4.2.6. MPLS-Based Ethernet VPN (EVPN)
4.2.6.1. Solution description
MPLS-Based Ethernet VPN (EVPN), in the form documented in [RFC7432]
and [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), [RFC4664].
EVPN provides client adaptation and reuses the MPLS data plane
discussed above in Section 4.2.4. In certain special cases, it also
uses the PW MPLS Control Word. EVPN control is via BGP, [RFC7432],
and may use TE-LSPs, e.g., controlled via [RFC3209] for MPLS
transport. Additional EVPN related RFCs and in progress drafts are
being developed by the BGP Enabled Services Working Group [6].
Korhonen, et al. Expires September 22, 2016 [Page 30]
Internet-Draft DetNet data plane alternatives March 2016
4.2.6.2. Analysis and Discussion
#? DetNet Service Interface (M/W)
The service supported by EVPN is a layer 2 Ethernet virtual
private network. While EVPN is typically envisioned to be
deployed on provider edge systems, it is also possible to extent
the EVPN service to a DetNet end or edge system if such service is
needed.
#1 Encapsulation and overhead (M)
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.
#2 Flow identification (W)
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.
#3 Packet sequencing (M/W)
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" [RFC4385] or the
entropy labels [RFC6790].
If additional ordering mechanisms are required, such mechanisms
will need to be defined.
#4 Explicit routes (M)
EVPN itself doesn't offer support for explicit routes as it is
simply an adaptation function. Explicit routes for EVPN at the
DetNet transport layer would be provided via MPLS.
#5 Packet replication and deletion (M/W)
Korhonen, et al. Expires September 22, 2016 [Page 31]
Internet-Draft DetNet data plane alternatives March 2016
EVPN relies on the MPLS layer for all protection functions. See
Section 4.1.3 and Section 4.2.4. 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.)
#6 Operations, Administration and Maintenance (M/W)
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. [RFC6371] provides some useful background
on this topic.
#7 Time synchronization (W)
The interface to the DetNet time synchronization service is still
to be determined. If the service is accessed by end systems via
IEEE defined mechanisms, then those mechanisms will need to be
mapped to the MPLS provided mechanisms discussed in Section 4.1.3.
#8 Class and quality of service capabilities (M/W)
EVPN is largely silent on the topics of CoS and QoS, but the
existing Ethernet and MPLS mechanisms can be directly used. While
an implementation may support such mappings today, standardized
mappings do not (yet) exist.
#9 Packet traceability (M)
EVPN nodes can utilize MPLS layers tracing mechanisms.
#10 Technical maturity
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.
Korhonen, et al. Expires September 22, 2016 [Page 32]
Internet-Draft DetNet data plane alternatives March 2016
4.2.6.3. Summary
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.
4.2.7. Bit Indexed Explicit Replication (BIER)
Bit Indexed Explicit Replication [I-D.ietf-bier-architecture] (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 listeners that
are intended for a particular packet, which means that 1) the sender
is aware of the individual listeners 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 faces a lot of traction from
Service Providers. Section 4.2.7.1 discusses the applicability of
BIER for replication in the DetNet.
The simplicity of the BIER technology makes it very versatile as a
network plane signaling protocol. Already, a new Traffic Engineering
variation is emerging that uses bits to signal segments along a TE
path. While the more classical BIER is mainly a multicast technology
that typically leverages a unicast distributed control plane through
IGP extensions, BIER-TE is mainly a unicast technology that leverages
a central computation to setup path, compute segments and install the
mapping in the intermediate nodes. Section 4.2.7.2 discusses the
applicability of BIER-TE for replication, traceability and OAM
operations in DetNet.
4.2.7.1. Base BIER
Bit-Indexed Explicit Replication (BIER) layer may be considered to be
included into Deterministic Networking data plane solution.
Encapsulation of a BIER packet in MPLS network presented in Figure 7
Korhonen, et al. Expires September 22, 2016 [Page 33]
Internet-Draft DetNet data plane alternatives March 2016
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BIER packet in MPLS encapsulation
4.2.7.1.1. Solution description
The DetNet may be presented in BIER as distinctive payload type with
its own Proto(col) ID. Then it is likely that DetNet will have the
header that would identify:
o Version;
o Sequence Number;
o Timestamp;
o Payload type, e.g. data vs. OAM.
DetNet node, collocated with BFIR, may use multiple BIER sub-domains
to create replicated flows. Downstream DetNet nodes, collocated with
BFER, would terminate redundant flows based on Sequence Number and/or
Timestamp information. Such DetNet may be BFER in one BIER sub-
domain and BFIR in another. Thus DetNet flow would traverse several
BIER sub-domains.
Korhonen, et al. Expires September 22, 2016 [Page 34]
Internet-Draft DetNet data plane alternatives March 2016
+-----+
| A |
+-----+
/ \
. .
/ .
. \
/ .
. .
/ \
+-----+ +-----+
| B | | C |
+-----+ +-----+
/ \ / \
. . . .
/ \ . .
. . / \
/ \ . .
. . . .
/ \ / \
+-----+ +-----+ +-----+
| D | | E | | F |
+-----+ +-----+ +-----+
\ . . /
. . . .
\ . . .
. . . /
\ . . .
. . . .
\ . . /
+-----+ +-----+
| G | | H |
+-----+ +-----+
Figure 8: DetNet in BIER domain
Consider DetNet flow that must traverse BIER enabled domain from A to
G and H. DetNet may use three BIER subdomains:
o A-B-D-E-G (dash-dot): A is BFIR, E and G are BFERs,
o A-C-E-F-H (dash-double-dot): A is BFIR, E and H are BFERs,
o E-G-H (dotted): E is BFIR, G and H are BFERs.
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 deemed too-late.
Korhonen, et al. Expires September 22, 2016 [Page 35]
Internet-Draft DetNet data plane alternatives March 2016
DetNet nodes G and H receive DetNet flows, terminate duplicates and
those that are too-late.
4.2.7.1.2. Analysis and Discussion
4.2.7.1.3. Summary
4.2.7.2. BIER - Traffic Engineering
An alternate use of Bit-Indexed Explicit Replication (BIER) uses bits
in the BitString to represent adjacencies as opposed to destinations,
as discussed in BIER Traffic Engineering (TE)
[I-D.eckert-bier-te-arch].
The proposed function of BIER-TE in the DetNet data plane is to
control the process of replication and elimination, as opposed to the
identification of the flows or and the sequencing of packets within a
flow.
At the path ingress, BIER-TE identifies the adjacencies that are
activated for this packet (under the rule of the controller). At the
egress, BIER-TE is used to identify the adjacencies where
transmission failed. This information is passed to the controller,
which in turn can modify the active adjacencies for the next packets.
The value is that the replication can be controlled and monitored
with the granularity of a packet and a adjacency in a control loops
that involves an external controller.
4.2.7.2.1. Solution description
BIER-TE enables to activate the replication and elimination functions
in a manner that is abstract to the data plane forwarding
information. An adjacency, which is represented by a bit in the BIER
header, can correspond in the data plane to an Ethernet hop, a Label
Switched Path, or it can correspond to an IPv6 loose or strict source
routed path.
In a nutshell, BIER-TE is used as follows:
o A controller computes a complex path, sometimes called a track,
which takes the general form of a ladder. The steps and the side
rails between them are the adjacencies that can be activated on
demand on a per-packet basis using bits in the BIER header.
Korhonen, et al. Expires September 22, 2016 [Page 36]
Internet-Draft DetNet data plane alternatives March 2016
===> (A) ====> (C) ====
// ^ | ^ | \\
ingress (I) | | | | (E) egress
\\ | v | v //
===> (B) ====> (D) ====
Figure 9: Ladder Shape with Replication and Elimination Points
o The controller assigns a BIER domain, and inside that domain,
assigns bits to the adjacencies. The controller assigns each bit
to a replication node that sends towards the adjacency, for
instance the ingress router into a segment that will insert a
routing header in the packet. A single bit may be used for a step
in the ladder, indicating the other end of the step in both
directions.
===> (A) ====> (C) ====
// 1 ^ | 4 ^ | 7 \\
ingress (I) |2| |6| (E) egress
\\ 3 | v 5 | v 8 //
===> (B) ====> (D) ====
Figure 10: Assigning Bits
o The controller activates the replication by deciding the setting
of the bits associated with the adjacencies. This decision can be
modified at any time, but takes the latency of a controller round
trip to effectively take place. Below is an example that uses
Replication and Elimination to protect the A->C adjacency.
Korhonen, et al. Expires September 22, 2016 [Page 37]
Internet-Draft DetNet data plane alternatives March 2016
+-------+-----------+-------+---------------------+
| Bit # | Adjacency | Owner | Example Bit Setting |
+-------+-----------+-------+---------------------+
| 1 | I->A | I | 1 |
| 2 | A->B | A | 1 |
| | B->A | B | |
| 3 | I->C | I | 0 |
| 4 | A->C | A | 1 |
| 5 | B->D | B | 1 |
| 6 | C->D | C | 1 |
| | D->C | D | |
| 7 | C->E | C | 1 |
| 8 | D->E | D | 0 |
+-------+-----------+-------+---------------------+
Replication and Elimination Protecting A->C
Table 1: Controlling Replication
o The BIER header with the controlling BitString is injected in the
packet by the ingress node of the deterministic path. That node
may act as a replication point, in which case it may issue
multiple copies of the packet
====> Repl ===> Elim ====
// | ^ \\
ingress | | egress
v |
Fwd ====> Fwd
Figure 11: Enabled Adjacencies
o For each of its bits that is set in the BIER header, the owner
replication point resets the bit and transmits towards the
associated adjacency; to achieve this, the replication point
copies the packet and inserts the relevant data plane information,
such as a source route header, towards the adjacency that
corresponds to the bit
Korhonen, et al. Expires September 22, 2016 [Page 38]
Internet-Draft DetNet data plane alternatives March 2016
+-----------+----------------+
| Adjacency | BIER BitString |
+-----------+----------------+
| I->A | 01011110 |
| A->B | 00011110 |
| B->D | 00010110 |
| D->C | 00010010 |
| A->C | 01001110 |
+-----------+----------------+
BitString in BIER Header as Packet Progresses
Table 2: BIER-TE in Action
o Adversely, an elimination node on the way strips the data plane
information and performs a bitwise AND on the BitStrings from the
various copies of the packet that it has received, before it
forwards the packet with the resulting BitString.
+-----------+----------------+
| Operation | BIER BitString |
+-----------+----------------+
| D->C | 00010010 |
| A->C | 01001110 |
| | -------- |
| AND in C | 00000010 |
| | |
| C->E | 00000000 |
+-----------+----------------+
BitString Processing at Elimination Point C
Table 3: BIER-TE in Action (cont.)
o In this example, all the transmissions succeeded and the BitString
at arrival has all the bits reset - note that the egress may be an
Elimination Point in which case this is evaluated after this node
has performed its AND operation on the received BitStrings).
Korhonen, et al. Expires September 22, 2016 [Page 39]
Internet-Draft DetNet data plane alternatives March 2016
+-------------------+-----------------------+
| Failing Adjacency | Egress BIER BitString |
+-------------------+-----------------------+
| I->A | Frame Lost |
| I->B | Not Tried |
| A->C | 00010000 |
| A->B | 01001100 |
| B->D | 01001100 |
| D->C | 01001100 |
| C->E | Frame Lost |
| D->E | Not Tried |
+-------------------+-----------------------+
BitString indicating failures
Table 4: BIER-TE in Action (cont.)
o But if a transmission failed along the way, one (or more) bit is
never cleared. Table 4 provides the possible outcomes of a
transmission. If the frame is lost, then it is probably due to a
failure in either I->A or C->E, and the controller should enable
I->B and D->E to find out. A BitString of 00010000 indicates
unequivocally a transmission error on the A->C adjacency, and a
BitString of 01001100 indicates a loss in either A->B, B->D or
D->C; enabling D->E on the next packets may provide more
information to sort things out.
In more details:
The BIER header is of variable size, and a DetNet network of a
limited size can use a model with 64 bits if 64 adjacencies are
enough, whereas a larger deployment may be able to signal up to 256
adjacencies for use in very complex paths. Figure 7 illustrates a
BIER header as encapsulated within MPLS. The format of this header
is common to BIER and BIER-TE.
For the DetNet data plane, a replication point is an ingress point
for more than one adjacency, and an elimination point is an egress
point for more than one adjacency.
A pre-populated state in a replication node indicates which bits are
served by this node and to which adjacency each of these bits
corresponds. With DetNet, the state is typically installed by a
controller entity such as a PCE. The way the adjacency is signaled
in the packet is fully abstracted in the bit representation and must
be provisioned to the replication nodes and maintained as a local
state, together with the timing or shaping information for the
associated flow.
Korhonen, et al. Expires September 22, 2016 [Page 40]
Internet-Draft DetNet data plane alternatives March 2016
The DetNet data plane uses BIER-TE to control which adjacencies are
used for a given packet. This is signaled from the path ingress,
which sets the appropriate bits in the BIER BitString to indicate
which replication must happen.
The replication point clears the bit associated to the adjacency
where the replica is placed, and the elimination points perform a
logical AND of the BitStrings of the copies that it gets before
forwarding.
As is apparent in the examples above, clearing the bits enables to
trace a packet to the replication points that made any particular
copy. BIER-TE also enables to detect the failing adjacencies or
sequences of adjacencies along a path and to activate additional
replications to counter balance the failures.
Finally, using the same BIER-TE bit for both directions of the steps
of the ladder enables to avoid replication in both directions along
the crossing adjacencies. At the time of sending along the step of
the ladder, the bit may have been already reset by performing the AND
operation with the copy from the other side, in which case the
transmission is not needed and does not occur (since the control bit
is now off).
4.2.8. Higher layer header fields
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. In
general a safe bet is 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
(Section 3.4).
4.2.8.1. TCP
The TCP header includes a sequence number parameter, which can be
applied to detect and eliminate duplicate packets if seamless
redundancy 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.
Korhonen, et al. Expires September 22, 2016 [Page 41]
Internet-Draft DetNet data plane alternatives March 2016
4.2.8.2. RTP
RTP is often used to deliver time critical traffic in IP networks.
RTP is is carried on top of IP and UDP [RFC3550]. The RTP header
includes a 2-byte sequence number, which can be used to detect and
eliminate duplicate packets if seamless redundancy 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.
5. Summary of data plane alternatives
TBD.
6. Security considerations
TBD.
7. IANA Considerations
This document has no IANA considerations.
8. Acknowledgements
The author(s) ACK and NACK.
The following people were part of the DetNet Data Plane Design Team:
Jouni Korhonen
Janos Farkas
Norman Finn
Olivier Marce
Gregory Mirsky
Pascal Thubert
Zhuangyan Zhuang
The DetNet chairs serving during the DetNet Data Plane Design Team:
Lou Berger
Pat Thaler
Korhonen, et al. Expires September 22, 2016 [Page 42]
Internet-Draft DetNet data plane alternatives March 2016
9. References
9.1. Informative References
[I-D.eckert-bier-te-arch]
Eckert, T. and G. Cauchie, "Traffic Enginering for Bit
Index Explicit Replication BIER-TE", draft-eckert-bier-te-
arch-02 (work in progress), October 2015.
[I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic
Networking Architecture", draft-finn-detnet-
architecture-02 (work in progress), November 2015.
[I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-finn-detnet-problem-statement-04 (work
in progress), October 2015.
[I-D.ietf-6man-rfc2460bis]
Deering, S. and B. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-04 (work
in progress), March 2016.
[I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-01 (work in progress), March 2016.
[I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., P, T., and S.
Aldrin, "Multicast using Bit Index Explicit Replication",
draft-ietf-bier-architecture-03 (work in progress),
January 2016.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015.
[I-D.ietf-intarea-gre-ipv6]
Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", draft-ietf-
intarea-gre-ipv6-14 (work in progress), September 2015.
Korhonen, et al. Expires September 22, 2016 [Page 43]
Internet-Draft DetNet data plane alternatives March 2016
[I-D.ietf-isis-pcr]
Farkas, J., Bragg, N., Unbehagen, P., Parsons, G.,
Ashwood-Smith, P., and C. Bowers, "IS-IS Path Computation
and Reservation", draft-ietf-isis-pcr-05 (work in
progress), February 2016.
[I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Sasha, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-05 (work in
progress), March 2016.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-07 (work in progress), December
2015.
[I-D.ietf-sunset4-gapanalysis]
Perreault, S., Tsou, T., Zhou, C., and P. Fan, "Gap
Analysis for IPv4 Sunset", draft-ietf-
sunset4-gapanalysis-07 (work in progress), April 2015.
[I-D.ietf-v6ops-ipv6-ehs-in-real-world]
Gont, F., Linkova, J., Chown, T., and S. LIU,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", draft-ietf-v6ops-
ipv6-ehs-in-real-world-02 (work in progress), December
2015.
[IEEE802.1Qbv]
IEEE, "Enhancements for Scheduled Traffic", 2016,
<http://www.ieee802.org/1/files/private/bv-drafts/>.
[IEEE802.1Qch]
IEEE, "Cyclic Queuing and Forwarding", 2016,
<http://www.ieee802.org/1/files/private/ch-drafts/>.
[IEEE8021CB]
Finn, N., "Draft Standard for Local and metropolitan area
networks - Seamless Redundancy", IEEE P802.1CB
/D2.1 P802.1CB, December 2015,
<http://www.ieee802.org/1/files/private/cb-drafts/
d2/802-1CB-d2-1.pdf>.
Korhonen, et al. Expires September 22, 2016 [Page 44]
Internet-Draft DetNet data plane alternatives March 2016
[IEEE8021Qca]
IEEE 802.1, "IEEE 802.1Qca Bridges and Bridged Networks -
Amendment 24: Path Control and Reservation", IEEE
P802.1Qca/D2.1 P802.1Qca, June 2015,
<http://www.ieee802.org/1/files/private/ca-drafts/
d2/802-1Qca-d2-1.pdf>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
DOI 10.17487/RFC1393, January 1993,
<http://www.rfc-editor.org/info/rfc1393>.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
DOI 10.17487/RFC1700, October 1994,
<http://www.rfc-editor.org/info/rfc1700>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<http://www.rfc-editor.org/info/rfc2702>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
Korhonen, et al. Expires September 22, 2016 [Page 45]
Internet-Draft DetNet data plane alternatives March 2016
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003,
<http://www.rfc-editor.org/info/rfc3443>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
Korhonen, et al. Expires September 22, 2016 [Page 46]
Internet-Draft DetNet data plane alternatives March 2016
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<http://www.rfc-editor.org/info/rfc4023>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446,
DOI 10.17487/RFC4446, April 2006,
<http://www.rfc-editor.org/info/rfc4446>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<http://www.rfc-editor.org/info/rfc4448>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<http://www.rfc-editor.org/info/rfc4664>.
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March
2007, <http://www.rfc-editor.org/info/rfc4817>.
Korhonen, et al. Expires September 22, 2016 [Page 47]
Internet-Draft DetNet data plane alternatives March 2016
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>.
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
<http://www.rfc-editor.org/info/rfc5086>.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
"Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
DOI 10.17487/RFC5087, December 2007,
<http://www.rfc-editor.org/info/rfc5087>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<http://www.rfc-editor.org/info/rfc5331>.
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
"MPLS Multicast Encapsulations", RFC 5332,
DOI 10.17487/RFC5332, August 2008,
<http://www.rfc-editor.org/info/rfc5332>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <http://www.rfc-editor.org/info/rfc5462>.
Korhonen, et al. Expires September 22, 2016 [Page 48]
Internet-Draft DetNet data plane alternatives March 2016
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
DOI 10.17487/RFC5659, October 2009,
<http://www.rfc-editor.org/info/rfc5659>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
Transport Profile Data Plane Architecture", RFC 5960,
DOI 10.17487/RFC5960, August 2010,
<http://www.rfc-editor.org/info/rfc5960>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073,
DOI 10.17487/RFC6073, January 2011,
<http://www.rfc-editor.org/info/rfc6073>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar,
N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-
TP) Control Plane Framework", RFC 6373,
DOI 10.17487/RFC6373, September 2011,
<http://www.rfc-editor.org/info/rfc6373>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <http://www.rfc-editor.org/info/rfc6378>.
Korhonen, et al. Expires September 22, 2016 [Page 49]
Internet-Draft DetNet data plane alternatives March 2016
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, DOI 10.17487/RFC6426, November 2011,
<http://www.rfc-editor.org/info/rfc6426>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, DOI 10.17487/RFC6540, April 2012,
<http://www.rfc-editor.org/info/rfc6540>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<http://www.rfc-editor.org/info/rfc6564>.
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding",
RFC 6621, DOI 10.17487/RFC6621, May 2012,
<http://www.rfc-editor.org/info/rfc6621>.
[RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis,
"Packet Pseudowire Encapsulation over an MPLS PSN",
RFC 6658, DOI 10.17487/RFC6658, July 2012,
<http://www.rfc-editor.org/info/rfc6658>.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012,
<http://www.rfc-editor.org/info/rfc6718>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, DOI 10.17487/RFC6814, November 2012,
<http://www.rfc-editor.org/info/rfc6814>.
Korhonen, et al. Expires September 22, 2016 [Page 50]
Internet-Draft DetNet data plane alternatives March 2016
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<http://www.rfc-editor.org/info/rfc6864>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
[RFC7167] Frost, D., Bryant, S., Bocci, M., and L. Berger, "A
Framework for Point-to-Multipoint MPLS in Transport
Networks", RFC 7167, DOI 10.17487/RFC7167, April 2014,
<http://www.rfc-editor.org/info/rfc7167>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<http://www.rfc-editor.org/info/rfc7209>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<http://www.rfc-editor.org/info/rfc7271>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <http://www.rfc-editor.org/info/rfc7426>.
Korhonen, et al. Expires September 22, 2016 [Page 51]
Internet-Draft DetNet data plane alternatives March 2016
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>.
[ST20227] SMPTE 2022, "Seamless Protection Switching of SMPTE ST
2022 IP Datagrams", ST 2022-7:2013, 2013,
<https://www.smpte.org/digital-library>.
[TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networks Task Group", 2013,
<http://www.IEEE802.org/1/pages/avbridges.html>.
9.2. URIs
[1] http://6lab.cisco.com/stats/
[2] https://www.google.com/intl/en/ipv6/statistics.html
[3] https://datatracker.ietf.org/wg/spring/charter/
[4] http://www.iana.org/assignments/g-ach-parameters/g-ach-
parameters.xhtml
[5] http://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
[6] https://tools.ietf.org/wg/bess/
Appendix A. Examples of combined DetNet Service and Transport layers
Authors' Addresses
Korhonen, et al. Expires September 22, 2016 [Page 52]
Internet-Draft DetNet data plane alternatives March 2016
Jouni Korhonen (editor)
Broadcom
3151 Zanker Road
San Jose, CA 95134
USA
Email: jouni.nospam@gmail.com
Janos Farkas
Ericsson
Konyves Kalman krt. 11/B
Budapest 1097
Hungary
Email: janos.farkas@ericsson.com
Gregory Mirsky
Ericsson
Email: gregory.mirsky@ericsson.com
Pascal Thubert
Cisco
Email: pthubert@cisco.com
Yan Zhuang
Huawei
Email: zhuangyan.zhuang@huawei.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Korhonen, et al. Expires September 22, 2016 [Page 53]
