SPRING Working Group X. Geng
Internet-Draft M. Chen
Intended status: Standards Track F. Yang
Expires: August 26, 2021 Huawei Technologies
February 22, 2021
Segment Routing for Redundancy Protection
draft-geng-spring-sr-redundancy-protection-01
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 August 26, 2021.
Geng, et al. Expires August 26, 2021 [Page 1]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
Copyright Notice
Copyright (c) 2021 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 . . . . . . 4
4. Segment to Support Redundancy Protection . . . . . . . . . . 5
4.1. Redundancy Segment . . . . . . . . . . . . . . . . . . . 5
4.1.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 5
4.1.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Alternative Option of Redundancy Segment . . . . . . . . 6
4.3. Merging Segment . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 7
4.3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Meta Data to Support Redundancy Protection . . . . . . . . . 7
6. Segment Routing Policy to Support Redundancy Protection . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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, it targets to provide the deterministic flow transmission.
Meanwhile, with the emerge of Cloud VR, Cloud Game, 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.
Geng, et al. Expires August 26, 2021 [Page 2]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
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
different copies through different paths 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].
Geng, et al. Expires August 26, 2021 [Page 3]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
3. Redundancy Protection in Segment Routing Scenario
| |
|<-------------- SR Domain ------------->|
| |
| +-----+R3+-----+ |
+---+ +-+-+ +-+-+ +---+
-------|R1 |--------|Red| |Mer|--------|R2 |-------
+---+ +-+-+ +-+-+ +---+
+-----+R4+-----+
Figure 1: Example Scenario of Redundancy Protection in SR Domain
This figure shows an example of redundancy protection used in SR
domain. When a flow is sent into SR domain, the process is:
1) R1 receives the traffic flow and encapsulates packets with a list
of segments, which is instantiated as a stack of MPLS labels or an
ordered list of SRv6 SIDs. The final destination of packets is R2.
R1, R2, R3, R4, Red and Mer are SR-capable nodes.
2) When the packet flow arrives in Red node, known as Redundancy
Node, one flow is replicated into two copies. Each copy of flow is
encapsulated with different newly-defined list of SIDs, and the last
SID is always pointed to the SID of Mer node, known as Merging Node.
3) Packet is encapsulated with the information of flow identification
and sequence number. Flow identification identifies the specific
flow, and sequence number distinguishes the packet sequence of a
flow.
4) When the original flow and replicated flow go through different
paths till Mer node, the first received packet of the flow is
transmitted from Merging Node to R2, and the redundant packets are
eliminated.
5) When there is any failures happened in one path, the service
continues to deliver through the other path without break.
6) 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 two
packet flows transmitted over two forwarding paths. For a
unidirectional flow, Red node supports replication function, and Mer
node supports elimination and ordering functions.
Geng, et al. Expires August 26, 2021 [Page 4]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
4. Segment to Support Redundancy Protection
To achieve the Packet Replication/Elimination/Ordering Function,
Redundancy Segment and Merging Segment are introduced.
4.1. Redundancy Segment
Redundancy Segment is associated with a Redundancy Policy on
redundancy node. Redundancy segment is instantiated with service
instructions, indicating the following operations:
o Steering the packet into the corresponding redundancy policy
o Packet replication and encapsulation 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
4.1.1. SR over MPLS
In the case of SR over MPLS, when the Active Segment is a redundancy
segment, a redundancy policy is associated. According to the
information of candidate paths in redundancy policy, packets are
replicated and a CONTINUE operation is applied. Incoming redundancy
segment is swapped with different Adj-SIDs to forward the packet in
different paths.
4.1.2. SRv6
In the case of SRv6, a new behavior End.R for redundancy segment is
defined.
When an SRv6-capable node (N) receives an IPv6 packet whose
destination address matches a local IPv6 address instantiated as an
SRv6 SID (S), and S is a Redundancy SID, N does:
Geng, et al. Expires August 26, 2021 [Page 5]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
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 segment list
S12. Set IPv6 DA of IPv6+SRH-2 to the first segment of SRv6 Policy in SRH-2 segment list
S13. }
S14. ELSE {
S15. Drop the packet
S16. }
Note that, redundancy node decapsulates the original IPv6 and SRH
header, and encapsulates another newly created IPv6 and SRH header to
the packet payload. In this case, it would not bring extra header
insertion risk to IPv6.
4.2. Alternative Option of Redundancy Segment
Redundancy segment can also be a variation of Binding SID (BSID).
Different paths between redundancy node and merging node can be
encapsulated or inserted by using the End.B6.Encaps and End.B6.Insert
behavior of BSID. In this way, headend can have a complete segment
list in SRH to indicate the path from R1 to R2 in Figure 1. Take
End.B6.Encaps as an example. The behavior of redundancy segment
includes replicating packets into different copies, pushing new IPv6
and SRH header to packets, and newly adding or copying the
information like flow identification and sequence number from
original packet. By using the BSID and End.B6.Encaps behavior, the
IPv6 header insertion issue can be avoided too.
4.3. 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 August 26, 2021 [Page 6]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
4.3.1. SR over MPLS
In the case of SR over MPLS, when the Active Segment is a Merging
Segment and this packet is not a redundant packet, a CONTINUE
operation is applied. Incoming merging segment is swapped with
Prefix-SID of destination address. The redundancy of packets is
determined by other techniques, and is not within the scope of this
document.
4.3.2. SRv6
In the case of SRv6, a new behavior End.M for Merging Segment is
defined.
When an SRv6-capable node (N) receives an IPv6 packet whose
destination address matches a local IPv6 address instantiated as an
SRv6 SID (S), and S is a Merging SID, N does:
S01. When an SRH is processed {
S02. If (Segments Left>0) {
S03. Acquire the sequence number of received packet and lookup it in a local table
S04. If (the sequence number is not existed in table ) {
S05. Store the packet and record the sequence number in table
S06. Decrement IPv6 Hop Limit by 1
S07. Decrement Segments Left by 1
S08. Update IPv6 DA with Segment List[Segments Left]
S09. Submit the packet to the egress IPv6 FIB lookup and transmit
S10. }
S11. ELSE {
S12. Drop the packet
S13. }
S14. }
S15. }
5. Meta Data to Support Redundancy Protection
To support the redundancy protection function, Flow Identification
and Sequence Number are required. Flow identification identifies the
specific flow with target of redundancy protection. Sequence number
distinguishes the packets within a flow by specifying the order of
packets. The information is carried in the service packets along the
different paths to merging node. Merging node removes flow
identifier and sequence number once the elimination and ordering is
accomplished. Flow identification and sequence number can be defined
as MPLS label in SR over MPLS data plane, or is extended in SRH in
SRv6 data plane. In case of SRv6,
[I-D.geng-6man-redundancy-protection-srh] specifies the options of
supporting flow identification and sequence number on SRH extensions.
Geng, et al. Expires August 26, 2021 [Page 7]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
Note that, the flow identification and sequence number can be added
either at the headend of the path, or at the redundancy node. In the
former case, the information is managed and assigned from the SDN
controller, and carried in the packet along the entire forwarding
path in SR domain. In the latter case, redundancy node assigns the
values of flow identification and sequence number itself, and this
information is only used between redundancy node and merging node.
6. Segment Routing Policy to Support Redundancy Protection
Redundancy Policy is a variation of SR Policy, and is identified
through the tuple <redundancy node, redundancy ID, merging node>.
Redundancy node is specified as IPv4/IPv6 address of the headend,
which is able to do packet replication. Merging node is specified as
IPv4/IPv6 address of the endpoint, which is able to do packet
elimination and ordering (optional). Redundancy ID could be a
specified value of "color" define in section 2.1 of
[I-D.ietf-spring-segment-routing-policy], which indicates the SR
policy as a redundancy policy. Redundancy ID could also be used to
distinguish different redundancy policies sharing the same redundancy
node and 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 requires registration of End.R behavior and End.M
behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment
Routing Parameters" registry.
8. Security Considerations
TBD
9. Acknowledgements
The authors would like to thank Bruno Decraene, Ron Bonica, and James
Guichard for their valuable comments.
10. References
Geng, et al. Expires August 26, 2021 [Page 8]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
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-28 (work in
progress), December 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
[I-D.geng-6man-redundancy-protection-srh]
Geng, X., M. Chen, and F. Yang, "SRH Extension for Redundancy
Protection", draft-geng-6man-redundancy-protection-
srh-00 (work in progress), February 2021.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress),
November 2020.
[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
Beijing
China
Email: gengxuesong@huawei.com
Geng, et al. Expires August 26, 2021 [Page 9]
Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021
Mach(Guoyi) Chen
Huawei Technologies
Beijing
China
Email: mach.chen@huawei.com
Fan Yang
Huawei Technologies
Beijing
China
Email: shirley.yangfan@huawei.com
Geng, et al. Expires August 26, 2021 [Page 10]