SPRING Working Group X. Geng
Internet-Draft M. Chen
Intended status: Standards Track F. Yang
Expires: May 6, 2021 Huawei Technologies
November 2, 2020
Segment Routing for Redundancy Protection
draft-geng-spring-sr-redundancy-protection-00
Abstract
Redundancy protection is one of the mechanisms to achieve service
protection, following the principle of PREOF (Packet Replication/
Elimination/Ordering Function). To empower the Segment Routing with
the capability of redundancy protection, two types of Segment
including Redundancy Segment and Merging Segment are introduced. The
instantiation of Redundancy and Merging Segments can be applied to
both segment routing over MPLS (SR-MPLS) and segment routing over
IPv6 (SRv6).
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 .
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 May 6, 2021.
Geng, et al. Expires May 6, 2021 [Page 1]
Internet-Draft November 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Redundancy Protection in Segment Routing Scenario . . . . . . 3
4. Segment to Support Redundancy Protection . . . . . . . . . . 4
4.1. Redundancy Segment . . . . . . . . . . . . . . . . . . . 5
4.2. Merging Segment . . . . . . . . . . . . . . . . . . . . . 5
5. Meta Information to Support Redundancy Protection . . . . . . 6
6. Segment Routing Policy to Support Redundancy Protection . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Service protection defined in [RFC8655] is initially required from
the use cases in a variety of industries described in [RFC8578].
Together with other two techniques Resource allocation and Explicit
routes, targets to provide the deterministic flow transmission.
Meanwhile, with the emerge of Cloud VR, Cloud Game, HDV (high-
definition video) applications running in the Internet, SLA (Service
Level Agreement) guarantee becomes an important issue which requires
new technologies and solutions for network.
Redundancy Protection is one of the mechanisms to achieve service
protection, following the principle of PREOF (Packet Replication/
Elimination/Ordering Function) defined in [RFC8655]. Specifically,
replicates the packets of flows into two or more copies, transports
Geng, et al. Expires May 6, 2021 [Page 2]
Internet-Draft November 2020
different copies through different path in parallel, eliminates and
orders the packets at end to provide redundancy protection.
Segment Routing (SR) leverages the source routing paradigm. An
ingress node steers a packet through an ordered list of instructions,
called "segments". A segment can be associated to an arbitrary
processing of the packet in the node identified by the segment.
This document extends the capabilities in SR paradigm to support the
redundancy protection, including the definitions of new Segments and
a variation of Segment Routing Policy. The new mechanism applies
equally to both segment routing with MPLS data plane (SR-MPLS) and
segment routing with IPv6 data plane (SRv6).
2. Terminology and Conventions
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
[I-D.ietf-spring-srv6-network-programming] and[RFC2119].
Redundancy Node: the start point of redundancy protection, which is a
network device that could implement packet replication
Merging Node: the end point of redundancy protection, which is a
network node that could implement packet elimination and ordering
(optionally)
Redundancy Policy: an extended SR policy which includes more than one
active segment lists to support redundancy protection
Flow Identification: information in SR data service to indicate one
flow
Sequence Number: information in SR data service to indicate the
packet sequence of one flow
Editor's Note: Similar mechanism is defined as "Service Protection"
in the [RFC8655]. In this document, we define a new term "Redundancy
Protection" to distinguish with other service protection method.
Some of the terms are similar as [RFC8655].
3. Redundancy Protection in Segment Routing Scenario
Geng, et al. Expires May 6, 2021 [Page 3]
Internet-Draft November 2020
| |
|<-------------- SR Domain ------------->|
| |
| +-----+R3+-----+ |
+---+ +-+-+ +-+-+ +---+
-------|R1 |--------|Red| |Mer|--------|R2 |-------
+---+ +-+-+ +-+-+ +---+
+-----+R4+-----+
Figure 1: Example Scenario of Redundancy Protection in SR Domain
This figure shows the process of redundancy protection when a flow is
sent into SR domain:
1) R1 receives the packet flow and encapsulates with segment to
destination R2, either instantiated in a stack of MPLS labels or
Segment Routing Extension Header (SRH) defined in [RFC8754];
2) When the packet flow arrives in Red node, known as Redundancy
Node, one flow is replicated to two copies with the same flow
identifier; For each packet in one flow, sequence number is marked to
indicate the packet sequence; the flow identifier and sequence number
of each packet can alternatively be marked at the ingress edge R1 of
SR domain;
3) Two replicated flows go through different paths till Mer node,
known as Merging Node; When there is any failures happened in one
path, the service continues to deliver through the other path without
break;
4) The first received packet of the flow is transmitted from Merging
Node to R2, and the redundant packets are eliminated;
5) Sometimes, the packet will arrive out of order because of
redundancy protection, the function of reordering may be necessary in
the Merging Node;
In this example, service protection is supported by utilizing at
least two packet flows transmitted over two candidate paths. For a
unidirectional flow, Red node supports replication function, and Mer
node supports elimination and ordering functions.
4. Segment to Support Redundancy Protection
To achieve the Packet Replication/ Elimination/Ordering Function,
Redundancy Segment and Merging Segment are introduced.
Geng, et al. Expires May 6, 2021 [Page 4]
Internet-Draft November 2020
4.1. Redundancy Segment
Redundancy Segment is associated with a Redundancy Policy on
redundancy node. Redundancy Segment is associated with service
instructions, indicating the following operations:
o Steering the packet into the corresponding redundancy policy
o Packet replication based on the redundancy policy, e.g., the
number of replication copies
o Encapsulate the packet with necessary meta data (e.g., flow
identification, sequence number) if it is not included in the
original packet
In the case of SRv6, a new behavior End.R for Redundancy Segment is
defined.
When N receives a packet whose IPv6 DA is S and S is a Redundancy
SID, N does:
S01. When an SRH is processed {
S02. If (Segments Left>0) {
S03. Create two headers IPv6+SRH-1 and IPv6+SRH-2
S04. Insert different policy-instructed segment lists into SRH-1 and SRH-2
S05. Add Flow Identification and Sequence Number to SRH-1 and SRH-2
S06. Remove the incoming outer IPv6+SRH header
S07. Create a duplication of the incoming packet payload
S08. Encapsulate the original packet with IPv6+SRH-1 header
S09. Encapsulate the duplicate packet with IPv6+SRH-2 header
S10. Set IPv6 SA as the local address of this node
S11. Set IPv6 DA of IPv6+SRH-1 to the first segment of SRv6 Policy in SRH-1
S12. Set IPv6 DA of IPv6+SRH-2 to the first segment of SRv6 Policy in SRH-2
S13. }
S14. ELSE {
S15. Drop the packet
S16. }
4.2. Merging Segment
Merging Segment is associated with service instructions, indicates
the following operations:
o Packet merging and elimination: forward the first received packets
and eliminate the redundant packets
o Packet ordering(optional): reorder the packets if the packet
arrives out of order
Geng, et al. Expires May 6, 2021 [Page 5]
Internet-Draft November 2020
In the case of SRv6, a new behavior End.M for Merging Segment is
defined.
When N receives a packet whose IPv6 DA is S and S is a Merging SID, N
does:
S01. When an SRH is processed {
S02. If (Segments Left>0) & "the packet is not a redundant packet" {
S03. Do not decrement SL nor update the IPv6 DA with SRH[SL]
S04. Create a new outer IPv6+SRH-3 header
S05. Insert the policy-instructed segment lists in the newly created SRH-3
S06. Remove the incoming outer IPv6+SRH header
S07. Set IPv6 DA of IPv6+SRH-3 to the first segment of SRv6 Policy in SRH-3
S08. }
S09. ELSE {
S10. Drop the packet
S11. }
5. Meta Information to Support Redundancy Protection
To distinguish the different copies replicated at Redundancy node,
and distinguish the different packets in the same flow to perform
elimination and ordering, the definition of Flow Identification and
Sequence Number is required.
Flow Identification and Sequence Number can be defined as MPLS labels
in SR over MPLS data plane, or as option TLV in SRH header in SR over
IPv6 data plane. This information must be carried along the path to
Merging node. Merging node removes Flow Identifier and Sequence
Number once the elimination and ordering is accomplished.
6. Segment Routing Policy to Support Redundancy Protection
Redundancy Policy is a variation of SR Policy, which is identified
through the tuple <redundancy node, redundancy ID, merging node>.
Redundancy Policy extends SR policy to include more than one ordered
lists of segments between redundancy node and merging node to steer
the same flow through different paths in SR domain. In Redundancy
Policy, Redundancy Segment MUST be specified, and the last segment of
each ordered list of segments SHOULD be Merging Segment.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Geng, et al. Expires May 6, 2021 [Page 6]
Internet-Draft November 2020
8. Security Considerations
TBD
9. Acknowledgements
TBD
10. References
10.1. Normative References
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-24 (work in
progress), October 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>.
10.2. Informative References
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>.
[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 Technologies
Email: gengxuesong@huawei.com
Geng, et al. Expires May 6, 2021 [Page 7]
Internet-Draft November 2020
Mach(Guoyi) Chen
Huawei Technologies
Email: mach.chen@huawei.com
Fan Yang
Huawei Technologies
Email: shirley.yangfan@huawei.com
Geng, et al. Expires May 6, 2021 [Page 8]