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.

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

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.

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

DetNet edge node

DetNet relay node

DetNet transit node

End system

DetNet service sub-layer

DetNet forwarding sub-layer

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.

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.

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

The DetNet packet processing is as follows:

Ingress:

Relay Node 1(Replication Node):

Relay Node 2(Elimination Node):

Egress:

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.

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

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

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

Ingress:

T1 Node (Transit Node):

The processing of T2 and T3 Node is similar.

Egress:

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

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

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", Internet-Draft draft-filsfils-spring-srv6-network-programming-07, 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)", Internet-Draft draft-ietf-6man-segment-routing-header-26, October 2019.
[I-D.ietf-detnet-dp-sol-mpls] Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Encapsulation", Internet-Draft draft-ietf-detnet-dp-sol-mpls-02, March 2019.
[I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-08, July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.
[RFC8655] Finn, N., Thubert, P., Varga, B. and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019.
[RFC8754] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020.

Authors' Addresses

Xuesong Geng Huawei EMail: gengxuesong@huawei.com
Zhenbin Li Huawei EMail: lizhenbin@huawei.com
Mach Chen Huawei EMail: mach.chen@huawei.com