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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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]