draft-ietf-detnet-mpls-09.txt   draft-ietf-detnet-mpls-10.txt 
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 13, 2021 L. Berger Expires: January 27, 2021 L. Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
Malis Consulting Malis Consulting
S. Bryant S. Bryant
Futurewei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
July 12, 2020 July 26, 2020
DetNet Data Plane: MPLS DetNet Data Plane: MPLS
draft-ietf-detnet-mpls-09 draft-ietf-detnet-mpls-10
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating over an MPLS Packet Switched Networks. operating over an MPLS Packet Switched Network. It leverages
existing pseudowire (PW) encapsulations and MPLS Traffic Engineering
encapsulations and mechanisms. This document builds on the DetNet
Architecture and Data Plane Framework.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2021. This Internet-Draft will expire on January 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 34
4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9
4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10
4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14
4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17
4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17
4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17
4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18
4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19
4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19
4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20
4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20
4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20
4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21
5. Management and Control Information Summary . . . . . . . . . 21 5. Management and Control Information Summary . . . . . . . . . 21
5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22
5.1.1. Service Aggregation Information Summary . . . . . . . 23 5.1.1. Service Aggregation Information Summary . . . . . . . 23
5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows extremely low a network to DetNet flows. DetNet provides these flows with
packet loss rates and assured maximum end-to-end delivery latency. extremely low packet loss rates and assured maximum end-to-end
General background and concepts of DetNet can be found in [RFC8655]. delivery latency. General background and concepts of DetNet can be
found in [RFC8655].
The DetNet Architecture models the DetNet related data plane The DetNet Architecture models the DetNet related data plane
functions decomposed into two sub-layers: a service sub-layer and a functions decomposed into two sub-layers: a service sub-layer and a
forwarding sub-layer. The service sub-layer is used to provide forwarding sub-layer. The service sub-layer is used to provide
DetNet service functions such as protection and reordering. The DetNet service functions such as protection and reordering. The
forwarding sub-layer is used to provide forwarding assurance (low forwarding sub-layer is used to provide forwarding assurance (low
loss, assured latency, and limited reordering). loss, assured latency, and limited reordering).
This document specifies the DetNet data plane operation and the on- This document specifies the DetNet data plane operation and the on-
wire encapsulation of DetNet flows over an MPLS-based Packet Switched wire encapsulation of DetNet flows over an MPLS-based Packet Switched
Network (PSN) using the service sub-layer reference model. MPLS Network (PSN) using the service reference model. MPLS encapsulation
encapsulation already provides a solid foundation of building blocks already provides a solid foundation of building blocks to enable the
to enable the DetNet service and forwarding sub-layer functions. DetNet service and forwarding sub-layer functions. MPLS encapsulated
MPLS encapsulated DetNet can be carried over a variety of different DetNet can be carried over a variety of different network
network technologies that can provide the DetNet required level of technologies that can provide the DetNet required level of service.
service. However, the specific details of how DetNet MPLS is carried However, the specific details of how DetNet MPLS is carried over
over different network technologies is out of scope of this document. different network technologies is out of scope of this document.
MPLS encapsulated DetNet flows can carry different types of traffic. MPLS encapsulated DetNet flows can carry different types of traffic.
The details of the types of traffic that are carried in DetNet are The details of the types of traffic that are carried in DetNet are
also out of scope of this document. An example of IP using DetNet also out of scope of this document. An example of IP using DetNet
MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS
may use an associated controller and Operations, Administration, and may use an associated controller and Operations, Administration, and
Maintenance (OAM) functions that are defined outside of this Maintenance (OAM) functions that are defined outside of this
document. document.
Background information common to all data planes for DetNet can be Background information common to all data planes for DetNet can be
skipping to change at page 8, line 38 skipping to change at page 8, line 38
Figure 3: MPLS-Based Native DetNet Figure 3: MPLS-Based Native DetNet
4. MPLS-Based DetNet Data Plane Solution 4. MPLS-Based DetNet Data Plane Solution
4.1. DetNet Over MPLS Encapsulation Components 4.1. DetNet Over MPLS Encapsulation Components
To carry DetNet over MPLS the following is required: To carry DetNet over MPLS the following is required:
1. A method of identifying the MPLS payload type. 1. A method of identifying the MPLS payload type.
2. A method of identifying the DetNet flow group to the processing 2. A method of identifying the DetNet flow(s) to the processing
element. element.
3. A method of distinguishing DetNet OAM packets from DetNet data 3. A method of distinguishing DetNet OAM packets from DetNet data
packets. packets.
4. A method of carrying the DetNet sequence number. 4. A method of carrying the DetNet sequence number.
5. A suitable LSP to deliver the packet to the egress PE. 5. A suitable LSP to deliver the packet to the egress PE.
6. A method of carrying queuing and forwarding indication. 6. A method of carrying queuing and forwarding indication.
skipping to change at page 9, line 29 skipping to change at page 9, line 29
required queue processing as well as the forwarding parameters. Note required queue processing as well as the forwarding parameters. Note
that the possible use of Penultimate Hop Popping (PHP) means that the that the possible use of Penultimate Hop Popping (PHP) means that the
S-Label may be the only label received at the terminating DetNet S-Label may be the only label received at the terminating DetNet
service. service.
4.2. MPLS Data Plane Encapsulation 4.2. MPLS Data Plane Encapsulation
Figure 4 illustrates a DetNet data plane MPLS encapsulation. The Figure 4 illustrates a DetNet data plane MPLS encapsulation. The
MPLS-based encapsulation of the DetNet flows is well suited for the MPLS-based encapsulation of the DetNet flows is well suited for the
scenarios described in [I-D.ietf-detnet-data-plane-framework]. scenarios described in [I-D.ietf-detnet-data-plane-framework].
Furthermore, an end to end DetNet service i.e., native DetNet Furthermore, an end-to-end DetNet service i.e., native DetNet
deployment (see Section 3.2) is also possible if DetNet end systems deployment (see Section 3.2) is also possible if DetNet end systems
are capable of initiating and termination MPLS encapsulated packets. are capable of initiating and termination MPLS encapsulated packets.
The MPLS-based DetNet data plane encapsulation consists of: The MPLS-based DetNet data plane encapsulation consists of:
o DetNet control word (d-CW) containing sequencing information for o DetNet control word (d-CW) containing sequencing information for
packet replication and duplicate elimination purposes, and the OAM packet replication and duplicate elimination purposes, and the OAM
indicator. indicator.
o DetNet service Label (S-Label) that identifies a DetNet flow at o DetNet service Label (S-Label) that identifies a DetNet flow at
skipping to change at page 16, line 27 skipping to change at page 16, line 27
Resources may be allocated in a hierarchical fashion per LSP that is Resources may be allocated in a hierarchical fashion per LSP that is
represented by each F-Label. Each LSP MAY be provisioned with a represented by each F-Label. Each LSP MAY be provisioned with a
service parameters that dictates the specific traffic treatment to be service parameters that dictates the specific traffic treatment to be
received by the traffic carried over that LSP. Implementations of received by the traffic carried over that LSP. Implementations of
this document MUST ensure that traffic carried over each LSP this document MUST ensure that traffic carried over each LSP
represented by one or more F-Labels receives the traffic treatment represented by one or more F-Labels receives the traffic treatment
provisioned for that LSP. Typical mechanisms used to provide provisioned for that LSP. Typical mechanisms used to provide
different treatment to different flows includes the allocation of different treatment to different flows includes the allocation of
system resources (such as queues and buffers) and provisioning or system resources (such as queues and buffers) and provisioning or
related parameters (such as shaping, and policing). Support can also related parameters (such as shaping, and policing) that may be found
be provided via an underlying network technology such IEEE802.1 TSN in implementations of Resource ReSerVation Protocol (RSVP) [RFC2205]
[I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms used by a (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Support can also be
DetNet node to ensure DetNet service delivery requirements are met provided via an underlying network technology such IEEE802.1 TSN
[I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms selected by
a DetNet node to ensure DetNet service delivery requirements are met
for supported DetNet flows is outside the scope of this document. for supported DetNet flows is outside the scope of this document.
Packets that are marked in a way that do not correspond to allocated Packets that are marked in a way that do not correspond to allocated
resources, e.g., lack a provisioned F-Label, can disrupt the QoS resources, e.g., lack a provisioned F-Label, can disrupt the QoS
offered to properly reserved DetNet flows by using resources offered to properly reserved DetNet flows by using resources
allocated to the reserved flows. Therefore, the network nodes of a allocated to the reserved flows. Therefore, the network nodes of a
DetNet network: DetNet network:
o MUST defend the DetNet QoS by discarding or remarking (to an o MUST defend the DetNet QoS by discarding or remarking (to an
allocated DetNet flow or non-competing non-DetNet flow) packets allocated DetNet flow or non-competing non-DetNet flow) packets
skipping to change at page 22, line 10 skipping to change at page 22, line 16
Much like other MPLS labels, there are a number of alternatives Much like other MPLS labels, there are a number of alternatives
available for DetNet S-Label and F-Label advertisement to an upstream available for DetNet S-Label and F-Label advertisement to an upstream
peer node. These include distributed signaling protocols such as peer node. These include distributed signaling protocols such as
RSVP-TE, centralized label distribution via a controller that manages RSVP-TE, centralized label distribution via a controller that manages
both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc.,
and hybrid combinations of the two. The details of the controller and hybrid combinations of the two. The details of the controller
plane solution required for the label distribution and the management plane solution required for the label distribution and the management
of the label number space are out of scope of this document. There of the label number space are out of scope of this document. There
are particular DetNet considerations and requirements that are are particular DetNet considerations and requirements that are
discussed in [I-D.ietf-detnet-data-plane-framework]. discussed in [I-D.ietf-detnet-data-plane-framework]. Conformance
language is not used in the summary since it applies to future
mechanisms such as those that may be provided in signaling and YANG
models, e.g., [I-D.ietf-detnet-yang].
5.1. Service Sub-Layer Information Summary 5.1. Service Sub-Layer Information Summary
The following summarizes the information that is needed on service The following summarizes the information that is needed on service
sub-layer aware nodes that transmit DetNet MPLS traffic, on a per sub-layer aware nodes that transmit DetNet MPLS traffic, on a per
service basis: service basis:
o App-Flow identification information, e.g., IP information as o App-Flow identification information, e.g., IP information as
defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information
is not needed on DetNet relay nodes. is not needed on DetNet relay nodes.
skipping to change at page 24, line 29 skipping to change at page 24, line 40
forwarded as a transit node, or provided to the service sub-layer. forwarded as a transit node, or provided to the service sub-layer.
It is the responsibility of the DetNet controller plane to properly It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet resources needed to provided the traffic treatment needed to meet
each flow's service requirements. This applies for aggregated and each flow's service requirements. This applies for aggregated and
individual flows. individual flows.
6. Security Considerations 6. Security Considerations
General security considerations are described in [RFC8655]. Detailed security considerations for DetNet are cataloged in
Additionally, security considerations and a threat analysis are [I-D.ietf-detnet-security], and more general security considerations
described in [I-D.ietf-detnet-security]. This section considers are described in [RFC8655]. This section considers exclusively
security considerations which are specific to the DetNet MPLS data security considerations which are specific to the DetNet MPLS data
plane. The considerations raised related to MPLS networks in general plane. The considerations raised related to MPLS networks in general
in [RFC5920] are equally applicable to the the DetNet MPLS data in [RFC5920] are equally applicable to the the DetNet MPLS data
plane. plane.
Security aspects which are unique to DetNet are those whose aim is to Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency. and bounded end-to-end delivery latency. Achieving such loss rates
and bounded latency may not be possible in the face of a highly
capable adversary, such as the one envisioned by the Internet Threat
Model of BCP 72 that can arbitrarily drop or delay any or all
traffic. In order to present meaningful security considerations, we
consider a somewhat weaker attacker who does not control the physical
links of the DetNet domain, but may have the ability to control a
network node within the boundary of the DetNet domain.
The primary considerations for the data plane is to maintain The primary consideration for the DetNet data plane is to maintain
integrity of data and delivery of the associated DetNet service integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected traversing the DetNet network. Application flows can be protected
through whatever means is provided by the underlying technology. For through whatever means are provided by the underlying technology.
example, encryption may be used, such as that provided by IPSec For example, encryption may be used, such as that provided by IPsec
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
From a data plane perspective this document does not add or modify From a data plane perspective this document does not add or modify
any header information. any header information.
At the management and control level DetNet flows are identified on a At the management and control level DetNet flows are identified on a
per-flow basis, which may provide controller plane attackers with per-flow basis, which may provide controller plane attackers with
additional information about the data flows (when compared to additional information about the data flows (when compared to
controller planes that do not include per-flow identification). This controller planes that do not include per-flow identification). This
skipping to change at page 28, line 21 skipping to change at page 28, line 33
Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking
(TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in (TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in
progress), June 2020. progress), June 2020.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T. and E. Grossman, "Deterministic Networking Mizrahi, T. and E. Grossman, "Deterministic Networking
(DetNet) Security Considerations", draft-ietf-detnet- (DetNet) Security Considerations", draft-ietf-detnet-
security-10 (work in progress), May 2020. security-10 (work in progress), May 2020.
[I-D.ietf-detnet-yang]
Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Li, Z., and R.
Rahman, "Deterministic Networking (DetNet) Configuration
YANG Model", draft-ietf-detnet-yang-07 (work in progress),
July 2020.
[IEEE802.1AE-2018] [IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018, Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>. <https://ieeexplore.ieee.org/document/8585421>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
 End of changes. 18 change blocks. 
34 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/