| Internet-Draft | Encapsulation of SAN Header | October 2022 |
| Ma, et al. | Expires 26 April 2023 | [Page] |
This document proposes the encapsulation of the SAN header in the IPv6 data plane to carry the SAN related information, which could be used to associate the networking and computing resources indexed by SAN ID and route and forward the service traffic accordingly.¶
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 26 April 2023.¶
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.¶
SAN ID and SAN header is designed under the SAN framework[I-D.huang-service-aware-network-framework] as a interface between user and service as well as between service and network. Client requests the service through SAN header encapsulated in user data packet header by SAN routing and forwarding network. SAN network would index SAN ID based on the corresponding networking and computing policies and resources. This document provides several scalable solutions about SAN header encapsulation to support SAN architecture in IPv6 networks.¶
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.¶
To support Service Awareness Network, it is necessary to define an IPv6 header option [RFC8200], that is the SAN Option.¶
The SAN option format is as the following format:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Opt Type=TBA1 | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SAN header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opt Type: 8-bit identifier of the type of option identifies this option as SAN Option. A new type value TBA1 for SAN option, recommended value 0x1D, the highest-order 3 bits should be set to zero-valued.¶
Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, that is, length of the SAN data.¶
SAN header: Option-Type-specific data. It carries the SAN identification. Data of this field specified in [I-D.service-identification-header-of-san].¶
The SAN service identification can be encapsulated in several locations in the IPv6 packet extension header, such as Hop-by-Hop Options Header, Destination Options Header, and Segment Routing Header, depend upon the scenarios and implementation requirements.¶
SAN header can be carried as an option in the ipv6 hop-by-hop options header. The Option Type indicates that this option is a service identification SAN Option. The SAN header can be resolved by every SAN network nodes.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Opt Type=TBA1 | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SAN header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SAN header can be carried as an option in the ipv6 destination options header. The Option Type indicates that this option is a service identification SAN Option. The SAN header can be resolved by the SAN network nodes.¶
The encapsulation format is the same as Figure 2¶
The segment routing header (SRH) and the SRH TLV is defined in [RFC8754]. The SAN header can be carried in SRH as one type of SRH TLV. When a SAN packet is sent to a SRv6 domain, according to the network service and computing service policy, the packet could be encapsulated or parsed SRv6 header, and the SAN header could be carried in the SRv6 header.¶
New SIDs defined in the future will indicate how the SAN type of SRH TLV works. The SAN header encapsulated in SRH TLV can be processed by the SAN nodes along the SRv6 path. The SAN TLV in SRH is as the following format:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBA2 | Length |D| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SAN header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: A new type value TBA2 for SAN Type, suggested value 0x1D.¶
SAN header: Carries the SAN identification. Data of this field specified in [I-D.service-identification-header-of-san].¶
IANA is requested to assign new values for the SAN Identification, one new IPv6 Header Option Type, one new SRH TLV Type, and one new Internet Protocol Numbers, as follows:¶
| Value | Description | Reference |
|---|---|---|
| TBA1 | SAN option type | [this document] |
| TBA2 | SAN Type in SRH TLV | [this document] |
TBA¶
TBA¶