[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]
Versions: 00 01 02 03 04
Network Working Group Y. Jiang
Internet-Draft N. Finn
Intended status: Informational Huawei
J. Ryoo
ETRI
B. Varga
Ericsson
L. Geng
China Mobile
Expires: July 2018 January 24, 2018
Deterministic Networking Application in Ring Topologies
draft-jiang-detnet-ring-00
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 July 24, 2018.
Jiang and et al Expires July 24, 2018 [Page 1]
Internet-Draft DetNet Ring January 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 ....................... 4
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 ............................. 8
4.1.1. DetNet relay node as interconnection node ............ 9
4.1.2. Elimination first approach ........................... 9
4.2. Dual node interconnection .............................. 10
4.2.1. Dual node interconnection for P2P traffic ........... 10
4.2.2. Elimination first approach in dual node interconnection
for P2P traffic ............................................. 11
4.2.3. Dual node interconnection for P2MP traffic using
section LSP ................................................. 11
4.2.4. Elimination first approach in dual node interconnection
for P2MP traffic using section LSP .......................... 12
4.2.5. Dual node interconnection for P2MP traffic using P2MP
LSP 13
5. Resource reservation ...................................... 13
6. Security Considerations ................................... 13
7. IANA Considerations ....................................... 13
Jiang and et al Expires July 24, 2018 [Page 2]
Internet-Draft DetNet Ring January 2018
8. References ............................................... 13
1.1. Informative References ................................ 13
9. Acknowledgments .......................................... 15
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] 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, Operations,
Administration and Maintenance is not needed either for its working)
for any service protection.
Jiang and et al Expires July 24, 2018 [Page 3]
Internet-Draft DetNet Ring January 2018
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].
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
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 on 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. An elimination
function 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 July 24, 2018 [Page 4]
Internet-Draft DetNet Ring January 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 need 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 July 24, 2018 [Page 5]
Internet-Draft DetNet Ring January 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
Jiang and et al Expires July 24, 2018 [Page 6]
Internet-Draft DetNet Ring January 2018
replication and elimination 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
elimination function 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, 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 replication 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 elimination
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 DetNet elimination
Jiang and et al Expires July 24, 2018 [Page 7]
Internet-Draft DetNet Ring January 2018
function so that 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.
4. DetNet Ring Interconnections
Two DetNet rings can be connected via one or more interconnection
nodes. Figures 3a and 3b show 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 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.
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).
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 the single interconnection node
between two rings. Two approaches are described in the following
subsections.
Jiang and et al Expires July 24, 2018 [Page 8]
Internet-Draft DetNet Ring January 2018
4.1.1. DetNet relay node as interconnection node
In this approach, the interconnection node acts as a DetNet relay
node, which provides packet replication and elimination.
For P2P DetNet traffic going from Ring L to Ring R, interconnection
node I performs packet replication on input and sends the packet to
the outputs connected to the links on Ring R clockwise and counter-
clockwise. Then, after each output of interconnection node I
eliminates any duplicates, the packet is transported over Ring R.
In Figure 3(a), when interconnection node I receives traffic on
input from node C, node I replicates the traffic and send it to
both outputs to nodes S and W. For the traffic from input from node
E, node I also replicates the traffic and send it to both outputs
to nodes S and W. Then, the output to node S eliminates any
duplicates, and sends only one copy to node S. Similarly, the
output to node W eliminates any duplicates, and sends only one copy
to node W.
For P2MP DetNet traffic going from Ring L to Ring R, the input of
interconnection node I performs the same packet replication as
described for P2P DetNet traffic going from Ring L to Ring R. In
addition, the third copy is sent to the other ring port on Ring L,
in order to deliver the P2MP DetNet traffic to the remaining tail-
end nodes that reside in the other side of Ring L over the
interconnected node. The outputs to nodes S and W perform the same
duplicate elimination as described for P2P DetNet traffic going
from Ring L to Ring R.
4.1.2. Elimination first approach
This approach uses two "logical" DetNet relay nodes (or, DA-*-PE as
described in [I-D.ietf-detnet-dp-sol]) coupled back-to-back, such
that interconnection node I performs the duplicate elimination
function first.
For the Detnet traffic arrived from both node C and node E, the
interconnection node I performs duplicate elimination first, and
then replicates the traffic in both clockwise and counter-clockwise
directions of Ring R, i.e., one copy to node S and the other copy
to node W. Therefore, this approach reduces the bandwidth used
inside the interconnection node when there is a central unit that
eliminates any duplicate among the packets arrived from two ring
ports before replication.
Jiang and et al Expires July 24, 2018 [Page 9]
Internet-Draft DetNet Ring January 2018
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,
which provide packet replication and elimination.
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 the other copy to output towards node S.
When interconnection node I1 receives counter-clockwise traffic
from interconnection node I2, it forwards the traffic to the output
that is connected to node S.
At the output of interconnection node I1 facing to node S,
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 counter-clockwise traffic
from node E, it replicates the traffic and sends one copy to
interconnection node I1 and the other copy to the output that is
connected to node V.
When interconnection node I2 receives clockwise traffic from
interconnection node I1, it forwards the traffic to the output that
is connected to node V.
At the output of interconnection node I2 facing to node V,
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).
Jiang and et al Expires July 24, 2018 [Page 10]
Internet-Draft DetNet Ring January 2018
4.2.2. Elimination first approach in dual node interconnection for P2P
traffic
The elimination first approach described in Section 4.1.2 can also
be used for dual node interconnection, so that each interconnection
node performs the duplicate elimination function first.
For the traffic arrived from both node B and interconnection node
I2, the interconnection node I1 performs duplicate elimination
first, and replicates the traffic in both clockwise and counter-
clockwise directions of Ring R, i.e., one copy to node S and the
other copy to interconnection node I2.
For the traffic arrived from both node E and interconnection node
I1, the interconnection node I2 performs duplicate elimination
first, and replicates the traffic in both clockwise and counter-
clockwise directions of Ring R, i.e., one copy to interconnection
node I1 and the other copy to node V.
4.2.3.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,
it replicates the traffic and sends one copy to interconnection
node I2 and the other copy to the output that is connected to node
S.
When interconnection node I1 receives the counter-clockwise traffic
from interconnection node I2, it replicates the traffic and sends
one copy to node B and the other copy to the output that is
connected to node S 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 forwarded to the output
that is connected to node S.
At the output interface of I1 facing to node S, 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).
Jiang and et al Expires July 24, 2018 [Page 11]
Internet-Draft DetNet Ring January 2018
When interconnection node I2 receives the counter-clockwise traffic
from node E, it replicates the traffic and sends one copy to
interconnection node I1 and the other copy to the output that is
connected to node V.
When interconnection node I2 receives the clockwise traffic from
interconnection node I1, it replicates the traffic and sends one
copy to node E and the other copy to the output that is connected
to node V 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 forwarded to the output that is connected to node V.
At the output interface of I2 facing to node V, 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.4. Elimination first approach in dual node interconnection for
P2MP traffic using section LSP
The elimination first approach described in Section 4.2.2 is
applied without modification for dual node interconnection for P2MP
traffic using section LSP only if interconnection nodes I1 and I2
are the penultimate nodes for the counter-clockwise traffic and the
clockwise traffic on Ring L, respectively.
When an interconnection node is not the penultimate node for either
clockwise or counter-clockwise traffic, the interconnection node
replicates the traffic in three ways; one for the remaining tail-
ends on Ring L and two for the tail-ends in both clockwise and
counter-clockwise directions on Ring R.
For example, assume that interconnection node I2 is not the
penultimate node for the clock-wise traffic on Ring L. For the
traffic arrived from both node E and interconnection node I1,
interconnection node I2 performs duplicate elimination first, and
replicates the traffic for the following three outputs; one copy to
the output towards node E, another copy to the output towards
interconnection node I1, and the other copy to the output towards
node V.
Jiang and et al Expires July 24, 2018 [Page 12]
Internet-Draft DetNet Ring January 2018
4.2.5.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 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.
7. IANA Considerations
There are no IANA actions required by this document.
8. References
1.1. Informative References
[I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B.,
and J. Farkas, "Deterministic Networking Architecture",
draft-ietf-detnet-architecture (work in progress),
October 2017
Jiang and et al Expires July 24, 2018 [Page 13]
Internet-Draft DetNet Ring January 2018
[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), October, 2017
[I-D.ietf-detnet-use-cases] Grossman, E., and etc., "Deterministic
Networking Use Cases", draft-ietf-detnet-use-cases (work
in progress), October, 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[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 July 24, 2018 [Page 14]
Internet-Draft DetNet Ring January 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 July 24, 2018 [Page 15]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/