draft-ietf-detnet-dp-sol-mpls-00.txt   draft-ietf-detnet-dp-sol-mpls-01.txt 
DetNet J. Korhonen, Ed. DetNet J. Korhonen, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track B. Varga, Ed. Intended status: Standards Track B. Varga, Ed.
Expires: January 1, 2019 Ericsson Expires: April 24, 2019 Ericsson
June 30, 2018 October 21, 2018
DetNet MPLS Data Plane Encapsulation DetNet MPLS Data Plane Encapsulation
draft-ietf-detnet-dp-sol-mpls-00 draft-ietf-detnet-dp-sol-mpls-01
Abstract Abstract
This document specifies Deterministic Networking data plane This document specifies Deterministic Networking data plane
encapsulation solutions. The described data plane solutions is encapsulation solutions. The described data plane solutions is
applied over an MPLS Packet Switched Networks. applied over an MPLS Packet Switched Networks.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 1, 2019. This Internet-Draft will expire on April 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms used in this document . . . . . . . . . . . . . . . 4 2.1. Terms used in this document . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements language . . . . . . . . . . . . . . . . . . . . 6 3. Requirements language . . . . . . . . . . . . . . . . . . . . 6
4. MPLS DetNet data plane overview . . . . . . . . . . . . . . . 6 4. MPLS DetNet data plane overview . . . . . . . . . . . . . . . 6
4.1. DetNet data plane encapsulation requirements . . . . . . 12 4.1. Layers of DetNet data plane . . . . . . . . . . . . . . . 6
5. DetNet encapsulation . . . . . . . . . . . . . . . . . . . . 13 4.2. MPLS DetNet data plane scenarios . . . . . . . . . . . . 7
4.3. Packet flow example (service protection) . . . . . . . . 11
5. DetNet MPLS Data Considerations . . . . . . . . . . . . . . . 12
5.1. End-system specific considerations . . . . . . . . . . . 13 5.1. End-system specific considerations . . . . . . . . . . . 13
5.2. DetNet domain specific considerations . . . . . . . . . . 15 5.2. DetNet domain specific considerations . . . . . . . . . . 15
5.2.1. DetNet Layer Two Service . . . . . . . . . . . . . . 15 5.2.1. DetNet Layer Two Service . . . . . . . . . . . . . . 16
5.2.2. DetNet Routing Service (IP over MPLS) . . . . . . . . 16 5.2.2. DetNet Routing Service (IP over MPLS) . . . . . . . . 17
5.3. DetNet Inter-Working Function (DN-IWF) . . . . . . . . . 17 5.3. DetNet Inter-Working Function (DN-IWF) . . . . . . . . . 18
5.3.1. Networks with multiple technology segments . . . . . 17 5.3.1. Networks with multiple technology segments . . . . . 18
5.3.2. DN-IWF related considerations . . . . . . . . . . . . 18 5.3.2. DN-IWF related considerations . . . . . . . . . . . . 19
6. MPLS-based DetNet data plane solution . . . . . . . . . . . . 19 6. MPLS-based DetNet data plane solution . . . . . . . . . . . . 20
6.1. DetNet over MPLS Encapsulation Components . . . . . . . . 19 6.1. DetNet over MPLS Encapsulation Components . . . . . . . . 20
6.2. MPLS data plane encapsulation . . . . . . . . . . . . . . 21 6.2. MPLS data plane encapsulation . . . . . . . . . . . . . . 22
6.3. DetNet control word . . . . . . . . . . . . . . . . . . . 22 6.3. DetNet control word . . . . . . . . . . . . . . . . . . . 23
6.4. Flow Identification . . . . . . . . . . . . . . . . . . . 23 6.4. Flow Identification . . . . . . . . . . . . . . . . . . . 24
6.5. Indication of the DetNet Payload Type . . . . . . . . . . 23 6.5. Indication of the DetNet Payload Type . . . . . . . . . . 24
6.6. OAM Indication . . . . . . . . . . . . . . . . . . . . . 24 6.6. OAM Indication . . . . . . . . . . . . . . . . . . . . . 25
6.7. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 24 6.7. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 25
6.7.1. Aggregation at the LSP . . . . . . . . . . . . . . . 25 6.7.1. Aggregation at the LSP . . . . . . . . . . . . . . . 26
6.7.2. Aggregating DetNet flows as a new DetNet flow . . . . 25 6.7.2. Aggregating DetNet flows as a new DetNet flow . . . . 26
6.7.3. Simple Aggregation at the DetNet layer . . . . . . . 26 6.7.3. Simple Aggregation at the DetNet layer . . . . . . . 27
6.8. Service Layer Considerations . . . . . . . . . . . . . . 27 6.8. Service Layer Considerations . . . . . . . . . . . . . . 28
6.8.1. Edge node processing . . . . . . . . . . . . . . . . 27 6.8.1. Edge node processing . . . . . . . . . . . . . . . . 28
6.8.2. Relay node processing . . . . . . . . . . . . . . . . 28 6.8.2. Relay node processing . . . . . . . . . . . . . . . . 29
6.9. Other DetNet data plane considerations . . . . . . . . . 29 6.9. Other DetNet data plane considerations . . . . . . . . . 30
6.9.1. Class of Service . . . . . . . . . . . . . . . . . . 29 6.9.1. Class of Service . . . . . . . . . . . . . . . . . . 30
6.9.2. Quality of Service . . . . . . . . . . . . . . . . . 30 6.9.2. Quality of Service . . . . . . . . . . . . . . . . . 31
6.9.3. Cross-DetNet flow resource aggregation . . . . . . . 31 6.9.3. Cross-DetNet flow resource aggregation . . . . . . . 32
6.9.4. Layer 2 addressing and QoS Considerations . . . . . . 32 6.9.4. Layer 2 addressing and QoS Considerations . . . . . . 33
6.9.5. Time Synchronization . . . . . . . . . . . . . . . . 32 6.9.5. Time Synchronization . . . . . . . . . . . . . . . . 33
7. Management and control considerations . . . . . . . . . . . . 33 7. Management and control considerations . . . . . . . . . . . . 34
7.1. MPLS-based data plane . . . . . . . . . . . . . . . . . . 33 7.1. MPLS-based data plane . . . . . . . . . . . . . . . . . . 34
7.1.1. S-Label assignment and distribution . . . . . . . . . 33 7.1.1. S-Label assignment and distribution . . . . . . . . . 34
7.1.2. Explicit routes . . . . . . . . . . . . . . . . . . . 33 7.1.2. Explicit routes . . . . . . . . . . . . . . . . . . . 34
7.2. Packet replication and elimination . . . . . . . . . . . 34 7.2. Packet replication and elimination . . . . . . . . . . . 35
7.3. Congestion protection and latency control . . . . . . . . 35 7.3. Congestion protection and latency control . . . . . . . . 36
7.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 35 7.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 36
7.5. Flow aggregation control . . . . . . . . . . . . . . . . 35 7.5. Flow aggregation control . . . . . . . . . . . . . . . . 36
8. DetNet IP Operation over DetNet MPLS Service . . . . . . . . 35 8. DetNet IP Operation over DetNet MPLS Service . . . . . . . . 36
9. IEEE 802.1 TSN Interconnection over DetNet MPLS Service . . . 36 9. IEEE 802.1 TSN Interconnection over DetNet MPLS Service . . . 37
10. DetNet MPLS Transport Layer Operation over IEEE 802.1 TSN 10. DetNet MPLS Transport Layer Operation over IEEE 802.1 TSN
Sub-Networks . . . . . . . . . . . . . . . . . . . . . . . . 36 Sub-Networks . . . . . . . . . . . . . . . . . . . . . . . . 37
11. DetNet MPLS Transport Layer Operation over IP DetNet PSNs . . 36 10.1. Mapping of TSN Stream ID and Sequence Number . . . . . . 38
12. Security considerations . . . . . . . . . . . . . . . . . . . 38 10.2. TSN Usage of FRER . . . . . . . . . . . . . . . . . . . 40
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 38 10.3. Management and Control Implications . . . . . . . . . . 40
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 11. DetNet MPLS Transport Layer Operation over IP DetNet PSNs . . 40
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 12. Security considerations . . . . . . . . . . . . . . . . . . . 42
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 42
16.1. Normative references . . . . . . . . . . . . . . . . . . 41 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 43
16.2. Informative references . . . . . . . . . . . . . . . . . 44 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
Appendix A. Example of DetNet data plane operation . . . . . . . 45 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 16.1. Normative references . . . . . . . . . . . . . . . . . . 45
16.2. Informative references . . . . . . . . . . . . . . . . . 48
Appendix A. Example of DetNet data plane operation . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 with a low a network to DetNet flows. DetNet provides these flows with a low
packet loss rates and assured maximum end-to-end delivery latency. packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in General background and concepts of DetNet can be found in
[I-D.ietf-detnet-architecture]. [I-D.ietf-detnet-architecture].
This document specifies the DetNet data plane and the on-wire This document specifies the DetNet data plane and the on-wire
skipping to change at page 4, line 26 skipping to change at page 4, line 29
functions. An S-Label is also used to identify a functions. An S-Label is also used to identify a
DetNet flow at DetNet service layer. DetNet flow at DetNet service layer.
PEF A Packet Elimination Function (PEF) eliminates PEF A Packet Elimination Function (PEF) eliminates
duplicate copies of packets received by an edge or a duplicate copies of packets received by an edge or a
relay node to prevent excess packets flooding the relay node to prevent excess packets flooding the
network, or to prevent duplicate packets being sent out network, or to prevent duplicate packets being sent out
of the DetNet domain. of the DetNet domain.
PRF A Packet Replication Function (PRF) replicates DetNet PRF A Packet Replication Function (PRF) replicates DetNet
flow packets in an edge or a relay node and forwards flow packets and forwards them to one or more next hops
them to one or more next hops in the DetNet domain. in the DetNet domain. The number of packet copies sent
The number of packet copies sent to each next hop is a to each next hop is a DetNet flow specific parameter at
DetNet Flow specific parameter at the node doing the the node doing the replication. PRF can be implemented
replication. by an edge node, a relay node, or an end system.
POF A Packet Order Function (POF) re-orders packets within POF A Packet Ordering Function (POF) re-orders packets
a DetNet flow that are received out of order. This within a DetNet flow that are received out of order.
function may be implemented at an edge or a relay node. This function can be implemented by an edge node, a
relay node, or an end system.
PREOF Collective name for Packet Replication, Elimination, PREOF Collective name for Packet Replication, Elimination,
and Ordering Functions. and Ordering Functions.
d-CW A DetNet Control Word (d-CW) is used for sequencing and d-CW A DetNet Control Word (d-CW) is used for sequencing and
identifying duplicate packets of a DetNet flow at the identifying duplicate packets of a DetNet flow at the
DetNet service layer. DetNet service layer.
2.2. Abbreviations 2.2. Abbreviations
skipping to change at page 6, line 19 skipping to change at page 6, line 23
3. Requirements language 3. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. MPLS DetNet data plane overview 4. MPLS DetNet data plane overview
4.1. Layers of DetNet data plane
This document describes how DetNet flows are carried over MPLS This document describes how DetNet flows are carried over MPLS
networks. The DetNet Architecture, [I-D.ietf-detnet-architecture], networks. The DetNet Architecture, [I-D.ietf-detnet-architecture],
decomposes the DetNet data plane into two layers: a service layer and decomposes the DetNet data plane into two layers: a service layer and
a transport layer. The basic approach defined in this document a transport layer. The basic approach defined in this document
supports the DetNet service layer based on existing pseudowire (PW) supports the DetNet service layer based on existing pseudowire (PW)
encapsulations and mechanisms, and supports the DetNet transport encapsulations and mechanisms, and supports the DetNet transport
layer based on existing MPLS Traffic Engineering encapsulations and layer based on existing MPLS Traffic Engineering encapsulations and
mechanisms. Background on PWs can be found in [RFC3985] and mechanisms. Background on PWs can be found in [RFC3985] and
[RFC3031]. [RFC3031].
skipping to change at page 7, line 5 skipping to change at page 7, line 7
Figure 1: DetNet adaptation to MPLS data plane Figure 1: DetNet adaptation to MPLS data plane
The MPLS DetNet data plane approach defined in this document is shown The MPLS DetNet data plane approach defined in this document is shown
in Figure 1. The service layer is supported by a DetNet control word in Figure 1. The service layer is supported by a DetNet control word
(d-CW) which conforms to the Generic PW MPLS Control Word (PWMCW) (d-CW) which conforms to the Generic PW MPLS Control Word (PWMCW)
defined in [RFC4385]. A d-CW identifying service label (S-Label) is defined in [RFC4385]. A d-CW identifying service label (S-Label) is
also used. The transport layer is supported by one or labels also used. The transport layer is supported by one or labels
(T-Labels). (T-Labels).
A node operating on a DetNet flow in the Detnet layer, i.e. a node
processing a DetNet packet which has the S-label as top of stack uses
the local context associated with that S-label to determine what
local operation(s) are applied to that packet. The S-label has to be
unique on each edge and relay node, which is achieved by using a
label taken from the platform label space [RFC3031].
4.2. MPLS DetNet data plane scenarios
TSN Edge Transit Edge TSN TSN Edge Transit Edge TSN
End System Node Node Node End System End System Node Node Node End System
(T-PE) (LSR) (T-PE) (T-PE) (LSR) (T-PE)
+---------+ +.........+ +.........+ +---------+ +---------+ +.........+ +.........+ +---------+
| Appl. |<--:Svc Proxy:--End to End Svc.--:Svc Proxy:-->| Appl. | | Appl. |<--:Svc Proxy:--End to End Svc.--:Svc Proxy:-->| Appl. |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| TSN | |TSN| |Svc|<-- DetNet flow -->: Service :-->| TSN | | TSN | |TSN| |Svc|<-- DetNet flow -->: Service :-->| TSN |
+---------+ +---+ +---+ +---------+ +---------+ +---------+ +---------+ +---+ +---+ +---------+ +---------+ +---------+
|Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport| |Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport|
skipping to change at page 7, line 33 skipping to change at page 7, line 44
Figure 2: A TSN over DetNet MPLS Enabled Network Figure 2: A TSN over DetNet MPLS Enabled Network
Figure 2 shows several node types defined in Figure 2 shows several node types defined in
[I-D.ietf-detnet-architecture]. DetNet Edge Nodes sit at the [I-D.ietf-detnet-architecture]. DetNet Edge Nodes sit at the
boundary of a DetNet domain. They are responsible for mapping non- boundary of a DetNet domain. They are responsible for mapping non-
DetNet aware traffic to DetNet services. They also support the DetNet aware traffic to DetNet services. They also support the
imposition and disposition of the required DetNet encapsulation. imposition and disposition of the required DetNet encapsulation.
These are functionally similar to pseudowire (PW) Terminating These are functionally similar to pseudowire (PW) Terminating
Provider Edge (T-PE) nodes which use MPLS-TE LSPs. Provider Edge (T-PE) nodes which use MPLS-TE LSPs.
Native TSN flow and DetNet MPLS flow differ not only by the
additional MPLS specific encapsulation, but DetNet MPLS flows have on
each DetNet node an associated DetNet specific data structure, what
defines flow related characteristics and required forwarding
functions. Edge Nodes MUST provide a Service Proxy entity that
"associates" the DetNet flows and native flows at the edge of the
DetNet domain. It ensures that the DN Flow is properly served at the
Edge node (and inside the domain).
Transit nodes are normal MPLS Label Switching Routers (LSRs). They Transit nodes are normal MPLS Label Switching Routers (LSRs). They
are generally unaware of the special requirements of DetNet flows, are generally unaware of the special requirements of DetNet flows,
although they need to provide traffic engineering services and proper although they need to provide traffic engineering services and proper
QoS to the LSPs associated with DetNet flows to enhance the prospect QoS to the LSPs associated with DetNet flows to enhance the prospect
of the LSPs meeting the DetNet service requirements. Some of the LSPs meeting the DetNet service requirements. Some
implementations of transit nodes may be DetNet aware, but such nodes implementations of transit nodes may be DetNet aware, but such nodes
just support the DetNet transport layer. just support the DetNet transport layer.
The MPLS LSP may be provided by any MPLS method (provisioned, RSVP- The MPLS LSP may be provided by any MPLS method (provisioned, RSVP-
TE, MPLS- TP, or MPLS Segment Routing (SR)). TE, MPLS- TP, or MPLS Segment Routing (SR)).
skipping to change at page 9, line 19 skipping to change at page 9, line 22
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | E1 |=======| R1 |=======| E2 | | +---+ +---+ | | E1 |=======| R1 |=======| E2 | | +---+
| |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| | | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| |
|CE1| | | \ | | X | | / | | |CE2| |CE1| | | \ | | X | | / | | |CE2|
| | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | | | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Edge Node Relay Node Edge Node | | Edge Node Relay Node Edge Node |
| (T-PE) (S-PE) (T-PE) | | (T-PE) (S-PE) (T-PE) |
| | | |
|<--TSN--> <---- TSN Over DetNet MPLS ----> <--TSN-->| |<-TSN-> <------- TSN Over DetNet MPLS ---------> <-TSN->|
| | | |
|<--- Emulated Time Sensitive Networking (TSN) Service --->| |<--- Emulated Time Sensitive Networking (TSN) Service --->|
DFx = DetNet Flow x DFx = DetNet Flow x
Figure 4: IEEE 802.1TSN over DetNet Figure 4: IEEE 802.1TSN over DetNet
[Editor's note: TSN Over DetNet MPLS arrows extended beyond the 'X'
(the PREF points).]
Figure 5 illustrates how an end to end MPLS-based DetNet service is Figure 5 illustrates how an end to end MPLS-based DetNet service is
provided in a more detail. In this case, the end systems, CE1 and provided in a more detail. In this case, the end systems, CE1 and
CE2, are able to send and receive DetNet flows, and R1 and R2 are CE2, are able to send and receive DetNet flows, and R1 and R2 are
relay nodes as they sit in the middle of a DetNet network. For relay nodes as they sit in the middle of a DetNet network. For
example, an end system sends data encapsulated in MPLS. The 'X' in example, an end system sends data encapsulated in MPLS. The 'X' in
the end systems, and relay nodes represents potential DetNet flow the end systems, and relay nodes represents potential DetNet flow
packet replication and elimination points. Here the relay nodes may packet replication and elimination points. In this figure, the relay
change the underlying transport, for example tunneling MPLS over IP nodes may change the underlying transport, for example tunneling MPLS
Section 11, or simply interconnect network segments. over IP Section 11, or simply interconnect network segments.
DetNet DetNet DetNet DetNet
MPLS Service Transit Transit Service MPLS MPLS Service Transit Transit Service MPLS
DetNet | |<-Tnl->| |<-Tnl->| | DetNet DetNet | |<-Tnl->| |<-Tnl->| | DetNet
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2| |CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
skipping to change at page 10, line 45 skipping to change at page 10, line 45
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | E1 |=======| R2 |=======| E3 | | +---+ +---+ | | E1 |=======| R2 |=======| E3 | | +---+
| |--------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|------| | | |--------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|------| |
|CE1| | | \ | | X | | / | | |CE2| |CE1| | | \ | | X | | / | | |CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
^ Edge Node Relay Node Edge Node^ ^ Edge Node Relay Node Edge Node^
| (T-PE) (S-PE) (T-PE) | | (T-PE) (S-PE) (T-PE) |
| | | |
<--IP-->| <----- IP Over DetNet MPLS ----> |<--IP--> <--IP-->| <-------- IP Over DetNet MPLS ---------> |<--IP-->
| | | |
|<------ End to End DetNet Service ------->| |<------ End to End DetNet Service ------->|
Figure 6: MPLS-Based DetNet (non-MPLS End System) Figure 6: MPLS-Based DetNet (non-MPLS End System)
Figure 7 illustrates how end to end DetNet service is provided where Figure 7 illustrates how end to end DetNet service is provided where
the end systems are able to send and receive IP DetNet flows, e.g., the end systems are able to send and receive IP DetNet flows, e.g.,
per [I-D.ietf-detnet-dp-sol-ip], and the MPLS nodes optionally per [I-D.ietf-detnet-dp-sol-ip], and the MPLS nodes optionally
provide service protection. In this case R1 and R3 are T-PEs and R2 provide service protection. In this case R1 and R3 are T-PEs and R2
is an S-PE and the DetNet service is end-to-end. is an S-PE and the DetNet service is end-to-end.
DetNet DetNet DetNet DetNet
IP Service Transit Transit Service IP IP Service Transit Transit Service IP
DetNet |<-Tnl->| |<-Tnl->| DetNet DetNet |<-Tnl->| |<-Tnl->| DetNet
End | V 1 V V 2 V | End End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+ +---+ | | R1 |=======| R2 |=======| R3 | | +---+
| |--------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|------| | | |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| |
|CE1| | | \ | | X | | / | | |CE2| |CE1| | | \ | | X | | / | | |CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+ +---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^ ^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node | | Relay Node Relay Node Relay Node |
| (T-PE) (S-PE) (T-PE) | | (T-PE) (S-PE) (T-PE) |
| | | |
|<-DN IP-> <------ DetNet MPLS ------> <-DN IP->| |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
| | | |
|<--------------- End to End DetNet Service -------------->| |<-------------- End to End DetNet Service --------------->|
Figure 7: DetNet IP over DetNet (DN) MPLS Figure 7: DetNet IP over DetNet (DN) MPLS
4.3. Packet flow example (service protection)
An example MPLS DetNet network fragment and packet flow is An example MPLS DetNet network fragment and packet flow is
illustrated in Figure 8. illustrated in Figure 8.
1 1.1 1.1 1.2.1 1.2.1 1.2.2 1 1.1 1.1 1.2.1 1.2.1 1.2.2
CE1----EN1--------R1-------R2-------R3--------EN2-----CE2 CE1----EN1--------R1-------R2-------R3--------EN2-----CE2
\ 1.2.1 / / \ 1.2.1 / /
\1.2 /-----+ / \1.2 /-----+ /
+------R4------------------------+ +------R4------------------------+
1.2.2 1.2.2
skipping to change at page 12, line 32 skipping to change at page 12, line 35
packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips
any DetNet encapsulation from packet copy 1.2.2 and forwards the any DetNet encapsulation from packet copy 1.2.2 and forwards the
packet to CE2. When EN2 receives the later packet copy 1.2.1 this is packet to CE2. When EN2 receives the later packet copy 1.2.1 this is
discarded. discarded.
The above is of course illustrative of many network scenarios that The above is of course illustrative of many network scenarios that
can be configured. Between a pair of relay nodes there may be one or can be configured. Between a pair of relay nodes there may be one or
more transport nodes that simply forward the DetNet traffic, but more transport nodes that simply forward the DetNet traffic, but
these are omitted for clarity. these are omitted for clarity.
4.1. DetNet data plane encapsulation requirements 5. DetNet MPLS Data Considerations
Two major groups of scenarios can be distinguished which require flow This section provides informative considerations related to providing
identification during transport: DetNet service to flows which are identified based on their header
information. At a high level, the following are provided on a per
flow basis:
1. DetNet function related scenarios: Congestion protection and latency control:
* Congestion protection and latency control: usage of allocated Usage of allocated resources (queuing, policing, shaping) to
resources (queuing, policing, shaping). ensure that the congestion-related loss and latency/jitter
requirements of a DetNet flow are met.
* Explicit routes: select/apply the flow specific path. Explicit routes:
* Service protection: recognize DetNet compound and member flows Use of a specific path for a flow. This limits miss-ordering and
for replication an elimination. latency.
2. OAM function related scenarios: Service protection:
* troubleshooting (e.g., identify misbehaving flows, etc.) Which in the case of this document primarily relates to
* recognize flow(s) for analytics (e.g., increase counters, replication and elimination. Changing the explicit path after a
etc.) failure is detected in order to restore delivery of the required
DetNet service characteristics is also possible. Path changes,
even in the case of failure recovery, can lead to the out of order
delivery of data.
* correlate events with flows (e.g., volume above threshold, Load sharing:
etc.)
* etc. Generally, distributing packets of the same DetNet flow over
multiple paths is not recommended. Such load sharing, e.g., via
ECMP or UCMP, impacts ordering and end-to-end jitter.
The DetNet data plane allows for the aggregation of DetNet flows, Troubleshooting:
e.g., via MPLS hierarchical LSPs, to improved scaling. When DetNet
flows are aggregated, transit nodes may have limited ability to For example, to support identification of misbehaving flows.
provide service on per-flow DetNet identifiers. Therefore,
Recognize flow(s) for analytics:
For example, increase counters.
Correlate events with flows:
For example, unexpected loss.
The DetNet data plane also allows for the aggregation of DetNet
flows, e.g., via MPLS hierarchical LSPs, to improved scaling. When
DetNet flows are aggregated, transit nodes may have limited ability
to provide service on per-flow DetNet identifiers. Therefore,
identifying each individual DetNet flow on a transit node may not be identifying each individual DetNet flow on a transit node may not be
achieved in some network scenarios, but DetNet service can still be achieved in some network scenarios, but DetNet service can still be
assured in these scenarios through resource allocation and control. assured in these scenarios through resource allocation and control.
A node operating on a DetNet flow in the Detnet layer, i.e. a node
processing a DetNet packet which has the S-label as top of stack uses
the local context associated with that S-label to determine what
local operation(s) are applied to that packet. The S-label has to be
unique on each edge and relay node, which is achieved by using a
label taken from the platform label space [RFC3031].
5. DetNet encapsulation
5.1. End-system specific considerations 5.1. End-system specific considerations
Data-flows requiring DetNet service are generated and terminated on Data-flows requiring DetNet service are generated and terminated on
end-systems. Encapsulation depends on application and its end-systems. Encapsulation depends on application and its
preferences. In a DetNet (or even a TSN) domain the DN (TSN) preferences. In a DetNet (or even a TSN) domain the DN (TSN)
functions use at most two flow parameters, namely Flow-ID and functions use at most two flow parameters, namely Flow-ID and
Sequence Number. However, an application may exchange further flow Sequence Number. However, an application may exchange further flow
related parameters (e.g., time-stamp), which are not considered by DN related parameters (e.g., time-stamp), which are not considered by DN
functions. functions.
Two types of end-systems are distinguished: Two types of end-systems are distinguished:
o L2 (Ethernet) end-system: application directly over L2. o L2 (Ethernet) end-system: application directly over L2.
o L3 (IP) end-system: application over L3. o L3 (IP) end-system: application over L3.
Note: An MPLS DetNet end system (as shown in Figure 5) can be treated
as a combination of an L3 (IP) end-system and an MPLS DetNet edge
node.
In case of Ethernet end-systems the application data is encapsulated In case of Ethernet end-systems the application data is encapsulated
directly in L2. From the DN domain perspective no upper layer directly in L2. From the DN domain perspective no upper layer
protocols are visible. The Data-flow uses only Ethernet tag(s) and protocols are visible. The Data-flow uses only Ethernet tag(s) and
further flow specific parameters (if needed) are hidden inside the further flow specific parameters (if needed) are hidden inside the
protocol data unit (PDU). protocol data unit (PDU).
The IP end-system scenario is different. Data-flows are encapsulated The IP end-system scenario is different. In this case, data-flows
directly in L3 (i.e., IP) and the application may use further upper are encapsulated directly in IP and, typically, other higher layer
layer protocols (e.g., Real-time Transport Protocol (RTP)). Many protocols such as UDP and Real-time Transport Protocol (RTP). Many
valid combinations exist, and it may be application specific how the valid combinations exist and it is up to applications to select
IP header fields are used. Also, usage of further upper layer specific headers to be used. Details on support for DetNet IP data
protocols depends on application requirements (e.g., time-stamp). flows can be found in [I-D.ietf-detnet-dp-sol-ip].
See [I-D.ietf-detnet-dp-sol-ip] more details.
[Editor's note: IP solution document does not really detail
anything beyond 6-tuple.]
As a general rule, DetNet domains MUST be capable of forwarding any As a general rule, DetNet domains MUST be capable of forwarding any
Data-flows and the DetNet domain MUST NOT mandate the end-system Data-flows and the DetNet domain MUST NOT mandate the end-system
encapsulation format. encapsulation format.
Furthermore, no application-level-proxy function is envisioned inside Furthermore, no application-level-proxy function is envisioned inside
the DetNet domain, so end-systems peer with end-systems using the the DetNet domain, so end-systems peer with end-systems using the
same application encapsulation format (see figure below): same application encapsulation format (see figure below):
o L2 end-systems peer with L2 end-systems and o L2 end-systems peer with L2 end-systems and
skipping to change at page 16, line 43 skipping to change at page 17, line 43
+------+ +------+ +------+ +------+ +------+ +------+
| IP | | IP |
+------+ +------+
| L2 | | L2 |
+------+ +------+
Figure 11: Encapsulation format for DetNet Layer Two Service Figure 11: Encapsulation format for DetNet Layer Two Service
As shown in Figure 11 both L2 and L3 end-systems can be served by As shown in Figure 11 both L2 and L3 end-systems can be served by
such a DetNet L2 encapsulation service. This encapsulation service such a DetNet L2 encapsulation service. This encapsulation service
may be carried over MPLS natively Section 6.2, of over MPLS over IP may be carried over MPLS natively Section 6.2, or over MPLS over IP
Section 11. Section 11.
5.2.2. DetNet Routing Service (IP over MPLS) 5.2.2. DetNet Routing Service (IP over MPLS)
IP traffic and IP DetNet flows, see [I-D.ietf-detnet-dp-sol-ip], can IP traffic and IP DetNet flows, see [I-D.ietf-detnet-dp-sol-ip], can
be carried over a DetNet MPLS domain. In such cases, the IP headers be carried over a DetNet MPLS domain. In such cases, the IP headers
are modified per standard router behavior, e.g., TTL handling. are modified per standard router behavior, e.g., TTL handling.
Figure 12 shows the encapsulation of an IP flow over MPLS as well as Figure 12 shows the encapsulation of an IP flow over MPLS as well as
when MPLS is carried over an IP PSN, see Section 11. when MPLS is carried over an IP PSN, see Section 11.
skipping to change at page 33, line 5 skipping to change at page 34, line 5
will be updated/removed if such a document is available before will be updated/removed if such a document is available before
publication of this text.] publication of this text.]
Time synchronization is important both from the perspective of Time synchronization is important both from the perspective of
operating the DetNet network itself and from the perspective of operating the DetNet network itself and from the perspective of
transferring time across the network between client applications. transferring time across the network between client applications.
Some clients may be able to use the DetNet as their provider of time Some clients may be able to use the DetNet as their provider of time
and frequency, others may require the DetNet to transfer time between and frequency, others may require the DetNet to transfer time between
a client clock source and a client clock user. a client clock source and a client clock user.
The reader's attention is drawn to [RFC8169] which describes a method For example, [RFC8169] describes a method of recording the packet
of recording the packet queuing time in an MPLS LSR on a packet by queuing time in an MPLS LSR on a packet by per packet basis and
per packet basis and forwarding this information to the egress edge forwarding this information to the egress edge system. This allows
system. This allows compensation for any variable packet queuing compensation for any variable packet queuing delay to be applied at
delay to be applied at the packet receiver. The mechanism described the packet receiver. Other mechanisms for IP/MPLS networks are
in [RFC8169] may have wider application than basic time transfer in a defined based on IEEE Standard 1588 [IEEE1588], such as ITU-T
DetNet. [G.8275.1] and [G.8275.2].
A more detailed discussion of time synchronization is outside the A more detailed discussion of time synchronization is outside the
scope of this document. scope of this document.
7. Management and control considerations 7. Management and control considerations
[Editor's note: This section needs to be different for MPLS and IP [Editor's note: This section needs to be different for MPLS and IP
solutions. Most solutions are technology dependant. Currently most solutions. Most solutions are technology dependant. Currently most
text in this section is just a draft and may have bits that are text in this section is just a draft and may have bits that are
already moved to other places/documents.] already moved to other places/documents.]
skipping to change at page 36, line 17 skipping to change at page 37, line 17
[Editor's note: this is a place holder section. A standalone section [Editor's note: this is a place holder section. A standalone section
on TSN "island" interconnect over DetNet". Includes RFC2119 on TSN "island" interconnect over DetNet". Includes RFC2119
Language.] Language.]
10. DetNet MPLS Transport Layer Operation over IEEE 802.1 TSN Sub- 10. DetNet MPLS Transport Layer Operation over IEEE 802.1 TSN Sub-
Networks Networks
[Editor's note: this is a place holder section. A standalone section [Editor's note: this is a place holder section. A standalone section
on MPLS over IEEE 802.1 TSN. Includes RFC2119 Language.] on MPLS over IEEE 802.1 TSN. Includes RFC2119 Language.]
This section covers how MPLS DetNet flows operate over an IEEE 802.1
TSN sub-network. Figure 17 illustrates such a scenario, where two
MPLS (DetNet) nodes are interconnected by a TSN sub-network. Node-1
is single homed and Node-2 is dual-homed. MPLS nodes can be (1) MPLS
DetNet End System, (2) MPLS DetNet Edge or Relay node or (3) MPLS
Transit node.
Note: in case of MPLS Transit node there is no DetNet Service sub-
layer.
MPLS (DetNet) MPLS (DetNet)
Node-1 Node-2
+---------+ +---------+
<--| Service*|-- DetNet flow ---| Service*|-->
+---------+ +---------+
|Transport| |Transport|
+-------.-+ <-TSN Str-> +-.-----.-+
\ ,-------. / /
+----[ TSN-Sub ]---+ /
[ Network ]--------+
`-------'
<---------------- DetNet MPLS --------------->
Note: * no service sub-layer for transit nodes
Figure 17: DetNet Enabled MPLS Network over a TSN sub-network
The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
Working Group have defined (and are defining) a number of amendments
to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
bounded latency in bridged networks. Furthermore IEEE 802.1CB
[IEEE8021CB] defines frame replication and elimination functions for
reliability that should prove both compatible with and useful to,
DetNet networks. All these functions have to identify flows those
require TSN treatment.
As is the case for DetNet, a Layer 2 network node such as a bridge
may need to identify the specific DetNet flow to which a packet
belongs in order to provide the TSN/DetNet QoS for that packet. It
also may need a CoS marking, such as the priority field of an IEEE
Std 802.1Q VLAN tag, to give the packet proper service.
The challange for MPLS DeNet flows is that the protocol interworking
function defined in IEEE 802.1CB [IEEE8021CB] works only for IP
flows. The aim of the protocol interworking function is to convert
an ingress flow to use a specific multicast destination MAC address
and VLAN, for example to direct the packets through a specific path
inside the bridged network. A similar interworking pair at the other
end of the TSN sub-network would restore the packet to its original
destination MAC address and VLAN.
As protocol interworking function defined in [IEEE8021CB] does not
work for MPLS labeled flows, the MPLS DetNet nodes MUST ensure proper
TSN sub-network specific Ethernet encapsulation of the MPLS DetNet
packets. For a given TSN Stream (i.e., DetNet flow) an MPLS (DetNet)
node MUST behave as a TSN-aware Talker or a Listener inside the TSN
sub-network.
10.1. Mapping of TSN Stream ID and Sequence Number
TSN capable MPLS (DetNet) nodes are TSN-aware Talker/Listener as
shown in Figure 18. MPLS (DetNet) node MUST provide the TSN sub-
network specific Ethernet encapsulation over the link(s) towards the
sub-network. An TSN-aware MPLS (DetNet) node MUST support the
following TSN components:
1. For recognizing flows:
* Stream Identification (MPLS-flow-aware)
2. For FRER used inside the TSN domain, additonaly:
* Sequencing function (MPLS-flow-aware)
* Sequence encode/decode function
3. For FRER when the node is a TSN replication or elimination point,
additionally:
* Stream splitting function
* Individual recovery function
[Editor's note: Should we added here requirements regarding IEEE
802.1Q C-VLAN component?]
The Stream Identification and The Sequencing functions are slightly
modified for frames passed down the protocol stack from the upper
layers.
Stream Identification MUST pair MPLS flows and TSN Streams and encode
that in data plane formats as well. The packet's stream_handle
subparameter (see IEEE 802.1CB [IEEE8021CB]) inside the Talker/
Listener is defined based on the Flow-ID used in the upper MPLS
DetNet layer. Stream Identification function MUST encode Ethernet
header fields namely (1) the destination MAC-address, (2) the VLAN-ID
and (3) priority parameters with TSN sub-network specific values.
Encoding is provided for the frame passed down the stack from the
upper layers.
The sequence generation function resides in the Sequencing function.
It generates a sequence_number subparameter for each packet of a
Stream passed down to the lower layers. Sequencing function MUST
copy sequence information from the MPLS d-CW of the packet to the
sequence_number subparameter for the frame passed down the stack from
the upper layers.
MPLS (DetNet)
Node-1
<--------->
+---------+
<--| Service |-- DetNet flow ------------------
+---------+
|Transport|
+---------+ +---------------+
| L2 with |<---| L2 Relay with |---- TSN ----
| TSN | | TSN function | Stream
+----.----+ +--.---------.--+
\__________/ \______
TSN-aware
Talker / TSN-Bridge
Listener Relay
<--------- TSN sub-network ------------
Figure 18: MPLS (DetNet) node with TSN functions
The Sequence encode/decode function MUST support the Redundancy tag
(R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB].
10.2. TSN Usage of FRER
TSN Streams supporting DetNet flows may use Frame Replication and
Elimination for Redundancy (FRER) [802.1CB] based on the loss service
requirements of the TSN Stream, which is derived from the DetNet
service requirements of the DetNet mapped flow. The specific
operation of FRER is not modified by the use of DetNet and follows
IEEE 802.1CB [IEEE8021CB].
FRER function and the provided service recovery is available only
within the TSN sub-network however as the Stream-ID and the TSN
sequence number are paired with the MPLS flow parameters they can be
combined with PREOF functions.
10.3. Management and Control Implications
[Editor's note: This section is TBD Covers Creation, mapping, removal
of TSN Stream IDs, related parameters and,when needed, configuration
of FRER. Supported by management/control plane.]
11. DetNet MPLS Transport Layer Operation over IP DetNet PSNs 11. DetNet MPLS Transport Layer Operation over IP DetNet PSNs
This section specifies the DetNet encapsulation over an IP transport This section specifies the DetNet encapsulation over an IP transport
network. The approach is modeled on the operation of MPLS and network. The approach is modeled on the operation of MPLS and
PseudoWires (PW) over an IP Packet Switched Network (PSN) PseudoWires (PW) over an IP Packet Switched Network (PSN)
[RFC3985][RFC4385][RFC7510]. It is also based on the MPLS data plane [RFC3985][RFC4385][RFC7510]. It is also based on the MPLS data plane
encapsulation described in Section 6.2. encapsulation described in Section 6.2.
To carry DetNet with full functionality at the DetNet layer over an To carry DetNet with full functionality at the DetNet layer over an
IP transport network, the following components are required (these IP transport network, the following components are required (these
skipping to change at page 37, line 24 skipping to change at page 41, line 27
+---------------------------------+ <--/ +---------------------------------+ <--/
| UDP Header | | UDP Header |
+---------------------------------+ +---------------------------------+
| IP Header | | IP Header |
+---------------------------------+ +---------------------------------+
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
Figure 17: IP Encapsulation of DetNet Figure 19: IP Encapsulation of DetNet
Where the UDP header is used as defined in Section 3 of [RFC7510]. Where the UDP header is used as defined in Section 3 of [RFC7510].
As in Section 6.2, the S-Label is used to identify a DetNet flow to As in Section 6.2, the S-Label is used to identify a DetNet flow to
the peer node that processes it, in this case the node addressed by the peer node that processes it, in this case the node addressed by
the IP Header in Figure 17. The S-Label is allocated from the the IP Header in Figure 19. The S-Label is allocated from the
receiving node?s platform label space [RFC3031]. receiving node?s platform label space [RFC3031].
In ingress Edge Nodes, the encapsulation in Figure 17 will be imposed In ingress Edge Nodes, the encapsulation in Figure 19 will be imposed
on Detnet Flow Payload Packets as received from DetNet End Systems, on Detnet Flow Payload Packets as received from DetNet End Systems,
and the encapsulation will be removed in egress Edge Nodes as they and the encapsulation will be removed in egress Edge Nodes as they
transmit the Payload Packets to the End Systems. transmit the Payload Packets to the End Systems.
Note that this encapsulation works equally well with IPv4 and IPv6. Note that this encapsulation works equally well with IPv4 and IPv6.
This encapsulation can also be used in conjunction with segment This encapsulation can also be used in conjunction with segment
routing as specified in [I-D.ietf-spring-segment-routing-mpls]. In routing as specified in [I-D.ietf-spring-segment-routing-mpls]. In
this case, the T-Label(s) in Figure 17 should be retained, and at this case, the T-Label(s) in Figure 19 should be retained, and at
each hop, the top T-label is popped and mapped to a corresponding each hop, the top T-label is popped and mapped to a corresponding
UDP/IP tunnel, resulting in the following encapsulation: UDP/IP tunnel, resulting in the following encapsulation:
+---------------------------------+ +---------------------------------+
| | | |
| DetNet Flow | | DetNet Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
skipping to change at page 38, line 26 skipping to change at page 42, line 26
+---------------------------------+ +---------------------------------+
| UDP Header | | UDP Header |
+---------------------------------+ +---------------------------------+
| IP Header | | IP Header |
+---------------------------------+ +---------------------------------+
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
Figure 18: IP Encapsulation of DetNet with MPLS-SR Figure 20: IP Encapsulation of DetNet with MPLS-SR
Again, the UDP header is used as defined in Section 3 of [RFC7510]. Again, the UDP header is used as defined in Section 3 of [RFC7510].
Note that if required in both the case of IP Encapsulation of DetNet Note that if required in both the case of IP Encapsulation of DetNet
Figure 17, and of IP Encapsulation of DetNet with MPLS-SR Figure 18, Figure 19, and of IP Encapsulation of DetNet with MPLS-SR Figure 20,
it is possible to omit the UDP header if required. Operation of MPLS it is possible to omit the UDP header if required. Operation of MPLS
directly over IP is described in [RFC4023]. In this case DetNet directly over IP is described in [RFC4023]. In this case DetNet
Service can be provided on a per IP flow basis as described in Service can be provided on a per IP flow basis as described in
[I-D.ietf-detnet-dp-sol-ip]. [I-D.ietf-detnet-dp-sol-ip].
12. Security considerations 12. Security considerations
The security considerations of DetNet in general are discussed in The security considerations of DetNet in general are discussed in
[I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other [I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other
security considerations will be added in a future version of this security considerations will be added in a future version of this
skipping to change at page 44, line 16 skipping to change at page 48, line 16
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative references 16.2. Informative references
[G.8275.1]
International Telecommunication Union, "Precision time
protocol telecom profile for phase/time synchronization
with full timing support from the network", ITU-T
G.8275.1/Y.1369.1 G.8275.1, June 2016,
<https://www.itu.int/rec/T-REC-G.8275.1/en>.
[G.8275.2]
International Telecommunication Union, "Precision time
protocol telecom profile for phase/time synchronization
with partial timing support from the network", ITU-T
G.8275.2/Y.1369.2 G.8275.2, June 2016,
<https://www.itu.int/rec/T-REC-G.8275.2/en>.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-05 (work in progress), May 2018. detnet-architecture-08 (work in progress), September 2018.
[I-D.ietf-detnet-dp-alt] [I-D.ietf-detnet-dp-alt]
Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
and Solution Alternatives", draft-ietf-detnet-dp-alt-00 and Solution Alternatives", draft-ietf-detnet-dp-alt-00
(work in progress), October 2016. (work in progress), October 2016.
[I-D.ietf-detnet-dp-sol-ip] [I-D.ietf-detnet-dp-sol-ip]
Korhonen, J., Varga, B., "DetNet IP Data Plane Korhonen, J., Varga, B., "DetNet IP Data Plane
Encapsulation", 2018. Encapsulation", 2018.
[I-D.sdt-detnet-security] [I-D.sdt-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Mizrahi, T., Grossman, E., Hacker, A., Das, S.,
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
Considerations, draft-sdt-detnet-security, work in Considerations, draft-sdt-detnet-security, work in
progress", 2017. progress", 2017.
[IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems Version 2", 2008.
[IEEE8021CB] [IEEE8021CB]
Finn, N., "Draft Standard for Local and metropolitan area Finn, N., "Draft Standard for Local and metropolitan area
networks - Seamless Redundancy", IEEE P802.1CB networks - Seamless Redundancy", IEEE P802.1CB
/D2.1 P802.1CB, December 2015, /D2.1 P802.1CB, December 2015,
<http://www.ieee802.org/1/files/private/cb-drafts/ <http://www.ieee802.org/1/files/private/cb-drafts/
d2/802-1CB-d2-1.pdf>. d2/802-1CB-d2-1.pdf>.
[IEEE8021Q] [IEEE8021Q]
IEEE 802.1, "Standard for Local and metropolitan area IEEE 802.1, "Standard for Local and metropolitan area
networks--Bridges and Bridged Networks (IEEE Std 802.1Q- networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
 End of changes. 46 change blocks. 
133 lines changed or deleted 346 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/