Deterministic Networking (DetNet) Data Plane: IP over MPLSEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comLabN Consulting, L.L.C.lberger@labn.netLabN Consulting, L.L.C.dfedyk@labn.netFuturewei Technologiessb@stewartbryant.comjouni.nospam@gmail.comDetNetsub-network
This document specifies the Deterministic Networking data plane
when encapsulating IP over an MPLS packet-switched network.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() 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
. Introduction
. Terminology
. Terms Used in This Document
. Abbreviations
. Requirements Language
. DetNet IP Data Plane Overview
. DetNet IP over DetNet MPLS
. DetNet IP over DetNet MPLS Data Plane Scenarios
. DetNet IP over DetNet MPLS Encapsulation
. DetNet IP over DetNet MPLS Procedures
. DetNet IP over DetNet MPLS Flow Identification and Aggregation
Procedures
. DetNet IP over DetNet MPLS Traffic Treatment Procedures
. Management and Control Information Summary
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction
Deterministic Networking (DetNet) is a service that can be offered by a
network to DetNet flows.
DetNet provides a capability for the delivery of data flows with
extremely low packet loss rates and bounded end-to-end delivery
latency.
General background and concepts of DetNet can be found in the DetNet
architecture .
This document specifies use of the IP DetNet encapsulation over an
MPLS network. It maps the IP data plane encapsulation described in to the DetNet MPLS data plane defined in .
TerminologyTerms Used in This Document
This document uses the terminology and concepts established in the
DetNet architecture and in
. The reader is assumed to
be familiar with these documents and their terminology.
Abbreviations
This document uses the abbreviations defined in the DetNet
architecture and in . This document uses the
following abbreviations:
CE
Customer Edge (equipment)
d-CW
DetNet Control Word
DetNet
Deterministic Networking
DF
DetNet Flow
DN
DetNet
L2
Layer 2
LSP
Label-Switched Path
MPLS
Multiprotocol Label Switching
PEF
Packet Elimination Function
PRF
Packet Replication Function
PREOF
Packet Replication, Elimination, and Ordering Functions
POF
Packet Ordering Function
PW
Pseudowire
S-Label
DetNet "service" Label
S-PE
Switching Provider Edge
T-PE
Terminating Provider Edge
TE
Traffic Engineering
TSN
Time-Sensitive Networking; TSN is a Task Group of the IEEE
802.1 Working Group
Requirements Language
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 when, and
only when, they appear in all capitals, as shown here.
DetNet IP Data Plane Overview illustrates an IP
DetNet with an MPLS-based DetNet network as a sub-network between the
relay nodes. An IP flow is mapped to one or more PWs and MPLS (TE)
LSPs. The end systems still originate IP-encapsulated traffic,
identified as DetNet flows. The relay nodes follow procedures defined
in to map each DetNet
flow to MPLS LSPs. While not shown, relay nodes can provide service
sub-layer functions such as PREOF using DetNet over MPLS, and this is
indicated by the solid line for the MPLS-facing portion of the Service
component. Note that the Transit node is MPLS (TE) LSP aware and
performs switching based on MPLS labels; it need not have any
specific knowledge of the DetNet service or the corresponding DetNet
flow identification. See for details on the mapping of IP flows to MPLS, and
for general support of
DetNet services using MPLS.
Architecture: DetNet IP over DetNet MPLS Network
DetNet IP Relay Transit Relay DetNet IP
End System Node Node Node End System
+----------+ +----------+
| Appl. |<------------- End to End Service ---------->| Appl. |
+----------+ .....-----+ +-----..... +----------+
| Service |<--: Service |--DetNet flow ---| Service :-->| Service |
| | : |<-DN MPLS flow ->| : | |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
|<---- DetNet MPLS ---->|
|<--------------------- DetNet IP ------------------>|
DetNet IP over DetNet MPLS
This section defines how IP-encapsulated flows are carried over a
DetNet MPLS data plane as defined in . Since both non-DetNet and DetNet IP packets are
identical on the wire, this section is applicable to any node that
supports IP over DetNet MPLS, and this section refers to both cases as
DetNet IP over DetNet MPLS.
DetNet IP over DetNet MPLS Data Plane Scenarios
An example use of DetNet IP over DetNet MPLS is presented here.
illustrates IP
DetNet-enabled End Systems (hosts) connected to DetNet-enabled IP
networks (DN IP), operating over a DetNet-aware MPLS network. In this
figure, we have a case where the relay nodes act as T-PEs and sit at
the boundary of the MPLS domain since the non-MPLS domain is DetNet
aware. This case is very similar to the DetNet MPLS Network (Figure
2 in ). However, in Figure
2 of , the T-PEs are
located at the end system and MPLS spans the whole DetNet service.
The primary difference in this document is that the relay nodes are
at the edges of the MPLS domain and therefore function as T-PEs, and
that MPLS service sub-layer functions are not provided over the
DetNet IP network. The transit node functions shown above are
identical to those described in .
illustrates how
relay nodes can provide service protection over an MPLS domain. In
this case, CE1 and CE2 are IP DetNet end systems that are
interconnected via an MPLS domain such as that described in . Note that R1 and R3 sit at the
edges of an MPLS domain and therefore are similar to T-PEs, while R2
sits in the middle of the domain and is therefore similar to an
S-PE.
Service Protection over DetNet MPLS Network for DetNet IP
DetNet DetNet
IP Service Transit Transit Service IP
DetNet |<-Tnl->| |<-Tnl->| DetNet
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+
| |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| |
|CE1| | | \ | | X | | / | | |CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node |
| (T-PE) (S-PE) (T-PE) |
| |
|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
| |
|<-------------- End to End DetNet Service --------------->|
-------------------------- Data Flow ------------------------->
X = Service protection (PRF, PREOF, PEF/POF)
DFx = DetNet member flow x over a TE LSP
illustrates
DetNet-enabled end systems connected to DetNet-enabled (DN) MPLS
networks. A similar situation occurs when end systems are not DetNet
aware. In this case, edge nodes sit at the boundary of the MPLS
domain since it is also a DetNet domain boundary. The edge nodes
provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP
flows. While the node types differ, there is essentially no
difference in data plane processing between relays and edges. There
are likely to be differences in Controller Plane operation,
particularly when distributed control plane protocols are used.
It is still possible to provide DetNet service protection for
non-DetNet-aware end systems. This case is basically the
same as , with the exception
that CE1 and CE2 are non-DetNet-aware end systems and R1 and R3
become edge nodes.
DetNet IP over DetNet MPLS Encapsulation
The basic encapsulation approach is to treat a DetNet IP flow as an
App-flow from the DetNet MPLS perspective. The corresponding example
DetNet Sub-network format is shown in .
Example DetNet IP over MPLS Sub-network Formats
/-> +------+ +------+ +------+ ^ ^
| | X | | X | | X |<- App-flow : :
| +------+ +------+ +------+ : :
App-flow <-+ |NProto| |NProto| |NProto| : :(1)
for MPLS | +------+ +------+ +------+ : :
| | IP | | IP | | IP | : v
\-> +---+======+--+======+--+======+-----+ :
DetNet-MPLS | d-CW | | d-CW | | d-CW | :
+------+ +------+ +------+ :(2)
|Labels| |Labels| |Labels| v
+---+======+--+======+--+======+-----+
Link/Sub-network | L2 | | TSN | | UDP |
+------+ +------+ +------+
| IP |
+------+
| L2 |
+------+
(1) DetNet IP Flow (or simply IP flow)
(2) DetNet MPLS Flow
In , "App-flow"
indicates the payload carried by the DetNet IP data plane. "IP" and
"NProto" indicate the fields described in Sections (IP Header Information) and (Other
Protocol Header Information) of , respectively.
"App-flow for MPLS" indicates that an individual DetNet IP
flow is the payload from the perspective of the DetNet MPLS
data plane defined in .
Per , the DetNet MPLS data plane uses a single
S-Label to support a single App-flow. DetNet IP Flow
Identification Procedures in states that a
single DetNet flow is identified based on IP- and next-level
protocol header information. (DetNet Flow
Aggregation) defines the ways in which aggregation is supported
through the use of prefixes, wildcards, lists, and port ranges.
Collectively, this results in the fairly straightforward
procedures defined in the next section.
As shown in , DetNet relay nodes
are responsible for the mapping of a DetNet flow, at the service
sub-layer, from the IP to MPLS DetNet data planes and back
again. Their related DetNet IP over DetNet MPLS data plane
operation is comprised of two sets of procedures: the mapping of
flow identifiers and ensuring proper traffic treatment.
Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows.
The six-tuple of IP is mapped to the S-Label in both cases.
The various fields may be mapped or ignored when going from IP to MPLS.
DetNet IP over DetNet MPLS Procedures
The main differences of mapping IP to DetNet MPLS (compared to plain MPLS) are
that (1) there is a mandatory flow identification to make the forwarding
decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet
Control Word) is mandatory for the MPLS encapsulation, and
(3) during forwarding over the DetNet MPLS network, treatment specific to
DetNet flows is needed.
DetNet IP over DetNet MPLS Flow Identification and Aggregation
Procedures
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over
a DetNet MPLS network MUST map a DetNet IP flow, as
identified in , into a
single MPLS DetNet flow and MUST process it in
accordance to the procedures defined in . PRF MAY be supported at the MPLS
level for DetNet IP flows sent over a DetNet MPLS network.
Aggregation MAY be supported as defined in . Aggregation considerations in MAY be used to
identify an individual DetNet IP flow. The provisioning of the
mapping of DetNet IP flows to DetNet MPLS flows MUST
be supported via configuration, e.g., via the Controller Plane.
A DetNet relay node (egress T-PE) MAY be provisioned
to handle packets received via the DetNet MPLS data plane as DetNet
IP flows. A single incoming DetNet MPLS flow MAY be
treated as a single DetNet IP flow, without examination of IP
headers. Alternatively, packets received via the DetNet MPLS data
plane MAY follow the normal DetNet IP flow
identification procedures defined in .
An implementation MUST support the provisioning for
handling any packet flows received via the DetNet MPLS data plane as
DetNet IP flows via configuration. Note that such configuration
MAY include support from PREOF on the incoming DetNet
MPLS flow.
DetNet IP over DetNet MPLS Traffic Treatment Procedures
The traffic treatment required for a particular DetNet IP flow is
provisioned via configuration or the Controller Plane. When a DetNet
IP flow is sent over DetNet MPLS, a DetNet relay node
MUST ensure that the provisioned DetNet IP traffic
treatment is provided at the forwarding sub-layer as described in
. Note that PRF
MAY be utilized when sending IP over MPLS.
Traffic treatment for DetNet IP flows received over the DetNet MPLS
data plane MUST follow (DetNet IP
Traffic Treatment Procedures).
Management and Control Information Summary
The following summarizes the set of information that is needed to
support DetNet IP over DetNet MPLS at the MPLS ingress node:
Each MPLS App-Flow is selected from the incoming IP traffic using the IP flow
identification information defined in . This information is summarized in Section of that document and
includes all wildcards, port ranges, and the ability to ignore specific IP
fields.
The DetNet MPLS service that is to be used to send the matching IP
traffic. This matching information is provided in and includes both service and traffic delivery
information.
The following summarizes the set of information that is needed to
support DetNet IP over DetNet MPLS at the MPLS egress node:
The S-Label value that identifies the encapsulated App-flow traffic.
For each S-Label, how the received traffic is to be handled. The
traffic may be processed as any other DetNet IP traffic as defined
in this document or in ,
or the traffic may be directly treated as an MPLS App-flow for
additional processing according to .
It is the responsibility of the DetNet Controller Plane to
properly provision both flow identification information and
the flow-specific resources needed to provide the traffic
treatment to meet each flow's service requirements.
This applies for aggregated and individual flows.
Security Considerations
General security
considerations for DetNet are described in detail in .
DetNet MPLS and DetNet IP security considerations equally apply to this document and
are described in
and .
Security aspects that are unique to DetNet are those whose aim is to
protect the support of specific quality-of-service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
The primary considerations for the data plane are to maintain
integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected
through whatever means is provided by the underlying technology. For
example, encryption may be used, such as that provided by IPsec for IP flows and/or by an
underlying sub-net using MACsec for IP-over-Ethernet (Layer 2) flows.
From a data plane perspective, this document does not add or modify any
header information.
At the management and control level, DetNet flows are identified on a
per-flow basis, which may provide Controller Plane attackers with
additional information about the data flows (when compared to
Controller Planes that do not include per-flow identification). This
is an inherent property of DetNet, which has security implications that
should be considered when determining if DetNet is a suitable
technology for any given use case.
To provide uninterrupted availability of the DetNet service,
provisions can be made against DoS attacks and delay attacks. To
protect against DoS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example,
through the use of existing mechanisms such as policing and shaping
applied at the input of a DetNet domain. To prevent DetNet packets
from being delayed by an entity external to a DetNet domain, DetNet
technology definitions can allow for the mitigation of
man-in-the-middle attacks (for example, through use of authentication
and authorization of devices within the DetNet domain).
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Deterministic Networking ArchitectureThis document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.Deterministic Networking (DetNet) Data Plane FrameworkThis document provides an overall framework for the Deterministic Networking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well.Deterministic Networking (DetNet) Data Plane: IPThis document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).Deterministic Networking (DetNet) Data Plane: MPLSThis document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.Deterministic Networking (DetNet) Security ConsiderationsA DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.Informative ReferencesIEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) SecurityIEEEIEEE 802.1AE-2018Security Architecture for the Internet ProtocolThis document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]Acknowledgements
The authors wish to thank , , , , , , , , , , , and
for their various contributions to
this work.
Contributors
RFC 7322 limits the number of authors listed on the front page to a
maximum of 5. The editor wishes to thank and acknowledge the following
authors for contributing text to this document.
Ericssonjanos.farkas@ericsson.comMalis Consultingagmalis@gmail.com contributed substantially to the content of this
document.
Authors' AddressesEricssonMagyar Tudosok krt. 11.BudapestHungary1117balazs.a.varga@ericsson.comLabN Consulting, L.L.C.lberger@labn.netLabN Consulting, L.L.C.dfedyk@labn.netFuturewei Technologiessb@stewartbryant.comjouni.nospam@gmail.com