RTGWG D. Huang Internet-Draft ZTE Corporation Intended status: Standards Track F. Yang Expires: 8 January 2025 China Mobile G. Chen China Telecom Y. Zhang China Unicom D. Dong Beijing Jiaotong University 7 July 2024 L3 Standalone Service ID Framework draft-huang-rtgwg-standalone-sid-framework-00 Abstract In the scenarios of both client to service and service to service interconnections, the host-oriented addressing mechanism turns out to be ineffective, and employment of a standalone service ID in routing network could facilitate the fine-grained interfaces of underlay networking capabilities, as well as cross connections among services residing at multiple sites. 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 8 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Huang, et al. Expires 8 January 2025 [Page 1] Internet-Draft L3 Standalone Service ID Framework July 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. L3 standalone service ID in network entities . . . . . . . . 4 4.1. Service ID for the governance system . . . . . . . . . . 4 4.2. Service ID for service points . . . . . . . . . . . . . . 5 4.2.1. Service ID for client terminal . . . . . . . . . . . 5 4.2.2. Service ID for service terminal . . . . . . . . . . . 5 4.2.3. Service ID for service Gateway . . . . . . . . . . . 5 4.2.4. Service ID for service Proxy . . . . . . . . . . . . 5 4.3. Service ID for network edge nodes . . . . . . . . . . . . 5 5. Service ID as new interfaces . . . . . . . . . . . . . . . . 5 5.1. Interface to service sites . . . . . . . . . . . . . . . 6 5.2. Interface to client terminal . . . . . . . . . . . . . . 6 5.3. Interface to underlay network capabilities . . . . . . . 6 6. Service ID for control plane . . . . . . . . . . . . . . . . 6 7. Service ID for data plane . . . . . . . . . . . . . . . . . . 7 8. Work flow . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Work flow of south-north traffic . . . . . . . . . . . . 8 8.2. Work flow of east-west traffic . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The host-oriented addressing mechanism has been running well without significant gaps, and it is also the designing philosophy of routing network to be unaware of the services. Nevertheless, the computing deployment starts migrating from centralized DCs to edge sites, thus the networking topology under which these edge service sites have been interconnected has migrates too. The magnitude of cross- connections among the service sites increases exponentially with architectural significance. The assumption that every function of an application or service would be instantiated at a single DC site would not be true because of the limited capabilities of the edge Huang, et al. Expires 8 January 2025 [Page 2] Internet-Draft L3 Standalone Service ID Framework July 2024 sites while it would be realistic to disaggregate the applications and instantiate different functions at different edge sites. The underlay routing network needs to adapt the emerging service deployment pattern and address the gaps demonstrated in [I-D.huang-rtgwg-us-standalone-sid]. An L3 standalone service ID thus is employed against the above scenarios as well as gaps. Traditional 5 tuples have been utilized to identify service flows while they could not be able to directly indicate the service itself. Particularly, both IP address and port are host-related identifications. Nonetheless, the service or fundamental networking capabilities (as a service) is always host and device independent. Therefore, L3 service ID in this proposal is designed to be a standalone entity against 5 tuples in the first place, and it would be a new architectural entity in the routing network. The framework demonstrates how L3 standalone servcie ID is positioned in routing network in terms of both functional enhancement of the existing networking entities and the new interfaces. Work flows would also be illustrated. 2. 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. 3. Terminology * SSR: Standalone Service ID-enabled Router * Service Point: service operation entity which either initiates a service request or execute the service functions. Service point could be the client terminal, CPE, server terminal and service proxy etc. * SGW: Service Gateway * SPX: Service Proxy * S-ID: standalone service ID Huang, et al. Expires 8 January 2025 [Page 3] Internet-Draft L3 Standalone Service ID Framework July 2024 4. L3 standalone service ID in network entities L3 standalone service ID is employed as an independent entity against the 5-tuples, so it could be instantiated at selected network entities to enable the enhanced routing and forwarding capabilities. The standalone service ID-enabled network framework is demonstrated in figure 1. +------------------------------------+ | Service ID governance system | +------------------+-----------------+ | | +------------------------------------v---------------------------------+ | Service ID for multi-entity | +---+-----------------+--------------------------+-----------------+---+ | | | | | | | | +---v---+ | | +---v---+ |+-----+| | | |+-----+| ||S-ID || | | ||S-ID || ||in L4|| | | ||in L4|| |+-----+| +----------v-----------+ +-----------v----------+ |+-----+| |+-----+| |+--------+ +--------+| |+--------+ +--------+| |+-----+| ||S-ID || || S-ID | | S-ID || || S-ID | | S-ID || ||S-ID || ||in L3||<->|sublayer| |sublayer||<->|sublayer| |sublayer||<->|in L3|| |+-----++ |+----^---+ +-----^--+| |+----^---+ +----^---+| |+-----+| | | | | | | | | | | | | |+-----+| |+----v---+ +-----v--+| |+----v---+ +----v---+| |+-----+| || || ||Underlay| |Underlay|| ||Underlay| |Underlay|| || || |+-----+| |+--------+ +--------+| |+--------+ +--------+| |+-----+| |Service| | SSR SSR | | SSR SSR | |Service| | Point | | ingress1 egress1 | | ingress2 egress2 | | Point | +-------+ +----------------------+ +----------------------+ +-------+ AS1 AS2 Figure 1: The standalone service ID-enabled network framework 4.1. Service ID for the governance system L3 standalone service ID is designed to indicate a selected and specified set of both fundamental networking capabilities and service types. Therefore it should be governed by a controlled system where the life cycle of service ID would be controlled and managed. Registration, publishing and subscribing among users, service and networking capability providers would be managed by the governance system. Service ID-related policies would be configured and managed Huang, et al. Expires 8 January 2025 [Page 4] Internet-Draft L3 Standalone Service ID Framework July 2024 between the governance system and the selected networking nodes. 4.2. Service ID for service points 4.2.1. Service ID for client terminal Client terminal subscribes the service ID from the governance system and labels the service traffic with the service ID, which explicitly indicates to the underlay network the service intention in terms of its specific requirements. In particular, the service ID could also be instantiated at CPE. 4.2.2. Service ID for service terminal The service terminal would terminates the service traffic flow and might initiate the next service request upon the service ID from the first service traffic flow. 4.2.3. Service ID for service Gateway Traditionally, the service gateway in the DC site always terminates the service flow and reestablish a service session as a proxy of the client terminal. However, L3 standalone service ID labeling the service traffic might remain in the user packet header (such as encapsulated in IPv6 extension header), so the service traffic could be forwarded and delivered by the service ID. 4.2.4. Service ID for service Proxy Similar to the service gateway, service proxy (such as side car in service mesh) terminates the service traffic. Nonetheless, the service ID-associated scheduling policies might be maintained at the service proxy to enable the multiple service function chain connections. 4.3. Service ID for network edge nodes When the service traffic arrives at SSR which always resides at the network edge, SSR would forward the service traffic by indexing the specified policy in terms of service ID. SSR could maintain service ID indexed policies from the service ID management and control system or initiate the forwarding policy by the first packet of the traffic as well as the service ID. 5. Service ID as new interfaces As an independent entity in layer 3 network, the service ID could be rendered as interfaces to multiple parties. Huang, et al. Expires 8 January 2025 [Page 5] Internet-Draft L3 Standalone Service ID Framework July 2024 5.1. Interface to service sites When the service ID is explicitly representative of the very service which resides in the DC site, it could be instantiated as an interface to the service-associated status, the underlay network as well as the governance system could be aware of this status information indexed by the service ID. 5.2. Interface to client terminal Client terminal accesses the service through the host address upon which the service resides, however, the underlay network could not be aware of the service simply through the host address. So the standalone service ID could be an interface for the client terminal to request the service specific routing and forwarding. Other than the URL link, the client terminal access the service specific networking service through the service ID in the service traffic. 5.3. Interface to underlay network capabilities The fundamental underlay network capabilities such as bandwidth, latency, jitter and loss could be templates which are indicated by the service ID. So the service ID in the service traffic could be interface to the underlay networking capabilities. When the service is registered from a computing site and is selected as the one that requires the service specific networking capabilities, the service ID could be an interface and index to the specified networking policies. 6. Service ID for control plane The service ID is governed and controlled to ensure the end to end service delivery. The control plane acquires the service requirements from the governance system which maintains the service profile, and accordingly tailors the networking policies for the service and renders them as the service ID-indexed policies. Moreover, the policy could be extended beyond networking (e.g. computing-aware routing policy). In the case of service traffic forwarding across multiple domains (Autonomous System) as illustrated in figure 1, the control plane might manage and control different sets of service ID in terms of different domains and ensure smooth mapping to guarantee the consistency of the service profiles. Huang, et al. Expires 8 January 2025 [Page 6] Internet-Draft L3 Standalone Service ID Framework July 2024 7. Service ID for data plane The service ID is specifically designed to label the service traffic to indicate the service type, therefore the service ID should be explicitly rendered in data plane. Particularly, the IPv6 header and extension header could be candidate home for the service ID. Balance of benefits and loss should be carefully kept in terms of the deployment models. 8. Work flow As stated in the use cases and requirements, the standalone service ID enables enhanced capabilities in both south-north and east-west traffic forwarding scenarios, two of the work flows would be demonstrated as in figure 2. +----------------------------------------------------------+ | Service ID governance-esystem | +------+------------+--------------+----------------+------+ | | | | | | | | | | +-----+----+ +-----+----+ | | | DC site1 | | DC site3 | | | +----------+ +----------+ | | | SGW/SPX | | SGW/SPX | | | +-----^----+ +----------+ | | | | | +---v--+ +------+ | | +-->| SSR1 | | SSR3 | | | | +---+--+ +------+ +-----+----+ +---+---+ | | | Terminal +-->| SSR-I +--+ | +----------+ +-------+ +---v--+ +------+ | SSR2 +-------->| SSR4 | +---^--+ +---+--+ | | +-----v----+ +----v-----+ | SGW/SPX | | SGW/SPX | +----------+ +----------+ | DC site2 | | DC site4 | +----------+ +----------+ Figure 2: work flows of south-north and east-west service traffic forwarding Huang, et al. Expires 8 January 2025 [Page 7] Internet-Draft L3 Standalone Service ID Framework July 2024 8.1. Work flow of south-north traffic The terminal acquires the service ID through subscription from the service ID governance system and encapsulates it in its L3 IPv6 header. The service traffic labeled with the service ID arrive at the ingress SSR-I which maintains the service ID specific forwarding policy, e.g. 50Mbps guaranteed VPN tunnel for the service traffic. SSR-I forwards the service traffic accordingly. In particular, when the specified service resides at both DC site1 and DC site2, SSR-I could couple the networking policy with the service site status, and forward the service traffic to the selected DC site1. 8.2. Work flow of east-west traffic The service to service interconnection would always be rendered as part of the end to end south-north service traffic forwarding. Nevertheless, the forwarding patterns as well as the specific process is distinguished from the client to service connection. The service residing at DC site 1 needs to initiate a service traffic to the second service residing at DC site2 and the end to end service process would be terminated at the third service at DC site4. From perspective of the underlay routing network, there are actually 2 different routing process between SRR1 and SRR2, SRR2 and SRR4. As the standalone service ID instantiated at the service traffic, significant forwarding performance benefits could be gained with the coordination of the service ID governance system. The service point at DC site1 renders the service ID in the traffic, and when it arrive at SRR1 which could forward the service traffic by the service ID specific policy to SRR2. The SPX of SRR2 will deliver the service traffic to the second service by the L3 service ID and maintain the service ID metadata for the next service request. After the service traffic is processed, another associated service request would be initiated and arrive at the SPX which would establish another service ID and render it in the service traffic through the metadata of the the previous service ID. SRR4 would forward the traffic as the same way as SRR2. From the perspective of the end to end application and service, a consistent and fine-grained networking guarantee enables experience and quality of service which would not be likely otherwise. 9. Security Considerations TBD. Huang, et al. Expires 8 January 2025 [Page 8] Internet-Draft L3 Standalone Service ID Framework July 2024 10. IANA Considerations TBA 11. Normative References [I-D.huang-rtgwg-us-standalone-sid] Huang, D., Liang, J., Yang, F., Zhang, Y., and D. Yang, "Use Cases-Standalone Service ID in Routing Network", Work in Progress, Internet-Draft, draft-huang-rtgwg-us- standalone-sid-01, 1 July 2024, . [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, . Authors' Addresses Daniel Huang ZTE Corporation China Email: huang.guangping@zte.com.cn Feng Yang China Mobile China Email: yangfeng@chinamobile.com Ge Chen China Telecom China Email: chengg55@chinatelecom.cn Yan Zhang China Unicom China Email: zhangy1156@chinaunicom.cn Huang, et al. Expires 8 January 2025 [Page 9] Internet-Draft L3 Standalone Service ID Framework July 2024 Dong Yang Beijing Jiaotong University China Email: dyang@bjtu.edu.cn Huang, et al. Expires 8 January 2025 [Page 10]