Internet-Draft Connection-oriented Path in SRv6 July 2022
Du & Liu Expires 6 January 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-du-spring-connection-oriented-srv6-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Du
China Mobile
P. Liu
China Mobile

Connection-oriented Path in SRv6 Network

Abstract

This document proposes a method to support connection-oriented path in the SRv6 network. Two related SRv6 Functions need to be supported on each node along the connection-oriented path.

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 RFC 2119 [RFC2119].

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 6 January 2023.

Table of Contents

1. Introduction

SRv6 Network Programming concept is introduced in [RFC8986] and [I-D.filsfils-spring-srv6-net-pgm-illustration], which enables a data plane based network programming mechanism that goes beyond mere packet routing.

According to [RFC8986], an SRv6 SID is defined as the format of LOC:FUNCT:ARG, where the LOC stands for a locator, the FUNCT stands for a function, and the ARG is optional and stands for the arguments of the function. The locator is usually used to route the packet to the node who generates the SID. The basic functions of SRv6 are End (related to a node) and End.X (related to a link/adjacency), and many other functions are also defined, including some VPN related ones and some binding SIDs. In addition, it is said that even a local VM or container which can apply any complex processing on the packet can be defined as a function. The functions may or may not include arguments.

Based on SRv6, a node in the network can initiate a SID list <SID1, SID2, SID3> for a flow, so that a packet of the flow would be routed to the first node where the function1 related to SID1 would be implemented, then be routed to the second node where function2 related to SID2 would be implemented, and trigger similar operations according to SID3.

In fact, both MPLS and SRv6 are some kind of languages that support network programming. By using a label to represent a VPN instance, MPLS provides a good support to the VPN services in the network. SRv6 now shows a more powerful capability in network programming. Perhaps in future, a lot of new network characteristics would be developed based on SRv6; meanwhile, some old network characteristics may also be realized by using SRv6 in order to integrate network protocols, and simplify the network. This document gives an example of the later.

Traditional MPLS transport is not source routing based, but is label switching based. In MPLS networks, we can establish a label switching path for a specific flow. It looks like a connection-oriented path. If using the current SRv6 mechanism, we need to initiate a SID list <SID1, SID2, SID3, ...> that includes every node along the path, which is inconvenience. This document proposes a new SRv6 mechanism to support the connection-oriented path by defining two new functions on the node.

The motivation to support the connection-oriented path in SRv6 is that sometimes a strict hop-by-hop TE path is needed in the network, such as a DetNet path defined in RFC 8655 [RFC8655]. In one realization of DetNet, each node along the path need allocate specific resources to the critical traffic, and a fixed path must be used. In future, the network may evolve to a pure SRv6 network without MPLS. In this situation, SRv6 should support some old network characteristics, such as the connection-oriented characteristic mentioned in this document.

2. Data Plane for Connection-oriented Path

Data plane for a connection-oriented path in SRv6 is easy to design. We just need to define a new End.XCopd function, which is similar to END.X (binding to a cross-connected adjacency in Layer-3), but includes a label argument. The function needs to be supported on each node along the path, and it is used to support the connection-oriented path on the data plane.

When receiving a packet with an End.XCopd SID S as the Destination Address (DA), the node will match the SID in "My SID Table" to ensure that S is generated by itself, and also check whether the label is valid. If all checks are ok, the node should be able to obtain the outgoing SID S2 in the "My SID Table". The node should replace the DA with the outgoing SID S2, and forward the packet to the layer-3 adjacency bound to the SID S.

The penultimate node along the path will find that the connection-oriented path is about to terminate, so that it will do normal End.X operations, i.e., decrement SL, update the IPv6 DA with SRH[SL], and forward the packet to the layer-3 adjacency bound to the SID.

    _______      _______      _______      _______      _______
   | Node1 |----| Node2 |----| Node3 |----| Node4 |----| Node5 |
    -------      -------      -------      -------      -------
 Node1: <A1::, A2::End.XCopd:ARG2>
 Node2:            <A1::, A3::End.XCopd:ARG3>
 Node3:                        <A1::, A4::End.XCopd:ARG4>
 Node4:                                    <A1::, A5::End.DT4>

   Figure 1: <SA, DA> changes along the Connection-oriented Path
                         on the data plane

Figure 1 shows an example of label switching in SRv6. It is assumed that each NodeX has a locator as AX. Node 1 generates a packet to Node 5 with an SRH header: <A1::End.XCopd:ARG1, A5::End.DT4> and an <SA, DA> pair: <A1::, A1::End.XCopd:ARG1>. And it is assumed that A1::End.XCopd:ARG1 can match a "switching table" entry: incoming SID A1::End.XCopd:ARG1, outgoing SID A2::End.XCopd:ARG2, and an interface binding to this End.XCopd:ARG1 function. Hence, after the process of "label switching", the Node 1 sends out a packet with an SRH header: <A1::End.XCopd:ARG1, A5::End.DT4> and an <SA, DA> pair: <A1::, A2::End.XCopd:ARG2>.

We assume that the Node 2 has a switching table entry: incoming SID A2::End.XCopd:ARG2, outgoing SID A3::End.XCopd:ARG3, and an interface binding to that End.XCopd:ARG2 function, so that the packet will be sent to Node 3, and then Node 4.

We also assume that the Node 4 has a switching table entry: incoming SID A4::End.XCopd:ARG4, outgoing SID A5::End.XCopd:0003, and an interface binding to that End.XCopd function. When the label "0003" appears, it means the node is the penultimate node. The Node 4 will do normal End.X operations, and sends out a packet without an SRH header, but with an <SA, DA> pair: <A1::, A5::End.DT4>.

The switching table should be established in advance on each node along the path, and it demonstrates the mapping relationship of the incoming SID and the outgoing SID. In the first hop of the path, it also demonstrates the mapping relationship of the first SID and the connection-oriented path. The way by which the label switching table is established on each node is described in the following section.

3. Control Plane for Connection-oriented Path

A PCE-based/controller-based method can surely configure each node along the path with a proper label switching table. However, this document also provides another optional mechanism for the distributed control plane. In fact, this method looks like what the RSVP-TE does in the MPLS network defined in RFC 3209 [RFC3209]. In other words, we can simulate some basic functions of RSVP-TE by using SRv6 network programming.

We need to define a new End.Copc function, which is used to establish and maintain the connection-oriented path in the SRv6 network. The function needs to be supported on each node along the path.

The End.Copc function also includes a label argument. Some of the label space should be reserved. In this document, we suppose that the label "0000" stands for the path establishment procedure. If a node receives a packet with an End.Copc function as the DA with a label value "0000", the node will trigger the path establishment procedure just as what the PATH message does in RSVP-TE. If a node receives a packet with an End.Copc function as the DA with a normal label value, the node will use the downstream label to establish a label switching table entry just as what the RESV message does in RSVP-TE.

However, in this way, the Head-End needs to notify each node along the path by some means, and we do not have a notification mechanism between different nodes in the data-plane network programming now. This document suggests to enable a simple notification method for the data-plane network programming if the information is not that complicated. For example, we can send a "ping" message with a specific TLV containing the necessary information. The advantage is easy to inter operate.

    _______      _______      _______      _______      _______
   | Node1 |----| Node2 |----| Node3 |----| Node4 |----| Node5 |
    -------      -------      -------      -------      -------
 Node1: <A1::, A2::End.Copc:0000> --->>
 Node2:            <A1::, A3::End.Copc:0000> --->>
 Node3:                        <A1::, A4::End.Copc:0000> --->>
 Node4:                              --->> <A1::, A5::Copc:0000>
 Node5:                              <<--- <A1::, A4::Copc:0003>
 Node4:                 <<---  <A1::, A3::End.Copc:0117>
 Node3:      <<--- <A1::, A2::End.Copc:0445>
 Node2: <A1::, A1::End.Copc:0998> <<---

   Figure 2: <SA, DA> changes along the Connection-oriented Path
                        on the control plane

Figure 2 shows an example of label switching path establishment in SRv6. Node 1 generates a "ping" packet with an <SA, DA> pair: <A1::, A1::End.Copc:0000>. A new TLV defined for "ping" would include each End.Copc functions along the path, and the TLV is supposed to be in the payload of the "ping" message. And it is assumed that A1::End.Copc:0000 can match the "My SID Table", and the DA is replaced by A2::End.Copc:0000 after the Node 1 has read the specific TLV in the payload. Then, Node 1 sends the packet to the Node2 according to the new DA. Similar operation takes place in Node2-4.

Node 5 will find it is the last SID after reading the specific TLV in the payload. It generates a label "0003", and sends back the packet, as a response packet. In this time, the "ping" packet has an <SA, DA> pair: <A1::, A4::Copc:0003>. Based on the information in the response packet, Node 4 can generate a label "0117", and establish a swapping table entry: incoming SID A4::End.XCopd:0117, outgoing SID A5::End.XCopd:0003, and an interface binding to the A4's End.XCopd function.

Similarly, the Node 3 can generate a label "0445", and establish a swapping table entry: incoming SID A3::End.XCopd:0445, outgoing SID A4::End.XCopd:0117, and an interface binding to the A3's End.XCopd function.

The Node 1 will find it is the first SID after reading the specific TLV in the payload of the "ping" message, and optionally, it can also generate a label "1111", and establish a swapping table entry: incoming SID A1::End.XCopd:1111, outgoing SID A2::End.XCopd:0998, and an interface binding to the A1's End.XCopd function.

The swapping table is used in this document for the convenience of description. In fact, it should be several entries in the "My SID Table". We can also define some label for the procedure of releasing the path in future version of the draft.

4. IANA Considerations

TBD.

5. Security Considerations

TBD.

6. Acknowledgements

TBD.

7. References

7.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.

7.2. Informative References

[I-D.filsfils-spring-srv6-net-pgm-illustration]
Filsfils, C., Garvia, P. C., Li, Z., Matsushima, S., Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and J. Leddy, "Illustrations for SRv6 Network Programming", Work in Progress, Internet-Draft, draft-filsfils-spring-srv6-net-pgm-illustration-04, , <https://www.ietf.org/archive/id/draft-filsfils-spring-srv6-net-pgm-illustration-04.txt>.
[RFC3209]
Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, , <https://www.rfc-editor.org/info/rfc3209>.
[RFC8655]
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, , <https://www.rfc-editor.org/info/rfc8655>.

Authors' Addresses

Zongpeng Du
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China
Peng Liu
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China