Skip to main content

Deterministic Networking Application in Ring Topologies
draft-jiang-detnet-ring-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yuanlong Jiang , Norman Finn , Jeong-dong Ryoo , Balazs Varga , Liang Geng
Last updated 2018-07-02
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jiang-detnet-ring-01
Network Working Group                                         Y. Jiang
Internet-Draft                                                 N. Finn
Intended status: Standards Track                                Huawei
                                                               J. Ryoo
                                                                  ETRI
                                                              B. Varga
                                                              Ericsson
                                                               L. Geng
                                                          China Mobile
Expires: January 2019                                     July 2, 2018

          Deterministic Networking Application in Ring Topologies
                        draft-jiang-detnet-ring-01

Abstract

   Deterministic Networking (DetNet) provides a capability to carry
   data flows for real-time applications with extremely low data loss
   rates and bounded latency. This document describes how DetNet can
   be used in ring topologies to support Point-to-Point (P2P) and
   Point-to-Multipoint (P2MP) real-time services.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 2, 2019.

Jiang and et al        Expires January 2, 2019                [Page 1]
Internet-Draft                 DetNet Ring                   July 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
   (http://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 ............................................... 3
      1.1. Conventions used in this document ....................... 3
      1.2. Terminology ............................................. 4
   2.   P2P DetNet Ring ............................................ 4
      2.1. DetNet applications on a single ring for P2P traffic .... 4
      2.2. Implementation implications of a DetNet ring for P2P
      traffic ...................................................... 5
   3.   P2MP DetNet Ring ........................................... 5
      3.1. DetNet applications on a single ring for P2MP traffic ... 5
      3.2. Section LSPs as underlay (Service layer replication) .... 6
      3.3. P2MP LSP tunnels as underlay (LSP layer replication) .... 7
   4.   DetNet Ring Interconnections ............................... 8
      4.1. Single node interconnection ............................. 9
      4.2. Dual node interconnection ............................... 9
      4.2.1.  Dual node interconnection for P2P traffic ............ 9
      4.2.2.  Dual node interconnection for P2MP traffic using
      section LSP ................................................. 10
      4.2.3.  Dual node interconnection for P2MP traffic using P2MP
      LSP     11
   5.   Resource reservation ...................................... 11
   6.   Security Considerations ................................... 11
   7.   IANA Considerations ....................................... 12
   8.   References ................................................ 12
      8.1. Normative References ................................... 12
      8.2. Informative References ................................. 12
   9.   Acknowledgments ........................................... 13

Jiang and et al        Expires January 2, 2019                [Page 2]
Internet-Draft                 DetNet Ring                   July 2018

1. Introduction

   An overview of Deterministic Networking (DetNet) architecture is
   given in [I-D.ietf-detnet-architecture], and DetNet data plane
   encapsulations are specified in [I-D.ietf-detnet-dp-sol]. But there
   is not any discussion on a ring topology in [I-D.ietf-detnet-
   architecture] yet. Furthermore, [I-D.ietf-detnet-use-cases]
   outlines several Detnet use cases where multicast capability is
   needed. If a multicast service replicates all of its packets from
   the source (as a traditional Virtual Private LAN Service (VPLS)
   does), the requirements of deterministic delay and high
   availability for all these replicated packets will pose a great
   challenge to the Detnet network.

   In fact, ring topologies have been very popular and widely deployed
   in network arrangements for various transport networks, such as
   Synchronous Digital Hierarchy, Synchronous Optical Network, Optical
   Transport Network, and Ethernet. The IETF has done some work on
   ring protection in Multi-Protocol Label Switching - Transport
   Profile (MPLS-TP), such as [RFC6974] and [RFC8227]. All these works,
   except Ethernet ring protection, typically use swapping or steering
   as the protection mechanism. As ring topologies are widely deployed
   for transport networks, it is also necessary for DetNet to support
   ring topologies (currently, there is not any discussion on a ring
   topology in [I-D.ietf-detnet-architecture] yet).

   This draft demonstrates how DetNet can be used in a ring topology.
   Specifically, DetNet ring supports for Point-to-Point (P2P) and
   Point-to-Multipoint (P2MP, for multicast services) are discussed in
   details. This document assumes that MPLS encapsulation for DetNet
   is supported as specified in [I-D.ietf-detnet-dp-sol-mpls] and all
   nodes in a ring network can support the Multi-Protocol Label
   Switching (MPLS) functionalities. It should be noted that it is
   more convenient for DetNet to support a ring topology with the
   intrinsic duplication and elimination mechanism, as there is no
   need of swapping or steering operations (consequently, its
   Operations, Administration and Maintenance (OAM) can also be
   simplified) for any service protection.

1.1. Conventions used in this document

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

Jiang and et al        Expires January 2, 2019                [Page 3]
Internet-Draft                 DetNet Ring                   July 2018

1.2. Terminology

   DetNet  Deterministic Networking

   LSP    Label Switched Path

   MPLS    Multi-Protocol Label Switching

   MPLS-TP Multi-Protocol Label Switching - Transport Profile

   P2MP   Point-to-Point

   P2P    Point-to-Multipoint

   PEF    Packet Elimination Function

   PRF    Packet Replication Function

   PW      Pseudowire

2. P2P DetNet Ring

2.1. DetNet applications on a single ring for P2P traffic

   Figure 1 depicts an example of the DetNet ring for P2P real time
   traffic. Nodes A and C are DetNet aware devices, and P2P DetNet
   traffic is transported from node A to node C.

   A clockwise and a counter clockwise Pseudowire (PW) and Label
   Switched Path (LSP) tunnel are configured from node A to node C
   respectively. The DetNet traffic is replicated by a Packet
   Replication Function (PRF) in node A, encapsulated with the
   specific PW and LSP labels, and transported on both LSP paths
   towards node C. Upon reception of the traffic, node C terminates
   the LSP and is aware of the DetNet traffic by inspection of the PW
   label carried in each packet. A Packet Elimination Function (PEF)
   in node C guarantees that only one copy of the DetNet service exits
   on egress with the help of the DetNet sequence number.

Jiang and et al        Expires January 2, 2019                [Page 4]
Internet-Draft                 DetNet Ring                   July 2018

                          +---+#############+---+
                          | B |-------------| C | +-- DetNet
                          +---+             +---+     egress
                          #/                    *\
                         #/                      *\
                        #/                        *\
                      +---+                     +---+
            DetNet--+ | A |                     | D |
           ingress    +---+                     +---+
                         \*                      */
                          \*                    */
                           \*                  */
                          +---+*************+---+
                          | F |-------------| E |
                          +---+             +---+

                            ----- Physical Links
                            ##### Clockwise_
                            ***** Counter Clockwise

                      Figure 1: DetNet Ring for P2P traffic

2.2. Implementation implications of a DetNet ring for P2P traffic

   In a DetNet ring for P2P traffic, one path may be far longer than
   the other path for the DetNet (this is a DetNet issue more general
   than a ring).

   The buffer needs to be large enough to accommodate for the sequence
   number difference between these two paths. Otherwise, some packets
   may get lost when a link fault causes traffic switching from a path
   to another path.

3. P2MP DetNet Ring

3.1. DetNet applications on a single ring for P2MP traffic

   Figure 2 further depicts an example of the DetNet ring for P2MP
   real time traffic. Nodes A, B, C, E and F are DetNet aware devices,
   and P2MP DetNet traffic is transported from head-end node A to
   multiple tail-end nodes C, E and F.

Jiang and et al        Expires January 2, 2019                [Page 5]
Internet-Draft                 DetNet Ring                   July 2018

   Two approaches are described in Section 3.2 and 3.3 for P2MP
   traffic.

                        +---+#############+---+
                        | B |-------------| C | +-- DetNet
                        +---+*************+---+     egress
                        #/                    *\#
                       #/                      *\#
                      #/                        *\#
                    +---+                     +---+
          DetNet--+ | A |                     | D |
         ingress    +---+                     +---+
                       \*                      */#
                        \*                    */#
                         \*                  */#
                        +---+*************+---+
              DetNet--+ | F |-------------| E |+-- DetNet
              egress    +---+#############+---+    egress

                          ----- Physical Links
                          ##### Clockwise traffic
                          ***** Counter Clockwise traffic

                    Figure 2: DetNet Ring for P2MP traffic

3.2. Section LSPs as underlay (Service layer replication)

   If section LSPs are used as an underlay for DetNet services, a
   bidirectional section LSP tunnel is set up between each pair of
   neighboring nodes in the ring (e.g., node A and node B, ..., node F
   and node A). In this case, DetNet PW layer replicates the DetNet
   packets from one tail-end to another neighboring tail-end.

   The DetNet head-end (i.e., node A) in the ring needs to support
   DetNet replication function. Upon reception on node A, the DetNet
   traffic is replicated in node A, encapsulated with the specific PW
   and section LSP labels, and then transported on both section LSPs
   (i.e., A-B and A-F) originated from the head-end.

   All intermediate nodes (non tail-ends) on the ring SHOULD
   transparently forward the DetNet traffic with a specific PW to the
   next hop on the ring in the same direction.

   All DetNet tail-ends except the penultimate node (egress nodes such
   as nodes C and E in the clockwise, and node F, E and C in the
   counter clockwise) on the ring MUST support both DetNet PRF and PEF

Jiang and et al        Expires January 2, 2019                [Page 6]
Internet-Draft                 DetNet Ring                   July 2018

   functions. For example, upon reception of the clockwise traffic,
   node C terminates the section LSP and is aware of the DetNet
   traffic by inspection of the PW label in the packet. Firstly, node
   C needs to transparently forward the DetNet traffic with a specific
   PW to the next hop on the ring in the same direction. Secondly,
   DetNet traffic is directed to a DetNet PEF associated with a
   specific PW, only one copy of the DetNet service exits on egress by
   inspection of the DetNet sequence number.

   If multiple endpoints are attached to a tail-end node, a multicast
   module can be used to forward the filtered DetNet traffic to all
   these endpoints.

   To avoid a loop of DetNet service, the penultimate node in the ring
   (such as node B on the counter clock-wise LSP) needs to terminate
   the DetNet flow. For example, upon reception of the clockwise
   DetNet traffic, node F terminates the DetNet traffic by inspection
   of the PW label in the packet. As an alternative, the last DetNet
   tail-end (such as node C on the counter clock-wise LSP) may
   terminate the DetNet flow, so that the bandwidth from this node to
   the penultimate node can be saved.

3.3.  P2MP LSP tunnels as underlay (LSP layer replication)

   If P2MP LSPs are used as an underlay for the DetNet service, a P2MP
   unidirectional LSP tunnel in clockwise is set up from head-end
   (ingress node A) to all the tail-ends (egress nodes C, E and F) for
   the ring, and another P2MP unidirectional LSP tunnel in counter
   clockwise is set up from head-end (ingress node A) to all the tail-
   ends (egress nodes F, E and C) for the ring. Thus, a PRF in LSP
   layer replicates the DetNet packets from one tail-end to another
   neighboring tail-end.

   The DetNet head-end (i.e., node A) in the ring needs to support
   DetNet PRF function. Upon reception on node A, the DetNet traffic
   is replicated, encapsulated with the specific PW and P2MP LSP
   labels, and transported on both P2MP LSP tunnels in the ring.

   All DetNet tail-ends (egress nodes such as node C, E and F in
   Figure 2) on the ring need to support the DetNet PEF function. For
   example, upon reception of the traffic, node C pops the P2MP LSP
   label and is aware of the DetNet traffic by inspection of the PW
   label in the label stack. Traffic from both directions with the
   same PW is directed to the same PEF so that only one copy of the

Jiang and et al        Expires January 2, 2019                [Page 7]
Internet-Draft                 DetNet Ring                   July 2018

   DetNet service exits on egress by inspection of the DetNet sequence
   number.

   If multiple endpoints are attached to a tail-end node, a multicast
   module can be used to forward the filtered DetNet traffic to all
   these endpoints.

4. DetNet Ring Interconnections

   Two DetNet rings can be connected via one or more interconnection
   nodes. Figures 3(a) and 3(b) show the ring interconnection
   scenarios with a single node and dual nodes respectively. In the
   interconnected rings, each ring operates in the same way as
   described in Sections 2 and 3 except the node or nodes that are
   used to interconnect two rings.

   In this section, we describe the behavior of interconnection nodes
   with the traffic going from Ring L to Ring R. Symmetrical
   description is assumed for the traffic in the other direction (i.e.,
   from Ring R to Ring L).

                                            S   T
         B   C     S   T                    O---O
         O---O     O---O                   /     \
        /     \   /     \            B  I1/       \
       /       \ /       \           O---O  Ring R O U
    A O Ring L  O Ring R  O U       /     \       /
       \       /I\       /         /       \     /
        \     /   \     /       A O Ring L  O---O
         O---O     O---O           \       /I2  V
         F   E     W   V            \     /
                                     O---O
                                     F   E

            (a)                         (b)

   Figure 3: DetNet ring interconnection with: (a) single node (node
   I), and (b) dual nodes (nodes I1 and I2).

Jiang and et al        Expires January 2, 2019                [Page 8]
Internet-Draft                 DetNet Ring                   July 2018

4.1. Single node interconnection

   In the case of the single node interconnection, as shown in Figure
   3(a), both P2P and P2MP DetNet traffic that needs to be transported
   between Ring L and Ring R uses a single interconnection node
   between two rings. Thus, the interconnection node acts as a DetNet
   relay node, which provides both PRF and PEF functions.

   For P2P DetNet traffic going from Ring L to Ring R, interconnection
   node I receives the same Detnet flow traffic from both node C and
   node E (i.e., clockwise and counter-clockwise), a PEF in node I
   performs packet elimination, and a PRF in node I replicates the
   packet, node I then sends one copy to node S and another copy to
   node W.

   For P2MP DetNet traffic going from Ring L to Ring R,
   interconnection node I performs the same packet elimination and
   replication functions as described above. In addition, node I
   further transparently forwards the P2MP DetNet traffic on Ring L in
   the same direction if it is not the last tail-end node.

4.2. Dual node interconnection

   In order to prevent a single point of failure, two interconnection
   nodes can be used as shown in Figure 3(b). To provide high
   availability for DetNet services, dual node interconnection is
   recommended. Two interconnection nodes act as DetNet relay nodes,
   each provides both packet replication and elimination functions.

4.2.1. Dual node interconnection for P2P traffic

   For the P2P DetNet traffic that flows from Ring L to Ring R, the
   operation of interconnection nodes I1 and I2 follows the
   description on relay nodes shown in Figure 1 of Section 3.2.4 in
   [I-D.ietf-detnet-architecture]. In the following, the operation is
   explained with Figure 3(a).

   When interconnection node I1 receives clockwise traffic from node B,
   it replicates the traffic and sends one copy to interconnection
   node I2 and another copy to a PEF in node I1.

   When interconnection node I1 receives counter-clockwise traffic
   from interconnection node I2, it also forwards the traffic to the
   PEF of I1.

   At the PEF of I1, duplicate elimination is performed for the
   clockwise traffic from node B and the counter-clockwise traffic

Jiang and et al        Expires January 2, 2019                [Page 9]
Internet-Draft                 DetNet Ring                   July 2018

   from interconnection node I2, and only one copy is sent to the
   clockwise direction of Ring R (i.e., sent towards node S).

   When interconnection node I2 receives counter-clockwise traffic
   from node E, it replicates the traffic and sends one copy to
   interconnection node I1 and another copy to a PEF in node I2.

   When interconnection node I2 receives clockwise traffic from
   interconnection node I1, it also forwards the traffic to the PEF of
   I2.

   At the PEF of I2, duplicate elimination is performed for the
   counter-clockwise traffic from node E and the clockwise traffic
   from interconnection node I1, and only one copy is sent to the
   counter-clockwise direction of Ring R (i.e., sent towards node V).

4.2.2.Dual node interconnection for P2MP traffic using section LSP

   For the P2MP traffic that flows from Ring L to Ring R, each ring is
   configured and operated as described in Section 3.2 except the
   interconnection nodes, whose operations are described below.

   When interconnection node I1 receives clockwise traffic from node B,
   its PRF replicates the traffic and sends one copy to
   interconnection node I2 and another copy to node I1's PEF.

   When interconnection node I1 receives the counter-clockwise traffic
   from interconnection node I2, its PRF replicates the traffic and
   sends one copy to node B and another copy to node I1's PEF unless
   interconnection node I1 is the penultimate node for the counter-
   clockwise traffic on Ring L. In the case that interconnection node
   I1 is the penultimate node for the counter-clockwise traffic on
   Ring L, the counter-clockwise traffic from interconnection node I2
   is only forwarded to node I1's PEF.

   At node I1's PEF, duplicate elimination is performed for the
   clockwise traffic from node B and the counter-clockwise traffic
   from interconnection node I2, and only one copy is sent to the
   clockwise direction of Ring R (i.e., sent towards node S).

   When interconnection node I2 receives the counter-clockwise traffic
   from node E, its PRF replicates the traffic and sends one copy to
   interconnection node I1 and another copy to node I2's PEF.

Jiang and et al        Expires January 2, 2019               [Page 10]
Internet-Draft                 DetNet Ring                   July 2018

   When interconnection node I2 receives the clockwise traffic from
   interconnection node I1, its PRF replicates the traffic and sends
   one copy to node E and another copy to node I2's PEF unless
   interconnection node I2 is the penultimate node for the clockwise
   traffic in Ring L. In the case that interconnection node I2 is the
   penultimate node for the clockwise traffic in Ring L, the clockwise
   traffic from interconnection node I1 is only forwarded to node I2's
   PEF.

   At node I2's PEF, duplicate elimination is performed for the
   counter-clockwise traffic from node E and the clockwise traffic
   from interconnection node I1, and only one copy is sent to the
   counter-clockwise direction of Ring R (i.e., sent towards node V).

4.2.3.Dual node interconnection for P2MP traffic using P2MP LSP

   If P2MP LSPs are used in the interconnected rings, two P2MP
   unidirectional LSP tunnels are used on each ring for the clockwise
   and counter-clockwise directions.

   When the P2MP traffic is forwarded from one ring to another ring,
   for example from Ring L to Ring R in Figure 3(b), each P2MP LSP in
   Ring L MUST include interconnection nodes I1 and I2 as its tail-
   ends. For Ring R, one P2MP LSP is set up from interconnection node
   I1 to all the tail-ends in the clockwise direction on Ring R, and
   the other P2MP LSP is set up from interconnection node I2 to all
   the tail-ends in the counter-clockwise direction on Ring R.
   Therefore, an interconnection node acts as a tail-end for one ring
   and a head-end for another ring in one direction, and performs the
   same operation of tail-end and head-end as specified in Section 3.3.

5. Resource reservation

   In order to guarantee that DetNet flows don't suffer from network
   congestion, resource reservation considerations as outlined in
   Section 4.3.2 of [I-D.ietf-detnet-architecture] apply here.

6. Security Considerations

   This document describes the application of DetNet on general ring
   topologies. Thus the security considerations as described in [I-
   D.ietf-detnet-dp-sol] also apply to this document.

Jiang and et al        Expires January 2, 2019               [Page 11]
Internet-Draft                 DetNet Ring                   July 2018

7. IANA Considerations

   There are no IANA actions required by this document.

8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997

   [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B.,
             and J. Farkas, "Deterministic Networking Architecture",
             draft-ietf-detnet-architecture (work in progress), June
             2018

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

8.2. Informative References

   [I-D.ietf-detnet-dp-sol] Korhonen, J., Andersson, L., Jiang, Y.,
             and etc., "DetNet Data Plane Encapsulation", draft-ietf-
             detnet-dp-sol (work in progress), March 2018

   [I-D.ietf-detnet-use-cases] Grossman, E., and etc., "Deterministic
             Networking Use Cases", draft-ietf-detnet-use-cases (work
             in progress), June 2018

   [RFC6974] Weingarten, Y., Bryant, S., and etc., "Applicability of
             MPLS Transport Profile for Ring Topologies", RFC 6974,
             July 2013

   [RFC8227] Cheng, W., Wang, L., and etc., "MPLS-TP Shared-Ring
             Protection (MSRP) Mechanism for Ring Topology", RFC 8227,
             August 2017

Jiang and et al        Expires January 2, 2019               [Page 12]
Internet-Draft                 DetNet Ring                   July 2018

9. Acknowledgments

   TBD

Authors' Addresses

   Yuanlong Jiang
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China
   Phone: +86-18926415311
   Email: jiangyuanlong@huawei.com

   Norman Finn
   Huawei Technologies Co. Ltd
   3755 Avocado Blvd,
   California  91941, USA
   Phone: +1 925 980 6430
   Email: norman.finn@mail01.huawei.com

   Jeong-dong Ryoo
   ETRI
   218 Gajeongno
   Yuseong-gu, Daejeon 305-700, South Korea
   Phone: +82-42-860-5384
   Email: ryoo@etri.re.kr

   Balazs Varga
   Ericsson
   Konyves Kalman krt. 11/B
   Budapest 1097
   Hungary
   Email: balazs.a.varga@ericsson.com

   Liang Geng
   China Mobile
   Beijing, China
   Email: gengliang@chinamobile.com

Jiang and et al        Expires January 2, 2019               [Page 13]