[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/