L3 Standalone Service ID Framework

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

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

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

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.

The standalone service ID-enabled network framework |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 ]]>

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 between the governance system and the selected networking nodes.

Service ID for service points

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.

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.

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.

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.

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.

Service ID as new interfaces As an independent entity in layer 3 network, the service ID could be rendered as interfaces to multiple parties.

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.

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.

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.

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.

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.

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.

work flows of south-north and east-west service traffic forwarding | SSR1 | | SSR3 | | | | +---+--+ +------+ +-----+----+ +---+---+ | | | Terminal +-->| SSR-I +--+ | +----------+ +-------+ +---v--+ +------+ | SSR2 +-------->| SSR4 | +---^--+ +---+--+ | | +-----v----+ +----v-----+ | SGW/SPX | | SGW/SPX | +----------+ +----------+ | DC site2 | | DC site4 | +----------+ +----------+ ]]>

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.

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.

Security Considerations TBD.

IANA Considerations TBA