[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                              Z. Du
Internet-Draft                                                    P. Liu
Intended status: Standards Track                                 L. Geng
Expires: September 10, 2020                                 China Mobile
                                                           March 9, 2020


                Connection-oriented Path in SRv6 Network
              draft-du-spring-connection-oriented-srv6-00

Abstract

   This document proposes a method to support connection-oriented path
   in the SRv6 network.

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 September 10, 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



Du, et al.             Expires September 10, 2020               [Page 1]


Internet-Draft      Connection-oriented Path in SRv6          March 2020


   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.  Data Plane for Connection-oriented Path . . . . . . . . . . .   3
   3.  Control Plane for Connection-oriented Path  . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   SRv6 Network Programming concept is introduced in
   [I-D.ietf-spring-srv6-network-programming] 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 [I-D.ietf-spring-srv6-network-programming], an SRv6 SID
   is defined as the format of LOC:FUNCT:ARG, where the LOC stands for a
   locater, the FUNCT stands for a function, and the ARG stands for the
   arguments of the function.  The locater 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.



Du, et al.             Expires September 10, 2020               [Page 2]


Internet-Draft      Connection-oriented Path in SRv6          March 2020


   SRv6 now shows a much 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 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
   some new functions on the node.

   The motivation to support 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 talked in this document.

2.  Data Plane for Connection-oriented Path

   Data plane for 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.

   When receiving a packet with an End.Xcopd SID S as the 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.  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.








Du, et al.             Expires September 10, 2020               [Page 3]


Internet-Draft      Connection-oriented Path in SRv6          March 2020


       _______      _______      _______      _______      _______
      | 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
                              in data plane


   Figure 1 shows an example of label switching in SRv6.  It is assumed
   that each NodeX has a locater as AX.  Node 1 sends 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 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 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 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 MPLS network defined in RFC 3209 [RFC3209].  In other words, we
   can simulate some basic functions of RSVP-TE by using SRv6 network
   programming.




Du, et al.             Expires September 10, 2020               [Page 4]


Internet-Draft      Connection-oriented Path in SRv6          March 2020


   We need to define a new End.Copc function, which can establish and
   maintain the connection-oriented 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
                           in control plane


   Figure 2 shows an example of label switching path establishment in
   SRv6.  Node 1 sends 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 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 new TLV
   in the payload.  Similar operation takes place in Node2-4.

   Node 5 will find it is the last SID after reading the new TLV in the
   payload.  It generates a label "0003", and sends back the packet.  In
   this time, the "ping" packet has an <SA, DA> pair: <A1::,



Du, et al.             Expires September 10, 2020               [Page 5]


Internet-Draft      Connection-oriented Path in SRv6          March 2020


   A4::Copc:0003>.  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 new TLV in
   the payload, 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 description
   convenience.  In fact, it should be several entries in the "My SID
   Table".

4.  IANA Considerations

   TBD.

5.  Security Considerations

   TBD.

6.  Acknowledgements

   TBD.

7.  References

7.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-12 (work in
              progress), March 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>.





Du, et al.             Expires September 10, 2020               [Page 6]


Internet-Draft      Connection-oriented Path in SRv6          March 2020


7.2.  Informative References

   [I-D.filsfils-spring-srv6-net-pgm-illustration]
              Filsfils, C., Camarillo, P., Li, Z., Matsushima, S.,
              Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
              J. Leddy, "Illustrations for SRv6 Network Programming",
              draft-filsfils-spring-srv6-net-pgm-illustration-01 (work
              in progress), August 2019.

   [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, December 2001,
              <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, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

Authors' Addresses

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

   Email: duzongpeng@foxmail.com


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

   Email: liupengyjy@chinamobile.com


   Liang Geng
   China Mobile
   No.32 XuanWuMen West Street
   Beijing  100053
   China

   Email: gengliang@chinamobile.com





Du, et al.             Expires September 10, 2020               [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/