SPRING Working Group X. Geng
Internet-Draft M. Chen
Intended status: Standards Track F. Yang, Ed.
Expires: 19 August 2022 Huawei Technologies
P. Camarillo
Cisco Systems, Inc.
G. Mishra
Verizon Inc.
15 February 2022
SRv6 for Redundancy Protection
draft-ietf-spring-sr-redundancy-protection-01
Abstract
Redundancy Protection is a generalized protection mechanism to
achieve the high reliability of service transmission in Segment
Routing network. The mechanism inherits the "Live-Live" methodology,
targeting to enhance the functionalities of Segment Routing over
IPv6. Inspired by DetNet Packet Replication and Packet Elimination
functions, two new Segments are introduced to provide replication and
elimination functions on specific network nodes by leveraging SRv6
Segment programming capabilities.
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 19 August 2022.
Geng, et al. Expires 19 August 2022 [Page 1]
Internet-Draft SRv6 for Redundancy Protection February 2022
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
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.2. Merging Segment . . . . . . . . . . . . . . . . . . . . . 6
5. Meta Data to Support Redundancy Protection . . . . . . . . . 7
6. Segment Routing Policy to Support Redundancy Protection . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Redundancy Protection is a generalized protection mechanism to
achieve the high reliability of service transmission in Segment
Routing network. Specifically, packets of flows are replicated at a
network node into two or more copies, which are transported via
different and disjoint paths in parallel. When copies of packets are
received and merged at one network node, the redundant packets are
determined and further eliminated to guarantee only one copy of
packets is transmitted. The mechanism inherits the "Live-Live"
methodology, targeting to enhance the functionalities of Segment
Routing over IPv6 [RFC8986]. Inspired by DetNet [RFC8655] Packet
Replication and Packet Elimination Functions, two new Segments are
introduced to provide the replication and elimination functions on
Geng, et al. Expires 19 August 2022 [Page 2]
Internet-Draft SRv6 for Redundancy Protection February 2022
specific network nodes by leveraging SRv6 Segment programming
capabilities. As it is unnecessary to perform switchover of
recieving packets between different paths, redundancy protection can
facilitate to achieve zero packet loss target when failure on either
path happens.
Redundancy protection provides ultra reliable protection to many
services, for example Cloud VR/Game, IPTV service and other type of
video services, high value private line service etc. In this
document, redundancy protection is applied to point-to-point service.
The mechanism for point-to-multipoint service stays out of the scope
of this document.
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 Segment Routing capabilities to support the
redundancy protection in an SRv6 environment, including the
definitions of two new Segments, meta data encapsulation, and a
variation of Segment Routing Policy.
2. Terminology
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Terminology and Conventions
SR: Segment Routing
URLLC: Ultra-Reliable Low-Latency Communication
VR: Virtual Reality
Red node: Redundancy node
Mer node: Merging node
FID: Flow IDentification
Geng, et al. Expires 19 August 2022 [Page 3]
Internet-Draft SRv6 for Redundancy Protection February 2022
SN: Sequence Number
3. Redundancy Protection in Segment Routing Scenario
| |
|<--------------- SRv6 Domain ---------------->|
| |
| +-----+ |
| +-----+ R3 +-----+ |
| | +-----+ | |
+-----+ +--+--+ +--+--+ +-----+
-------+ R1 +--------+ Red | | Mer +-------+ R2 +-------
+-----+ +--+--+ +--+--+ +-----+
| +-----+ |
+------+ R4 +-----+
+-----+
Figure 1: Example Scenario of Redundancy Protection in SRv6 Domain
This figure shows an example of redundancy protection used in SRv6
domain. R1, R2, R3, R4, Red and Mer are SR-capable nodes. When a
flow is sent into SRv6 domain, the process is:
1) R1 receives the traffic flow and encapsulates packets with a list
of segments destined to R2, which is instantiated as an ordered list
of SRv6 SIDs.
2) When the packet flow arrives at Red node, known as Redundancy
node, each packet is replicated into two or more copies. Each copy
of the packet is encapsulated with a new segment list, which
represents different disjoint forwarding paths.
3) Meta data information such as flow identification (FID) and
sequence number (SN) is used to facilitate the packet elimination on
Merging node (Mer). Flow identification identifies the specific
flow, and sequence number distinguishes the packet sequence of a
flow. Meta data is either carried in the packet before it arrives at
redundancy node, or added to each of the replicas at redundancy node.
4) The multiple replicas go through different paths until the Mer
node, known as Merging node. The first received copy of each flow
packet is transmitted from Merging node to R2, and the redundant
packets are eliminated.
5) When there is any failures or packet loss in one path, the service
transmission continues through the other path non-disruptively.
Geng, et al. Expires 19 August 2022 [Page 4]
Internet-Draft SRv6 for Redundancy Protection February 2022
6) Sometimes, out-of-order packets may occur since service packets
are recovered from different forwarding paths. In this case, the
merging node or other network nodes behind merging node is desired to
include a reordering function, which is implementation specific and
out of the scope of this document.
In this example, service protection is supported by utilizing two
packet flows transmitted over two forwarding paths. It is noted that
there is no limitation of the number of replicas. For a
unidirectional flow, Red node supports replication function, and Mer
node supports elimination function. Reordering function MAY be
required in combination of elimination function on merging node. To
minimize the jitter caused by random packet loss, the disjoint paths
are recommended to have similar path forwarding delay.
4. Segment to Support Redundancy Protection
To achieve the packet replication and elimination functions,
Redundancy Segment and Merging Segment, as well as the related SRv6
Endpoint Behavior are introduced.
4.1. Redundancy Segment
Redundancy Segment is the identifier of packets which need to be
replicated on redundancy node. It is a variation of Binding SID
(BSID) to associate with a Redundancy Policy, instantiation of which
provides segment lists of different disjoint paths. Similar to the
relationship between BSID and SR Policy
[I-D.ietf-spring-segment-routing-policy], the use of Redundancy
Segment would trigger the Redundancy Policy instantiation on
redundancy node.
Redundancy Segment is associated with service instructions,
indicating the following operations:
* Steers the packet into the corresponding redundancy policy
* Encapsulates flow identification and sequence number in packets if
the two information is not carried in packets
* Packet replication and segment encapsulation based on the
information of redundancy policy, e.g., the number of replication
copies, an ordered list of segments with a topological instruction
Geng, et al. Expires 19 August 2022 [Page 5]
Internet-Draft SRv6 for Redundancy Protection February 2022
In the case of SRv6, a new behavior End.R for Redundancy Segment is
defined. An instance of a redundancy SID is associated with a
redundancy policy B and a source address A. In the following
description, End.R behavior is specified in the encapsulation mode.
The End.R behavior in the insertion mode is for further study.
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:
S01. When an SRH is processed {
S02. If (Segments Left>0) {
S03. Decrement IPv6 Hop Limit by 1
S04. Decrement Segments Left by 1
S05. Update IPv6 DA with Segment List[Segments Left]
S06. Add flow identification and sequence number if indicated*
S07. Duplicate the packets (as number of active SID lists in B)
S08. Push the new IPv6 headers to each replica. The IPv6 header
contains an SRH with the SID list in B
S09. Set the outer IPv6 SA to A
S10. Set the outer IPv6 DA to the first SID of new SRH SL
S11. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit and Next-Header fields
S12. Submit the packet to the egress IPv6 FIB lookup
for transmission to the new destination
S13. }
S14. }
* Adding flow identification and sequence number is an optional behavior
for Redundancy Segment. The instruction execution is determined and
explicitly indicated by SR policy or Segment itself.
4.2. Merging Segment
Merging Segment is associated with service instructions, indicates
the following operations:
* Packet merging and elimination: forward the first received packets
and eliminate the redundant packets
In order to eliminate the redundant packet of a flow, merging node
utilizes sequence number to evaluate the redundant status of a
packet. Note that implementation specific mechanism could be applied
to control the amount of state monitored on sequence number, so that
system memory usage can be limited at a reasonable level.
As merging node needs to maintain the state of flows, a centralized
controller should have a knowledge of merging nodes capability, and
never provision the redundancy policy to redundancy node when the
Geng, et al. Expires 19 August 2022 [Page 6]
Internet-Draft SRv6 for Redundancy Protection February 2022
computation result goes beyond the flow recovery capability of
merging node. The capability advertisement of merging node will be
specified separately elsewhere, which is not within the scope of this
document.
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> or ==0) {
S03. Acquire the sequence number of received packet and
look it up in table
S04. If (this sequence number does not exist in the table) {
S05. Store this sequence number in table
S06. Remove the outer IPv6+SRH header
S07. Decrement IPv6 Hop Limit by 1 in inner SRH
S08. Decrement Segments Left by 1 in inner SRH
S09. Update IPv6 DA with Segment List[Segments Left] in inner SRH
S10. Submit the packet to the egress IPv6 FIB lookup and transmit
S11. }
S12. ELSE {
S13. Drop the packet
S14. }
S15. }
S16. }
5. Meta Data to Support Redundancy Protection
To support the redundancy protection function, flow identification
and sequence number are added in the packet and further used at
merging node when the merging function is executed. Flow
identification identifies one specific flow of redundancy protection,
and is usually allocated from centralized controller to SR ingress
node or redundancy node in SR network. Note that flow identification
can also be allocated and advertised by merging node. BGP, PCEP or
Netconf protocols can facilitate the advertisement and distribution
of flow identification among controller, redundancy node and merging
node. Sequence number distinguishes the packets within a flow by
specifying the order of packets. Not like the uniqueness of flow
identification to one specific flow, sequence number keeps changing
to each packet within a flow. It is RECOMMENDED to add the sequence
number in forwarding plane as performance and scalability is
required.
Geng, et al. Expires 19 August 2022 [Page 7]
Internet-Draft SRv6 for Redundancy Protection February 2022
Figure 4 suggests an encapsulation of flow identification and
sequence number in Segment Routing Header (SRH)[RFC8754] when
redundancy protection is used in SRv6 network.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag (Sequence Number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Merging Segment (Locator+Function+Arg:Flow ID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Segment List[n] (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Encapsulation of Flow Identification and Sequence Number
Since the flow identification is only used at merging node to
identify the specific flow of redundancy protection, it is
RECOMMENDED to be encapsulated in the Arguments of Merging Segment in
SRH. The length of flow identification is not limited, however in
practice it is suggested to be 16 bits.
All the duplicates of the same packet need to be tagged for
deduplication at the merging node. For this purpose, we will use a
sequence number. It is RECOMMENDED to encode the seq number in the
Tag field of the SRH, with a length of 16bits.
6. Segment Routing Policy to Support Redundancy Protection
Redundancy Policy is a variation of SR Policy to conduct the replicas
to multiple disjoint paths for redundancy protection. It extends SR
policy [I-D.ietf-spring-segment-routing-policy] to include more than
one active and parallel ordered lists of segments between redundancy
node and merging node, and all the ordered lists of segments are used
at the same time to steer each copy of flow into different disjoint
paths.
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.
Geng, et al. Expires 19 August 2022 [Page 8]
Internet-Draft SRv6 for Redundancy Protection February 2022
8. Security Considerations
TBD
9. Acknowledgements
The authors would like to thank Bruno Decraene, Ron Bonica, James
Guichard, Jeffrey Zhang, Balazs Varga for their valuable comments and
discussions.
10. References
10.1. Normative References
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-16, 28 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-16.txt>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
10.2. Informative References
[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>.
Geng, et al. Expires 19 August 2022 [Page 9]
Internet-Draft SRv6 for Redundancy Protection February 2022
Authors' Addresses
Xuesong Geng
Huawei Technologies
China
Email: gengxuesong@huawei.com
Mach(Guoyi) Chen
Huawei Technologies
China
Email: mach.chen@huawei.com
Fan Yang
Huawei Technologies
China
Email: shirley.yangfan@huawei.com
Pablo Camarillo Garvia
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Geng, et al. Expires 19 August 2022 [Page 10]