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.

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. Terminology
• 2.1. Terms used in this document
• 2.2. Abbreviations
• 3. Requirements language
• 4. DetNet Over an IP Network
• 5. DetNet over IP Encapsulation
• 6. Security considerations
• 7. IANA considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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 [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:

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.

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:

  +---------------------------------+
  |                                 |
  |           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:

 +---------------------------------+
 |                                 |
 |           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

9.2. Informative References

Authors' Addresses