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



Network Working Group                                              T. Li
Internet-Draft                                                   Z. Chen
Intended status: Standards Track                     Huawei Technologies
Expires: November 16, 2020                                  May 15, 2020


                           Short SID for SRv6
                      draft-li-spring-srv6-ssid-00

Abstract

   Segment Routing enables an operator or an application to specify a
   packet processing program. When Segment Routing is applied to IPv6
   data plane, the list of IPv6 SIDs in SRH makes overhead a big
   challenge.

   This document proposes Short SID (SSID) and Short SRH (SSRH), and the
   operations with SSRH. The proposed solution tries to reduce the
   overhead of SRv6 without defining new routing header.

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.

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 November 16, 2020.







Li & Chen              Expires November 16, 2020                [Page 1]


Internet-Draft                  Short SID                       May 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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Short SID (SSID)  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Short SRH (SSRH)  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Operations with Short SRH . . . . . . . . . . . . . . . . . .   8
     5.1.  Ingress Node  . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Transit Node  . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Egress Node . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Cross-domain Operation  . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Segment Routing [RFC8402] enables an operator or an application to
   specify a packet processing program. SRv6 applies Segment Routing to
   IPv6 data plane. A new routing header for IPv6, which is called
   Segment Routing Header (SRH) [RFC8754] is defined to carry 128-bit
   SIDs.

   One big challenge for SRv6 is the overhead. We can explain why the
   overhead should not be ignored in two scenarios. The first one is
   long distance or large scale transmission such as end-to-end TE path.
   It is hard for Network Processor to process the SRv6 packet if SRH
   contains too many SIDs and the forwarding performance may be
   affected. The second one is the scenario like IoT deployment, where



Li & Chen              Expires November 16, 2020                [Page 2]


Internet-Draft                  Short SID                       May 2020


   the payload is small and the energy on the device is limited. The
   size of SRH may be bigger than the payload which may affect the pay
   load efficiency and cause extra energy consumption.

   This document proposes a short SID mechanism in order to reduce the
   overhead of SRv6 by introducing Short SID (SSID). SSID contains
   Short Node Identifier (SNID) and Short Function Identifier (SFID).
   We consider SNID and SFID as two separate objects and compress them
   separately. The mechanism defines no new routing header and can stay
   compatibility with the existing SRH.

2.  Terminology

   The definitions of the SRv6 terms, such as SRv6, SID, SRH, locator
   and function can be found in [RFC8754], [RFC8402],
   [I-D.draft-ietf-spring-srv6-network-programming].

   This document introduces the following new terms:

   SSID: Short Segment Identifier.

   SNID: Short Node Identifier.

   SFID: Short Function Identifier.

   SSRH: Short Segment Routing Header.

3.  Short SID (SSID)

   The IPv6 DA contains 16 bytes SRv6 SID and can be separated into three
   parts: locator, function, and argument. As for the argument, we
   consider it as the accessory of function. This document omits
   argument to make the description of SSID clear and simple. More
   details will be contained in the next version of this document.

   This document proposes a short SID mechanism in order to reduce the
   overhead of SRv6. We compress locator and function separately. The
   locator is compressed by abstracting common prefix which is only
   carried in DA and the remaining part is SNID. The function is
   compressed by setting the function ID allocation rules at the node
   and only carry the valid bits in the SSRH.

   Then the IPv6 DA can be separated into three parts: P-bytes common
   prefix, N-bytes SNID, and F-bytes SFID.







Li & Chen              Expires November 16, 2020                [Page 3]


Internet-Draft                  Short SID                       May 2020


           0                                       16 bytes
           +-----------------+--------+-------+--------+
           |  Common Prefix  |  SNID  | 0..0  |  SFID  |
           +-----------------+--------+-------+--------+
           |<--------Locator--------->|<---Function--->|


           0                                       16 bytes
           +-----------------+--------+--------+-------+
           |  Common Prefix  |  SNID  |  SFID  | 0..0  |
           +-----------------+--------+--------+-------+
           |<--------Locator--------->|<---Function--->|

                        Figure 1: IPv6 DA


   The definition of common prefix in this document is similar with [I-
   D.draft-li-spring-compressed-srv6-np]. The common prefix is the
   common part among SIDs in the SID list. P is calculated by comparing
   the difference of each SID with other SIDs on the SID list.

   The remaining part in locator is called SNID. That is, locator is
   consist of SNID and common prefix. In some cases common prefix can
   be the SRv6 SID block in
   [I-D.draft-ietf-spring-srv6-network-programming].

   The function part of the SRv6 SID is an opaque identification of a
   local behavior bound to the SID, which is locally defined on the node
   where it is executed. This document requires that the identifier
   value of function is defined from 1. That is, if there are three
   functions on the node, the function identifier should be: 01, 10, and
   11. F is calculated by comparing the difference of each function ID
   with other function IDs on the SID list. That is, F is the longest
   bits of the valid bits among the function IDs. Then we can get the
   F-bit SFID. In most cases, one byte is enough for coding the SFID.

   The SFID can be the last part of SRv6 SID or after the SNID. SNID
   and SFID form the SSID, which is carried in the SRH.

                   +----------+----------+
                   |   SNID   |   SFID   |
                   +----------+----------+
                   |<--------SSID------->|

                        Figure 2: SSID






Li & Chen              Expires November 16, 2020                [Page 4]


Internet-Draft                  Short SID                       May 2020


   For example, the common prefix is A::/48, the SNID is a 16 bits
   value, and the SFID is a 8 bits value. Then the SSID, which is
   carried in the SRH, is 24 bits.

        0                   6       8                     15 16 bytes
        +-------------------+-------+-----------------------+----+
        |   Common Prefix   | SNID  |          0...0        |SFID|
        +-------------------+-------+-----------------------+----+

        0                   6       8    9                   16 bytes
        +-------------------+-------+----+-----------------------+
        |   Common Prefix   | SNID  |SFID|        0...0          |
        +-------------------+-------+----+-----------------------+

                     Figure 3: 24 bits SSID in IPv6 DA


4.  Short SRH (SSRH)

   This document defines Short Segment Routing Header (SSRH) to carry
   SSID. SSRH is not a new routing header type but a segment routing
   header that is indicated by flag bit. SSRH can stay compatibility
   with the existing SRH.

       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 |  Segment Left |
      +---------------------------------------------------------------+
      |  Last Entry   |S|L|   Flags   |Pre Len|SNIDLen|SFIDLen|  Tag  |
      +---------------------------------------------------------------+
      |              Segment List[0]                  |               .
      +-------------------------------+---------------+---------------+
      .     Segment List[1]           |             ...               |
      +-------------------------------+-------------------------------+
      |           ...                               ...               |
      +-----------------------------------------------+---------------+
      |              Segment List[n]                  |
      +-----------------------------------------------+---------------+
      //                                                             //
      //      Optional Type Length Value objects (variable)          //
      //                                                             //
      +---------------------------------------------------------------+

                    Figure 4: Short Segment Routing Header


   where:



Li & Chen              Expires November 16, 2020                [Page 5]


Internet-Draft                  Short SID                       May 2020


   o  Next Header: Defined in [RFC8200]

   o  Hdr Ext Len: Defined in [RFC8200]

   o  Routing Type: 4

   o  Segment Left: Defined in [RFC8200]

   o  Last Entry: Contains the index (zero based), in the Segment List,
      of the last element of the Segment List

   o  Flags: 8 bits of flags

   0 1 2 3 4 5 6 7
   +---------------+
   |S|L|U|U|U|U|U|U|
   +---------------+


   U: Unused and for future use. Must be 0 on transmission and ignored
   on receipt.

   S: Short flag, set when the SRH carries the SSIDs.

   1: the SRH carries SSIDs, the node should conduct corresponding
   processing of SSRH.

   0: the SRH carries normal 128-bit SIDs.

   L: Length flag, set when S flag is 1 and the length of common prefix,
   SNID, and SFID is carried in the SSRH.

   1: the SSRH carries the length of common prefix, SNID, and SFID.  The
   processing of SSRH should be based on the length values.

   0: the SSRH does not carries the length of common prefix, SNID, and
   SFID.  The length values can be configured by the control plane or by
   predefined recommended values (e.g., the length of common prefix is
   48 bits, the length of SNID is 16 bits, and the length of SFID is 8
   bits).

   o  Pre Len: 4-bit unsigned integer, length of common prefix carried
      in DA.

   o  SNID Len: 4-bit unsigned integer, length of SNIDs carried in SSRH.

   o  SFID Len: 4-bit unsigned integer, length of SFIDs carried in SSRH.




Li & Chen              Expires November 16, 2020                [Page 6]


Internet-Draft                  Short SID                       May 2020


   o  Tag: 4-bit value to tag a packet as part of a class or group of
      packets, e.g., packets sharing the same set of properties. When
      Tag is not used at the source, it MUST be set to zero on
      transmission.

   o  Segment List[0...n]: a list of Short SIDs and the length of SSID
      is defined by SNID Len and SFID Len or by control plane or by
      predefined configuration.

   o  TLV: Type Length Value (TLV) is described in [RFC8754].

   This document does not define new routing type. Instead, the S-flag
   is used to indicate that the SRH contains SSID and the node should
   conduct the corresponding operations with SSRH.

   The Pre Len, SNID Len and SFID Len indicate how many bytes the common
   prefix, SNID and SFID have and enable the ingress node to use
   variable length.

   Fixed length can also be used and the SSRH does not have to carry
   length values.

   1.  The length of common prefix, SNID and SFID may be informed by
       control plane.

   2.  The length of common prefix, SNID and SFID may be configured in
       the protocol stack. 48-bit common prefix, 16-bit SNID, and 8-bit
       FID are recommended and the SSRH only need to carry 24-bit SSID.























Li & Chen              Expires November 16, 2020                [Page 7]


Internet-Draft                  Short SID                       May 2020


       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 |  Segment Left |
      +-----------------------------------------------+---------------+
      |  Last Entry   |1|0|   Flags   |            Tag                |
      +-------------------------------+---------------+---------------+
      |              Segment List[0]                  |               .
      +-------------------------------+---------------+---------------+
      .     Segment List[1]           |             ...               |
      +-------------------------------+-------------------------------+
      |           ...                               ...               |
      +-----------------------------------------------+---------------+
      |              Segment List[n]                  |
      +-----------------------------------------------+---------------+
      //                                                             //
      //      Optional Type Length Value objects (variable)          //
      //                                                             //
      +---------------------------------------------------------------+

    Figure 5: Short Segment Routing Header with length values in packet


5.  Operations with Short SRH

5.1.  Ingress Node

   The SR domain ingress router has to insert SRH to the IPv6 packet and
   if the domain supports SSRH, the S-flag should be set. If the length
   of common prefix, SNID, and SFID are based on the length value
   carried in the packet, the L-flag is set. If the length of common
   prefix, SNID, and SFID are determined by the control plane or pre-
   configuration, the L-flag is not set.

   If the length values are carried in the SSRH, the ingress router has
   to compare the SID list that steers the packet through the domain and
   calculate the length values. The common prefix is the longest common
   part (in byte) among the SID locators and the length of common prefix
   is acquired.

   There are two options to put the SFID in the SRv6 SID.

   1.  Option 1: the SFID is at the end of the SRv6 SID. There are
       consequent zero bits between locator and SFID and the length of
       locator can be acquired. Then the length of SNID can be
       calculated. The length of SFID that should be carried in the
       SSRH is the longest length among the SFIDs of the SIDs. These
       length values are written in the SSRH.



Li & Chen              Expires November 16, 2020                [Page 8]


Internet-Draft                  Short SID                       May 2020


   2.  Option 2: the SFID is after the locator of the SRv6 SID. The end
       of SRv6 SID is padded with zero bits. The SNID and the SFID
       cannot be separated clearly. The total length of SNID and SFID
       can be calculated after the length of common prefix is acquired.
       Either of the SNID Len filed or SFID Len filed can be used to
       carry the total length of SNID and SFID.

   The SSID is consist of SNID and SFID. Every SIDs in the SID list are
   compressed into SSIDs which are written in the SSRH Segment List
   successively.

5.2.  Transit Node

   The transit nodes in the SR domain have to update the IPv6 DA before
   they forward the packets. The basic SRH operations are defined in
   [RFC8754], the only difference is how to update the IPv6 DA. The
   common prefix in the DA stays unchanged along the path in the domain.
   The SNID and SFID need to be updated. The length of common prefix,
   SNID, and SFID can be acquired via in-packet value, or pre-
   configuration, or control plane.

   If the method for locating SFID in the SRv6 SID is Option 1, then the
   SNID is copied to the location after common prefix of the DA and the
   SFID is copied to the end of the DA when updating the IPv6 DA.

   If the method for locating SFID in the SRv6 SID is Option 2, then the
   SNID and the SFID are copied to the location after common prefix
   together.

5.3.  Egress Node

   No new operation is defined in this document at the egress node.

6.  Control Plane

   The length of the common prefix, SNID, and SFID can be carried in the
   packet and no control plane extension is needed. While the length
   values can also be configured by control plane. Control plane (such
   as IS-IS) extensions are required to signal the length values. The
   detailed definitions of the extension will be described in the next
   version of this document.

7.  Illustration

   As illustrated in Figure 6, nodes A - F are SRv6 enabled nodes within
   the network domain. A is the ingress router and B is the egress
   router. A packet is forwarded along the path A-B-E-F-C-D, and the
   SRv6 SID list contains the SID of E, F, and D, which is



Li & Chen              Expires November 16, 2020                [Page 9]


Internet-Draft                  Short SID                       May 2020


   [2001:DB8:B:5::1

   2001:DB8:B:6::1

   2001:DB8:B:4::2]

                              +---+      +---+
                              | E +------+ F |
                              +-+-+      +-+-+
                                |          |
                                |          |
        +---+      +---+      +-+-+      +-+-+      +---+      +---+
        |CE1+------+ A +------+ B +------+ C +------+ D +------+CE2|
        +---+      +---+      +---+      +---+      +---+      +---+

                        Figure 6: Illustration Topology


   The flag field of SRH is

   11000000

   which means SSRH is enabled and the length values are carried in the
   packet.

   The common prefix is 2001:DB8:B::/56 and the length is 7 bytes. The
   SNIDs of E, F and D are 5, 6 and 4 and the length is 1 bytes. The
   SFIDs of E, F and D are 1, 1 and 2 and the length is 1 bytes. The
   SSID in the SSRH is 2 bytes. The SSRH is

      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 |  Segment Left |
      +---------------------------------------------------------------+
      |  Last Entry   |1 1 0 0 0 0 0 0|0 1 1 1|0 0 0 1|0 0 0 1|  Tag  |
      +---------------------------------------------------------------+
      |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 1|0 0 0 0 0 1 1 0|0 0 0 0 0 0 0 1|
      +---------------------------------------------------------------+
      |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0|
      +---------------------------------------------------------------+
      //                                                             //
      //      Optional Type Length Value objects (variable)          //
      //                                                             //
      +---------------------------------------------------------------+

                     Figure 7: Illustration SSRH




Li & Chen              Expires November 16, 2020               [Page 10]


Internet-Draft                  Short SID                       May 2020


8.  Cross-domain Operation

   TBD.

9.  Security Considerations

   TBD.

10.  IANA Considerations

   IANA is requested to allocated one bit in Segment Routing Header
   Flags to indicate that the STH contains SSID and the node should
   conduct the corresponding operations with SSRH.

11.  Acknowledgements

   TBD.

12.  Normative References

   [I-D.draft-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-15 (work in
              prograss) , March 2020.

   [I-D.draft-li-spring-compressed-srv6-np]
              Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F.,
              Guichard, J., Li, C., and S. Peng, "Compressed SRv6
              Network Programming", draft-li-spring-compressed-
              SRv6-np-02 (work in prograss) , February 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>.

   [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>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Spectification", RFC 8200 , July 2017.

   [RFC8402]  Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", RFC 8402 , July 2018.




Li & Chen              Expires November 16, 2020               [Page 11]


Internet-Draft                  Short SID                       May 2020


   [RFC8754]  Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754 , March 2020.

Authors' Addresses

   Taixin Li
   Huawei Technologies
   No. 156 Beiqing Rd
   Beijing  100095
   China

   Email: litaixin@huawei.com


   Zhe Chen
   Huawei Technologies
   No. 156 Beiqing Rd
   Beijing  100095
   China

   Email: chenzhe17@huawei.com





























Li & Chen              Expires November 16, 2020               [Page 12]

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