A Retrospective on Workload Identifiers: From Data Center to Cloud-Native Networks

As applications move to multiple clouds, the network has become a reactive element to support cloud consumption and application needs. Through each generation of network architectures, identifiers and the use of dynamic locators evolved in different levels of the protocol stack. The identifiers and locators type is defined by the isolation boundary and how the architecture considers semantic overload in the IP address. Each solution is an outcome of incrementalism, resulting in application delivery outgrowing the underlying network. This paper contributes an industrial retrospective of how the schemes and mechanisms for identification and location of network entities have evolved in traditional data centers and how they match cloud-native application requirements. Specifically, there is an evaluation of each application artifact that forced necessary changes in the identifiers and locators. Finally, the common themes are highlighted from observations to determine the investigation areas that may play an essential role in the future of cloud-native networking.


I. INTRODUCTION
In today's dynamic environment, the network is under pressure to deliver connectivity and identity across multiple clouds in an agile manner. The architectural support for identifiers and locator split has solidified their role as an essential function to keep pace with application growth and flexible cloud computing models.
From a network access-control perspective, IP addresses could be viewed as identity labels for authorization in a network zone model and, in parallel, are routing instructions for networked elements to guide a packet to the destination. In each generation of network architectures, there is a realization that the IP space cannot serve two purposes of identity and location in virtualization and cloud computing environments. A technique to overcome the semantic overload of IP addresses was to split the IP space for persistent identity and dynamic location through encapsulation protocols as a point The associate editor coordinating the review of this manuscript and approving it for publication was Nitin Gupta . of indirection. However, as the new generation of cloud applications emerges, the IP space has become weak and mutable to maintain its role as a persistent identifier. For example, microservice applications heavily depend on network proxies, known as sidecars, to provide application availability and resiliency. In such network rendezvous architectures, the IP address has no lasting semantics [28]. An observation is made that the cloud-native architectures have shifted workload identifiers and created new namespaces to support service discovery, routing, and identification for applications to extend administrative boundaries.
This paper contributes to a discussion of the schemes and techniques for identifying and locating network entities that have evolved in traditional data centers and how they match cloud-native application requirements. The distinction this paper makes is that it surfaces how each application artifact forced a shift in workload identifiers required for discovery, routing, and identification, which is not so obvious in past papers from a comparison point of view. For example, the rationale behind identifiers, locators, and insertion points required for today's cloud-native networks is emphasized rather than focusing on identity and location split in its generality.
In addition, this paper contributes an increased awareness of evolved cloud application artifacts that lead to the functionality required for Service Mesh and its impact on the use of location-independent identifiers.
Finally, this paper closes by considering the discussed techniques, state-of-the-art opportunities, and directions for future investigation into the critical elements foundational to a cloud-native network.

II. LOCATION/ID SEPARATION PROTOCOL A. SEMANTIC OVERLOAD IN THE IP ADDRESS
As background, the Internet Architecture Board (IAB) workshop [43], the concerns centered around the current routing information base (RIB) size of the border gateway protocol (BGP) [50]. One of the underlying causes of routing scalability was identifier/locator overload in the IP address. Enterprises were advertising provider-independent prefixes across sites to avoid server renumbering. From a firewall point of view, the server's IP address was its identity; therefore, IP renumbering would be an operational burden.
With the current IP architecture, it seemed impossible to have a single IP space that could serve two purposes, and a split seemed necessary to scale the routing system. This conclusion was the supporting material that led to the creation of the locator/ID separation protocol (LISP) [18]. There are several other proposals to separate identifiers and locators, such as HIP [45], Mobile IP [48] and RINA [29]. To get started, this section selected LISP that addressed the workload mobility challenges traditional in data centers.
The initial technique of LISP was to provide topological aggregation, leveraging a locator approach for the IP routing system. The network's edge contains more specific details needed to reach the endpoint. Provider-independent networks resided behind LISP networks and behaved similarly to network address translation (NAT) [17]. However, in contrast to NAT, the translation state in LISP was not held in a network device but stored in the original IP packet. In LISP, the original IP packet is encapsulated with an outer IP header that contains the locator information.

B. LISP FOR VIRTUALIZED DATA CENTERS AND THE VIRTUAL MACHINE ARTIFACT
While the initial motivation of LISP was to solve a route scalability issue, it became a tool to address mobility challenges created by virtualized data centers (VDCs) [4]. VDCs refer primarily to a hosted virtualization platform, where servers are decoupled from their underlying hardware resource. This disaggregation allowed the infrastructure layer to isolate memory, CPU, and storage to each virtual machine (VM) instance managed by the hypervisor [62]. Applications within the VMs artifact remained unaware of this abstraction. As VDCs became mainstream, VM portability between physical hosts became an appealing function for disaster recovery, operations maintenance, and a method to utilize capacity in active-active data centers (DC).

C. IDENTITY AND THE IP NAMESPACE
LISP naturally addressed the VDCs needs by allowing VM migration between data centers without burdening the routing system. The insertion point of LISP was at the edge of the data center core network, where the endpoint identifiers (EIDs), in this case, VMs, are mapped to routing locations (RLOCs) at the geozone level. The VMs are not globally routable and are topologically independent from the underlying network. For example, in Figure 1 VM ''/foo'' migrates from Geo-Zone-2 to Geo-Zone-3 without disrupting the existing transport-layer session from a client in Geo-Zone-1. Through LISP control-plane notifications, Geo-Zone-1 receives a Map-Notify to inform that ''/foo's'' IP address of ''10.1.1.1''has migrated to Geo-Zone-3. The  LISP-speaking router ''A1' updates ''10.1.1.1'' entry to map to ''C4'' in Geo-Zone-3. This map and encapsulation with a dynamic approach allow the VM's identity namespace to remain preserved during the migration procedure.
In summary, LISP introduced a disjoint IP namespace, where IP is separated as an identity (i.e., EID) attribute and IP as used for location. This separated namespace technique in the data center network architecture allowed VMs to preserve their identity while taking advantage of the virtualization operational model, which proved to minimize service disruption based on its mobility usecase. LISP's mapping system introduced a new approach to providing network control at the edge of the data center. The arguments for separation of edge vs. core become an important approach for the IP routing system [30], and for providing a network insertion point to support ephemeral and mobile data center workloads.

III. NETWORK VIRTUALIZATION A. CORE VS. EDGE SPLIT
In the section above, LISP's identifier mappings are only relevant at the edge (i.e., VMs), while the core of the network is forwarding IP packets to the correct Geo-Zone (i.e., location). This architecture is similar to Multi-protocol Label Switching (MPLS) [54]. In MPLS-VPN [53], the provider core (P) is solely focused on forwarding packets based on MPLS labels, while the provider edge (PE) has specific details of the neighbor domains (i.e., identifier). This separation allowed the PE to create multiple virtualized paths, which cater to overlapping address spaces over the same physical network.

B. NETWORK VIRTUALIZATION FOR CLOUD
In the quest for a purpose-built network for a cloud computing architecture, network virtualization (NV) [36] replicated the same separation of core and edge as demonstrated in the LISP and MPLS design and solved new challenges that cloud computing created.
In the technique of Network Virtualization (NV), the network becomes a reactive element to the application and cloud needs, promulgating the hypervisor vSwitch [49] as the newly revised edge, depicted in Figure 2. This is also known as the virtual network edge (NVE) [37]. Furthermore, cloud computing forced the network architecture to create a unifying abstraction across hypervisors. In contrast to LISP and MPLS-VPN, NV introduced the dynamic creation of virtual networks, each with independent address spaces and topologies that coexist over the same physical network.
In cloud computing, self-service consumption, rapid VM provisioning, and lifecycle management are subsumed in the NV architecture. The NVE allowed tenants to dynamically create network topologies to support the virtualized applications' or VM's lifecycle state. The virtual switch (vSwitch) within the hypervisor becomes the first network control point at the edge. In an NV model, the vSwitches are programmed by a logically centralized control plane responsible for synchronizing the forwarding state across all NVEs. The controller cluster is responsible for the overall state management, including the VM location. In addition, the control plane disseminates the VM identifiers to locator mappings efficiently using an advertisement-based model.

C. IDENTITY AND THE IP NAMESPACE
In the context of NVEs, vSwitches are responsible for providing connections over IP tunnels as paths without modifications to the physical network. While there are many variations of overlays [12], [24], the industry primarily adopted the Virtual eXtensible Local Area Network (VXLAN) [40] encapsulation protocol as the de facto standard in the data center and cloud. VXLAN embeds tenant-specific identifiers for isolation to ensure packets are distinguished between tenants that cohabit on a common platform. VXLAN preserves the original IP space as the VM's identity. The encapsulation contains an outer IP space to be used as a dynamic locator known as virtual-tunnel endpoints (VTEPs), which is a routable interface bound to the hypervisor.
In summary, NV adopted an application first principle, unlike LISP, where the NVE dynamically reacts to the consumption needs of self-service clouds. Rapid VM provisioning and management of lifecycle state requires the control plane to disseminate identifiers and locator mappings to hypervisors on a need-to-know basis. Like LISP, NV created a disjoint IPv4 namespace, separating the role of identifier and locator as independent addresses. Due to the prevalence of internal network-based middleware such as firewalls, the IP address must maintain its role as the core identifier for the VM.

IV. IDENTIFIER LOCATOR ADDRESSING A. CONTAINER ARTIFACT AND THE ENTERPRISE CLOUD
There has been a great increase in the adoption of delivering applications in the format of containers [3]. It is appealing for cloud-native applications to be delivered in container-based virtulization [61] due to their efficient resource utilization and portability between cloud platforms. There are two new challenges that containers create for networking. Firstly, every container process requires a single IPv4 address, which leads to exhaustion in CIDR allocation due to the scale of processes compared to virtual machines. Secondly, the container's runtime layer is above the hypervisor, requiring a new networking control point.

B. IDENTIFIER LOCATOR ADDRESSING (ILA) NAMESPACE
To address these challenges, identifier locator addressing (ILA) [26] was proposed. Similar to NV described in the previous section, ILA is also an overlay network focused on separating core and edge networks. However, ILA differs from NV in two ways. ILA focuses on the layer above server virtualization, to which NV becomes transparent. In addition, ILA is an IPv6 overlay solution that takes advantage of a larger address space to modify the identifier, thus removing encapsulation overhead that VXLAN and LISP introduced. Its primary motivation is to support container virtualization use cases such as scheduling, task migration, and container orchestration [34], while preserving container identity.
The fundamental principles of ILA were borrowed from earlier work in the identifier-locator network protocol (ILNP) [2] and GSE (8+8) [46], which also addressed the challenges of overloaded semantics in the IP address. The ILNP approach demonstrated a way of using addressing by creating a distinction between the core routing and end systems.
While ILNP had the design properties to fit the dynamic behavior of cloud workloads, the implementation required modifications to the TCP stack to perform dynamic changing of locator bindings. ILA addressed this challenge by implementing an IPv6 [13] transformation technique that ensures the transport layer remains unmodified with an immutable 64-bit identifier and SIR prefix. There is an allocation of a /64 prefix per host representing the locator within the ILA scheme. As described in Figure 3, when a client/server session is initiated between two containers, the ILA host will perform an outside-of-process stateless IP address transformation on the higher-order 64 bits, the locator, to forward packets to the container's destination. On the receiving side, the ILA host rewrites the destination IP address from the locator prefix to the original identifier address and subsequently delivers the packet to the container application.
The control plane of this architecture disseminates identifiers and locator mappings to all ILA host routing elements. The ILA control plane is a distributed key-value store that manages mappings of identifiers to locators in a network. As tasks or containers are registered, the mappings are published to the control plane and disseminated to all ILA hosts through its push-based model, which differs from LISP pull-based model.
In summary, while the ILA solution applies creative techniques through IPv6 transformations, the administrative boundaries of this architecture assume the control of the host stacks to allow an insertion strategy to preserve the original container identifiers and modify the locator instructions within the packet. In addition, it will continue to become more challenging to preserve the end-to-end identity that IPv6 advocates across heterogeneous cloud providers as NAT, Loadbalancers, and network-based middle-ware will force identifiers higher in the protocol stack.

V. CLOUD-NATIVE SERVICE MESH A. MICROSERVICES AND SERVICE MESH
Previous sections discussed the networking challenges in cloud computing models that deployed N-Tier applications in VM or container artifacts. This section discusses the network requirements for a new generation of cloud-native applications called microservices [15]. A microservice is a collection of networked services, with each service performing a specific business function. Services are built independently from each other and delivered in the format of containers. The value is that developers can alter and upgrade the application without a full redeployment.
A single cloud-native application can be represented by thousands of services that are continually changing states. The probability of communication failure between services increases as cloud-native applications grows exponentially. Application resiliency leads to the need for a dedicated infrastructure layer handling the service-to-service communication. Service mesh [39], [41] addresses this challenge by injecting a proxy service, known as a sidecar, distributed within an application or microservice boundary. The service mesh ensures an optimal application-level response time by handling requests, retries, and timeouts, such as circuit breaking, load balancing, and traffic engineering. Each application request is routed optimally and is load-balanced without the knowledge of the application. The following sections describe the refinements of identifiers and locators, considering that an application residence is in multiple cloud platforms.

B. SERVICE MESH NAMESPACE FOR DISCOVERY AND ROUTING
The service mesh is responsible for discovering, locating, and routing between proxies to establish application connections, as depicted in Figure 4. In this example, the client ''/bar'' service requests to communicate with the server ''/foo'' service. Firstly, the client sends an HTTP [20] request to query for foo, modifying the host header field to ''Host: foo''. The service name ''/foo'' is an anycast identifier [7] mapped to multiple instances or replicas of the service. The service mesh has a selection criterion to map the service identifier to a locator. In this example, the query for ''/foo'' is based on the proximity and latency between the client and server, and therefore ''foo-1'' is matched against the Fully Qualified Domain Name (FQDN) ''foo1.example.com ''. The resolution of this FQDN is IP address ''100.1.1.1'', which is the proxy rendezvous point. Furthermore, proxy-1 sets up a TCP connection with Proxy-2. Proxy-1 modifies the HTTP host header field to ''Host: foo-1''' to connect with the foo-1 service. In this example, the HTTP host header is a namespace that shifted the unique identifier from Layer-3 to Layer-7. The namespace to distinguish services is not limited to HTTP. With HTTP/S [51], the host header is encrypted, and the server name indicator (SNI), which is an extension of the TLS protocol [16] provides the namespace to distinguish services.
These name-based techniques were borrowed from earlier work in virtual-host networking [33], where web servers were consolidated to a common platform, overloading a single IP address with multiple service aliases [38]. A client would replicate the name previously learned from the Domain Name System (DNS) [44] into the HTTP application namespace, e.g., Host header field, to provide an application demuxer beyond the network layers. The HTTP/S protocol became the vehicle for carrying names and has been widely known as a name-based routing approach [35]. Content Delivery Networks (CDNs) also adopted the name-based virtual hosting to disentangle the conventional bindings between IP addresses, the applications they represent, and the servers to which they are assigned to [19].

C. SERVICE MESH IDENTITY AND THE URI NAMESPACE
Regarding identity, It is important to note that there are three distinct layers: the platform layer, the host layer, and the process/service layer. IP addresses have been the common identifier for modeling host-to-host communication. However, the scenarios where applications span multiple clouds present three challenges to model identity at the host layer: • Workloads are ephemeral in nature, and the IP address is short-lived as an identifier.
• Workloads are deployed outside traditional administrative boundaries, such as the public cloud, which does not intersect with the internal enterprise network.
• Given that the service mesh proxies TCP connections and the network is riddled with network-based middleware boxes, the IP address becomes a weak and mutable identifier.
The objective of workload identity is to model service-toservice communication without preserving the IP address as the identifier. Applications that span administrative domains and cloud realms require identifiers to be uncoupled from the underlying infrastructure.
For cloud-native applications, the secure production identity framework for everyone (SPIFFE) addresses the workload identity challenge [58] using its naming schema independent of the discovery and routing described in this section. There are three components of SPIFFE: a specification and identifier used as a referral for a service (SPIFFE-ID), a SPIFFE Verifiable Identity Document (SVID) for embedding the SPIFFE-ID that is signed by a trusted authority, and the Workload API, which is an agent running within the cloud that provides a method of obtaining the SVID. The SPIFFE-ID is a uniform resource identifier (URI) [5] that includes the scheme ''spiffe://,'' a trust domain, and a path that specifies the name of the service. For example, the foo service is a billing system whose administrative domain is in the production environment. The identifier can be represented as the following: spiffe://production.example.com/billing/foo The SPIFFE ID is codified into an SVID, which is an extension of the x509 certificate [11], signed by an authority inside the trust domain. Within the specification, the SPIFFE ID is set to the URI type in the subject alternative name extension (SAN) [11]. Thus, each workload will have a SPIFFE bundle used for path validation against all the SVIDS that belongs to the trust domain. SVIDs allow clients and servers to gain mutual knowledge by asserting their provable cryptographic identity for mutual TLS authentication [14], [23]. As depicted in Figure 5 an X509 certificate is issued to services ''/bar'' and ''/foo''. Both services are part of the trust domain of ''production.example.com' and have a common root of trust in the PKI hierarchy [9]. Both services will undergo the verification process in this scenario and exchange their x509 certificate as their identity document for mutual TLS authentication. The trust domain within the SVID identifier allows the administrative domain the flexibility to expand outside its platform and across multiple clouds where control of identity at the IP level is harder to achieve.
In summary, in the cloud-native service mesh, IP addresses are no longer identifiers for applications, and the distinguishing factors are names. Names do not represent a host, VM, or container; they refer to services inside an application. Services are assigned a persistent name as the identifier with a flexible administrative scope, spanning multiple cloud environments and organizations. Therefore, it is essential to delineate naming systems' for identifiers and locators in the cloud-native service mesh. First, the service name is derived from the HTTP header for the discovery and locating phase, which provides a mapping to a concrete FQDN. The URI within the SVID provides the verification phase for digital identity.

VI. COMPARISONS AND FUTURE DIRECTIONS
This paper discussed how the iteration of each network architecture addressed a new set of challenges that were non-existent in the previous generation. The paper includes an observation that the application artifact and cloud consumption model forced changes in identifiers and locators at various layers of the protocol stack. Firstly, this section will summarize how the core vs. edge evolved based on the network control required to meet the cloud-native needs. After that, the paper discusses future directions and provides topical areas that may play an essential role in future cloud-native networking. Table 1 summarizes the association between the generation of the application artifact, identity controller, identifier namespace, and the network architecture insertion point. LISP and NV were the generation architectures that intersected with server virtualization. The insertion point in both approaches assumes control of the network platform and therefore takes a bottom-up approach to identifiers and locators anchored to the IP layer. In contrast to LISP, NV shifted the edge to the hypervisor, projecting an application-first architecture supporting the dynamic characteristics of enterprise cloud computing. ILA adopted similar techniques to NV by adding a layer of indirection with IPv6 to preserve the container identifier. However, the ILA edge model shifted to a layer above NV by inserting control at the container OS network namespace level.

A. COMPARISON BETWEEN DISCUSSED TECHNIQUES
The public cloud created a new challenge not present in previous approaches. LISP, NV, and ILA are approaches where the insertion point can assert identity, independent of location, as long as there is network control of the platform. However, as the public cloud infrastructure layers are hidden from consumers, it negates the ability of the network-centric approaches to provide a persistent identity at the IP layer using overlay techniques. A new generation of applications is designed to be less dependent on the underlying platform. The artifact comprises ancillary services known as a sidecar, which provides reachability and resiliency. The cloud-native service mesh addressed this challenge by creating an insertion point as distributed proxies to be the new edge. The abstractions for identity evolved to be an attribute of the application. Therefore it did not serve the purpose of structuring the IP address plan for identity and location as demonstrated in predecessor architectures. The use of naming as a point of indirection demonstrated that network flows could be distinguished in the context of the application-level session.
SPIFFE was separated into its own category with the cloud-native workload identities framework. Many application instances could represent a service in a plurality of cloud platforms. SPIFFE addresses this challenge by disseminating identifiers in the form of the URI to genuine instances of a service. The x509 document underpins the SPIFFE solution; therefore, cloud-native workloads must have a common root of trust to authenticate mutually. If two services are under different trust hierarchies, then a third-party broker is required to exchange trust bundles between authority domains for mutual authentication.
Based on the observations of the cloud-native network requirements, there are four distinct roles of naming used as identifiers: 1) Service. A public-like persona to discover and identify services needed to compose an application. 2) Locator. The core or canonicalized name and the locator identifier to resolve the IP address of the service instance. 3) Routing. An application-level identifier replicated in the application protocol namespace to distinguish network sessions over a common IP address target. 4) Identification. Verifiable identifier to provide assurance it is a genuine copy or application instance.
Using these identifiers is only possible with the strict governance of naming inside an isolation boundary. Therefore, a namespace is required to ensure the scope of discovery, identifying, and locating workloads is within the trust domain.

B. COMPARISONS WITH THE STATE-OF-THE-ART
In recent years, developers have shifted their focus to constructing and deploying microservices without considering the underlying infrastructure requirements [52]. Serverless computing is an example of this paradigm that allows developers to focus on the business logic of the application without the consideration of provisioning and scaling of the entire system. Serverless functions are seen as event-driven, which triggers a temporary execution environment only when required. Amazon Web Services (AWS) Lambda, Microsoft Azure Functions, Google Functions, and Cloudflare Workers have introduced serverless capabilities, known as Function-as-a-Service (FaaS) [8].
In the event the serverless function is called, a virtualized workload is provisioned with application files and dependencies required to execute the function and terminates after the operations are performed [25]. In most implementations, containers are used as the primary artifact for their lightweight, application process isolation, and resource provisioning [21], [31]. Although serverless was originally enabled for cloud environments, it gained traction to cement its position in edge computing [59] where computational resources are closer to the data source [1]. However, as the edge environments consist of resource-constrained devices and diverse CPU architectures, WebAssembly (Wasm) [55] has emerged as a promising artifact for future serverless support at the cloudedge [21], [22], [25], [42].
The serverless model has created new challenges in cloud-native networking that were not present in previous sections of this paper. In comparison, cloud-native service mesh provides end-to-end network control through distributed proxies. Each proxy enacts as an ambassador for each service-to-service communication, using the above four identifiers. Unlike service mesh, serverless computing offered by cloud providers does not expose the naming and addressing of the infrastructure platform [32], which thwarts the ability to bind the identifiers and locators for network control.
Irrespective of the serverless artifact type, the cloud providers only expose a publicly accessible Universal Resource Locator (URL) [6] identifier, which is used in the HTTP protocol as an access mechanism to a serverless function. The URL namespace describes the path instructions to a location of the available service. For clarity, serverless applications do not reside in a single location but are replicated globally; therefore, the same URL is also required to access multiple instantiations or replicas.
In Figure 6, the domain name portion of the URL is referred to as anycast identifier [7], which is persistent and resolves to multiple locators or IP addresses. The domain name to IP address translation is coordinated by the cloud-providers DNS-based global traffic management system (GTM) [27]. The DNS-Based GTM enacts as a geographic site-selector directing client connections to the closest serverless function [56]. This allows the URL to remain immutable, allowing the DNS to be the identity-like and public persona, returning customized answers based on the information from the client queries [10], [57].

C. FUTURE DIRECTIONS AND INVESTIGATIONS
A preview of future directions using Internet identifiers to support cloud-native services is appearing. Globally decentralized cloud-native applications rely on URLs to mimic and behave like URIs; To refer to the service independent of its location. This leads to three investigative areas to provide identifiers and the underlying infrastructure support that will play an essential role in cloud-native networks.

1) PERSISTENT IDENTIFIER
In the digital library space, the Digital Object Identifier (DOI) [47] is a persistent identifier that refers to a book or document residing in multiple locations at the same time. Analogous to a library, a cloud-native application also contains instances simultaneously running in multiple environments and locations. However, the complexity is that cloud-native applications today require four separate identifiers to be referred to and verified as the given instance. Cloud-native architectures need to adopt similar principles from the digital libraries; all application service instances should refer to as a single identifier. What an application is should be separated from where it is.
Furthermore, an investigation is also required to provide referential consistency that anchors application instances to a common identification scheme. This would comprise a directory service where the identifier could be passed between parties to provide locator mappings to cloud resources. In addition, the identifier is decorated with additional metadata such that the identifier would remain persistent. Unlike copies of books, applications evolve; therefore, providing additional metadata to adorn the query is a possible technique to obviate the need to create a new identifier.

2) IDENTITY RENDEZVOUS
The identity rendezvous provides two functions. Firstly, identity attestation to analyze credentials from all workloads to assure they are qualified application replicas or instances. Secondly, to connect and mutually authenticate between source and destination service. This approach is only possible when there is control over the workload deployment pattern, e.g., container workload and its ancillary service. When microservices are also constructed with serverless functions, it exposes new identity challenges that require the following two investigation areas. Firstly, as described in this section, cloud providers hide the interconnections of a serverless environment. It is possible to provide identity rendezvous as a sidecar or proxy as long as it is outside the providers' realm. The challenge it may create is additional network latency costs, which are worth exploring. Secondly, the execution of a serverless function has a temporary runtime environment which creates performance vs. security pressure to minimize application startup delays. In the context of the SPIFFE example, the framework assumes control of the underlying operating system of where the application is running. Since the serverless environment does not provide access, it is unclear how the attestation process will be completed to ensure the application is a genuine instance and the true owner of the identifier it passes before mutual authentication. This is usecase is not limited to serverless but future applications where only the API is exposed without access to the underlying infrastructure.

3) DISSEMINATION OF IDENTITIES
In order to construct complex applications between network and cloud realms, isolation boundaries can span multiple clouds and be created on-demand. This ensures that VOLUME 10, 2022 application instances within an isolation boundary are uniquely rooted in a common trust model. If the industry wishes to continue using a SPIFFE-like model, where the certificate chain of trust underpins the identity framework, the challenge arises when applications are not within a common isolation boundary. While federation techniques are well understood in the industry with various approaches to exchanging bundles [60], the architecture lacks a third-party identity broker to manage and distribute trust bundles for general use and on a need-to-know basis.

VII. CONCLUSION
This paper highlighted how each generation of network architectures addressed a challenge created by evolved application artifacts. It highlights that cloud-native applications have shifted identifiers from the IP layer and have become an attribute of the application layer used to distinguish workloads and provide location-independent identification schemes. In addition, this paper reviewed the current state-ofthe-art application deployment patterns and the future identifier challenges that may arise. This is an important topic that requires further investigation into three topical areas. Firstly, evaluate existing persistent identifiers in the digital space that could be applied for broader use. Regardless of location, application instantiations should be referred to as the single identifier. Secondly, the verification process, where credentials are analyzed to provide identity attestation and issuance of its imprimatur, should be consistent across any cloud and edge computing platform. Lastly, the delivery method to control and disseminate trust anchors to allow application communication between trust realms will underpin the success of a common identity system. It is hoped this retrospective of identifiers may influence the future design of identifiers and locators used in cloud-native architectures.