DetNet Working Group A. Malis
Internet-Draft S. Bryant
Intended status: Standards Track M. Chen
Expires: September 6, 2018 Huawei Technologies
B. Varga
Ericsson
March 05, 2018
DetNet IP Encapsulation
draft-malis-detnet-ip-dp-00
Abstract
This document specifies Deterministic Networking data plane operation
over an IP network. It is primarily aimed at IPv4, but would work
with IPv6 as well if a unified solution is desired.
This document is a derivative work from draft-ietf-detnet-dp-sol-01,
to augment or replace the text currently contained in section 5.2.2.
Whether this is published as a stand-alone text, or serves as a focal
point to refine the IP design and subsequently remerged with draft-
ietf-detnet-dp-sol-01 is a matter for the DETNET WG.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Malis, et al. Expires September 6, 2018 [Page 1]
Internet-Draft DetNet IP March 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms used in this document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements language . . . . . . . . . . . . . . . . . . . . 3
4. DetNet Over an IP Network . . . . . . . . . . . . . . . . . . 3
5. DetNet over IP Encapsulation . . . . . . . . . . . . . . . . 5
6. Security considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document is a derivative work from [I-D.ietf-detnet-dp-sol].
Whether this is published as a stand-alone text, or serves as a focal
point to refine the IP design and subsequently remerged with draft-
ietf-detnet-dp-sol-01 is a matter for the DetNet WG.
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows extremely low
packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in
[I-D.ietf-detnet-architecture].
This document specifies the encapsulation and operation of
deterministic networking over an IP data-plane. The approach is
modeled on the operation of PseudoWires (PW) over an IP Packet
Switched Network (PSN) [RFC3985][RFC4385][RFC7510].
It is based on the "simplified model" discussed during the DetNet
Interim Meeting held on 14 February 2018
Malis, et al. Expires September 6, 2018 [Page 2]
Internet-Draft DetNet IP March 2018
[http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-
detnet-03].
It is also based on the MPLS encapsulation described in draft-bryant-
detnet-mpls-dp (this reference to be updated once draft is
available).
The DetNet transport layer functionality that provides congestion
protection for DetNet flows is assumed to be in place in a DetNet
node.
This document does not currently define the associated control plane
functions, or Operations, Administration, and Maintenance (OAM). It
also does not currently specify traffic handling capabilities
required to deliver congestion protection and latency control for
DetNet flows at the DetNet transport layer. These aspects may be
included in future revisions of this draft, or in other DetNet
documents.
2. Terminology
2.1. Terms used in this document
This document uses the same terminology as [I-D.ietf-detnet-dp-sol].
Please see that document for the definitions.
2.2. Abbreviations
This document uses the same abbreviations as
[I-D.ietf-detnet-dp-sol]. Please see that document for the list of
abbreviations.
3. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. DetNet Over an IP Network
The "simplified model" of DetNet, as discussed during the interim
meeting, is carried over an IP network is shown in Figure 1:
Malis, et al. Expires September 6, 2018 [Page 3]
Internet-Draft DetNet IP March 2018
DetNet Edge Transit Relay Edge DetNet
End Sys Node Node Node Node End Sys
+-----+ End to End Service +-----+
|Appln|<..............................................>|Appln|
+-----+ +---------+ DN Flow +---------+ +---------+ +-----+
| TSN | | Service |<------->| Service |--| Service | | TSN |
+-----+ +---+ +---+ +-----+ +---+ +---+ +---+ +---+ +-----+
|DNXpt| |Xpt| |Xpt| |IPXpt| |Xpt| |Xpt| |Xpt| |Xpt| |DNXpt|
+--.--+ +-.-+ +-.-+ +-.-.-+ +-.-+ +-.-+ +-.-+ +-.-+ +--.--+
: : : : :Link : :Link : : :
+-------+ /-------\+-----+ +------+ /-------\
TSN |Sub N/W| |TSN N/W|
Link \-------/ \-------/
Figure 1: Simplified Model of a DetNet Enabled Network
In this figure, "DNXpt" and "Xpt" are abbreviations for "DetNet
Transport" and "IPXpt" is an abbreviation for "IP Transport".
DetNet End Systems sent and receive packets over the DetNet. The
supported packet types are IP and Ethernet.
Note that in the Simplified Model, while the DetNet service is end-
to-end, the End Systems are not DetNet-aware and do not include
DetNet information to their packet headers. Rather, the packets
between the End Systems and the Edge Nodes may typically consist of
application information, L4 Transport (such as TCP or UDP), IP, and
Ethernet headers, transmitted over a TSN link or (sub)-Network
between the End System and the Edge Node.
Alternatively, the packets could contain Ethernet-native
applications, with the application information directly encapsulated
within Ethernet without L4 Transport or IP headers.
Because the End Systems are not DetNet-aware, Edge Nodes are
responsible for the imposition and disposition of the required DetNet
encapsulation. This functionality is similar to that in pseudowire
(PW) Provider Edge (PE) routers.
Relay Nodes are also strategically placed and used enhance the
reliability of delivery by enabling the DetNet-layer replication of
packets so that multiple copies, possibly over multiple paths. They
also reduce the impact of replication by the eliminating surplus
copies of DetNet packets. These functions may not be performed in
End Systems, as they are not DetNet-aware.
Malis, et al. Expires September 6, 2018 [Page 4]
Internet-Draft DetNet IP March 2018
Relay Nodes are aware of the needs of particular DetNet flows and
take care to process them in accordance with the required performance
needs.
Transit nodes are normal IP routers. They are unaware of DetNet
flows per se, although they may be configured to provide congestion
protection and delay control in order to meet the required DetNet
service level agreement (SLA) via non-DetNet-specific means (IP
traffic engineering, queuing mechanisms based on DiffServ markings,
etc.).
5. DetNet over IP Encapsulation
To carry DetNet over IP the following is required:
1. A method of identifying the DetNet flow to the processing
element.
2. A method of carrying the DetNet sequence number.
These latter two pieces of information are already carried in the
DetNet over MPLS Encapsulation, as shown in Figure 1, where the
Control Word contains a 28-bit sequence number, and the S-Label is
used to identify the particular flow.
+---------------------------------+
| |
| DetNet Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation
+---------------------------------+ <--/
| T-Label(s) |
+---------------------------------+
Figure 2: MPLS Encapsulation of DetNet
To simplify operations and implementations, rather than inventing a
brand new encapsulation, the IP encapsulation can take advantage of
the MPLS encapsulation. By using the specification of MPLS over UDP
and IP in [RFC7510], the T-Label(s) in Figure 2 can be replaced by
UDP and IP, resulting in the following encapsulation:
Malis, et al. Expires September 6, 2018 [Page 5]
Internet-Draft DetNet IP March 2018
+---------------------------------+
| |
| DetNet Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation
+---------------------------------+ <--/
| UDP Header |
+---------------------------------+
| IP Header |
+---------------------------------+
Figure 3: IP Encapsulation of DetNet
Where the UDP header is used as defined in Section 3 of [RFC7510].
In ingress Edge Nodes, the encapsulation in Figure 3 will be imposed
on Detnet Flow Payload Packets as received from DetNet End Systems,
and the encapsulation will be removed in egress Edge Nodes as they
transmit the Payload Packets to the End Systems.
Note that this encapsulation works equally well with IPv4 and IPv6.
This encapsulation can also be used in conjunction with segment
routing as specified in [I-D.ietf-spring-segment-routing-mpls]. In
this case, the T-Label(s) in Figure 2 should be retained, and at each
hop, the top T-label is popped and mapped to a corresponding UDP/IP
tunnel, resulting in the following encapsulation:
Malis, et al. Expires September 6, 2018 [Page 6]
Internet-Draft DetNet IP March 2018
+---------------------------------+
| |
| DetNet Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation
+---------------------------------+ <--/
| T-Label(s) |
+---------------------------------+
| UDP Header |
+---------------------------------+
| IP Header |
+---------------------------------+
Figure 4: IP Encapsulation of DetNet with MPLS-SR
Again, the UDP header is used as defined in Section 3 of [RFC7510].
6. Security considerations
The security considerations of DetNet in general are discussed in
[I-D.ietf-detnet-security]. Other security considerations will be
added in a future version of this draft.
7. IANA considerations
This document makes no IANA requests.
8. Acknowledgements
9. References
9.1. Normative References
[I-D.ietf-detnet-dp-sol]
Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga,
B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger,
"DetNet Data Plane Encapsulation", draft-ietf-detnet-dp-
sol-01 (work in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-12
(work in progress), February 2018.
Malis, et al. Expires September 6, 2018 [Page 7]
Internet-Draft DetNet IP March 2018
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
9.2. Informative References
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-04 (work in progress), October 2017.
[I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-01 (work in progress), October 2017.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
Authors' Addresses
Andrew G. Malis
Huawei Technologies
Email: agmalis@gmail.com
Stewart Bryant
Huawei Technologies
Email: stewart.bryant@gmail.com
Malis, et al. Expires September 6, 2018 [Page 8]
Internet-Draft DetNet IP March 2018
Mach Chen
Huawei Technologies
Email: mach.chen@huawei.com
Balazs Varga
Ericsson
Email: balazs.a.varga@ericsson.com
Malis, et al. Expires September 6, 2018 [Page 9]