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

Versions: 00 01

Network Working Group                                            X. Geng
Internet-Draft                                                     Z. Li
Intended status: Informational                                   M. Chen
Expires: January 14, 2021                                         Huawei
                                                           July 13, 2020


               SRv6 for Deterministic Networking (DetNet)
                  draft-geng-spring-srv6-for-detnet-01

Abstract

   Deterministic Networking provides service with low jitter, bounded
   latency and low loss rate, using technologies of explicit route,
   resource reservation and service protection.This document specifies
   how to implement Deterministic Networking (DetNet) in a SRv6 Network.

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 RFC 2119 [RFC2119].

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 January 14, 2021.

Copyright Notice

   Copyright (c) 2020 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



Geng, et al.            Expires January 14, 2021                [Page 1]


Internet-Draft               SRv6 for DetNet                   July 2020


   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
   3.  SRv6 for DetNet Overview  . . . . . . . . . . . . . . . . . .   4
   4.  Service Protection  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Service Protection Scenarios  . . . . . . . . . . . . . .   5
     4.2.  Data Plane Considerations . . . . . . . . . . . . . . . .   7
     4.3.  Control Plane Considerations  . . . . . . . . . . . . . .   7
   5.  Resource Reservation  . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Resource Reservation  Scenarios . . . . . . . . . . . . .   8
     5.2.  Data Plane Considerations . . . . . . . . . . . . . . . .  10
     5.3.  Control Plane Considerations  . . . . . . . . . . . . . .  10
   6.  Explicit Route  . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   With more and more applications running in the Internet, quality of
   the service gains more and more attention, especially for some new
   applications, for example Cloud VR, Cloud Game, HDV (high-definition
   video) and so on, SLA (Service Level Agreement), including jitter,
   delay and loss rate, influences the users' experience significantly.
   So SLA guarantee is an important issue which requires new
   technologies and solutions for the network.

   Deterministic Networking (DetNet defined in [RFC8655]) provides a
   capability to carry specified data flows for real-time applications
   with extremely low data loss rates, low jitter and bounded latency
   within a network domain.  Techniques used include: 1) providing
   explicit paths for DetNet flows that satisfies the SLA requirement
   from user and do not immediately change with the network topology; 2)
   reserving data plane resources for DetNet flows along the allocated
   path of the flow; 3) replicates DetNet flows into two or more copies
   and transport different copies through different path in parallel,
   called service protection.




Geng, et al.            Expires January 14, 2021                [Page 2]


Internet-Draft               SRv6 for DetNet                   July 2020


   Segment Routing(SR) leverages the source routing paradigm.  An
   ingress node steers a packet through an ordered list of instructions,
   called "segments".  SR can be applied over IPv6 data plane using
   Routing Extension Header(SRH, [RFC8754]).  A segment in Segment
   Routing is not limited to a routing/forwarding function.  An SRv6
   Segment can indicate functions that are executed locally in the node
   where they are defined.
   [I-D.filsfils-spring-srv6-network-programming] describes some well-
   known functions and segments associated to them.  SRH TLVs([RFC8754])
   also provides meta-data for segment processing.  All these features
   make SRv6 suitable to carry DetNet flows, by defining new segments
   associated with DetNet functions and meta data for DetNet.

   This document describes the concepts needed by implementing DetNet in
   an SRv6-based domain and provides considerations for any
   corresponding implementation.

   Editor's note: DetNet is limited in a controlled network domain, and
   it is not the only method to provide SLA guarantee.  But it is a good
   start to discuss how to use SRv6 to have a SLA-guaranteed network
   service.

2.  Terminology

   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].

   Terminologies for DetNet go along with the definition in [RFC8655]
   and [RFC8754]:

   DetNet domain

      The portion of a network that is DetNet aware.  It includes end
      systems and DetNet nodes

   DetNet edge node

      An instance of a DetNet relay node that acts as a source and/ or
      destination at the DetNet service sub-layer.  For example, it can
      include a DetNet service sub-layer proxy function for DetNet
      service protection (e.g., the addition or removal of packet
      sequencing information) for one or more end systems, or starts or
      terminates resource allocation at the DetNet forwarding sub-layer,
      or aggregates DetNet services into new DetNet flows.  It is
      analogous to a Label Edge Router (LER) or a Provider Edge (PE)
      router.




Geng, et al.            Expires January 14, 2021                [Page 3]


Internet-Draft               SRv6 for DetNet                   July 2020


   DetNet relay node

      A DetNet node including a service sub-layer function that
      interconnects different DetNet forwarding sub-layer paths to
      provide service protection.  A DetNet relay node participates in
      the DetNet service sub-layer.  It typically incorporates DetNet
      forwarding sub-layer functions as well, in which case it is
      collocated with a transit node.

   DetNet transit node

      A DetNet node operating at the DetNet forwarding sub-layer, that
      utilizes link layer and/or network layer switching across multiple
      links and/or sub-networks to provide paths for DetNet service sub-
      layer functions.  Typically provides resource allocation over
      those paths.  An MPLS LSR is an example of a DetNet transit node.

   End system

      End systems of interest to this document are either sources or
      destinations of DetNet flows.  And end system may or may not be
      DetNet forwarding sub-layer aware or DetNet service sub-layer
      aware.

   DetNet service sub-layer

      DetNet functionality is divided into two sub-layers.  One of them
      is the DetNet service sub-layer, at which a DetNet service, e.g.,
      service protection is provided.

   DetNet forwarding sub-layer

      DetNet functionality is divided into two sub-layers.  One of them
      is the DetNet forwarding sub-layer, which optionally provides
      resource allocation for DetNet flows over paths provided by the
      underlying network.

3.  SRv6 for DetNet Overview

   As mentioned above, there are mainly three technologies/functions
   defined in DetNet: Explicit Route, Resource Reservation and Service
   Protection.  Explicit Route is the basic of the other two
   technologies, and guarantees the path satisfies the SLA requirement
   from application.  Resource Reservation protects DetNet flows from
   network congestion, which could reduce the end-to-end latency and
   congestion loss; Service Protection prevents DetNet flow from random
   media errors and equipment failures, which makes the loss rate
   extremely low.



Geng, et al.            Expires January 14, 2021                [Page 4]


Internet-Draft               SRv6 for DetNet                   July 2020


   In [RFC8655], DetNet functionality is implemented in two sub-layers
   in the protocol stack: the DetNet service sub-layer and the DetNet
   forwarding sub-layer.  The DetNet service sub-layer provides DetNet
   service, e.g., service protection.  The DetNet forwarding sub-layer
   supports DetNet service in the underlying network, by providing
   explicit routes and resource allocation to DetNet flows.  There is no
   obvious protocol stack as MPLS, in SRv6 both service sub-layer and
   forwarding sub-layer are implemented through SRH.

   The following picture shows that a general DetNet enabled network
   defined in [RFC8655] :

   TSN               Edge        Transit         Relay        DetNet
   End System        Node         Node           Node        End System

   +----------+   +.........+                               +----------+
   |  Appl.   |<--:Svc Proxy:-- End to End Service -------->|  Appl.   |
   +----------+   +---------+                 +---------+   +----------+
   |   TSN    |   |TSN| |Svc|<- DetNet flow --: Service :-->| Service  |
   +----------+   +---+ +---+   +--------+    +---------+   +----------+
   |Forwarding|   |Fwd| |Fwd|   |  Fwd   |    |Fwd| |Fwd|   |Forwarding|
   +-------.--+   +-.-+ +-.-+   +--.----.+    +-.-+ +-.-+   +---.------+
           :  Link  :    /  ,-----. \   : Link  :    /  ,-----.  \
           +........+    +-[  Sub  ]-+  +.......+    +-[  Sub  ]-+
                           [Network]                   [Network]
                            `-----'                     `-----'

   In SRv6 for DetNet, the outer IPv6 Header with the SRH is used for
   carrying DetNet flows.  Explicit path is instantiated in the segment
   list of SRH, and other functions/arguments for service protection
   (packet replication, elimination and ordering, PREOF) and resource
   reservation (packet queuing and scheduling) are also defined in the
   specified SID.  Meta data for DetNet could be instantiated in the
   Optional TLVs.

4.  Service Protection

4.1.  Service Protection Scenarios

   The figure below shows that an IPv6 flow is sent out from the end
   station E1.  The packet of the flow is encapsulated in an outer
   IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and
   transported through an SRv6 DetNet domain.  In the Egress(Eg), the
   outer IPv6 header+SRH of the packet is popped, and the packet is sent
   to the destination E2.






Geng, et al.            Expires January 14, 2021                [Page 5]


Internet-Draft               SRv6 for DetNet                   July 2020


                |                                         |
    ----IPv6--->|<---------------SRv6 DetNet------------->|<----IPv6---
                |                                         |
                |             +------+T2+----+            |
      +---+    +---+        +-+-+          +-+-+        +---+    +---+
      | E1+----| In|--+T1+--+R1 |          |R2 |--+T4+--| Eg+----+ E2|
      +---+    +---+        +-+-+          +-+-+        +---+    +---+
                              +-----+T3+-----+

   The DetNet packet processing is as follows:

   Ingress:

      Inserts the SRv6 Policy that will steer the packet from Ingress to
      the destination

      The methods and mechanisms used for defining, instantiating and
      applying the policy are outside of this document.  An example of
      policies are described in [I-D.ietf-spring-segment-routing-policy]

      Flow Identification and Sequence Number are carried in the SRH.

   Relay Node 1(Replication Node):

      Replicates the payload and IPv6 Header with the SRH.  This is a
      new function in the context of SRv6 Network Programming which will
      associate a given SID to a replication instruction in the node
      originating and advertising the SID.  The replication instruction
      includes:



      *  The removal of the existing IPv6+SRH header

      *  The encapsulation into a new outer IPv6+SRH header.  Each
         packet (the original and the duplicated) are encapsulated into
         respectively new outer IPv6+SRH headers.

      Binding two different SRv6 Policies respectively to the original
      packet and the replicated packet, which can steer the packets from
      Relay Node 1 to Relay Node 2 through two tunnels.

   Relay Node 2(Elimination Node):

      Eliminates the redundant packets.

      Binds a new SRv6 Policy to the survival packet, which steers the
      packet from Relay Node 2 to Egress.



Geng, et al.            Expires January 14, 2021                [Page 6]


Internet-Draft               SRv6 for DetNet                   July 2020


   Egress:

      Decapsulates the outer Ipv6 header.

      Sends the inter packet to the End Station 2.

   The DetNet packet encapsulation is illustrated here below.  It has to
   be noted that, in the example below, the R2 address is a SRH SID
   associated to a TBD function related to the packet replication the
   node R1 has to perform.  The same (or reverse) apply to node R2 which
   is in charge of the discard of the duplicated packet.  Here also a
   new function will have a new SID allocated to it and representing the
   delete of the duplication in R2.

      End Station1 output packet: (E1,E2)

      Ingress output packet: (In, T1)(R1,T1, SL=2)(E1,E2)

      Transit Node1 output packet: (In, R1)(R1,T1,SL=1)(E1,E2)

      Relay Node1 output packets : (R1,T2)(R2,T2,SL=2)(E1,E2),
      (R1,T3)(R2,T3,SL=2)(E1,E2)

      Transit Node2 output packet: (R1, R2)(R2,T2,SL=1)(E1,E2)

      Transit Node3 output packet: (R1, R2)(R2,T3,SL=1)(E1,E2)

      Relay Node2 output packet: (R2, T4)(Eg,T4,SL=2)(E1,E2)

      Transit Node4 output packet: (R2, Eg)(Eg,T4,SL=1)(E1,E2)

      Egress out : (E1,E2)

4.2.  Data Plane Considerations

   Flow Identification and sequence number are necessary in the
   encapsulation of SRv6 for DetNet in order to support service
   protection.  Replication nodes decide which DetNet flows are supposed
   to be replicated by identifying the flow with the flow
   identification.  Elimination nodes decide whether a packet should be
   dropped because of redundancy by identifying the flow identification
   and sequence number.

4.3.  Control Plane Considerations







Geng, et al.            Expires January 14, 2021                [Page 7]


Internet-Draft               SRv6 for DetNet                   July 2020


               (1)         +----------+
      +------------------->+Controller|
      |                    +----+-----+
      |(2)                     / \
      |      +---------------/-----\-----------------+
      |      |             /   (3)   \               |
   +--V-------+  +--------V-+-->+-----V----+   +----------+
   | Ingress  +--|Relay Node|   |Relay Node|-->| Egresss  |
   +----------+  +----------+-->+----------+   +----------+
            |    Replication    Elimiantion         |
            +---------------------------------------+
                        DetNet Domain

   1.  Edge node->Controller: Sends a path computation requirement
   containing that service protection in order to have ultra-reliability
   through PCEP/BGP extenisons.

   2.  Controller->Edge node: Computes a P2MP2P path, including
   replication nodes and elimination nodes.  Between a pair of
   replication node and elimination node, there are more than one path,
   and if any equipment failure happens in one of them, the DetNet
   service is not interrupted.  Send the path computation result to the
   edge node through PCEP/BGP extensions.

   3.  Controller->Relay Node : In a P2MP2P path, every pair of
   replication node and elimination node should be configured to
   identify different DetNet flows by the different flow
   identifications, and the rule of sequence number should be negotiated
   between relay nodes.  After replication or elimination, the explicit
   path to the next relay is also required through BGP extensions or
   Netconf YANG.

5.  Resource Reservation

5.1.  Resource Reservation Scenarios

   The figure below shows that an IPv6 flow is sent out from the end
   station E1.  The packet of the flow is encapsulated in an outer
   IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and
   transported through an SRv6 DetNet domain.  In the Egress(Eg), the
   outer IPv6 header+SRH of the packet is popped, and the packet is sent
   to the destination E2.









Geng, et al.            Expires January 14, 2021                [Page 8]


Internet-Draft               SRv6 for DetNet                   July 2020


                |                                         |
    ----IPv6--->|<---------------SRv6 DetNet------------->|<----IPv6---
                |                                         |
                |                                         |
      +---+    +---+                                    +---+    +---+
      | E1+----| In|--+T1+---------+T2+---------+T3+----| Eg+----+ E2|
      +---+    +---+                                    +---+    +---+

   The DetNet packet processing is as follows:

   Ingress:

      Inserts the SRv6 Policy that will steer the packet from Ingress to
      the destination.

      The methods and mechanisms used for defining, instantiating and
      applying the policy are outside of this document.  An example of
      policies are described in [I-D.ietf-spring-segment-routing-policy]

      Explicit route and the corresponding resource is carried in the
      SRH.

   T1 Node (Transit Node):

      Forward the packet with the allocated resource.

      This is a new function in the context of SRv6 Network Programming
      which will associate a given SID to a replication instruction in
      the node originating and advertising the SID.  The instruction
      includes:



      *  Forward the packet to the link bound to the SID

      *  Use the resource when forwarding the packet

   The processing of T2 and T3 Node is similar.

   Egress:

      Decapsulates the outer IPv6 header.

      Sends the inter packet to the End Station 2.







Geng, et al.            Expires January 14, 2021                [Page 9]


Internet-Draft               SRv6 for DetNet                   July 2020


5.2.  Data Plane Considerations

   Congestion could cause uncontrolled delay and packet loss.  DetNet
   flows are supposed to be protected from congestion, so enough
   resource reservation for DetNet service is necessary.  Some of the
   resource in the network is complex and hard to quantize, e.g., packet
   processing resource; while some of them is easy to get and calculate,
   e.g., buffer size, port bandwidth and so on.  In order to use the
   allocated resource for the DetNet flow, SRv6 for DetNet is supposed
   to carry the information of the resource.  And the network device
   could transit the packet following the instruction in the SRH with
   the corresponding resources.

5.3.  Control Plane Considerations

               (1)         +----------+
      +------------------->+Controller|
      |                    +----+-----+
      |(2)                     / \
      |      +---------------/-----\-------------------+
      |      |             /   (3)   \                 |
   +--V-------+  +--------V---+   +---V--------+   +----------+
   | Ingress  +--|Transit Node|---|Transit Node|-->| Egress  |
   +----------+  +------------+   +------------+   +----------+
            |          Resource Reservation            |
            +------------------------------------------+
                        DetNet Domain

   1.  Edge node->Controller: Sends a path computation requirement
   containing the flow characteristics and resource reservation request
   through BGP/PCEP.

   2.  Controller->Edge node: The controller should collect the network
   resource information of the network, e.g., bandwidth, buffer size and
   so on, and maintain the resource status for every device/output port.
   Based on the flow characteristics, the controller should find a path
   which can guarantee that there are enough resources in every device/
   output port the flow goes through.  The controller sends the path
   computation results back to the edge node, and update the resources
   status of the network through BGP/PCEP.

   3.  Controller->Transit Node: Every transit node along the path
   should be configured in order to make sure that when the DetNet flow
   goes through, the allocated resource for this flow is able to be used
   and no more resource than what is allocated will be used for the same
   flow through BGP/Netconf YANG.\





Geng, et al.            Expires January 14, 2021               [Page 10]


Internet-Draft               SRv6 for DetNet                   July 2020


6.  Explicit Route

   SRv6 could support explicit route using segment list without extra
   extension.  In DetNet, explicit route could be used with service
   protection or resource reservation.  When explicit route works with
   service protection, a P2MP2P path is required to indicate the
   behavior of replication and elimination.  When explicit route works
   with resource reservation, the explicit path indicates the nodes or
   links a DetNet flow goes through, and also indicates the resource
   allocated for the DetNet flow in the specified nodes or links.

7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

8.  Security Considerations

   TBD

9.  Acknowledgements

   Thank you for valuable comments from James Guichard and Andrew Mails.

10.  Normative References

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-filsfils-spring-srv6-network-
              programming-07 (work in progress), February 2019.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
              progress), October 2019.

   [I-D.ietf-detnet-dp-sol-mpls]
              Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
              Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in
              progress), March 2019.







Geng, et al.            Expires January 14, 2021               [Page 11]


Internet-Draft               SRv6 for DetNet                   July 2020


   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-07 (work in progress),
              May 2020.

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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

Authors' Addresses

   Xuesong Geng
   Huawei

   Email: gengxuesong@huawei.com


   Zhenbin Li
   Huawei

   Email: lizhenbin@huawei.com


   Mach Chen
   Huawei

   Email: mach.chen@huawei.com







Geng, et al.            Expires January 14, 2021               [Page 12]


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