< draft-ietf-detnet-ip-over-mpls-00.txt   draft-ietf-detnet-ip-over-mpls-01.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: November 6, 2019 L. Berger Expires: January 2, 2020 L. Berger
D. Fedyk
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
S. Bryant S. Bryant
Huawei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
May 5, 2019 July 1, 2019
DetNet Data Plane: IP over MPLS DetNet Data Plane: IP over MPLS
draft-ietf-detnet-ip-over-mpls-00 draft-ietf-detnet-ip-over-mpls-01
Abstract Abstract
This document specifies the Deterministic Networking data plane when This document specifies the Deterministic Networking data plane when
operating in an IP over MPLS packet switched network. operating in an IP over MPLS packet switched network.
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.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 November 6, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4
4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 5 4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 4
4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5 4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5
4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 8 4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6
4.3. DetNet IP over DetNet MPLS Flow Identification 5. IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8
Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. DetNet IP over DetNet MPLS Flow Identification
4.4. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 10 Procedures . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Management and Control Information Summary . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative references . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative references . . . . . . . . . . . . . . . . . 14 10.1. Normative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 10.2. Informative references . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 extremely 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 the DetNet General background and concepts of DetNet can be found in the DetNet
Architecture [I-D.ietf-detnet-architecture]. Architecture [I-D.ietf-detnet-architecture].
This document specifies the DetNet data plane operation for IP hosts This document specifies use of the IP DetNet encapsulation over an
and routers that provide DetNet service to IP encapsulated data. No MPLS network. It maps the IP data plane encapsulation described in
DetNet specific encapsulation is defined to support IP flows, rather [I-D.ietf-detnet-ip] to the DetNet MPLS data plane defined in
existing IP and higher layer protocol header information is used to [I-D.ietf-detnet-mpls].
support flow identification and DetNet service delivery.
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer. The service sub-layer is used to provide DetNet service
protection and reordering. The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering). Since no DetNet specific headers are added to
support DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document. Service
protection can be provided on a per sub-net basis using technologies
such as MPLS [I-D.ietf-detnet-mpls] and IEEE802.1 TSN.
This document provides an overview of the DetNet IP data plane over
MPLS.
2. Terminology 2. Terminology
2.1. Terms Used In This Document 2.1. Terms Used In This Document
This document uses the terminology and concepts established in the This document uses the terminology and concepts established in the
DetNet architecture [I-D.ietf-detnet-architecture] and DetNet architecture [I-D.ietf-detnet-architecture] and
[I-D.ietf-detnet-data-plane-framework], and the reader is assumed to [I-D.ietf-detnet-data-plane-framework], and the reader is assumed to
be familiar with these documents and their terminology. be familiar with these documents and their terminology.
2.2. Abbreviations 2.2. Abbreviations
This document uses the abbreviations defined in the DetNet This document uses the abbreviations defined in the DetNet
skipping to change at page 4, line 22 skipping to change at page 4, line 13
"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.
3. DetNet IP Data Plane Overview 3. DetNet IP Data Plane Overview
Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network
as a sub-network between the relay nodes. It shows a more complex as a sub-network between the relay nodes. It shows a more complex
DetNet enabled IP network where an IP flow is mapped to one or more DetNet enabled IP network where an IP flow is mapped to one or more
PWs and MPLS (TE) LSPs. The end systems still originate IP PWs and MPLS (TE) LSPs. The end systems still originate IP
encapsulated traffic that is identified as DetNet flows. The relay encapsulated traffic that are identified as DetNet flows. The relay
nodes follow procedures defined in Section 4 to map each DetNet flow nodes follow procedures defined in Section 4 to map each DetNet flow
to MPLS LSPs. While not shown, relay nodes can provide service sub- to MPLS LSPs. While not shown, relay nodes can provide service sub-
layer functions such as PREOF using DetNet over MPLS, and this is layer functions such as PREOF using DetNet over MPLS, and this is
indicated by the solid line for the MPLS facing portion of the indicated by the solid line for the MPLS facing portion of the
Service component. Note that the Transit node is MPLS (TE) LSP aware Service component. Note that the Transit node is MPLS (TE) LSP aware
and performs switching based on MPLS labels, and need not have any and performs switching based on MPLS labels, and need not have any
specific knowledge of the DetNet service or the corresponding DetNet specific knowledge of the DetNet service or the corresponding DetNet
flow identification. See Section 4 for details on the mapping of IP flow identification. See Section 4 for details on the mapping of IP
flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of
DetNet services using MPLS. DetNet services using MPLS.
DetNet IP Relay Transit Relay DetNet IP DetNet IP Relay Transit Relay DetNet IP
End System Node Node Node End System End System Node Node Node End System
+----------+ +---------+ +----------+ +----------+
| Appl. |<-------------- End to End Service ---------->| Appl. | | Appl. |<------------- End to End Service ---------->| Appl. |
+----------+ .....-----+ +-----..... +---------+ +----------+ .....-----+ +-----..... +----------+
| Service |<--: Service |-- DetNet flow ---| Service :-->| Service | | Service |<--: Service |--DetNet flow ---| Service :-->| Service |
| | : |<- DN MPLS flow ->| : | | | | : |<-DN MPLS flow ->| : | |
+----------+ +---------+ +----------+ +---------+ +---------+ +----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| | Fwd | |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+--------.-+ +-.-+ +-.-+ +---.----.-+ +-.-+ +-.-+ +----.----+ +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \
+.......+ +-[ Sub ]-+ +.......+ +--[ Sub ]--+ +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
|<---- DetNet MPLS --->| |<---- DetNet MPLS ---->|
|<--------------------- DetNet IP ------------------->| |<--------------------- DetNet IP ------------------>|
Figure 1: DetNet IP Over DetNet MPLS Network Figure 1: DetNet IP Over DetNet MPLS Network
4. IP over DetNet MPLS 4. IP over DetNet MPLS
This section defines how IP encapsulated flows are carried over a This section defines how IP encapsulated flows are carried over a
DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since
both Non-DetNet and DetNet IP packet are identical on the wire, this both Non-DetNet and DetNet IP packet are identical on the wire, this
section is applicable to any node that supports IP over DetNet MPLS, 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. and this section refers to both cases as DetNet IP over DetNet MPLS.
4.1. IP Over DetNet MPLS Data Plane Scenarios 4.1. IP Over DetNet MPLS Data Plane Scenarios
An example use of IP over DetNet MPLS follows below. An example use of DetNet IP over DetNet MPLS is presented here.
IP DetNet Relay Transit Relay IP DetNet
End System Node Node Node End System
(T-PE) (LSR) (T-PE)
+----------+ +----------+
| Appl. |<------------ End to End Service ----------->| Appl. |
+----------+ .....-----+ +-----..... +----------+
| Service |<--: Service |-- DetNet flow --| Service :-->| Service |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
|<- DN IP->| |<---- DetNet MPLS ---->| |< -DN IP ->|
Figure 2: DetNet IP Over MPLS Network
Figure 2 illustrates DetNet enabled End Systems (hosts), connected to Figure 1 illustrated DetNet enabled End Systems (hosts), connected to
DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS
network. In this figure, Relay nodes sit at the boundary of the MPLS network. iUsing this figure we can have a case where the Relay nodes
domain since the non-MPLS domain is DetNet aware. This figure is act as T-PEs and sit at the boundary of the MPLS domain since the
very similar to the DetNet MPLS Network figure in non-MPLS domain is DetNet aware. This case is very similar to the
[I-D.ietf-detnet-mpls]. The primary difference is that the Relay DetNet MPLS Network figure 2 in [I-D.ietf-detnet-mpls]. However in
nodes are at the edges of the MPLS domain and therefore function as [I-D.ietf-detnet-mpls] figure 2 the T-PEs are located at the end
T-PEs, and that service sub-layer functions are not provided over the syetem and MPLS spans the whole DetNet service. The primary
DetNet IP network. The transit node functions show above are difference in this document is that the Relay nodes are at the edges
identical to those described in [I-D.ietf-detnet-mpls]. of the MPLS domain and therefore function as T-PEs, and that iMPLS
service sub-layer functions are not provided over the DetNet IP
network. The transit node functions show above are identical to
those described in [I-D.ietf-detnet-mpls].
Figure 3 illustrates how relay nodes can provide service protection Figure 2 illustrates how relay nodes can provide service protection
over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end
systems which are interconnected via a MPLS domain such as described systems which are interconnected via a MPLS domain such as described
in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of
an MPLS domain and therefore are similar to T-PEs, while R2 sits in 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. the middle of the domain and is therefore similar to an S-PE.
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
skipping to change at page 7, line 28 skipping to change at page 6, line 28
| | | |
|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->| |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
| | | |
|<-------------- End to End DetNet Service --------------->| |<-------------- End to End DetNet Service --------------->|
-------------------------- Data Flow -------------------------> -------------------------- Data Flow ------------------------->
X = Service protection (PRF, PREOF, PEF/POF) X = Service protection (PRF, PREOF, PEF/POF)
DFx = DetNet member flow x over a TE LSP DFx = DetNet member flow x over a TE LSP
Figure 3: DetNet IP Over DetNet MPLS Network Figure 2: DetNet IP Over DetNet MPLS Network
IP Edge Edge IP
End System Node Node End System
(T-PE) (LSR) (T-PE)
+----------+ +....-----+ +-----....+ +----------+
| Appl. |<--:Svc Proxy|-- E2E Service --|Svc Proxy:-->| Appl. |
+----------+ +.....+---+ +---+.....+ +----------+
| IP |<--:IP : |Svc|-- IP/DN Flow ---|Svc| :IP :-->| IP |
+----------+ +---+ +---+ +----------+ +---+ +---+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
|<--- IP --->| |<----- DetNet MPLS ----->| |<--- IP --->|
Figure 4: Non-DetNet Aware IP Over DetNet MPLS Network
Figure 4 illustrates non-DetNet enabled End Systems (hosts),
connected to DetNet (DN) enabled MPLS network. It differs from
Figure 2 in that the hosts and edge IP networks 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 relay and edges. There are likely to be
differences in controller plane operation, particularly when
distributed control plane protocols are used.
Figure 5 illustrates how it is still possible to provided DetNet
service protection for non-DetNet aware end systems. This figures is
basically the same as Figure 3, with the exception that CE1 and CE2
are non-DetNet aware end systems and E1 and E3 are edge nodes that
replace the relay nodes R1 and R3.
IP IP
Non Service Transit Transit Service Non
DetNet |<-Tnl->| |<-Tnl->| DetNet
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | E1 |=======| R2 |=======| E3 | | +---+
| |--------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|------| |
|CE1| | | \ | | X | | / | | |CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
+--------+ +--------+ +--------+
^ Edge Node Relay Node Edge Node^
| (T-PE) (S-PE) (T-PE) |
| |
<--IP-->| <-------- IP Over DetNet MPLS ---------> |<--IP-->
| |
|<------ End to End DetNet Service ------->|
X = Optional service protection (none, PRF, PREOF, PEF/POF) Figure 1 illustrates DetNet enabled End Systems (hosts), connected to
DFx = DetNet member flow x over a TE LSP DetNet (DN) enabled MPLS network. A similar situation occurs when
end systems are 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 relay and
edges. There are likely to be differences in controller plane
operation, particularly when distributed control plane protocols are
used.
Figure 5: MPLS-Based DetNet (non-MPLS End System) It is still possible to provided DetNet service protection for non-
DetNet aware end systems. case is basically the same as Figure 2,
with the exception that CE1 and CE2 are non-DetNet aware end systems
and R1 and R3 become edge nodes.
4.2. DetNet IP over DetNet MPLS Encapsulation 4.2. DetNet IP over DetNet MPLS Encapsulation
The basic encapsulation approach is to treat a DetNet IP flow as an The basic encapsulation approach is to treat a DetNet IP flow as an
app-flow from the DetNet MPLS app perspective. The corresponding app-flow from the DetNet MPLS perspective. The corresponding example
example DetNet Sub-Network format is shown in Figure 6. DetNet Sub-Network format is shown in Figure 3.
/-> +------+ +------+ +------+ ^ /-> +------+ +------+ +------+ ^ ^
| | X | | X | | X | IP App-Flow : | | X | | X | | X |<- App-Flow : :
| +------+ +------+ +------+ : | +------+ +------+ +------+ : :
MPLS <-+ |NProto| |NProto| |NProto| :(1) App-Flow <-+ |NProto| |NProto| |NProto| : :(1)
App-Flow | +------+ +------+ +------+ : for MPLS | +------+ +------+ +------+ : :
| | IP | | IP | | IP | v | | IP | | IP | | IP | : v
\-> +---+======+--+======+--+======+-----+ \-> +---+======+--+======+--+======+-----+ :
DetNet-MPLS | d-CW | | d-CW | | d-CW | ^ DetNet-MPLS | d-CW | | d-CW | | d-CW | :
+------+ +------+ +------+ :(2) +------+ +------+ +------+ :(2)
|Labels| |Labels| |Labels| v |Labels| |Labels| |Labels| v
+---+======+--+======+--+======+-----+ +---+======+--+======+--+======+-----+
Sub-Network | L2 | | TSN | | UDP | Link/Sub-Network | L2 | | TSN | | UDP |
+------+ +------+ +------+ +------+ +------+ +------+
| IP | | IP |
+------+ +------+
| L2 | | L2 |
+------+ +------+
(1) DetNet IP Flow (1) DetNet IP Flow (or simply IP flow)
(2) DetNet MPLS Flow (2) DetNet MPLS Flow
Figure 6: Example DetNet IP over MPLS Sub-Network Formats Figure 3: Example DetNet IP over MPLS Sub-Network Formats
In the figure, "IP App-Flow" indicates the payload carried by the In the figure, "App-Flow" indicates the payload carried by the DetNet
DetNet IP data plane. "IP" and "NProto" indicate the fields IP data plane. "IP" and "NProto" indicate the fields described in
described in Section 7.1.1. IP Header Information and Section 7.1.2. Section 7.1.1. IP Header Information and Section 7.1.2. Other
Other Protocol Header Information in [I-D.ietf-detnet-ip], Protocol Header Information in [I-D.ietf-detnet-ip], respectively.
respectively. "MPLS App-Flow" indicates that an individual DetNet IP "MPLS App-Flow" indicates that an individual DetNet IP flow is the
flow is the payload from the perspective of the DetNet MPLS data payload from the perspective of the DetNet MPLS data plane defined in
plane defined in [I-D.ietf-detnet-mpls]. [I-D.ietf-detnet-mpls].
Per [I-D.ietf-detnet-mpls], the DetNet MPLS data plane uses a single Per [I-D.ietf-detnet-mpls], the DetNet MPLS data plane uses a single
S-Label to support a single app flow. Section 7.1. DetNet IP Flow S-Label to support a single app flow. Section 7.1. DetNet IP Flow
Identification Procedures in [I-D.ietf-detnet-ip] states that a Identification Procedures in [I-D.ietf-detnet-ip] states that a
single DetNet flow is identified based on IP, and next level single DetNet flow is identified based on IP, and next level
protocol, header information. Section 7.4. Aggregation protocol, header information. Section 7.4. Aggregation
Considerations in [I-D.ietf-detnet-ip] defines that aggregation is Considerations in [I-D.ietf-detnet-ip] defines that aggregation is
supported through the use of prefixes, wildcards, bitmasks, and port supported through the use of prefixes, wildcards, bitmasks, and port
ranges. Collectively, this results in the fairly straight forward ranges. Collectively, this results in the fairly straight forward
procedures defined in this section. procedures defined in this section.
As shown in Figure 4, DetNet relay nodes are responsible for the As shown in Figure 2, DetNet relay nodes are responsible for the
mapping of a DetNet flow, at the service sub-layer, from the IP to 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 MPLS DetNet data planes and back again. Their related DetNet IP over
DetNet MPLS data plane operation is comprised of two sets of DetNet MPLS data plane operation is comprised of two sets of
procedures: the mapping of flow identifiers; and ensuring proper procedures: the mapping of flow identifiers; and ensuring proper
traffic treatment. traffic treatment.
4.3. DetNet IP over DetNet MPLS Flow Identification Procedures Mapping of IP to the MPLS Detnet is similar for IP Detnet 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.
A relay node that sends a DetNet IP flow over a DetNet MPLS network 5. IP over DetNet MPLS Procedures
MUST map that single DetNet IP flow into a single app-flow and MUST
process that app-flow in accordance to the procedures defined in
[I-D.ietf-detnet-mpls] Section 6.1. PRF MAY be supported for DetNet
IP flows sent over an DetNet MPLS network. Aggregation MAY be
supported as defined in [I-D.ietf-detnet-mpls] Section 5.4.
Aggregation Considerations in [I-D.ietf-detnet-ip] MAY be used to
identify an individual DetNet IP flow. The provisioning of the
mapping of DetNet IP flows to DetNet MPLS app-flows MUST be supported
via configuration, e.g., via the controller plane.
A relay node MAY be provisioned to handle packets received via the 5.1. DetNet IP over DetNet MPLS Flow Identification Procedures
DetNet MPLS data plane as DetNet IP flows. A single incoming MPLS
app-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 [I-D.ietf-detnet-ip]
Section 7.1. An implementation MUST support the provisioning for
handling any received DetNet MPLS data plane as DetNet IP flows via
configuration. Note that such configuration MAY include support from
PEOF on the incoming DetNet MPLS flow.
4.4. DetNet IP over DetNet MPLS Traffic Treatment 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
[I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process
it in accordance to the procedures defined in [I-D.ietf-detnet-mpls]
Section 6.1. PRF MAY be supported at the MPLS level for DetNet IP
flows sent over an DetNet MPLS network. Aggregation MAY be supported
as defined in [I-D.ietf-detnet-mpls] Section 5.4. Aggregation
considerations in [I-D.ietf-detnet-ip] 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 [I-D.ietf-detnet-ip]
Section 7.1.
An implementation MUST support the provisioning for handling any
received DetNet MPLS data plane as DetNet IP flows via configuration.
Note that such configuration MAY include support from PEOF on the
incoming DetNet MPLS flow.
5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures
The traffic treatment required for a particular DetNet IP flow is The traffic treatment required for a particular DetNet IP flow is
provisioned via configuration or the controller plane. When an provisioned via configuration or the controller plane. When an
DetNet IP flow is sent over DetNet MPLS, a relay node MUST ensure DetNet IP flow is sent over DetNet MPLS, a DetNet relay node MUST
that the provisioned DetNet IP traffic treatment is provided at the ensure that the provisioned DetNet IP traffic treatment is provided
forwarding sub-layer as described in [I-D.ietf-detnet-mpls] at the forwarding sub-layer as described in [I-D.ietf-detnet-mpls]
Section 5.2. Note that the PRF function MAY be utilized when sending Section 5.2. Note that the PRF function MAY be utilized when sending
IP over MPLS. IP over MPLS.
Traffic treatment for DetNet IP flows received over the DetNet MPLS Traffic treatment for DetNet IP flows received over the DetNet MPLS
data plane MUST follow Section 7.3 DetNet IP Traffic Treatment data plane MUST follow Section 7.3 DetNet IP Traffic Treatment
Procedures in [I-D.ietf-detnet-ip]. Procedures in [I-D.ietf-detnet-ip].
5. Security Considerations 6. Management and Control Information Summary
The security considerations of DetNet in general are discussed in
[I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. Other
security considerations will be added in a future version of this
draft.
6. IANA Considerations
TBD.
7. Contributors
RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5, far fewer than the 20 individuals below who
made important contributions to this draft. The editor wishes to
thank and acknowledge each of the following authors for contributing
text to this draft. See also Section 8.
Loa Andersson
Huawei
Email: loa@pi.nu
Yuanlong Jiang
Huawei
Email: jiangyuanlong@huawei.com
Norman Finn
Huawei
3101 Rio Way
Spring Valley, CA 91977
USA
Email: norman.finn@mail01.huawei.com
Janos Farkas
Ericsson
Magyar Tudosok krt. 11
Budapest 1117
Hungary
Email: janos.farkas@ericsson.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Tal Mizrahi
Marvell
6 Hamada st.
Yokneam
Israel
Email: talmi@marvell.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Andrew G. Malis The following summarizes the set of information that is needed to
Huawei Technologies support DetNet IP over DetNet MPLS at the MPLS ingress node:
Email: agmalis@gmail.com
8. Acknowledgements o Each MPLS App-Flow is identified using the IP flow identification
information as defined in [I-D.ietf-detnet-ip]. The information
is summarized in Section 6 of that document, and includes all
wildcards, port ranges and ability to ignore specific IP fields.
The author(s) ACK and NACK. o The DetNet MPLS service that is to be used to send the matching IP
traffic. Logically this is a pointer to the information provided
in [I-D.ietf-detnet-mpls] Section 5.1, and includes both service
and traffic delivery information.
The following people were part of the DetNet Data Plane Solution The following summarizes the set of information that is needed to
Design Team: support DetNet IP over DetNet MPLS at the MPLS egress node:
Jouni Korhonen o S-Label values that are carrying MPLS over IP encapsulated
traffic.
Janos Farkas o For each S-Label, how the received traffic is to be handled. The
traffic may be processed according as any other DetNet IP traffic
as defined in this document or in [I-D.ietf-detnet-ip], or the
traffic may be directly treated as an MPLS App-flow for additional
processing according to [I-D.ietf-detnet-mpls].
Norman Finn It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet
each flow's service requirements. This applies for aggregated and
individual flows.
Balazs Varga 7. Security Considerations
Loa Andersson This draft does not have additional security considerations.
Security considerations for DetNet are described in detail in
[I-D.ietf-detnet-security]. General security considerations are
described in [I-D.ietf-detnet-architecture]. MPLS and IP specific
considerations are described in [I-D.ietf-detnet-mpls] and
[I-D.ietf-detnet-ip].
Tal Mizrahi Security aspects which are unique to DetNet are those whose aim is to
provide the 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.
David Mozes The primary considerations for the data plane is 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
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
Yuanlong Jiang From a data plane perspective this document does not add or modify
any header information.
Andrew Malis 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.
Carlos J. Bernardos 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 mechanism 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 definition 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.
The DetNet chairs serving during the DetNet Data Plane Solution 8. IANA Considerations
Design Team:
Lou Berger This document makes no IANA requests.
Pat Thaler 9. Acknowledgements
Thanks to Stewart Bryant for his extensive review of the previous The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
versions of the document. David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
Bernardos for their various contributions to this work.
9. References 10. References
9.1. Normative references 10.1. Normative references
[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-12 (work in progress), March 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Korhonen J., "DetNet Data Plane IP", 2019. Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-00 (work in progress), May 2019.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Korhonen J., "DetNet MPLS", 2019. Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-00 (work in progress), May 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
9.2. Informative references 10.2. Informative references
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger L., MAlis A., Bryant S., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Korhonen J., "DetNet Data Plane Framework", 2019. Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-00
(work in progress), May 2019.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-04 (work in progress), March 2019. detnet-security-04 (work in progress), March 2019.
[IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
Authors' Addresses Authors' Addresses
Balazs Varga (editor) Balazs Varga (editor)
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
skipping to change at page 15, line 4 skipping to change at page 12, line 22
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Janos Farkas Janos Farkas
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
Andrew G. Malis Andrew G. Malis
Huawei Technologies Futurewei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Huawei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 64 change blocks. 
285 lines changed or deleted 229 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/