]> Encapsulation of SAN Header ZTE Corporation
China ma.liwei1@zte.com.cn
ZTE Corporation
No.50 Software Avenue Nanjing Jiangsu 210012 China zhao.detao@zte.com.cn
ZTE Corporation
No.50 Software Avenue Nanjing Jiangsu 210012 China zhou.fenlin@zte.com.cn
INT INTAREA Encapsulation of SAN Header 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.
Introduction SAN ID and SAN header is designed under the SAN 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.
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 when, and only when, they appear in all capitals, as shown here.
Terminology
  • SAN: Service Aware Network.
  • SAN ID: Service Aware Network Identification, an identification designed to indicate the fundamental and common service types.
  • SAN header: Encapsulation format of the SAN ID.
The SAN Option To support Service Awareness Network, it is necessary to define an IPv6 header option , that is the SAN Option. The SAN option format is as the following format:
The SAN Option
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 .
Encapsulation Location and Structure 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.
Encapsulation in the Hop-by-Hop Options Header 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.
SAN header in Options header
Encapsulation in the Destination Options 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
Encapsulation in the Segment Routing Header The segment routing header (SRH) and the SRH TLV is defined in . 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:
SAN type of SRH TLV
Type: A new type value TBA2 for SAN Type, suggested value 0x1D. SAN header: Carries the SAN identification. Data of this field specified in . Other fields follow the definition in the .
IANA Considerations 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]
Security Considerations TBA
Acknowledgements TBA
Normative References Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. IPv6 Segment Routing Header (SRH) Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Service Aware Network Framework ZTE Corporation ZTE Corporation Cloud has been migrating from concentrated center sites to edge nodes with responsive and agile services to the subscribers. This industry-wide trend would be reasonably expected to continue into the future which would enjoy geographically ubiquitous services. Rather than transmitting service data streams to the stable and limited service locations such as centered cloud sites, routing and forwarding network will have to adapt to the emerging scenarios where the service instances would be highly dynamic and distributed, and further more, demand more fine-grained networking policies than the current routing and forwarding scheme unaware of service SLA requirements. This proposal is to demonstrate a framework under which the above-mentioned requirements would be satisfied. Service Identification Header of Service Aware Network As the cloud and computing migrates to edges further away from the traditional centered cloud, the services residing at the distributed cloud start to be delivered in such a ubiquitous and dynamic way. That it is challenging to the ongoing routing and interconnecting scheme under which host address is the global networking identification. This draft proposes a service identification which is designed to be treated both as a service routable ID and an interface to the service requirements as well as service-associated cloud resources. Service Aware Network header is illustrated and specified.